LT-22222 transmitting twice

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.