Cannot join, RX issues

[JF002]

Hello!

I'm currently trying to port LoRaMac to the Pine64 PineDio LoRa USB adapter. This is basically a board with a SX1262 and a CH341 USB to SPI converter.

So I implemented the RTC, SPI, GPIO,... porting layers and adapted them to the desktop PC environment. Now, I'm trying to run the LoRaMac "periodic-uplink-lpp" demo application. I'm using the TTN network.

I reached a point where my code sends the join-request message, TTN receives it and accepts it and forward the join-accept message to the gateway:

However, my application have big troubles to receive those messages : most of the time, nothing is received and sometimes, it receives a message but fails at decoding it (This check in soft-se.c fails).
I checked with my SDR device : I can see the messages sent by my USB board and the one sent by the gateway. So, the join-accept message is sent by the GW but my USB board fails to receive it properly.

As most of RX errors seem to be caused by incorrect timing for RX1/RX2 windows, I changed the code so that the SX1262 would go into RX mode indefinitely as soon as TX Done is triggered. This way, I'm pretty sure the module is listening when the gateway sends the join-accept message, with no more luck, unfortunately.

So now, I'm looking for help : do you have any idea why RX does not work properly? Is there anything I can do to debug this issue?

Thanks !

[jamesl-dm]

Have you got the IQ polarity configured correctly?

Edit: sorry, stupid question. If you've ported LoRaMac-node, it will be setting the IQ polarity correctly already. I'd double check the encryption keys are right first. And check that the actual received bytes in the JoinAccept look sane. I think they're sent unencrypted, with just that CMAC check that you linked protecting them. So if the bytes other than the CMAC look sane, it will be an encryption issue.

[JF002]

Hi, and thank you so much for answering so quickly!

I confirm I'm using the driver for the sx1262 provided by LoRaMac-node, which seems to configures the IQ polarity properly.

Regarding the encryption keys, the TTN console allows me to specify a device EUI, 'AppKey' and 'NwkKey'. I ensured that the device EUI, the AppKey and the NwkKey from the TTN console correspond to the one specified in se-identity.h. The byte order seems to be correct, as TTN would report a "MIC mismatch" error when I revert them. I left all the other keys (J_S_INT_KEY, J_S_ENC_KEY, F_NWK_S_INT_KEY and many others) from this file to their default value.

I added a few debug logs to check the data sent and received. Here is the result :

###### ===================================== ######

Application name   : periodic-uplink-lpp
Application version: 1.3.0
GitHub base version: 4.6.0

###### ===================================== ######

GpioMcuSetInterrupt()
BoardGetUniqueId()
DevEui      : 70-B3-D5-7E-D0-04-F9-F0
JoinEui     : 00-00-00-00-00-00-00-00
Pin         : 00-00-00-00

SetPayload (23 B) :  0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xf0 0xf9 0x04 0xd0 0x7e 0xd5 0xb3 0x70 0x01 0x00 0x06 0x42 0xe7 0x2b 

###### =========== MLME-Request ============ ######
######               MLME_JOIN               ######
###### ===================================== ######
IRQ : 1
IRQ : 4
IRQ : 16
OnRxDone IRQ (33 B, rssi = -34, snr = 11) :  0x00 0xca 0xf3 0xdf 0x7b 0xc8 0x69 0xdf 0xb1 0xfa 0x01 0xd2 0xce 0x03 0xe6 0x94 0x19 0x54 0xa9 0x41 0x73 0x29 0xdf 0x57 0xfe 0x90 0x19 0x30 0x8f 0xc8 0xbc 0x86 0x3e 

EepromMcuWriteBuffer()
EepromMcuWriteBuffer()
EepromMcuWriteBuffer()
EepromMcuWriteBuffer()
EepromMcuWriteBuffer()
EepromMcuWriteBuffer()

SetPayload (23 B) :  0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xf0 0xf9 0x04 0xd0 0x7e 0xd5 0xb3 0x70 0x02 0x00 0xf8 0xed 0x98 0x37 

###### =========== MLME-Request ============ ######
######               MLME_JOIN               ######
###### ===================================== ######
IRQ : 1
IRQ : 4
IRQ : 16
IRQ : 2
OnRxDone IRQ (33 B, rssi = -35, snr = 9) :  0x20 0xc4 0x7c 0x4f 0x76 0xcf 0xd5 0x04 0x4d 0x3c 0x3b 0x23 0x09 0x05 0x2c 0x94 0x12 0x8d 0x52 0x93 0xce 0x43 0x86 0x1d 0x36 0x6a 0x99 0xbc 0xb7 0x2d 0xfe 0xec 0x3d 


###### =========== MLME-Confirm ============ ######
STATUS      : Join failed

