Cannot get ABP STM32 node to work with LMIC on v3

brych34 · April 25, 2021, 5:20pm

Good afternoon!

Lately I’ve been working on upgrading an air quality monitor to be compatible with V3 - before it used an Arduino Pro Mini with TinyLoRa.

In order to make the node capable of receiving MAC downlinks I am attempting to switch to LMIC. To do this I had to change to an STM32 blue pill MCU because the memory of the Pro Mini is too small.

I have wired the board up to an RFM95 and set it up as a device in the V3 console. I’m using the “ttn-abp” example supplied with the MCCI LMIC library with the keys from the console. My lmic_project_config.h file is as follows:

#define CFG_eu868 1

#define CFG_sx1276_radio 1

#define DISABLE_JOIN

When I program the STM32 I get some weird behaviour. At first the packets are received by my BasicStation gateway and forwarded to the application in TTN. However, every uplink that is received triggers a downlink:

I assume the repeated downlinks mean that the node is not reacting to the MAC packets correctly, causing the network to send them again, but I’m not sure.

After the first few uplinks the packets stop reaching the application with an error message Host `cluster` failed to handle message: Device not found on the live gateway data page:

The device not found errors looks like this:

{
  "name": "gs.up.drop",
  "time": "2021-04-25T16:35:50.293348086Z",
  "identifiers": [
    {
      "gateway_ids": {
        "gateway_id": "csl-gateway-1",
        "eui": "B827EBFFFE025D8F"
      }
    }
  ],
  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.ErrorDetails",
    "namespace": "pkg/gatewayserver",
    "name": "host_handle",
    "message_format": "host `{host}` failed to handle message",
    "attributes": {
      "host": "cluster"
    },
    "cause": {
      "namespace": "pkg/networkserver",
      "name": "device_not_found",
      "message_format": "device not found",
      "correlation_id": "9ca11e9a7bc0474faaf2bf693c858a31",
      "code": 5
    },
    "code": 5
  },
  "correlation_ids": [
    "gs:conn:01F44XVDCXD9K8Z4DV1FWYM3JB",
    "gs:up:host:01F44XVDD3E5CHK4AK4X0D1YEV",
    "gs:uplink:01F44Y67WH980JR7VJ4SW59JW5"
  ],
  "origin": "ip-10-100-6-72.eu-west-1.compute.internal",
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_GATEWAY_TRAFFIC_READ"
    ]
  },
  "unique_id": "01F44Y67WNYN03NY97B99PJYK0"
}

We can also see that for every packet that did reach the application, a mysterious red error was triggered. When I click on one I see this:

{
  "name": "gs.down.send",
  "time": "2021-04-25T16:35:28.617285622Z",
  "identifiers": [
    {
      "gateway_ids": {
        "gateway_id": "csl-gateway-1",
        "eui": "B827EBFFFE025D8F"
      }
    }
  ],
  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.DownlinkMessage",
    "raw_payload": "YEJpCyaAAgAASYwafZjoc/DwJpHheVxcVQ03alDnqxysQuoCTmEd7Shdjqf67bfzYkyQ",
    "request": {
      "downlink_paths": [
        {
          "uplink_token": "ChsKGQoNY3NsLWdhdGV3YXktMRIIuCfr//4CXY8Qs8GbngEaCwjQtJaEBhCotZpjILj29obUCQ=="
        }
      ],
      "rx1_delay": 1,
      "rx1_data_rate_index": 5,
      "rx1_frequency": "868500000",
      "rx2_frequency": "869525000",
      "priority": "HIGHEST",
      "frequency_plan_id": "EU_863_870_TTN"
    },
    "correlation_ids": [
      "gs:conn:01F44XVDCXD9K8Z4DV1FWYM3JB",
      "gs:up:host:01F44XVDD3E5CHK4AK4X0D1YEV",
      "gs:uplink:01F44Y5JAGTYSSMSF182EQCDDM",
      "ns:downlink:01F44Y5JQ8K4553BFQQC9X07C5",
      "ns:uplink:01F44Y5JAH0ABXPXB92EYC7HCJ",
      "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01F44Y5JAGXACKMPNJCVFEE3Y9",
      "gs:conn:01F44XVDCXD9K8Z4DV1FWYM3JB",
      "rpc:/ttn.lorawan.v3.NsGs/ScheduleDownlink:01F44Y5JQ9CB58BBWDX4TWX1TE"
    ]
  },
  "correlation_ids": [
    "gs:conn:01F44XVDCXD9K8Z4DV1FWYM3JB",
    "rpc:/ttn.lorawan.v3.NsGs/ScheduleDownlink:01F44Y5JQ9CB58BBWDX4TWX1TE"
  ],
  "origin": "ip-10-100-6-72.eu-west-1.compute.internal",
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_GATEWAY_TRAFFIC_READ"
    ]
  },
  "unique_id": "01F44Y5JQ9PGXET6TKTMMHPXA9"
}

