Loramac : Can't join Objenious Network

[ofauchon]

Hi.

I'm trying to connect Objenious Network with a custom Kinetis KW2xd + sx1276 board. The mote (APEUID, DEVEUID, APPKEY) is declared on the Spot Objenious backoffice.

I used pkg_semtech-loramac to try to connect (without success);

main(): This is RIOT! (Version: 2016.07-devel-11754-g06f71-pr/kinetis-pm)
[semtech-loramac] initializing loramac
[sx127x] SPI_0 initialized with success
[gpio] will block power mode 0 for pin interrupt while enabled
[gpio] will block power mode 0 for pin interrupt while enabled
[gpio] will block power mode 0 for pin interrupt while enabled
[gpio] will block power mode 0 for pin interrupt while enabled
[semtech-loramac] radio: initialization successful
[semtech-loramac] set dr 0
[semtech-loramac] set adr 0
[semtech-loramac] set public network 1
[semtech-loramac] set class 0
All up, running the shell now
> loramac set appeui xxxxxxxxxxxxxxxx
> loramac set deveui yyyyyyyyyyyyyyyy
> loramac set appkey zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
> loramac join otaa
[semtech-loramac] Starting join procedure: 0
[semtech-loramac] loramac cmd msg
[semtech-loramac] starting OTAA join
[semtech-loramac] get dr
[semtech-loramac] MAC timer timeout
[semtech-loramac] MAC timer timeout
[semtech-loramac] TX timer timeout
[semtech-loramac] MAC timer timeout
[semtech-loramac] MLME confirm event
[semtech-loramac] MLME confirm msg received
[semtech-loramac] join not successful (status:2)
Join procedure failed!

Are MAC/TX timeouts 'normals' ? What's #wrong with the join process ?

Thanks Olivier Fauchon

[ofauchon]

Please note I made a second test on a rebased riot/master RIOT source tree. Same results... unable to join and MAC/tx timeouts

Is there a DEBUG flag to dump all frames actually transmitted and received by the sx1276 radio?

Then I could confirm semtech_loramac really sends packet to join the network.

Thanks.

Olivier

[aabadie]

Note that enabling debug statement in the sx127x driver can break loramac timings.

MAC Tx timeouts debug messages are normal: there's a timer used for polling the MAC state after sending a message (or a join request).

What I see is that you received something from the network but the join was not successful. Can you verify your app key deveui and appeui ? (we never know) Maybe they are expected in reverse order in the Objenious backend ?

[ofauchon]

I'll double check again appeui/appkey/deveui settings.

In the case my zone is covered with multiple Lorawan operator, which one will answer ?

Is there a network selection setting (like when choosing SSID/channel while connecting Wifi ?)

Thx

[aabadie]

In the case my zone is covered with multiple Lorawan operator, which one will answer ?

All operators will received the join requests and message sent (encrypted) but only the network server where the device belongs answers.

Is there a network selection setting ?

You can try to set the netid and maybe public parameters in the shell.

[jia200x]

You can try to set the netid and maybe public parameters in the shell.

The netid will have no effect because it's not sent in Join Request packets nor data packets.

Is it a Public or Private network? It's important to tell the node this, because the syncword will change depending of this (and then packets might not be received by the network server)

Does your network server give you any kind of logs to see if it's receiving LoRaWAN Join Requests? If yes, keys are OK but there might be a problem with the reception (sometimes this happen because of clock drift, the RX window is opened at the wrong time).

You can check if modifying this and this macros

The LORAMAC_DEFAULT_MIN_RX_SYMBOLS is the number of symbols the RX window stays open (increase it if the timer is not accurate). LORAMAC_DEFAULT_SYSTEM_MAX_RX_ERROR give some extra ms to open the RX window before the expected time. This tries to correct timer drift.

If you are using an accurate clock, try reducing LORAMAC_DEFAULT_SYSTEM_MAX_RX_ERROR to 0-20 and see if this solves your issue. You can change these variables either from the application Makefile:

...
CFLAGS += -DLORAMAC_DEFAULT_SYSTEM_MAX_RX_ERROR=20
...

or from the command line: CFLAGS=-DLORAMAC_DEFAULT_SYSTEM_MAX_RX_ERROR=20 make all flash term

[aabadie]

I compared with one working setup and my guess is that there is an issue with your hardware setup.

You get a join status of 2 (from your log), which means a TX timeout:

[semtech-loramac] TX timer timeout

On my working setup, I get "Transmission completed":

