ADR and FSK (using mcci-catena LMIC)

jpmeijers · July 12, 2019, 10:07am

When ADR is enabled on my end device and I am very close to a gateway I would assume the network will instruct the end device to use the fastest possible data rate.

My uplinks looks like this, being done at SF7BW125.

And following every uplink I see a downlink which I assume to be the ADR instruction.

Now what I am wondering is does this downlink ADR instruction tell the end device to use FSK, or does it tell the end device it should stay at SF7BW125? The HopeRF and LMIC should be able to support FSK, and so does my gateways and the channel plan I’m using. So how come the end device sticks around on SF7BW125 and not move to the faster (shorter range) FSK channel?

terrillmoore · July 12, 2019, 4:38pm

First thing to find out is what MAC command is being sent. If you register a receive-message callback, you can print the MAC messages like this:

        if (port == 0)
                {
                Serial.print("MAC message:");
                for (unsigned i = 0; i < LMIC.dataBeg; ++i)
                        {
                        Serial.print(" ");
                        Serial.print(LMIC.frame[i], HEX);
                        }
                Serial.println();
                return;
                }

This is the main reason the LMIC passes port-0 messages to the receive-message callback. You return because the message is definitely not for the app if it’s for port 0.

This can be slightly changed to print Mac data that’s piggybacked on non-port-0 downlinks.

terrillmoore · July 12, 2019, 4:47pm

Also, to actually reply to the point of the question (sorry):

the FSK channel must be enabled by a downlink; it’s not enabled by default.
the non-FSK channels must be disabled; otherwise the LMIC will sometimes use FSK, sometimes LMIC.
you need to enable ADR during initialization – LMIC_setAdrMode(1);. If you are seeing the device always on SF7BS125, I start to wonder if ADR is turned off.

cslorabox · July 12, 2019, 9:12pm

Seems to me there are two distinct questions here:

Will TTN ever command via ADR the EU868 DR7 that uses FSK?

Given that only a single frequency is available (SX1301 limitation) there are some real strategic questions about the benefit of doing this, so what decision was actually made should be a starting point. (The same question can be asked about DR6, which at 250 KHz bandwidth is also single-channel).

Because an LinkADRReq message can be sent either unencrypted in FOpts prepending to a downlink with an application port, or encrypted with the network key in the body of a downlink to port 0, I’d probably put debugging code where any LinkADRReq itself is processed - particularly the first byte containing the data rate and the power, which you can find approximately here: https://github.com/mcci-catena/arduino-lmic/blob/master/src/lmic/lmic.c#L758

Can a particular build of LMIC actually honor this request?

There are a lot of non-obvious moving parts here, but it seems that if the datarate that uses FSK is commanded, then only the FSK channel should be being used, even if others are enabled. However, the node side of an ADR scheme has fallback, so if it gives up, presumably it will of its own accord start scaling back through datarates that use LoRa modulation and multiple channels. That mechanism will be in a check of the LMIC.adrAckReq counter, and has had some odd/undesirable behavior in various past versions, the current version https://github.com/mcci-catena/arduino-lmic/blob/master/src/lmic/lmic.c#L1923 seems to scale back by one DR each time it gives up, so presumably FSK DR7 would become 250KHz LoRa DR6 would become multi-channel 125KHz LoRa DR5 and so on.

If you really want to use this, getting some debug logging of the node behavior in there, and then testing (after it scales up to DR7 then remove node antenna or if the gateway is yours pulling its network cord?) and watching what happens will be essential.

jpmeijers · July 13, 2019, 12:48pm

I’m not exactly sure how to interpret the mac command messages yet, but I managed to get them printed out. After a join I force LMIC to SF12BW125 and let ADR push it back down to SF7BW125, which happends almost immediately (SF12->SF8->SF7 in 3 uplinks). But after we get to SF7 I don’t see any downlink MAC commands anymore, so I assume TTN’s ADR doesn’t push the device down to the FSK channel.

