Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

LoRa: No downlink receivable after sending at >=SF10 #11502

Closed
maxgerhardt opened this issue Sep 17, 2019 · 7 comments
Closed

LoRa: No downlink receivable after sending at >=SF10 #11502

maxgerhardt opened this issue Sep 17, 2019 · 7 comments
Labels
component: connectivity priority: community contribution type: bug

Comments

@maxgerhardt
Copy link
Contributor

maxgerhardt commented Sep 17, 2019 •
edited
Loading

Description

  • target: NUCLEO_L476RG
  • toolchain: GCC (7.2.1)
  • used in conjunction with the PlatformIO build system
  • mbed-os version: 5.13.4 release
  • hardware setup: NUCLEO_L476RG connected to an RFM95W (SX1276) radio (used module)

A firmware was written which does the following:

  • for all SFs from 7 to 12, do:
    • initialize the LoRaWAN stack
    • send an unconfirmed uplink message which has a LinkCheckReq MAC command attached
    • wait for the response of the LNS (LinkCheckResp) which gives the demodulation margin and number of gateways which have seen the message
    • if no answer is received, retry with at maximum 3 retries. if an answer was received, advance to the next SF

This firmware and configuration instructions can be found at https://github.com/maxgerhardt/mbedos-lorawan-no-dl-reproduction for easy reproduction.

The problem is as follows:

  • at max-sys-rx-error equal to the standard value of 5, the firmware works reliably only up to including SF9
  • with SF10, it only works very flakey (e.g. at the third retry). SF11 & SF12 do not work at all, no downlink is received

I have also discovered a forceful solution which hints at the underlying base problem: Changing the lora.max-sys-rx-error setting to 200 will make the node be able to receive downlink very, very reliably. This strongly hints at the LoRaWAN stack not calculating the correct wakeup time for the RX2 window or the microcontroller failing to wake up at the correct time. When setting the Sys RX error to 100 the firmware is only able to do SF10 and SF11, but not SF12. So it seems the larger the Sys RX error the more it can compensate for a wrongly calculated RX2 start offset.