The BasicStation console shows that for the first few uplinks (the ones that reached the application) a downlink was sent in response, but afterwards no downlinks were sent:

2021-04-25 16:34:44.000 [S2E:VERB] RX 868.1MHz DR5 SF7/BW125 snr=9.2 rssi=-48 xtime=0x2300001124D02B - updf mhdr=40 DevAddr=260B6942 FCtrl=80 FCnt=0 FOpts=[] 019764CE..141F mic=1323094012 (26 bytes)
2021-04-25 16:34:44.438 [S2E:DEBU] ::0 diid=1019 [ant#0] - next TX start ahead by 557ms423us
INFO: tx_start_delay=1495 (1495.500000) - (1497, bw_delay=1.500000, notch_delay=0.000000)
2021-04-25 16:34:44.976 [S2E:VERB] ::0 diid=1019 [ant#0] - starting TX in 19ms914us
2021-04-25 16:34:45.001 [S2E:INFO] TX ::0 diid=1019 [ant#0] - on air: 868.1MHz 16.0dBm ant#0(0) DR5 SF7/BW125 frame=6042690B2680000000AAEBEB..88F8AAD4
2021-04-25 16:34:45.093 [S2E:DEBU] Tx done diid=1019
2021-04-25 16:34:46.469 [SYN:ERRO] Repeated excessive clock drifts between MCU/SX130X#0 (6 retries): -23.3ppm (threshold 11.0ppm)
2021-04-25 16:34:51.719 [SYN:INFO] Time sync qualities: min=41 q90=60 max=96 (previous q90=100)
2021-04-25 16:35:06.088 [S2E:VERB] RX 868.3MHz DR5 SF7/BW125 snr=10.0 rssi=-48 xtime=0x2300001275D86B - updf mhdr=40 DevAddr=260B6942 FCtrl=80 FCnt=1 FOpts=[] 01B6056E..5115 mic=895455691 (26 bytes)
2021-04-25 16:35:06.517 [S2E:DEBU] ::0 diid=1020 [ant#0] - next TX start ahead by 566ms343us
INFO: tx_start_delay=1495 (1495.500000) - (1497, bw_delay=1.500000, notch_delay=0.000000)
2021-04-25 16:35:07.063 [S2E:VERB] ::0 diid=1020 [ant#0] - starting TX in 19ms913us
2021-04-25 16:35:07.088 [S2E:INFO] TX ::0 diid=1020 [ant#0] - on air: 868.3MHz 16.0dBm ant#0(0) DR5 SF7/BW125 frame=6042690B26800100002EE405..2E22A3C3
2021-04-25 16:35:07.181 [S2E:DEBU] Tx done diid=1020
2021-04-25 16:35:16.921 [SYN:INFO] MCU/SX130X drift stats: min: -10.5ppm  q50: -22.9ppm  q80: -26.3ppm  max: -31.9ppm - threshold q90: -27.3ppm
2021-04-25 16:35:16.921 [SYN:INFO] Mean MCU drift vs SX130X#0: -22.6ppm
2021-04-25 16:35:28.188 [S2E:VERB] RX 868.5MHz DR5 SF7/BW125 snr=7.0 rssi=-45 xtime=0x23000013C6E0B3 - updf mhdr=40 DevAddr=260B6942 FCtrl=80 FCnt=2 FOpts=[] 01744CD5..0B56 mic=661257186 (26 bytes)
2021-04-25 16:35:28.616 [S2E:DEBU] ::0 diid=1021 [ant#0] - next TX start ahead by 555ms366us
INFO: tx_start_delay=1495 (1495.500000) - (1497, bw_delay=1.500000, notch_delay=0.000000)
2021-04-25 16:35:29.151 [S2E:VERB] ::0 diid=1021 [ant#0] - starting TX in 19ms915us
2021-04-25 16:35:29.176 [S2E:INFO] TX ::0 diid=1021 [ant#0] - on air: 868.5MHz 16.0dBm ant#0(0) DR5 SF7/BW125 frame=6042690B2680020000498C1A..F3624C90
2021-04-25 16:35:29.269 [S2E:DEBU] Tx done diid=1021
2021-04-25 16:35:50.268 [S2E:VERB] RX 867.1MHz DR5 SF7/BW125 snr=9.0 rssi=-48 xtime=0x2300001517E8F3 - updf mhdr=40 DevAddr=260B6942 FCtrl=80 FCnt=3 FOpts=[] 01216001..9651 mic=280507219 (26 bytes)
2021-04-25 16:35:54.725 [SYN:INFO] Time sync qualities: min=39 q90=60 max=96 (previous q90=100)
2021-04-25 16:35:58.925 [SYN:INFO] MCU/SX130X drift stats: min: -8.1ppm  q50: -18.1ppm  q80: -19.5ppm  max: -26.7ppm - threshold q90: -23.8ppm
2021-04-25 16:35:58.925 [SYN:INFO] Mean MCU drift vs SX130X#0: -18.4ppm
2021-04-25 16:36:12.349 [S2E:VERB] RX 867.3MHz DR5 SF7/BW125 snr=9.8 rssi=-49 xtime=0x2300001668F153 - updf mhdr=40 DevAddr=260B6942 FCtrl=80 FCnt=4 FOpts=[] 01D818C9..3AC0 mic=-1076758132 (26 bytes)
2021-04-25 16:36:40.929 [SYN:INFO] MCU/SX130X drift stats: min: -11.0ppm  q50: -15.2ppm  q80: -16.7ppm  max: -19.0ppm - threshold q90: -16.7ppm
2021-04-25 16:36:40.929 [SYN:INFO] Mean MCU drift vs SX130X#0: -15.3ppm
2021-04-25 16:36:56.681 [SYN:INFO] Time sync qualities: min=37 q90=58 max=58 (previous q90=100)

My interpretation is that there seems to be two issues:

Some uplinks are dropped before they reach the application
All of the uplinks that do reach the application trigger a downlink, which is not sustainable

I’m at a loss as to what I’m doing wrong, so any help would be greatly appreciated

Thank you!

Jeff-UK · April 25, 2021, 7:01pm

Use forum search for TinyLoRa and V3 … to see why likely not a good idea and problems seen…

bluejedi · April 25, 2021, 7:55pm

See: LMIC-node | One example to rule them all

It also supports bluepill + RFM95.

brych34 · April 25, 2021, 8:06pm

Thank you, I’ll have a go setting it up!

descartes · April 25, 2021, 9:41pm

Did you setup the different frequencies used for your region - this is a reason ABP triggers downlinks.

With a Blue Pill you have plenty of space to run the preferred and easier to configure OTAA.

But if you get really stuck, I can help get MCCI LMiC 3.3 running on a Pro Mini.

brych34 · April 27, 2021, 6:56am

Actually no, I forgot to set up the frequencies in the console - I’ll do this as well. Thanks!

I think for now I’m going to stick with ABP while I try to get everything working, but I agree OTAA is probably a better long term solution.

I managed to get LMiC running at one point on the Pro Mini but there are a few other libraries I’m using for the sensors that didn’t fit in the remaining memory.

cslorabox · April 27, 2021, 1:39pm

Keep in mind you also need to set the downlink windows for V3 vs V2. With ABP that’s not automatic.

brych34 · April 27, 2021, 6:43pm

I also haven’t done that. Does it need to be be set in TTN or LMIC? Thanks!

bluejedi · April 27, 2021, 7:49pm

See: How to Migrate ABP Devices from V2 to V3

brych34 · May 1, 2021, 10:30pm

I’ve followed the instructions for migrating ABP devices to V3 to create a new device in the V3 console, with the frequencies and RX2 delay set up. I then had a go setting up the LMIC-node example in PlatformIO in Atom.

Each time I upload the code over serial the device transmits one uplink, which is dropped as shown on the gateway view:

The error message is like this:

{
  "name": "gs.up.drop",
  "time": "2021-05-01T22:17:25.913531143Z",
  "identifiers": [
    {
      "gateway_ids": {
        "gateway_id": "csl-gateway-1",
        "eui": "B827EBFFFE025D8F"
      }
    }
  ],
  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.ErrorDetails",
    "namespace": "pkg/gatewayserver",
    "name": "host_handle",
    "message_format": "host `{host}` failed to handle message",
    "attributes": {
      "host": "cluster"
    },
    "cause": {
      "namespace": "pkg/networkserver",
      "name": "device_not_found",
      "message_format": "device not found",
      "correlation_id": "317b54ea2e0c453fae530a0b803e5bc6",
      "code": 5
    },
    "code": 5
  },
  "correlation_ids": [
    "gs:conn:01F4MQN839CZ2KBVZ4YWGE2H0Q",
    "gs:up:host:01F4MQN83GGKCKPPMV8NRY9G62",
    "gs:uplink:01F4N0414D35171T221YSPV0XW"
  ],
  "origin": "ip-10-100-13-44.eu-west-1.compute.internal",
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_GATEWAY_TRAFFIC_READ"
    ]
  },
  "unique_id": "01F4N0414SXGPJVNXTM04MFF7S"
}

Nothing is shown on the live view of the application. After this one uplink the device does not transmit any more.

I can’t get anything to come up on the serial monitor in PlatformIO or the Arduino IDE.

I’ve double checked that the device ID, network session key and app session key are correct and that the LMIC pin mapping in the BSF is correct for my setup.

Do you have any ideas?

Thanks!

brych34 · May 1, 2021, 10:42pm

That’s typical, as soon as I ask on the forum it magically starts working!

I’m now getting data coming through to the application, and it seems a downlink is only scheduled on the first uplink:

I’ve added the payload formatter and I can see the counter being incremented, and I can reset it with a 0xC0 downlink. Very cool!

I still don’t see anything on the serial monitor strangely.

Thanks!

bluejedi · May 2, 2021, 8:58am

Have you noticed that for bluepill, fo serial monitor you need a USB to serial adapter connected to pins A9 and A10? Serial over onboard USB by default doesn’t work (I have not yet found a way to get it working at least). Maybe you have RX and TX pins accidentally switched?

I suspect that the PlatformIO serial monitor on Atom should just work but be aware that the preferred editor for PlatformIO is Visual Studio Code (IIRC last time I checked Atom was not even listed as supported editor anymore).

I don’t know what OS you are using but for Windows Termite is a handy and easy to use terminal program that can also show the serial output (this will allow you to verify if serial monitor in Atom is possibly the issue).

brych34 · May 2, 2021, 11:43am

I just found the problem - it turns out I had an outdated version of the platformio-ide-terminal package, once I updated it the serial monitor started working.

I haven’t used PlatformIO for a while, I wasn’t aware Atom was no longer supported. It’s probably worth moving to VS code like you said.

Termite does look handy, it seems it comes in a version that doesn’t require installation. Maybe I can put it on a USB stick!

Thank you!