• I added the log SetPlayload() in https://github.com/Lora-net/LoRaMac-node/blob/master/src/radio/sx126x/sx126x.c#L145
• IRQ : in https://github.com/Lora-net/LoRaMac-node/blob/master/src/radio/sx126x/radio.c#L1258
• OnRxDone IRQ in https://github.com/Lora-net/LoRaMac-node/blob/master/src/radio/sx126x/radio.c#L1316

I've just noticed that the first time it attempts to join the network, the function EepromMcuWriteBuffer() is called and then the join procedure is started again without error. The 2nd time, the join request fails.

I don't know how to check that the data sent and received are sane. Could you link me to resources so I can learn to understand the content of the packets?

Thanks again for your help 👍

[jamesl-dm]

Yeah that looks very suspicous.

received  : 60 12711a0b 90 0000 30 f575f3a0848e6471fbe92c602dd6b40876f01b12c687015322c65b6d596ec1d2f04a2781aa0b 7f28ae05
correct   : 60 12617a01 b0 0000 00 fd71f3b0e7c26478ebea26e06dc68782b4f81b71098f01531200ca6c595d07d0fa4a74849e9b 7f1a8e4d
difference: 00 0010600a 20 0000 30 08040010634c000910030a804010338ac2080063cf08000030c691010033c6020a0053053490 00322048

If these were different packets, the last two fields would be random. But they differ in less than a quarter of their bits - so strongly correlated. Since your test program was getting the right values, let's assume the SPI communications are OK.

The next thing I would suspect is the crystal. Is it a crystal, not a TCXO? You could try running the test under a fast fan, to keep the temperature as constant as possible, and you could try using the lowest transmit power to reduce heat generation.

In the test against the network, you transmit and then receive. While the transmitter is running, the SX1262 is going to heat up a bit, and the crystal next to it will heat up a bit and shift frequency. Then when it starts receiving, the crystal will be cooling down. It generates the most heat, and is the most sensitive to heat, at SF12, which you're using in the network test. It's well known that you can run into issues using a crystal instead of a TCXO at SF12, unless you're careful with the thermal design. But most devices use a TCXO. If your adapter IS using a TCXO, check that the TCXO voltage is configured correctly.

[JF002]

I don't really know if the board uses a crystal of a TCXO. Can we deduce that from the schematics?
I did a few tests with a fan blowing on the board, with not much success, unfortunately :/
Is it possible to configure LoRaMAC to use another SF than SF12 by default?

I'll do a few SPI check (read/write in the payload buffer) to ensure that SPI communication is reliable.

[jamesl-dm]

Yeah it looks like it's just a crystal (to double check, see if component MFB1 is populated - no MFB1 = no TCXO). No sure why it's marked 32.728 kHz on the schematics - should be 32 MHz. Try backing the power level off to reduce heat buildup. Also, check the center frequency is accurate, since they might have got the crystal capacitors wrong. You can do that by calibrating your SDR's ppm against a known source (ie. using Kalibrate or LTE-Cell-Scanner), then producing some continuous wave output from your pine. You should be able to see the initial offset, and some drift from heat buildup.

[jamesl-dm]

I guess it's worth putting it in ABP and setting the datarate up to SF7 as well? If you can get downlinks at SF7, but not at SF12, you can be pretty confident its a crystal problem.

[JF002]

I have a very good news! I asked my friend @lupyuen (who have already worked with LoRaMAC on other devices and who owns the same board than me) to help me diagnose this issue, and we've eventually managed to reliably connect to LoRaWAN networks (local Chirpstack instance and public TTN).
There are apparently 2 issues : the timing for the RX window that needed to be customized and the SPI driver that seems to work much better when reading the data by chunks instead of reading byte-per-byte.

Now I feel embarrassed as you've already mention those as possible cause of my issues and I couldn't find any problem around them... Sorry about that!

You'll find the results of our experiments here. The code is quite messy and needs to be cleaned and improved, but I'm already very happy we managed to connect to LoRaWAN networks using this USB adapter!

Thank you very much for you help, time and patience!

[MedadRufus]

If you are concerned about timing accuracy for the RX window, set the LmHandlerSetSystemMaxRxError(20); to something larger, like 500 milliseconds, as I have done in this pull request:
ImperialSpaceSociety@cf4cf9a#diff-169f8b670ece097ea0c2244bdcbc2c51a64fbb68473609a83c58f39516d37141R262

This is the safest way to handle timing inaccuracies without potentially breaking code changes.

[JF002]

Thanks, good idea. I'll give it a shot!

[MedadRufus]

Also, have you gotten loramac node and your new credentials working on one of the project's supported boards? It will allow you to narrow down your problems.

[JF002]

I do not have any device supported by LoRaMAC on hands. However, I've already managed to connect a PyCom LOPY board and a TTGO TTNMapper device to my TTN account.