Feather M0 Repeatedly Transmitting Empty Payloads

Arduino LMIC
1

Hello,

I’ve got a weird issue where my Feather M0 (RFM95 Lora Radio) board properly connects to The Things Network, then it waits for the TX interval (60 seconds in this test) and sends a successful message. However, periodically a message is sent immediately afterward without triggering the “Packet Queued” message associated with LMIC_setTxData2. Sometimes, this will loop multiple times in a row as shown by the last few entries in the serial log:

Transmission Repeating

The above serial log is from the “ttn-otaa-feather-us915” example sketch, with only the APPEUI, DEVEUI, and APPKEY modified.

I would greatly appreciate it if anyone could tell me what I’m doing wrong - it’s driving me mildly insane. The feather board has a wire antenna soldered to the antenna connector, and a jumper wire between pins i01 & #6. No other connections.

Thanks,

2

Hello Jefft,

It looks normal for me. I also see this behaviour with all my devices using the LMIC library. Same setup here, ttn-otaa-feather-us915 example sketch, tested on a chirpstack network server but also tested with TTN:

Starting
Packet queued
314483: EV_JOINING
380984: EV_TXSTART
702048: EV_JOINED
netid: 0
devaddr: 0106F14A
AppSKey: xxx
NwkSKey: xxx
702512: EV_TXSTART
773009: EV_TXCOMPLETE (includes waiting for RX windows)
1087436: EV_TXSTART
1156411: EV_TXCOMPLETE (includes waiting for RX windows)
1408412: EV_TXSTART
1474169: EV_TXCOMPLETE (includes waiting for RX windows)
1552588: EV_TXSTART
1618399: EV_TXCOMPLETE (includes waiting for RX windows)
1696764: EV_TXSTART
1762487: EV_TXCOMPLETE (includes waiting for RX windows)
1840941: EV_TXSTART
1906521: EV_TXCOMPLETE (includes waiting for RX windows)
1985117: EV_TXSTART
2050886: EV_TXCOMPLETE (includes waiting for RX windows)
2129293: EV_TXSTART
2270067: EV_TXCOMPLETE (includes waiting for RX windows)
6020224: EV_TXSTART
Packet queued
6086307: EV_TXCOMPLETE (includes waiting for RX windows)
6212348: EV_TXSTART
6446118: EV_TXCOMPLETE (includes waiting for RX windows)
10196274: EV_TXSTART
Packet queued
10337537: EV_TXCOMPLETE (includes waiting for RX windows)
14087703: EV_TXSTART
Packet queued
14228984: EV_TXCOMPLETE (includes waiting for RX windows)

The application payload is transmitted every 60s but MAC commands between the network server and the device are transmitted in between. As soon as the device receive a MAC command it will respond often without delay with an acknowledgment of the command.

Here you can see on the server side that many messages are transmitted on a short time at device startup:

messages
messages1335×1749 147 KB

Downlink messages are MAC commands, here new frequency mask, and ADR commands for dataRate, txPower and nbRep:

mac command
mac command417×1544 50.7 KB

Followed by an ack from the device with empty payload:

mac ack
mac ack477×766 31.2 KB

Nothing to worried about, the short transmission of messages after the join is normal and this stops after few commands. Then you will have your payload delivered every 60s.

Hope this helps.

3

Hey HB9HHA,

That greatly helps my sanity, thank you. I’ve been switching it off during the short transmission of messages fearing I was doing something wrong.

Ultimately, I would like to put this into a battery operated device that will sleep in low power modes between transmissions. Would you happen to know if going to sleep immediately following a successful join would cause issues due to the lack of response to the MAC commands?

Thanks again,

4

As long as you completely save state while asleep, this behavior on the network side will be uncommon. You’ll see it after joining, because the network is sending a bunch of info to make sure the device is in sync.

Be aware that in TTN V3, the delay will be 5 to 6 seconds instead of 1 to 2. I’ve got an improvement request to make this easier to deal with in your code, but for now you need to call an LMIC api to find out whether there are time-critical jobs pending in the LMIC; don’t sleep if there are.

5

Hey Terry,

Excellent, thank you very much!

6

Just to document for anyone who may experience problems like this in the future:

I still felt like I was getting an excessive amount of MAC commands sent between each uplink, and it didn’t stop after watching it for about a half hour. I decided to check through all of my settings again to see where I could have screwed something up. As it turns out, I had set the LoRaWAN version of my end device in The Things Network to 1.0.2 rather than 1.0.3. Switching it to 1.0.3 in TTN eliminated the problem and now it seems to be working perfectly.

Thanks again everyone for your help!

2 Likes