My Dragino LT-22222 is connected to TTS CE. After transmitting 28 data-packages it looks like it received a MAC-command and startet to transmit every package twice with the same FCnt but on different frequencies. The SNR is abt 10dB, RSSI abt. -90dBm, SF7, 125kHz.
The time-difference between the re-transmissions is 8 seconds.
Has anybody an explanation for this behaviour?
Are you mistakenly sending confirmed uplinks?
You shouldn’t.
Nooooo! I don’t use confirmed uplinks, they would cause downlinks from the gateway to the node. imho the node (LT 22222) received one downlink (MAC-command) that caused the node to transmit every message twice.
Confirmed uplinks would also mean the node transmits the same fcnt again if it doesn’t get a downlink from the network. But let’s assume you’re not in that mode.
What is the exact downlink MAC command sent?
Are the duplicate uplinks truly identical in all details, bit for bit? What about spreading factor and frequency? Do they both come through the same gateway?
We can’t know at this point that it’s not a one software bug, but details of the conversation on the air would help.
Does the note give any serial debug output? Have you asked Dragino?
I can’t see the MAC-command, it is not displayed in the gateway-log. What I see is that after 28 successful uploads there is one download and after that the node starts transmitting each message twice.
The messages are identical, only the TX-frequency is different.
All messages are received by the same gateway.
Maybe it’s a misinterpretation of a MAC-command by the node.
Could be a protocol version mismatch.
But you’re probably going to need to get the actual MAC command.
This morning after the 270th upload there was a download again and the node (LT-22222) stopped transmitting all messages twice.
What kind of MAC-command leads to this behaviour? This MAC-commands are a little bit mysterious for me.
And now I detected that my Dragino LHT65 startet to transmit even 3 times.
09/01-09:45:52 Data Unconfirmed Up LoRa 867.7 SF7 BW125 10075 Dev Addr: 260B36EF, Size: 26
{"ADDR":"260B36EF", "Size":26, "Rssi":-87, "snr":14, "FCtrl":["ADR":1,"ACK":0, "FPending":0, "FOptsLen":2], "FCnt":10075, "FPort":2, "MIC":"0608BDF9"}|B5E7E0E2CCED58F9B2AB01
09/01-09:45:45 Data Unconfirmed Up LoRa 868.5 SF7 BW125 10075 Dev Addr: 260B36EF, Size: 26
{"ADDR":"260B36EF", "Size":26, "Rssi":-87, "snr":11, "FCtrl":["ADR":1,"ACK":0, "FPending":0, "FOptsLen":2], "FCnt":10075, "FPort":2, "MIC":"0608BDF9"}|B5E7E0E2CCED58F9B2AB01
09/01-09:25:48 Data Unconfirmed Down LoRa 868.1 SF7 BW125 322 Dev Addr: 260B36EF, Size: 17
{"ADDR":"260B36EF", "Size":17, "InvertPol":true, "FCtrl":["ADR":1,"ACK":0, "FPending":0, "FOptsLen":5], "FCnt":322, "FPort":0, "MIC":"C46626AD"}|
09/01-09:25:45 Data Unconfirmed Up LoRa 868.1 SF7 BW125 10074 Dev Addr: 260B36EF, Size: 24
09/01-09:05:59 Data Unconfirmed Up LoRa 867.3 SF7 BW125 10073 Dev Addr: 260B36EF, Size: 24
{"ADDR":"260B36EF", "Size":24, "Rssi":-85, "snr":11, "FCtrl":["ADR":1,"ACK":0, "FPending":0, "FOptsLen":0], "FCnt":10073, "FPort":2, "MIC":"93FBBC9C"}|E957C2E8D8E02B9D0FC5D2
09/01-09:05:52 Data Unconfirmed Up LoRa 868.5 SF7 BW125 10073 Dev Addr: 260B36EF, Size: 24
{"ADDR":"260B36EF", "Size":24, "Rssi":-87, "snr":11, "FCtrl":["ADR":1,"ACK":0, "FPending":0, "FOptsLen":0], "FCnt":10073, "FPort":2, "MIC":"93FBBC9C"}|E957C2E8D8E02B9D0FC5D2
09/01-09:05:45 Data Unconfirmed Up LoRa 867.5 SF7 BW125 10073 Dev Addr: 260B36EF, Size: 24
{"ADDR":"260B36EF", "Size":24, "Rssi":-86, "snr":11, "FCtrl":["ADR":1,"ACK":0, "FPending":0, "FOptsLen":0], "FCnt":10073, "FPort":2, "MIC":"93FBBC9C"}|E957C2E8D8E02B9D0FC5D2
09/01-08:45:59 Data Unconfirmed Up LoRa 867.3 SF7 BW125 10072 Dev Addr: 260B36EF, Size: 24
09/01-08:45:52 Data Unconfirmed Up LoRa 867.9 SF7 BW125 10072 Dev Addr: 260B36EF, Size: 24
09/01-08:45:45 Data Unconfirmed Up LoRa 867.7 SF7 BW125 10072 Dev Addr: 260B36EF, Size: 24
09/01-08:25:59 Data Unconfirmed Up LoRa 868.5 SF7 BW125 10071 Dev Addr: 260B36EF, Size: 24
09/01-08:25:52 Data Unconfirmed Up LoRa 868.1 SF7 BW125 10071 Dev Addr: 260B36EF, Size: 24
09/01-08:25:45 Data Unconfirmed Up LoRa 867.1 SF7 BW125 10071 Dev Addr: 260B36EF, Size: 24
09/01-08:05:59 Data Unconfirmed Up LoRa 868.5 SF7 BW125 10070 Dev Addr: 260B36EF, Size: 26
09/01-08:05:52 Data Unconfirmed Up LoRa 867.7 SF7 BW125 10070 Dev Addr: 260B36EF, Size: 26
09/01-08:05:45 Data Unconfirmed Up LoRa 867.5 SF7 BW125 10070 Dev Addr: 260B36EF, Size: 26
09/01-07:45:54 Data Unconfirmed Down LoRa 868.1 SF7 BW125 321 Dev Addr: 260B36EF, Size: 17
{"ADDR":"260B36EF", "Size":17, "InvertPol":true, "FCtrl":["ADR":1,"ACK":0, "FPending":0, "FOptsLen":5], "FCnt":321, "FPort":0, "MIC":"EE6A9518"}|
09/01-07:45:52 Data Unconfirmed Up LoRa 868.1 SF7 BW125 10069 Dev Addr: 260B36EF, Size: 24
09/01-07:45:45 Data Unconfirmed Up LoRa 867.9 SF7 BW125 10069 Dev Addr: 260B36EF, Size: 24
09/01-07:25:52 Data Unconfirmed Up LoRa 868.5 SF7 BW125 10068 Dev Addr: 260B36EF, Size: 24
09/01-07:25:45 Data Unconfirmed Up LoRa 868.3 SF7 BW125 10068 Dev Addr: 260B36EF, Size: 24
09/01-07:05:52 Data Unconfirmed Up LoRa 867.1 SF7 BW125 10067 Dev Addr: 260B36EF, Size: 24
09/01-07:05:45 Data Unconfirmed Up LoRa 868.5 SF7 BW125 10067 Dev Addr: 260B36EF, Size: 24
It looks like an ADR-command (07:45:54) is the reason for this behavior. There are some other nodes that don’t belong to me received by my gateway. These nodes show the same behaviour but are using SF12 to transmit 27 bytes every 4-5 minutes. imho they exceed the FUP a little bit because of these ADR-commands.
Which firmware versions on the two Dragino devices?
No legitimate MAC command does. This is a spec violation, either a bug or a firmware hacked on by someone who “thought they knew better”.
When you’ve found the actual MAC command sent, and looked up its definition, you’ll find this is not a legitimate result of that - or of any other.