Error: Start Host Application during the GNSS Assisted Scan
Closed this issue · 7 comments
We have updated LR1110 EVK to Modem-E and flashed the EVK with LR1110 EVK Demo application. The firmware version files used are as follow:
- Python Host App Software Package : lr1110evk-2.1.0.tar.gz
- LR1110 Modem Updater File : lr1110_updater_tool_v1.1.0_modem_v1.0.7.bin
- LR1110 EVK Demo Application : lr1110_evk_demo_app_v2.1.0.bin
While working with the demo application we found some uncertainty in the functionality. During the entire process the device isn’t connected to the LoRaWAN network server.
We performed a WiFi Scan and sent the result to the host application and got location information. In a similar way, we performed GNSS autonomous scan and got location info. After setting the assist locations performed GNSS assisted scan, it was showing an error message “Error Start host application” and in the host application it was showing “Almanac is too old! (>31 days)
We have updated the almanac and performed the same scans again. While sending the results it shows “Added to stream, See application server” for WiFi and GNSS autonomous scans and “Error Start host application” for GNSS assisted scan on the EVK display. On host application it was showing “Error on serial reading: ''ascii' codec can't decode byte 0x80 in position 0: ordinal not in range(128)'”
Also, while trying to update the almanac for the command tool application for Modem-E (lr1110_modem_command_tool_v1.0.0.bin) we were facing the below issue. Even though we haven’t reset the board while the almanac update, it was showing the same output even after multiple tries.
Have a look at above issues and let us know the below information
- Could you suggest where we are going wrong?
- What does the below errors mean? Generally, when will we get that error?
a. Error on serial reading: ‘ ‘ascii’ codec can’t decode byte 0x84 in position 0: ordinal not in range(128)’
b. Error: Start Host Application on LR1110 EVK display during GNSS Assisted scan - Why does the Almanac update fail with modem command tool application? What are the probable reasons for that?
- If we use the lora connectivity - Wi-Fi and GNSS Autonomous scan data is added to the stream and being sent to the network server. How can we get the location details??
- Before Almanac update and after almanac update what are the changes being made?? As I am able to see the location details directly before the almanac update. But after the almanac update the scan data is being added to the stream.
Hi,
Thanks for reporting the issue.
Well, the Python Lr1110Demo software should not be used with a modem, but only with a transceiver (see in the readme). That's the reason why you get this weird behavior.
When using the modem, you must connect your device to a LoRaWAN network and use an Application Server. You can find an example of Application Server that is compatible with the EVK demo app here.
Also, concerning the AlmanacUpdate, this python software can only be used with the lr1110 evk demo app binary, and it cannot be used with the lr1110 command tool binary. That is the reason why you have the message Embedded seems connected but did not respond..
The serial reading error concerning the ASCII codec decoding failure is an exception handling coming from the python reading. It is expecting ASCII code from the USB, but sometimes (typically when the embedded the embedded resets) the serial bus sends a weird character that the python discards. And when the python discards it, it displays this message. In your case the situation seems different though as you only have non-ascii characters on the serial line.
Concerning the Wi-Fi and GNSS autonomous data, it is not sent to LoRaWAN network if the modem is not connected to a LoRaWAN network, even if the GUI says so. I suspect here that there is a bug when using the Lr1110Demo python with a modem. To have the location details with the modem, you have to connect the device to a network, and use an Application Server.
The only difference between before and after almanac update should be the update of the Almanac in the LR1110. The behavior you are observing is certainly due to a bug when using the python code with a modem.
If you want to test the LR1110 Modem, you will have to register the device on a LoRaWAN network, and use the Application Server.
I close this issue as I think the questions have been answered. For sure if there is something still unclear, don't hesitate to re-open it!
Thank you for making some things clear,
As suggested, we have installed LoRa Cloud node-red node and imported the examples modem.json and modem-e.json. We have made the following configurations and deployed the flow.
- Set assistance coordinates for GNSS autonomous scan inject node
- Set configuration for DAS server token, DAS URI and devEUIs inject nodes
- Configured the username and password for TTNV3 MQTT node
- Linked link out node of WiFi and GNSS request to the DAS parser input
- Linked link in node of parse TLV output to the DAS parser stream
After deploying the flow, TTN V3 MQTT nodes are connected. We have performed a WiFi scan and sent the results from EVK board. We observed the scan data sent as a stream file to LoRaWAN server and LoRa Cloud DAS.
But in the node-red debug terminal we could not find output of the DAS-Stream node. Apart from the direct API calls, only DAS-Data node data is observed in the debug terminal. As there is no data at DAS-Stream node, data is unavailable to the next nodes to prepare WiFi/GNSS requests.
Even after the Application layer clock synchronization data pending request is processed from the DAS server, the buttons are still un-highlighted for GNSS scan. Later we also flashed the command tool firmware, enabled the ALC sync mode and checked for the GPS time using getgpstime command, but it still shows 0 after multiple retries.
Also, In LoRa Cloud DAS server, only one request is processed after the device joins the network. Any requests that are scheduled to the EVK are queued. We tried manually sending the DM info from the command tool to process the pending requests, but the requests are not processed even after a very long time.
From the above mentioned issues, can you make the following queries clear for better understanding:
- Can you tell us where we are going wrong while performing and getting the solved results of WiFi scan ?
- If there are any references for modem-e, to perform WiFi and GNSS scan and obtain the solved result from LoRa Cloud solver, please provide us?
- How to get the ALC sync for the LR1110 modem-e device (Both Demo application & command tool application) and checkpoints to ensure that the ALC sync data is received at the device ?
- Why are the requests not processed from the DAS server? Are there any limitations in processing requests from LoRa cloud DAS server?
- How will the to and from communication between the LoRaWAN network - LoRa Cloud server while sending DM info, uplink packets, Stream/Upload info and sending requests from LoRa Cloud DAS server be ?
Can you double check that the node MQTT out in the Downlink Management section of the Node-red example is correctly configured and connected to your TTN LNS?
Also note that the GNSS or Wi-Fi results are likely to be sent with several uplinks through the Modem-E Streaming feature. The Node-Red Application Server sends these uplinks one after the other to the DAS. For each uplinks sent to the DAS, the DAS returns a DAS-Data. When the DAS has received all necessary uplinks, it will return the corresponding DAS-Stream.
Concerning the ALC sync, you must have the device registered to an LNS, and an Application Server running and connected to the LNS. Basically, when enabling the ALC sync feature, the LR1110 Modem-E device sends a specifically crafted uplink that the Application Server must provide to the DAS. Then the DAS answers with a downlink request that contains a specifically crafted payload. The Application Server then gives this payload to downlink to the LNS. The LNS eventually sends this payload to the device and its time is updated.
When the device receives the ALC sync response from the network, it raises the event Time Updated ALC Sync, and the value returned by calling the Get GPS time is different from 0.
Note that in the screenshot you provided the DAS returns the error Ignore obsolete uplink (...). This suggests that either two uplinks with fcnt equals to 1 have been transmitted to the DAS, or that the join of the device has not been transmitted to the DAS.
Could you check that the MQTT-in for your TTN-join req is correctly configured and connected to your TTN LNS?
I don't understand your last question point. What do you mean by How will the requests be ?
The LNS we are using here is The Things Enterprise Network Server.
The MQTT in and MQTT out nodes are configured properly for the examples. The Node-Red Application Server started working properly after removing the LoRa Cloud integration for the application created for LR1110 devices in the LNS. The LoRa Cloud send requests, ALC sync data are also getting processed whenever there is an uplink to LNS. We think even the error Ignore obsolete uplink (...) is due to the LoRa Cloud integration in the LNS, as we haven’t encountered this time.
After receiving the DAS-Stream for WiFi Scan request, it's showing the location in the world map as expected, but there is an error Unable to parse input as JSON string at the DAS parser node (The link out node after WiFi prepare and request output, json node is connected to the link in node of the DAS parser). This is not observed with GNSS requests. The json nodes have the same configurations as the GNSS node.
- What does the error mean here?
- And what is the use of pushing GNSS solver messages as downlink to the modem, can we use this payload in any form while building solutions?
The last question asked in the previous comment was, in case the Node-Red Application server is not used, then how and what kind of communication (i.e uplinks and downlinks from end node will be processed) will happen between LNS and LoRa Cloud server when using LoRa Cloud Integration for the LNS application.
Few queries to understand the Modem-E command tool application
- For modem-e command tool application should we use node-red application server to get the solved data by sending the WiFi/GNSS scan result as stream data using commands.
- In what cases should we use LoRa Cloud integration in the LNS?
Concerning the error Unable to parse input as JSON sting, this seems to come from the fact that at some point the DAS Parser node receives as input something that is not a string representing a JSON data.
Could you add a debug node on the input of DAS parser and copy/paste its output when the error occurs ? (Be careful to remove or hide sensitive data if there is some).
The dnlink field is documented here and contains message that must be delivered to the device.
To use the Command Tool with Node-Red Application Server example, have a look to this page that provides details about how to send data to the Application Server.
Hi Singamsettyvinay,
We suspect a bug that has been introduced with v1.2.0. On the Prepare Wi-Fi request path, the Link Out must be connected on the output of the http request but NOT on the output of the json node.
Hi mverdy,
After making the above changes as suggested, we didn't face any error while working with node-red application server. Also, referring to the command tool with Node-Red application server example reference provided by you, we have performed all the scans using command tool application and received the solved coordinated without any error.
Thank you for clearing all the queries we have.