(Note: when testing please change the value (https://github.com/maxgerhardt/mbedos-lorawan-no-dl-reproduction/blob/master/platformio.ini), this is on 200 so the firmware will work by default. Start by replacing this with the standard value of 5)

For the LNS, we tested this with both TTN and with a private LoRaServer.io instance with the same settings as TTN (most importantly: RX2 DR is DR_3 for SF9, in a EU868 setting), and the issue occurs with both LNS types. As activation method, only ABP is used.

Please note that this is supposed to be a supported target (NUCLEO_L476RG) with a standard configuration (e.g., tickless RTOS etc, though it makes no difference if tickless is disabled or if a us-timer or LPTIM is used ), a supported radio type (SX1276) and the world's most popular LNS (The Things Network in EU868). So, I'm also wondering how it can be that only I have noticed the issue or if it is a fault in my (really standard) setup.

Please find the linked firmware and tell me whether this is reproducible on your end.

Test output for sys rx error = 5:

Using dev addr 0x260112d8
Doing LoRa LinkCheck for sf = 7 retry = 0
Mbed LoRaWANStack initialized 
CONFIRMED message retries : 3 
Setting channel plan with 8 channels.
Connection - In Progress ...
Connection - Successful 
Link check OK. Demodulation margin: 17 Number of GWs: 2
TX DONE ToA: 47 channel 6 power 0 retransmissions 0
Message Sent to Network Server 
Disconnected Successfully 
Disconnected Successfully 
LoRa Connectivity Check SUCCESSFUL
LinkCheck done
Doing LoRa LinkCheck for sf = 8 retry = 0
Mbed LoRaWANStack initialized 
CONFIRMED message retries : 3 
Setting channel plan with 8 channels.
Connection - In Progress ...
Connection - Successful 
Link check OK. Demodulation margin: 21 Number of GWs: 2
TX DONE ToA: 93 channel 0 power 0 retransmissions 0
Message Sent to Network Server 
Disconnected Successfully 
Disconnected Successfully 
LoRa Connectivity Check SUCCESSFUL
LinkCheck done
Doing LoRa LinkCheck for sf = 9 retry = 0
Mbed LoRaWANStack initialized 
CONFIRMED message retries : 3 
Setting channel plan with 8 channels.
Connection - In Progress ...
Connection - Successful 
Link check OK. Demodulation margin: 24 Number of GWs: 2
TX DONE ToA: 165 channel 4 power 0 retransmissions 0
Message Sent to Network Server 
Disconnected Successfully 
Disconnected Successfully 
LoRa Connectivity Check SUCCESSFUL
LinkCheck done
Doing LoRa LinkCheck for sf = 10 retry = 0
Mbed LoRaWANStack initialized 
CONFIRMED message retries : 3 
Setting channel plan with 8 channels.
Connection - In Progress ...
Connection - Successful 
TX DONE ToA: 330 channel 2 power 0 retransmissions 0
Message Sent to Network Server 
Disconnected Successfully 
No connectivity.
Doing LoRa LinkCheck for sf = 10 retry = 1
Mbed LoRaWANStack initialized 
CONFIRMED message retries : 3 
Setting channel plan with 8 channels.
Connection - In Progress ...
Connection - Successful 
TX DONE ToA: 330 channel 3 power 0 retransmissions 0
Message Sent to Network Server 
Disconnected Successfully 
No connectivity.
Doing LoRa LinkCheck for sf = 10 retry = 2
Mbed LoRaWANStack initialized 
CONFIRMED message retries : 3 
Setting channel plan with 8 channels.
Connection - In Progress ...
Connection - Successful 
Link check OK. Demodulation margin: 22 Number of GWs: 2
TX DONE ToA: 330 channel 2 power 0 retransmissions 0
Message Sent to Network Server 
Disconnected Successfully 
Disconnected Successfully 
LoRa Connectivity Check SUCCESSFUL
LinkCheck done
Doing LoRa LinkCheck for sf = 11 retry = 0
Mbed LoRaWANStack initialized 
CONFIRMED message retries : 3 
Setting channel plan with 8 channels.
Connection - In Progress ...
Connection - Successful 
TX DONE ToA: 660 channel 7 power 0 retransmissions 0
Message Sent to Network Server 
Disconnected Successfully 
No connectivity.
Doing LoRa LinkCheck for sf = 11 retry = 1
Mbed LoRaWANStack initialized 
CONFIRMED message retries : 3 
Setting channel plan with 8 channels.
Connection - In Progress ...
Connection - Successful 
TX DONE ToA: 660 channel 1 power 0 retransmissions 0
Message Sent to Network Server 
Disconnected Successfully 
No connectivity.
Doing LoRa LinkCheck for sf = 11 retry = 2
Mbed LoRaWANStack initialized 
CONFIRMED message retries : 3 
Setting channel plan with 8 channels.
Connection - In Progress ...
Connection - Successful 
TX DONE ToA: 660 channel 5 power 0 retransmissions 0
Message Sent to Network Server 
Disconnected Successfully 
No connectivity.
LinkCheck done
Doing LoRa LinkCheck for sf = 12 retry = 0
Mbed LoRaWANStack initialized 
CONFIRMED message retries : 3 
Setting channel plan with 8 channels.
Connection - In Progress ...
Connection - Successful 
TX DONE ToA: 1156 channel 0 power 0 retransmissions 0
Message Sent to Network Server 
Disconnected Successfully 
No connectivity.
Doing LoRa LinkCheck for sf = 12 retry = 1
Mbed LoRaWANStack initialized 
CONFIRMED message retries : 3 
Setting channel plan with 8 channels.
Connection - In Progress ...
Connection - Successful 
TX DONE ToA: 1156 channel 6 power 0 retransmissions 0
Message Sent to Network Server 
Disconnected Successfully 
No connectivity.
Doing LoRa LinkCheck for sf = 12 retry = 2
Mbed LoRaWANStack initialized 
CONFIRMED message retries : 3 
Setting channel plan with 8 channels.
Connection - In Progress ...
Connection - Successful 
TX DONE ToA: 1156 channel 2 power 0 retransmissions 0
Message Sent to Network Server 
Disconnected Successfully 
No connectivity.
LinkCheck done

Test output for sys RX error = 200

Using dev addr 0x260112d8
Doing LoRa LinkCheck for sf = 7 retry = 0
Mbed LoRaWANStack initialized 
CONFIRMED message retries : 3 
Setting channel plan with 8 channels.
Connection - In Progress ...
Connection - Successful 
TX DONE ToA: 47 channel 6 power 0 retransmissions 0
Message Sent to Network Server 
Disconnected Successfully 
No connectivity.
Doing LoRa LinkCheck for sf = 7 retry = 1
Mbed LoRaWANStack initialized 
CONFIRMED message retries : 3 
Setting channel plan with 8 channels.
Connection - In Progress ...
Connection - Successful 
Link check OK. Demodulation margin: 17 Number of GWs: 2
TX DONE ToA: 47 channel 1 power 0 retransmissions 0
Message Sent to Network Server 
Disconnected Successfully 
Disconnected Successfully 
LoRa Connectivity Check SUCCESSFUL
LinkCheck done
Doing LoRa LinkCheck for sf = 8 retry = 0
Mbed LoRaWANStack initialized 
CONFIRMED message retries : 3 
Setting channel plan with 8 channels.
Connection - In Progress ...
Connection - Successful 
Link check OK. Demodulation margin: 20 Number of GWs: 2
TX DONE ToA: 93 channel 7 power 0 retransmissions 0
Message Sent to Network Server 
Disconnected Successfully 
Disconnected Successfully 
LoRa Connectivity Check SUCCESSFUL
LinkCheck done
Doing LoRa LinkCheck for sf = 9 retry = 0
Mbed LoRaWANStack initialized 
CONFIRMED message retries : 3 
Setting channel plan with 8 channels.
Connection - In Progress ...
Connection - Successful 
Link check OK. Demodulation margin: 24 Number of GWs: 2
TX DONE ToA: 165 channel 1 power 0 retransmissions 0
Message Sent to Network Server 
Disconnected Successfully 
Disconnected Successfully 
LoRa Connectivity Check SUCCESSFUL
LinkCheck done
Doing LoRa LinkCheck for sf = 10 retry = 0
Mbed LoRaWANStack initialized 
CONFIRMED message retries : 3 
Setting channel plan with 8 channels.
Connection - In Progress ...
Connection - Successful 
Link check OK. Demodulation margin: 26 Number of GWs: 2
TX DONE ToA: 330 channel 7 power 0 retransmissions 0
Message Sent to Network Server 
Disconnected Successfully 
Disconnected Successfully 
LoRa Connectivity Check SUCCESSFUL
LinkCheck done
Doing LoRa LinkCheck for sf = 11 retry = 0
Mbed LoRaWANStack initialized 
CONFIRMED message retries : 3 
Setting channel plan with 8 channels.
Connection - In Progress ...
Connection - Successful 
Link check OK. Demodulation margin: 21 Number of GWs: 2
TX DONE ToA: 660 channel 0 power 0 retransmissions 0
Message Sent to Network Server 
Disconnected Successfully 
Disconnected Successfully 
LoRa Connectivity Check SUCCESSFUL
LinkCheck done
Doing LoRa LinkCheck for sf = 12 retry = 0
Mbed LoRaWANStack initialized 
CONFIRMED message retries : 3 
Setting channel plan with 8 channels.
Connection - In Progress ...
Connection - Successful 
Link check OK. Demodulation margin: 30 Number of GWs: 2
TX DONE ToA: 1156 channel 6 power 0 retransmissions 0
Message Sent to Network Server 
Disconnected Successfully 
Disconnected Successfully 
LoRa Connectivity Check SUCCESSFUL
LinkCheck done

Issue request type

[ ] Question
[ ] Enhancement
[X] Bug
@ciarmcom
Copy link
Member

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-1772

@maxgerhardt
Copy link
Contributor Author

maxgerhardt commented Sep 26, 2019 •
edited
Loading

@ARMmbed/mbed-os-wan any insight here? I hope I made reproduction as painless as possible, let me know if there are troubles.

@maxgerhardt
Copy link
Contributor Author

Or @cmonr or @0xc0170, can you @ the correct team responsible for this please? (Or let me know if there are any issues)

@ciarmcom
Copy link
Member

This issue is on our backlog, but given our current priorities we can make no
commitment to address this in the near term.

As an open source project, we welcome fixes to Mbed OS, so we have opened this
issue up for community contribution.

If this is an issue you think you could address yourselves, then we'd welcome the
contribution. Please see our guidelines here -
https://os.mbed.com/docs/mbed-os/v5.13/contributing/workflow.html#contributions .

@chrissnow
Copy link
Contributor

@maxgerhardt Did you make any progress with this? I think we are having similar issues.

@chrissnow chrissnow mentioned this issue Mar 21, 2021
Open
@maxgerhardt
Copy link
Contributor Author

maxgerhardt commented Mar 21, 2021 •
edited
Loading

Oof, it's now been 2 years since I was dealing with that problem. If my memory isn't completely wrong, I think there was also some cross-play with another variable: Power consumption. With higher SFs, the transmission time is also longer, and thus the transmitter needs its peak energy for a longer time. This made problems with the power circuitry (bypass caps etc.) and (I'm only remembering this one extremely roughly so I could be wrong) the radio had problems being powered correctly, as well as the low-speed 32.768kHz crystal oscillator (LSE on our STM32L4 microcontroller). It had the peculiar effect that it made our crystal stop or slow down for some time, and with a slower or partially stopped crystal, the EventQueue which controls the timing inside the LoRaWAN stack, is also slowed down (comparing it to realtime), and then it would wake up later, missing the RX window when the gateway would send the actual packet.

You may try this for fun and giggles to reduce the output power by doing some driver hacking e.g. the function at https://github.com/ARMmbed/mbed-semtech-lora-rf-drivers/blob/afef18385b09c7e1e064c40379ee841c09090ad5/SX1276/SX1276_LoRaRadio.cpp#L1458-L1463 and replace power with some smaller value (I think it's around +14 (dBm) by default), like +3.

And again, the timing is closely coupled to the LSE, so if you monitor that you (either directly at oscillator or by using the master-clock-out / MCO feature of the microcontroller to output LSE divided by something on a pin) can also eliminate that as a problem source (or, switch to LSI for fun, can be done in custom_targets.json definitions).

I think someone in the project took a logic analyzer and a gateway to precisely see the timing of when the gateway's transmission started and when the microcontroller set the radio into receive mode (by toggling some GPIOs in a modified radio driver) and also found an issue with printf() delaying the receive window in some cases. I only remember this very vaguely.

In the end I think we still settled for some max-sys-rx-error that was definitely higher than 5ms. Again, at the expense of our low-power target.

All in all we had more problems with the LoRaWAN stack (some non-conformist behavior, some things that were straight out missing like good power management [the SPI peripheral is always on and adds significant sleep current]) and some things were outright so strange (like not being able to receive packets at all after some time) that we could only guard against it by force-resetting the entire mbed-os LoRaWAN stack after some amount of transmissions. In the end though, it worked out somehow with some hacks.. We'd strongly reconsider using it for our next project though.

PS: Of course the mbed-os version we were using there is now also very old, so maybe newer versions have become better?

In any case there has to be something more to it than it generally not working, if that were the case I would have expected this issue to be filled with a lot more users saying it doesn't work, and it getting at least some attention from mbed-os developers, but as can be seen from the history of this issue, nothing happened for the entire time, although I pleaded for it to be looked at. Though I'm also not suprised by that given the behavior / interaction in other issues I've filed and apparent company policy in e.g. ARMmbed/mbed-semtech-lora-rf-drivers#33. But that's a different story.

@ciarmcom
Copy link
Member

We closed this issue because it has been inactive for quite some time and we believe it to be low priority. If you think that the priority should be higher, then please reopen with your justification for increasing the priority.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
component: connectivity priority: community contribution type: bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@chrissnow @adbridge @ciarmcom @maxgerhardt