> loramac join otaa
loramac join otaa
[semtech-loramac] Starting join procedure: 0
[semtech-loramac] loramac cmd msg
[semtech-loramac] starting OTAA join
[semtech-loramac] Transmission completed
[semtech-loramac] MAC timer timeout
[semtech-loramac] MAC timer timeout
[semtech-loramac] MAC timer timeout
[semtech-loramac] MAC timer timeout
[semtech-loramac] MAC timer timeout
[semtech-loramac] MAC timer timeout
[semtech-loramac] RX started
[semtech-loramac] MLME confirm event
[semtech-loramac] MLME confirm msg received
[semtech-loramac] join succeeded
Join procedure succeeded!

Can you try with the tests/driver_sx127x application and verify 2 boards can send/receive packets ? It could also be an issue with the driver.

[ofauchon]

Hi.

Thanks to your advices and some more readings/experiments, I realized I did not wire DI0-DI3 pins. (I thougth SPI was enough and DIx pins were for extra features)

Now I receive a DIO0 interrupt meaning TX_Done / 'Transmission completed'

*** OFLMote LoRa Riot Version: git.2019.10-devel-326-g02df6 Mote Version: git. Build Date: 20190808_005859 Powersave radio sleep: 0 [semtech-loramac] initializing loramac Wait 1sec Initializing Lora Starting join procedure [semtech-loramac] Starting join procedure: 0 [semtech-loramac] loramac cmd msg [semtech-loramac] starting OTAA join [semtech-loramac] MAC timer timeout OFA: ISR DIO0 [semtech-loramac] Transmission completed [semtech-loramac] MAC timer timeout [semtech-loramac] MAC timer timeout [semtech-loramac] MAC timer timeout [semtech-loramac] MAC timer timeout [semtech-loramac] MAC timer timeout [semtech-loramac] MAC timer timeout OFA: ISR DIO1 [semtech-loramac] RX timer timeout [semtech-loramac] MAC timer timeout [semtech-loramac] MAC timer timeout OFA: ISR DIO1 [semtech-loramac] RX timer timeout [semtech-loramac] MAC timer timeout [semtech-loramac] MLME confirm event [semtech-loramac] MLME confirm msg received [semtech-loramac] join not successful Join procedure failed

But the join procedure still fails . I think I'll assemble a second board to validate simple RX/TX communications first.

Anyway, thank you very much for your help !

[aabadie]

It looks much better now. Can you also print the return code of the join request like you did in your first log ?

[ofauchon]

Starting join procedure [semtech-loramac] Starting join procedure: 0 [semtech-loramac] loramac cmd msg [semtech-loramac] starting OTAA join [semtech-loramac] MAC timer timeout OFA: ISR DIO0 [semtech-loramac] Transmission completed [semtech-loramac] MAC timer timeout [semtech-loramac] MAC timer timeout [semtech-loramac] MAC timer timeout [semtech-loramac] MAC timer timeout [semtech-loramac] MAC timer timeout [semtech-loramac] MAC timer timeout OFA: ISR DIO1 [semtech-loramac] RX timer timeout [semtech-loramac] MAC timer timeout [semtech-loramac] MAC timer timeout OFA: ISR DIO1 [semtech-loramac] RX timer timeout [semtech-loramac] MAC timer timeout [semtech-loramac] MLME confirm event [semtech-loramac] MLME confirm msg received [semtech-loramac] join not successful (status:4) Join procedure failed

=>Status 4 Maybe LORAMAC_EVENT_INFO_STATUS_RX2_TIMEOUT (semtech-loramac/src/mac/LoRaMac.h) ?

Seems I didn't received the join answer from the network during RX1 and RX2 timeslots No idea if it's a problem with radio driver , Lorawan credential or coverage.

I definitely need a local Lorawan gateway .... would you recommend a low-cost one?

Thx Olivier Fauchon

[ofauchon]

Hi.

I ran "test/driver_sx127x" on two kinetis nodes with BB-FRM9x-x 868 mhz Lora modules

** Node 1: send TEST_TX_FROM1 sending "TEST_TX_FROM1" payload (14 bytes)

DIO0 Transmission completed

** node2

listen Listen mode set

DIO0 {Payload: "TEST_TX_FROM1" (14 bytes), RSSI: 121, SNR: -15, TOA: 1450} Data reception started

=> Data is transmitted/received from/to both nodes.

I'll try to change appeui/appkey/deveui , syncwords now to see if I can connect the operator.

Olivier

[ofauchon]

Still investigating...