14:36:41.190 -> Starting
14:36:41.224 -> Packet queued
14:36:41.257 -> 312848: EV_JOINING
14:36:52.613 -> 563562: EV_TXSTART: ch 0 rps=0x1 (SF7 BW125 CR 4/5 Crc IH=0), datarate 5, opmode 88C
14:36:52.679 -> 871932: EV_RXSTART: freq=868.1 rps=0x81 (SF7 BW125 CR 4/5 NoCrc IH=0), datarate 5, opmode 88C, txend 567452, delta ms 4871
14:36:52.679 -> 885512: EV_JOINED: ch 0
14:36:52.679 -> netid: 19
14:36:52.679 -> devaddr: <redacted>
14:36:52.679 -> artKey: <readacted>
14:36:52.679 -> nwkKey: <redacted>
14:36:52.679 -> 886298: EV_TXSTART: ch 3 rps=0x1 (SF7 BW125 CR 4/5 Crc IH=0), datarate 5, opmode 888
14:36:52.679 -> 949691: EV_RXSTART: freq=867.1 rps=0x81 (SF7 BW125 CR 4/5 NoCrc IH=0), datarate 5, opmode 888, txend 890318, delta ms 949
14:36:52.746 -> 1009441: EV_RXSTART: freq=869.5 rps=0x83 (SF9 BW125 CR 4/5 NoCrc IH=0), datarate 5, opmode 888, txend 890318, delta ms 1905
14:36:52.746 -> 1023215: EV_TXCOMPLETE: ch 3 rps=0x83 (SF9 BW125 CR 4/5 NoCrc IH=0) txrxflags 0x20
14:36:57.630 -> Packet queued
14:37:01.449 -> Received message on port 0: 0 bytes
14:37:01.449 -> MAC message: 60 1A 2F 1 26 85 0 0 3 41 FF 0 1
14:37:01.515 -> 1336500: EV_TXSTART: ch 0 rps=0x6 (SF12 BW125 CR 4/5 Crc IH=0), datarate 0, opmode 888
14:37:01.515 -> 1501956: EV_RXSTART: freq=868.1 rps=0x86 (SF12 BW125 CR 4/5 NoCrc IH=0), datarate 0, opmode 888, txend 1439571, delta ms 998
14:37:01.515 -> 1558693: EV_RXSTART: freq=869.5 rps=0x83 (SF9 BW125 CR 4/5 NoCrc IH=0), datarate 0, opmode 888, txend 1439571, delta ms 1905
14:37:01.515 -> 1575831: EV_TXCOMPLETE: ch 0 rps=0x83 (SF9 BW125 CR 4/5 NoCrc IH=0) txrxflags 0x22
14:37:06.461 -> Packet queued
14:37:53.421 -> Received message on port 0: 0 bytes
14:37:53.421 -> MAC message: 60 1A 2F 1 26 A5 1 0 3 51 FF 0 1
14:37:53.421 -> 4742157: EV_TXSTART: ch 4 rps=0x2 (SF8 BW125 CR 4/5 Crc IH=0), datarate 4, opmode 888
14:37:53.421 -> 4809533: EV_RXSTART: freq=867.3 rps=0x82 (SF8 BW125 CR 4/5 NoCrc IH=0), datarate 4, opmode 888, txend 4750032, delta ms 952
14:37:53.421 -> 4819185: EV_TXCOMPLETE: ch 4 rps=0x82 (SF8 BW125 CR 4/5 NoCrc IH=0) txrxflags 0x21
14:37:58.338 -> Packet queued
14:39:43.423 -> Received message on port 0: 0 bytes
14:39:43.489 -> MAC message: 60 1A 2F 1 26 A5 2 0 3 51 FF 0 1
14:39:43.489 -> 11628265: EV_TXSTART: ch 1 rps=0x1 (SF7 BW125 CR 4/5 Crc IH=0), datarate 5, opmode 888
14:39:43.489 -> 11691851: EV_RXSTART: freq=868.3 rps=0x81 (SF7 BW125 CR 4/5 NoCrc IH=0), datarate 5, opmode 888, txend 11632478, delta ms 949
14:39:43.489 -> 11698696: EV_TXCOMPLETE: ch 1 rps=0x81 (SF7 BW125 CR 4/5 NoCrc IH=0) txrxflags 0x21
14:39:48.404 -> Packet queued
14:39:51.163 -> 12045747: EV_TXSTART: ch 2 rps=0x1 (SF7 BW125 CR 4/5 Crc IH=0), datarate 5, opmode 888
14:39:51.263 -> 12109461: EV_RXSTART: freq=868.5 rps=0x81 (SF7 BW125 CR 4/5 NoCrc IH=0), datarate 5, opmode 888, txend 12050088, delta ms 949
14:39:51.263 -> 12169209: EV_RXSTART: freq=869.5 rps=0x83 (SF9 BW125 CR 4/5 NoCrc IH=0), datarate 5, opmode 888, txend 12050088, delta ms 1905
14:39:51.263 -> 12182855: EV_TXCOMPLETE: ch 2 rps=0x83 (SF9 BW125 CR 4/5 NoCrc IH=0) txrxflags 0x20
.
.
.
14:47:30.039 -> Packet queued
14:47:31.168 -> Received message on port 0: 0 bytes
14:47:31.168 -> MAC message: 60 1A 2F 1 26 A5 3 0 3 55 FF 0 1
14:47:31.234 -> 40857996: EV_TXSTART: ch 7 rps=0x1 (SF7 BW125 CR 4/5 Crc IH=0), datarate 5, opmode 888
14:47:31.234 -> 40921387: EV_RXSTART: freq=867.9 rps=0x81 (SF7 BW125 CR 4/5 NoCrc IH=0), datarate 5, opmode 888, txend 40862014, delta ms 949
14:47:31.234 -> 40928235: EV_TXCOMPLETE: ch 7 rps=0x81 (SF7 BW125 CR 4/5 NoCrc IH=0) txrxflags 0x21
14:47:36.177 -> Packet queued
14:47:37.304 -> Received message on port 0: 0 bytes
14:47:37.304 -> MAC message: 60 1A 2F 1 26 A5 4 0 3 55 FF 0 1
14:47:37.371 -> 41241532: EV_TXSTART: ch 2 rps=0x1 (SF7 BW125 CR 4/5 Crc IH=0), datarate 5, opmode 888
14:47:37.371 -> 41305245: EV_RXSTART: freq=868.5 rps=0x81 (SF7 BW125 CR 4/5 NoCrc IH=0), datarate 5, opmode 888, txend 41245871, delta ms 949
14:47:37.371 -> 41312092: EV_TXCOMPLETE: ch 2 rps=0x81 (SF7 BW125 CR 4/5 NoCrc IH=0) txrxflags 0x21

