Lora-net / radio_firmware_images

Firmware images for all flash-based Semtech products
5 stars 7 forks source link

LR1110: AU915, Only succeeds in joining lorawan network after 42 failed attempts (consistently) #5

Closed ncasaril closed 3 years ago

ncasaril commented 3 years ago

When using AU915 lr1110 only succeeds in joining network after 42 failed attempts. That is, it fails 42 times and then succeeds, and has done so for at least 3 times now from reset.

I can see that the gateways are issuing join accepts for the majority of requests so it's not a mic issue. I've also tried to change the region to EU868 and then back to AU915 before issuing join.

Could it be listening on the wrong channel for the reply?

I'll add more info here when I've done more in depth testing, i.e. which channel that eventually succeeds etc.

matthieuantoine commented 3 years ago

Hi @ncasaril - thanks for reporting!

Can you please share with us the type of gateway you are using (with the corresponding channel configuration)?

ncasaril commented 3 years ago

I'm using a Laird RG191 gw with The Things Network (TTN) AU915.

For AU915, TTN use Frequency Sub Band 2, also known as channels 8-15, or 916.8MHz through to 918.2MHz.

https://www.thethingsnetwork.org/docs/lorawan/frequency-plans/#au915-928

ncasaril commented 3 years ago

I've watched the join sequence now and logged to the best of my ability the requests and responses. The request entries with only frequency was captured using a spektrum-analyzer. The timing of these are lessa accurate as it's just me watching the spektrum and the watch.

The first log without spektrum-analyzer to pickup the out-of-bands requests:

20210531_lr1110_au915.log

Second log with spektrum-analyzer working:

20210531_lr1110_au915_2.log

In both sessions the lr1110 connected successfully on the 43rd attempt.

My main problem with this is that during development of the firmware I don't really want to wait 30min each time the lr1110 resets for a connection to be established. If there's a way to save / restore the lorawan session info or, provide the device with a channel-mask to speed up join sequence that'd be lovely!

Kind regards, Niklas

matthieuantoine commented 3 years ago

Thanks for the detailed answer!

Another information would be helpful: did you try with another gateway?

ncasaril commented 3 years ago

Yes, I've also tried with a RAK831, also configured for TTN@AU915. I just did another test with that one and got a join after 46 failed attempts.

See the TTN log below for the attempts where the lr1110 was requesting on the channels that the GW listened to. Note that the most recent message is at the top. Orange lightning is join-request, green lightning is join-accept, blue arrow is uplink.

image

image

matthieuantoine commented 3 years ago

Did you download the configuration file provided by TTN?

ncasaril commented 3 years ago

Look, the two gateways I run works well with other devices so I seriously doubt it's a config issue on my side. Note that I'm still on TTN2, not TTN3.

I've attached the global config showing you the channels used by ttn2 in au915. Also, please let me know how to set the channel mask for the lr1110, I'm sure it's in one of the memory areas :)

rak831_global_conf.json.txt

matthieuantoine commented 3 years ago

Look, the two gateways I run works well with other devices so I seriously doubt it's a config issue on my side.

I'm sure you do things the right way :-) - I just want to check the obvious first.

Thanks for the global configuration file - I'll try to reproduce the issue on my side.

ncasaril commented 3 years ago

Ping, any update on this? Were you able to reproduce?

matthieuantoine commented 3 years ago

Hi, not able to reproduce yet.

Can you please tell me if the DL channel configuration is: 923300000 / 923900000 / 924500000 / 925100000 / 925700000 / 926300000 / 926900000 / 927500000

ncasaril commented 3 years ago

Yes those numbers looks correct, from this link

AU915 Uplink:
916.8 - SF7BW125 to SF12BW125
917.0 - SF7BW125 to SF12BW125
917.2 - SF7BW125 to SF12BW125
917.4 - SF7BW125 to SF12BW125
917.6 - SF7BW125 to SF12BW125
917.8 - SF7BW125 to SF12BW125
918.0 - SF7BW125 to SF12BW125
918.2 - SF7BW125 to SF12BW125
917.5 - SF8BW500
AU915 Downlink:
923.3 - SF7BW500 to SF12BW500 (RX1)
923.9 - SF7BW500 to SF12BW500 (RX1)
924.5 - SF7BW500 to SF12BW500 (RX1)
925.1 - SF7BW500 to SF12BW500 (RX1)
925.7 - SF7BW500 to SF12BW500 (RX1)
926.3 - SF7BW500 to SF12BW500 (RX1)
926.9 - SF7BW500 to SF12BW500 (RX1)
927.5 - SF7BW500 to SF12BW500 (RX1)
923.3 - SF12BW500 (RX2)
ncasaril commented 3 years ago

This was actually a problem with the TCXO parameters for the lr1110. This could be useful for someone else coming across this problem.

The parameters that was problematic for tcxo were:

rc = lr1110_modem_system_set_tcxo_mode(dev, LR1110_MODEM_SYSTEM_TCXO_CTRL_3_3V, 1500);

With the delay set to 1500 the modem doesn't receive the join accept messages for most of the attempts. Our TXCO starts up within 2.5ms, so with a value around 80 (~startup time in us / 30.52) it works much better and the device typically joins a network with a few tries.

That is, with the below line it's working as expected:

rc = lr1110_modem_system_set_tcxo_mode(dev, LR1110_MODEM_SYSTEM_TCXO_CTRL_3_3V, 80);