Example-lorawan on Bluepill board

Development Networking
24

hi @aidiaz

could you check in which channels does the working setup joins the network? You should be able to see that in TTN. If it’s not a TX power issue it could be related to wrong channels (from the other picture, SNR 7 seems reasonable)

25

note compatibility is a property of the LoRaWAN implementation, not of the shield. Some RPi gateways are running single channels, but this is definitely not the case for all of them. In fact, we have some multi-channel class B setups running LoRaWAN on RPi.

26

@Wosym What I meant is that the Dragino RPi Hat shield is not meant to be a full TTN LoRaWAN gateway (as it only has 1 channel, fyi: Single-channel gateways | The Things Network), but should work as LoRaWAN end node with no prob.

27

Did a join with the working setup on ttn v3 (recently ported the gateway, hope there’s no incompatibility)

image \

As stated in the image: channel 9046000000 SF8

28

Ah yes, of course. If the shield is not a concentrator, it won’t work as a regular gateway.

29

Could you try the following experiments?

  1. Could you setup PA_BOOST? You can add this to the bluepills’s board.h:
#define SX127X_PARAM_PASELECT               (SX127X_PA_BOOST)

(see e.g boards/sensebox_samd21/include/board.h)

  1. Could you set the same PHY values you used with the working setup?
diff --git a/pkg/semtech-loramac/contrib/semtech_loramac_radio.c b/pkg/semtech-loramac/contrib/semtech_loramac_radio.c
index ea05dcb2ac..2d7b01778a 100644
--- a/pkg/semtech-loramac/contrib/semtech_loramac_radio.c
+++ b/pkg/semtech-loramac/contrib/semtech_loramac_radio.c
@@ -77,7 +77,9 @@ void SX127XSetModem(RadioModems_t modem)
 
 void SX127XSetChannel(uint32_t freq)
 {
-    loramac_netdev_ptr->driver->set(loramac_netdev_ptr, NETOPT_CHANNEL_FREQUENCY, &freq, sizeof(uint32_t));
+    (void) freq;
+    uint32_t _freq = 904600000;
+    loramac_netdev_ptr->driver->set(loramac_netdev_ptr, NETOPT_CHANNEL_FREQUENCY, &_freq, sizeof(uint32_t));
 }
 
 bool SX127XIsChannelFree(RadioModems_t modem, uint32_t freq,
@@ -111,11 +113,16 @@ void SX127XSetRxConfig(RadioModems_t modem, uint32_t bandwidth,
     (void)bandwidthAfc;
     (void)fixLen;
     (void)modem;
+    (void) bandwidth;
     uint16_t modem_val = NETDEV_TYPE_LORA;
+    (void) bandwidth;
+    (void) spreading_factor;
+    uint8_t _sf = 8;
+    uint32_t _bw = 2;
     loramac_netdev_ptr->driver->set(loramac_netdev_ptr, NETOPT_DEVICE_TYPE, &modem_val, sizeof(uint16_t));
-    loramac_netdev_ptr->driver->set(loramac_netdev_ptr, NETOPT_BANDWIDTH, &bandwidth, sizeof(uint8_t));
+    loramac_netdev_ptr->driver->set(loramac_netdev_ptr, NETOPT_BANDWIDTH, &_bw, sizeof(uint8_t));
     loramac_netdev_ptr->driver->set(loramac_netdev_ptr, NETOPT_CODING_RATE, &coding_rate, sizeof(uint8_t));
-    loramac_netdev_ptr->driver->set(loramac_netdev_ptr, NETOPT_SPREADING_FACTOR, &spreading_factor, sizeof(uint8_t));
+    loramac_netdev_ptr->driver->set(loramac_netdev_ptr, NETOPT_SPREADING_FACTOR, &_sf, sizeof(uint8_t));
     loramac_netdev_ptr->driver->set(loramac_netdev_ptr, NETOPT_PREAMBLE_LENGTH, &preambleLen, sizeof(uint16_t));
     netopt_enable_t fixed_header = NETOPT_DISABLE;
     loramac_netdev_ptr->driver->set(loramac_netdev_ptr, NETOPT_FIXED_HEADER, &fixed_header, sizeof(netopt_enable_t));
  1. We solved a similar issue once dumping all registers of the SX1276 from a working LMIC. You could try to do the same on Arduino. It should be enough to print the registers right before sending (e.g https://github.com/matthijskooijman/arduino-lmic/blob/e6061a5171f4e00e84259bb5df41cb023b3d3667/src/lmic/radio.c#L505). You can base on https://github.com/RIOT-OS/RIOT/blob/master/tests/driver_sx127x/main.c#L138

Also, do you know if that module requires GPIO to switch between TX/RX? IIRC some modules require that (see https://github.com/RIOT-OS/RIOT/blob/master/drivers/sx127x/include/sx127x_params.h#L67).

30

hi again,

I found this on the datasheet of the NiceRF:

Note: According to the design of the module, the maximum bit of register 0x09 must be set as 1. PaSelect must be set 1;

So, it sems 1. should do the trick

31

Hi @jia200x, I’ve really busy so couldn’t catch up with the updates. PA_BOOST alone didn’t fix the problem, but after play around with the examples/lorawan/main.c, the device reported Join Successful after implementing a hard join retry. Anyways, it’s a really strange behaviour. Hope to reproduce the same output soon to keep you updated.

32

I don’t remember if this was tried before, but did you try joining with DR0?

https://github.com/RIOT-OS/RIOT/issues/16419 had a similar issue and worked after joining with DR0.

33

@jia200x So I’m back working with the bluepill board and RFM95W module. By using tests/pkg_semtech_loramac with DR0 I got a successful join otaa but only after a uncountable number of retries and configurations. The problems I see:

  • Join-request is not always received in the gateway, I’ve seen a very low receive rate.
  • When a Join-request has been received, the downlink is not received by the end-node. This situation has only happened once in several days of testing.
34

  • Been debugging and the duty-cycle restriction slows down the iterations. Tried CFLAGS =-DDISABLE_LORAMAC_DUTYCYCLE make .. and also adding CFLAGS +=-DISABLE... on the program Makefile. Any suggestions to disable the restriction for faster debugging?

  • Got some outputs of a working join otaa test:

Shell console:

[semtech-loramac] initializing loramac
main(): This is RIOT! (Version: 2021.04)
All up, running the shell now
> loramac set appeui
loramac set appeui 
> loramac set deveui 
loramac set deveui 
> loramac set appkey 
loramac set appkey 
> loramac set dr 0 
loramac set dr 0
> loramac set adr on
loramac set adr on
> loramac join otaa
loramac join otaa
[semtech-loramac] Starting join procedure: 0
[semtech-loramac] loramac cmd msg
[semtech-loramac] starting OTAA join
[semtech-loramac] MAC timer timeout
[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 timer timeout
[semtech-loramac] MAC timer timeout
[semtech-loramac] MAC timer timeout
[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!
> loramac set tx_power 2
loramac set tx_power 2
> loramac join otaa
loramac join otaa
[semtech-loramac] Starting join procedure: 0
[semtech-loramac] loramac cmd msg
[semtech-loramac] starting OTAA join
[semtech-loramac] join otaa: duty cycle restricted
[semtech-loramac] join status msg received
Cannot join: dutycycle restriction
> loramac set tx_power 2
loramac set tx_power 2
> loramac join otaa
loramac join otaa
[semtech-loramac] Starting join procedure: 0
[semtech-loramac] loramac cmd msg
[semtech-loramac] starting OTAA join
[semtech-loramac] join otaa: duty cycle restricted
[semtech-loramac] join status msg received
Cannot join: dutycycle restriction
> loramac set tx_power 2
loramac set tx_power 2
> loramac join otaa
loramac join otaa
[semtech-loramac] Starting join procedure: 0
[semtech-loramac] loramac cmd msg
[semtech-loramac] starting OTAA join
[semtech-loramac] join otaa: duty cycle restricted
[semtech-loramac] join status msg received
Cannot join: dutycycle restriction
> loramac set tx_power 2
loramac set tx_power 2
> loramac join otaa
loramac join otaa
[semtech-loramac] Starting join procedure: 0
[semtech-loramac] loramac cmd msg
[semtech-loramac] starting OTAA join
[semtech-loramac] MAC timer timeout
[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 timer timeout
[semtech-loramac] MAC timer timeout
[semtech-loramac] MAC timer timeout
[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!
> loramac join otaa
loramac join otaa
[semtech-loramac] Starting join procedure: 0
[semtech-loramac] loramac cmd msg
[semtech-loramac] starting OTAA join
[semtech-loramac] join otaa: duty cycle restricted
[semtech-loramac] join status msg received
Cannot join: dutycycle restriction
> loramac set tx_power 2
loramac set tx_power 2
> loramac join otaa
loramac join otaa
[semtech-loramac] Starting join procedure: 0
[semtech-loramac] loramac cmd msg
[semtech-loramac] starting OTAA join
[semtech-loramac] join otaa: duty cycle restricted
[semtech-loramac] join status msg received
Cannot join: dutycycle restriction
> loramac set tx_power 2
loramac set tx_power 2
> loramac join otaa
loramac join otaa
[semtech-loramac] Starting join procedure: 0
[semtech-loramac] loramac cmd msg
[semtech-loramac] starting OTAA join
[semtech-loramac] join otaa: duty cycle restricted
[semtech-loramac] join status msg received
Cannot join: dutycycle restriction
> loramac set tx_power 2
loramac set tx_power 2
> loramac join otaa
loramac join otaa
[semtech-loramac] Starting join procedure: 0
[semtech-loramac] loramac cmd msg
[semtech-loramac] starting OTAA join
[semtech-loramac] MAC timer timeout
[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 timer timeout
[semtech-loramac] MAC timer timeout
[semtech-loramac] MAC timer timeout
[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!
> loramac join otaa
loramac join otaa
[semtech-loramac] Starting join procedure: 0
[semtech-loramac] loramac cmd msg
[semtech-loramac] starting OTAA join
[semtech-loramac] join otaa: duty cycle restricted
[semtech-loramac] join status msg received
Cannot join: dutycycle restriction
> loramac join otaa
loramac join otaa
[semtech-loramac] Starting join procedure: 0
[semtech-loramac] loramac cmd msg
[semtech-loramac] starting OTAA join
[semtech-loramac] join otaa: duty cycle restricted
[semtech-loramac] join status msg received
Cannot join: dutycycle restriction
> loramac join otaa
loramac join otaa
[semtech-loramac] Starting join procedure: 0
[semtech-loramac] loramac cmd msg
[semtech-loramac] starting OTAA join
[semtech-loramac] join otaa: duty cycle restricted
[semtech-loramac] join status msg received
Cannot join: dutycycle restriction
> loramac join otaa
loramac join otaa
[semtech-loramac] Starting join procedure: 0
[semtech-loramac] loramac cmd msg
[semtech-loramac] starting OTAA join
[semtech-loramac] join otaa: duty cycle restricted
[semtech-loramac] join status msg received
Cannot join: dutycycle restriction
> loramac join otaa
loramac join otaa
[semtech-loramac] Starting join procedure: 0
[semtech-loramac] loramac cmd msg
[semtech-loramac] starting OTAA join
[semtech-loramac] join otaa: duty cycle restricted
[semtech-loramac] join status msg received
Cannot join: dutycycle restriction
> loramac join otaa
loramac join otaa
[semtech-loramac] Starting join procedure: 0
[semtech-loramac] loramac cmd msg
[semtech-loramac] starting OTAA join
[semtech-loramac] MAC timer timeout
[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] MLME confirm event
[semtech-loramac] MLME confirm msg received
[semtech-loramac] join succeeded
Join procedure succeeded!
> loramac tx RIOTOS 
loramac tx RIOTOS
[semtech-loramac] loramac cmd msg
[semtech-loramac] send frame RIOTOS
[semtech-loramac] MCPS request: confirmed TX
[semtech-loramac] MCPS request: OK
[semtech-loramac] MAC timer timeout
[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 timer timeout
[semtech-loramac] MAC timer timeout
[semtech-loramac] MAC timer timeout
[semtech-loramac] RX 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] 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] MCPS confirm event
[semtech-loramac] MCPS indication event
[semtech-loramac] MCPS confirm msg received
[semtech-loramac] MCPS confirm event OK
[semtech-loramac] MCPS confirm event: CONFIRMED
[semtech-loramac] forward TX status to sender thread
[semtech-loramac] MCPS indication msg received
[semtech-loramac] MCPS indication Unconfirmed
[semtech-loramac] MCPS indication: ACK received
[semtech-loramac] received something
Received ACK from network
Message sent with success

Along TTN gateway logs:

  "name": "as.up.data.forward",
  "time": "2021-05-24T20:40:21.790171104Z",
  "identifiers": [
    {
      "device_ids": {
        "device_id": "clevertek-endnode",
        "application_ids": {
          "application_id": "clevertek"
        }
      }
    },
    {
      "device_ids": {
        "device_id": "clevertek-endnode",
        "application_ids": {
          "application_id": "clevertek"
        },
        "dev_eui": "00E3835063728DBE",
        "join_eui": "70B3D57ED0040CCE",
        "dev_addr": "260D4EE9"
      }
    }
  ],
  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.ApplicationUp",
    "end_device_ids": {
      "device_id": "clevertek-endnode",
      "application_ids": {
        "application_id": "clevertek"
      },
      "dev_eui": "00E3835063728DBE",
      "join_eui": "70B3D57ED0040CCE",
      "dev_addr": "260D4EE9"
    },
    "correlation_ids": [
      "as:up:01F6G1PT8HGHXZC2TMX6W9NYHV",
      "gs:conn:01F6FQKSYH761Q2D5B7VVG9TB8",
      "gs:up:host:01F6FQKT6QH0RBDK1KRH9WW5R2",
      "gs:uplink:01F6G1PT22RSXH82YP20YEBR8N",
      "ns:uplink:01F6G1PT237Q898YMH4ES4NPJY",
      "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01F6G1PT232EM87XYYWJBDTW21",
      "rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01F6G1PT8GW68KMK2YR0R1N511"
    ],
    "received_at": "2021-05-24T20:40:21.522586291Z",
    "uplink_message": {
      "session_key_id": "AXmgGv35tXWvYQ1ANbVd1Q==",
      "f_port": 2,
      "frm_payload": "UklPVA==",
      "rx_metadata": [
        {
          "gateway_ids": {
            "gateway_id": "clevertek-wan",
            "eui": "A84041FFFF1BB6D8"
          },
          "time": "2021-05-24T20:40:21.130653Z",
          "timestamp": 1997968452,
          "rssi": -105,
          "channel_rssi": -105,
          "snr": 5,
          "uplink_token": "ChsKGQoNY2xldmVydGVrLXdhbhIIqEBB//8bttgQxKjauAcaDAi1nrCFBhCW2tSVASCg08yBk7QC",
          "channel_index": 3
        }
      ],
      "settings": {
        "data_rate": {
          "lora": {
            "bandwidth": 125000,
            "spreading_factor": 12
          }
        },
        "coding_rate": "4/5",
        "frequency": "917400000",
        "timestamp": 1997968452,
        "time": "2021-05-24T20:40:21.130653Z"
      },
      "received_at": "2021-05-24T20:40:21.315511484Z",
      "confirmed": true,
      "consumed_airtime": "1.318912s"
    }
  },
  "correlation_ids": [
    "as:up:01F6G1PT8HGHXZC2TMX6W9NYHV",
    "gs:conn:01F6FQKSYH761Q2D5B7VVG9TB8",
    "gs:up:host:01F6FQKT6QH0RBDK1KRH9WW5R2",
    "gs:uplink:01F6G1PT22RSXH82YP20YEBR8N",
    "ns:uplink:01F6G1PT237Q898YMH4ES4NPJY",
    "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01F6G1PT232EM87XYYWJBDTW21",
    "rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01F6G1PT8GW68KMK2YR0R1N511"
  ],
  "origin": "ip-10-102-13-255.ap-southeast-2.compute.internal",
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_APPLICATION_TRAFFIC_READ",
      "RIGHT_APPLICATION_TRAFFIC_READ"
    ]
  },
  "unique_id": "01F6G1PTGYYC7GH84087J283R2"
}


{
  "name": "as.up.data.forward",
  "time": "2021-05-24T20:40:37.022575614Z",
  "identifiers": [
    {
      "device_ids": {
        "device_id": "clevertek-endnode",
        "application_ids": {
          "application_id": "clevertek"
        }
      }
    },
    {
      "device_ids": {
        "device_id": "clevertek-endnode",
        "application_ids": {
          "application_id": "clevertek"
        },
        "dev_eui": "00E3835063728DBE",
        "join_eui": "70B3D57ED0040CCE",
        "dev_addr": "260D4EE9"
      }
    }
  ],
  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.ApplicationUp",
    "end_device_ids": {
      "device_id": "clevertek-endnode",
      "application_ids": {
        "application_id": "clevertek"
      },
      "dev_eui": "00E3835063728DBE",
      "join_eui": "70B3D57ED0040CCE",
      "dev_addr": "260D4EE9"
    },
    "correlation_ids": [
      "as:up:01F6G1Q9CKNFA5RFNGN87V2QG4",
      "gs:conn:01F6FQKSYH761Q2D5B7VVG9TB8",
      "gs:up:host:01F6FQKT6QH0RBDK1KRH9WW5R2",
      "gs:uplink:01F6G1Q9545Z28S78W896905PB",
      "ns:uplink:01F6G1Q963Y4FMA9EQNAG0HJ0X",
      "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01F6G1Q963BW8KG8AWM93D5FPX",
      "rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01F6G1Q9CKEJ5PYN7XVZ4CAHVC"
    ],
    "received_at": "2021-05-24T20:40:37.018954718Z",
    "uplink_message": {
      "session_key_id": "AXmgGv35tXWvYQ1ANbVd1Q==",
      "f_port": 2,
      "f_cnt": 1,
      "frm_payload": "UklPVCE=",
      "rx_metadata": [
        {
          "gateway_ids": {
            "gateway_id": "clevertek-wan",
            "eui": "A84041FFFF1BB6D8"
          },
          "time": "2021-05-24T20:40:36.593554Z",
          "timestamp": 2013428804,
          "rssi": -43,
          "channel_rssi": -43,
          "snr": 11.2,
          "uplink_token": "ChsKGQoNY2xldmVydGVrLXdhbhIIqEBB//8bttgQxPiJwAcaDAjEnrCFBhCitIvwAiCg09XNzLQC",
          "channel_index": 4
        }
      ],
      "settings": {
        "data_rate": {
          "lora": {
            "bandwidth": 125000,
            "spreading_factor": 12
          }
        },
        "coding_rate": "4/5",
        "frequency": "917600000",
        "timestamp": 2013428804,
        "time": "2021-05-24T20:40:36.593554Z"
      },
      "received_at": "2021-05-24T20:40:36.803231266Z",
      "confirmed": true,
      "consumed_airtime": "1.482752s"
    }
  },
  "correlation_ids": [
    "as:up:01F6G1Q9CKNFA5RFNGN87V2QG4",
    "gs:conn:01F6FQKSYH761Q2D5B7VVG9TB8",
    "gs:up:host:01F6FQKT6QH0RBDK1KRH9WW5R2",
    "gs:uplink:01F6G1Q9545Z28S78W896905PB",
    "ns:uplink:01F6G1Q963Y4FMA9EQNAG0HJ0X",
    "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01F6G1Q963BW8KG8AWM93D5FPX",
    "rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01F6G1Q9CKEJ5PYN7XVZ4CAHVC"
  ],
  "origin": "ip-10-102-13-255.ap-southeast-2.compute.internal",
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_APPLICATION_TRAFFIC_READ",
      "RIGHT_APPLICATION_TRAFFIC_READ"
    ]
  },
  "unique_id": "01F6G1Q9CYWCMGYZGP15BM3AD5"
}

Greetings.

35

@jia200x after setting up PHY values manualy at semteck_loramac_radio.c I’m getting consistent join requests in the gateway, but no join accept (apparently the downlink is missed by the end-node).

image
image1239×401 40.2 KB

Noticed that with examples/lorawan the keys weren’t correctly set from the Makefile, and hard-codded them into CONFIG_LORAMAC_DEV_EUI_DEFAULT, CONFIG_LORAMAC_APP_EUI_DEFAULT and CONFIG_LORAMAC_APP_KEY_DEFAULT to get the above results.

I’m getting close to it, so hope to get some feedback soon! Thanks

36

nice to hear there’s some progress!

Which PHY settings did you change? Could you send the patch around?

Noticed that with examples/lorawan the keys weren’t correctly set from the Makefile, and hard-codded them into CONFIG_LORAMAC_DEV_EUI_DEFAULT, CONFIG_LORAMAC_APP_EUI_DEFAULT and CONFIG_LORAMAC_APP_KEY_DEFAULT to get the above results.

That’s strange. Do you have the steps to reproduce the issue? Does it work when you set them up using Kconfig? (run BOARD=<your_board> make menuconfig)

37

Through Kconfig the keys are set up correctly. Got some packages with null keys on the gateway so I can confirm that the Makefile keys are not affecting the implementation.

I’m new to the github workflow of reproducing issues and patch logs, if you can give me and advice or insight to them would be nice!

thanks for the feedback

38

I had a similar issue with a TTN gateway running V2 (the ones on IoT-Lab). Apparently, after an update, OTA stopped working(same behaviour as you describe, join request received but no join-accept). The solution was to migrate to v3. Maybe you are experiencing a similar issue and a similar fix would do?

39

@fjmolinas Actually merged to V3 a couple of weeks ago, so no fix by this side.

40

the patch around is the one suggested by you in the previous post.

41

Through Kconfig the keys are set up correctly. Got some packages with null keys on the gateway so I can confirm that the Makefile keys are not affecting the implementation.

Did you set them like this?

DEVEUI=aaaaaaaaaaaaaaaa APPEUI=bbbbbbbbbbbbbbbb APPKEY=cccccccccccccccccccccccccccccccc make

With that, I can see the keys in riotbuild.h:

/* Generated file do not edit */
...
#define LORAMAC_ACTIVE_REGION LORAMAC_REGION_EU868
#define CONFIG_LORAMAC_APP_KEY_DEFAULT "cccccccccccccccccccccccccccccccc"
#define CONFIG_LORAMAC_APP_EUI_DEFAULT "bbbbbbbbbbbbbbbb"
#define CONFIG_LORAMAC_DEV_EUI_DEFAULT "aaaaaaaaaaaaaaaa"
...

@jia200x after setting up PHY values manualy at semteck_loramac_radio.c I’m getting consistent join requests in the gateway, but no join accept (apparently the downlink is missed by the end-node).

This is expected with the patch, because the downlink configuration is usually different. This patch was just to test whether the TX path was ok or not.

From what I see, it seems that the region configuration is either wrong or not loaded properly. This would explain why you get a successful join request every now and then consistent joins when you use a fixed frequency.

It could be that for whatever reason the parameters PHY parameters are not loaded properly in the radio, but this is unlikely.

I remember we had to use the US915 Hybrid region in Chile . Could you try that region? You can select US902-928(hybrid) in Kconfig

42

Inside my riotbuild.h there is no CONFIG_LORAMAC_XXX... for neither of the keys. The file looks like this:

/* Generated file do not edit */
#define DEVEUI "aaaaaaaaaaaaaaaaa"
#define APPEUI "bbbbbbbbbbbbbbbbb"
#define APPKEY "cccccccccccccccccccccccccccccccc"
#define CPU_FAM_STM32F1 1
#define STM32F103xB 1
#define CPU_LINE_STM32F103xB 1
#define STM32_FLASHSIZE 65536U
#define __SYSTEM_STM32F1XX_H 1
#define CPU_MODEL_STM32F103C8 1
#define CPU_CORE_CORTEX_M3 1
#define RIOT_APPLICATION "lorawan"
#define BOARD_BLUEPILL "bluepill"
#define RIOT_BOARD BOARD_BLUEPILL
#define CPU_STM32 "stm32"
#define RIOT_CPU CPU_STM32
#define MCU_STM32 "stm32"
#define RIOT_MCU MCU_STM32
#define NDEBUG 1
#define REGION_US915_HYBRID 1
#define LORAMAC_ACTIVE_REGION LORAMAC_REGION_US915_HYBRID
#define RIOT_VERSION "2021.04"

The us915-hybrid didn’t work either.

43

@jia200x I’ve kept working with the tests/pkg_semtech_loramac and noticed that the selected frequencies for uplinks are usually incorrect (if I’m getting the driver right).

Since TTN proposes AU915 for chilean network, I’ve setup all the devices in the network to do so. The arduino-lmic node works as usual. For the debugging process join abp is done to get into transmission quest asap.

The output of tests/pkg_semtech_loramac and ENABLE_DEBUG 1 on drivers/sx127x_getset.c:

> loramac tx RIOT
loramac tx RIOT
[semtech-loramac] loramac cmd msg
[semtech-loramac] send frame riot
[semtech-loramac] MCPS request: confirmed TX
[sx127x] Set channel: 926800000
[sx127x] set modem: 1
[sx127x] already using modem: 1
[sx127x] Set bandwidth: 0
[sx127x] Set coding rate: 1
[sx127x] Set spreading factor: 12
[sx127x] Set CRC: 1
[sx127x] Set freq hop: 0
[sx127x] Set Hop period: 0
[sx127x] Set fixed header length: 0
[sx127x] Set IQ invert: 0
[sx127x] Set power: 27
[sx127x] Set preamble length: 8
[sx127x] Set TX timeout: 3000
[sx127x] Set max payload len: 17
[sx127x] Set payload len: 17
[sx127x] Change state: TX
[sx127x] Set op mode: TRANSMITTER
[semtech-loramac] MCPS request: OK
[semtech-loramac] MAC timer timeout
[sx127x] Change state: IDLE
[sx127x] Set sleep
[sx127x] Set op mode: SLEEP
[sx127x] Change state: IDLE
[sx127x] Set channel: 923300000
[sx127x] set modem: 1
[sx127x] already using modem: 1
[sx127x] Set bandwidth: 2
[sx127x] Set coding rate: 1
[sx127x] Set spreading factor: 12
[sx127x] Set preamble length: 8
[sx127x] Set fixed header length: 0
[sx127x] Set payload len: 0
[sx127x] Set CRC: 0
[sx127x] Set freq hop: 0
[sx127x] Set Hop period: 0
[sx127x] Set IQ invert: 1
[sx127x] Set symbol timeout: 29
[sx127x] Set RX single: 0
[sx127x] Set max payload len: 66
[sx127x] Set RX timeout: 0
[sx127x] Set RX
[sx127x] Change state: RX
[sx127x] Set op mode: RECEIVER
[semtech-loramac] Transmission completed
[semtech-loramac] MAC timer timeout
[semtech-loramac] MAC timer timeout

As we can see, the selected frequency for the first uplink is 926.8 MHz, and not part of the AU915-928 as stated on the following img:

image
image440×666 30.5 KB

Is this a bug? or this behaviour is correct?