I'd like to verify Join frames are properly sent during "loramac join otaa" procedure:

Can you tell me If It's possible to 'sniff' join frames with on a node1 (with test/driver_sx127x and "listen" command) while trying to join the netwok on a node2 (test/pkg_semtec_loramac example and "loramac join otaa" command) ?

Of course the node1 and node2 have to be on same channel

Thanks.

Olivier

[rdagher]

@ofauchon , I experienced this issue of receiving LORAMAC_EVENT_INFO_STATUS_RX2_TIMEOUT, even when my (private) gateway accepted the join request.

I assumed that the node kinda missed the acceptation response during his RX window, and tried to rejoin afterwards but received a code status SEMTECH_LORAMAC_DUTYCYCLE_RESTRICTED. I therefore tried sleeping 5 seconds before retrying the join, and I kept receiving the same status code.

As a workaround, I ended up rebooting the node (using pm_reboot) upon join failure, and after a couple of retries the join accept was received.

My guess is that it's a timing issue that can be probably tuned as @jia200x suggested.

Roudy

[ofauchon]

Hi @rdagher,

Thanks for your feedback. I could not join (even with the reboots trick)

Now I suspect a problem with frame transmission.

On the following example, NODE 1 sends two packets (9 and 7 bytes):

> send aaaaaaaa
sending "aaaaaaaa" payload (9 bytes)
sx127x: send 9 done
> Transmission completed
channel get
Channel: 868299987
> send bbbbbbb
sending "bbbbbbb" payload (7 bytes)
sx127x: send 7 done
> Transmission completed

The recieve node only receives the second packet (7bytes)

listen
Listen mode set
> channel get
Channel: 868299987
> Data reception started
{Payload: "bbbbbbb" (7 bytes), RSSI: 139, SNR: 2, TOA: 1188}

and It's even worse when changing channels before RX/TX (Node2 never receive frames)

There is something wrong with my board+sx127x (Maybe related with LPM/xtimer) ...

Olivier

[ofauchon]

Hi !

I was suspecting "join frames" where not send during my previous tests.

It seems the semtech stack switch the radio to SLEEP before the Frames are actualy sent:

loramac join otaa
....

  sx217xWRITE (addr=00, sz=23) => 00 01 01 01 01 00 00 00 00 01 01 01 01 dd de 13 aa c9 32 55 63 a3 01 
  sx127x: send 23 done
  sx217xWRITE (addr=11, sz=1) => f7                                                                                    
  sx217xREAD (addr=40, sz=1) => 00                                                                                     
  sx217xWRITE (addr=40, sz=1) => 40                                                                                    

  [sx127x] Change state: TX                                                                                            
  [sx127x] Set op mode: TRANSMITTER                                                                                    
  sx217xREAD (addr=01, sz=1) => 89                                                                                     
  sx217xWRITE (addr=01, sz=1) => 8b                                                                                    
  [semtech-loramac] MAC timer timeout
  sx217xREAD (addr=12, sz=1) => 08 
  sx217xWRITE (addr=12, sz=1) => 08                                                                                    
  [sx127x] Change state: IDLE                                                                                          
  [sx127x] Set sleep                                                                                                   
  [sx127x] Set op mode: SLEEP                                                                                          
  sx217xREAD (addr=01, sz=1) => 89                                                                                     
  sx217xWRITE (addr=01, sz=1) => 88                                                                                    
  [sx127x] Change state: IDLE                                                                                          
  [sx127x] Set sleep   <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
  [sx127x] Set op mode: SLEEP
  sx217xREAD (addr=01, sz=1) => 88 
  sx217xWRITE (addr=01, sz=1) => 88 
  [sx127x] Change state: IDLE
  [semtech-loramac] Transmission completed
  [semtech-loramac] MAC timer timeout

So i tried to comment the sleep state change:

@@ -481,7 +483,7 @@ static int _set_state(sx127x_t *dev, netopt_state_t state)
 {
     switch (state) {
         case NETOPT_STATE_SLEEP:
-            sx127x_set_sleep(dev);
+            //OFA sx127x_set_sleep(dev);
             break;

=> And now I can sniff the "join frame" from a second board (in listen mode).

I'll try to find the problem (maybe related to timers...), and propose a fix if needed .

Olivier Fauchon

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[jia200x]

@ofauchon is this still an issue? Did you manage to join the network?

[aabadie]

I'll try to find the problem (maybe related to timers...), and propose a fix if needed .

@ofauchon were you able to fix your issue ?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.