jpmeijers · July 13, 2019, 3:52pm

After running for a couple of hours (and 28 ADR downlinks) it seems like the network keeps on telling the device to stick to SF7BW125 at 6dBm.

DevAddr: 26012F1A

60 1A 2F 1 26 85 0 0 3 41 FF 0 1
60 = MHDR = 011 000 00 = (Unconfirmed data down, LoRaWAN R1)
1A2F0126 = DevAddr
85=FCtrl=1000101=(ADR,FOptLen=5)
0000=FCnt

FOpts:
03=LinkADRReq
4=DR=SF8BW125
1=TXP=(max-2 = 14dBm)
FF00=ChannelMask=(channels 1-8)
01=Redundancy=(single tx per message)


60 1A 2F 1 26 A5 1 0 3 51 FF 0 1
5=SF7BW125
1=(max-2=14dBm)

60 1A 2F 1 26 A5 2 0 3 51 FF 0 1
5=SF7BW125
1=(max-2=14dBm)

60 1A 2F 1 26 A5 3 0 3 55 FF 0 1
5=SF7BW125
5=(max-10=6dBm)

60 1A 2F 1 26 A5 4 0 3 55 FF 0 1
5=SF7BW125
5=(max-10=6dBm)


60 1A 2F 1 26 A5 1C 0 3 55 FF 0 1
5=SF7BW125
5=(max-10=6dBm)

kersing · July 13, 2019, 4:17pm

Are you getting downlinks for every uplink?

jpmeijers · July 13, 2019, 5:15pm

Originally when I was sending an uplink every 10 minutes I was getting a downlink every time. This might be because I had LinkCheck enabled. For experimentation I am now sending every minute and only seeing a downlink roughly every 8 minutes.

cslorabox · July 13, 2019, 7:32pm

That would have been my guess from the start.

I expect the code is somewhere you could examine… or not?

Interesting what would happen if you forced it anyway on the node side when conditions look good; I’d assume TTN would get the packet if your gateway does (but other people’s gateways might not), but it might fail at getting the right settings for a corresponding downlink.

And regardless it’s being interesting to think about for situations outside of TTN.