You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 20, 2020. It is now read-only.
Where I run into problems is when keeping the application alive for long periods of time. It seems as though I am not ever receiving a downlink message from the gateway. This results in my end-node eventually increasing the SF until the max and holding it there. Meanwhile the gateway is sending MAC commands requesting ADR to a lower SF. Also, eventually the AckRequested bit goes high since I haven't heard from the gateway.
I would like to be able to respond to the MAC commands from the gateway and be at the optimal DR/SF, but this doesn't seem to be working with this system as is. I noticed in your blog post that you said,"The examples work, however I would like to do some more analysis and fine tuning regarding the timing of the receive window, and I like to add more debug output to understand what is going on in the network in regards of the LoRaWAN protocol." I am just wondering if you have ideas of where I should start in debugging this issue. In the EV_TXCOMPLETE case I am checking LMIC.dataLen, but the value is always 0.
As a related question: How do people recognize that they are no longer connected to the gateway and that they should try joining again? I was considering putting a counter on the number of TX_COMPLETE with LMIC_dataLen 0 and then resetting after some number of transmissions.
The text was updated successfully, but these errors were encountered:
jtisaacs
changed the title
Problems RX when connected to LoRaWAN gateway
Problems with RX when connected to LoRaWAN gateway
Aug 2, 2019
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I have a RPi 3 and the Dragino LoRa / GPS Hat version 1.4. I am using modified version of the periodic application to connect to both TTN and Comcast MQCentral with either a Laird Sentrius RG191(https://assets.lairdtech.com/home/brandworld/files/Sentrius%20RG1xx%20User%20Guide%20v2_2.pdf) or a Comcast Area 8C (https://store.machineq.com/store/products/area-8c) gateway. In both cases I have no problem Joining with OTAA nor transmitting messages periodically as the application specifies.
Where I run into problems is when keeping the application alive for long periods of time. It seems as though I am not ever receiving a downlink message from the gateway. This results in my end-node eventually increasing the SF until the max and holding it there. Meanwhile the gateway is sending MAC commands requesting ADR to a lower SF. Also, eventually the AckRequested bit goes high since I haven't heard from the gateway.
I would like to be able to respond to the MAC commands from the gateway and be at the optimal DR/SF, but this doesn't seem to be working with this system as is. I noticed in your blog post that you said,"The examples work, however I would like to do some more analysis and fine tuning regarding the timing of the receive window, and I like to add more debug output to understand what is going on in the network in regards of the LoRaWAN protocol." I am just wondering if you have ideas of where I should start in debugging this issue. In the EV_TXCOMPLETE case I am checking LMIC.dataLen, but the value is always 0.
As a related question: How do people recognize that they are no longer connected to the gateway and that they should try joining again? I was considering putting a counter on the number of TX_COMPLETE with LMIC_dataLen 0 and then resetting after some number of transmissions.
The text was updated successfully, but these errors were encountered: