LoRa STD (SF7BW250) channel frequency incorrect

[jpmeijers]

My frequency plan is set to #define CFG_eu868 1 in lmic_project_config.h. After doing a OTAA join, then forcing the DR to use the STD channel using LMIC_setDrTxpow(DR_SF7B,14), lmic transmits packets on 867.1MHz.

19:24:18.635 -> 12309932: EV_TXSTART: ch 3 rps=0x9 (SF7 BW250 CR 4/5 Crc IH=0), datarate 6, opmode 888
19:24:18.635 -> 12371335: EV_RXSTART: freq=867.1 rps=0x89 (SF7 BW250 CR 4/5 NoCrc IH=0), datarate 6, opmode 888, txend 12312023, delta ms 948
19:24:18.635 -> 12431146: EV_RXSTART: freq=869.5 rps=0x83 (SF9 BW125 CR 4/5 NoCrc IH=0), datarate 6, opmode 888, txend 12312023, delta ms 1905
19:24:18.635 -> 12444921: EV_TXCOMPLETE: ch 3 rps=0x83 (SF9 BW125 CR 4/5 NoCrc IH=0) txrxflags 0x20
19:24:23.582 -> Packet queued

The LoRa STD channel in EU is 868.3MHz. See: https://github.com/TheThingsNetwork/gateway-conf/blob/master/EU-global_conf.json and: https://www.thethingsnetwork.org/docs/lorawan/frequency-plans.html

[terrillmoore]

Thanks for this report @jpmeijers . This is interesting, because according to the regional parameters in LoRaWAN Regional Parameters 1.0.3, section 2.3, the only standard channels are 0, 1, and 2, at 868.10, 868.30 and 868.50. and all three are 125 kHz.

So we can probably conclude that TTN has sent additional channel parameter configuration information in the JoinAccept, including whatever value we're using for channel 3. I'll come back with suggested debug prints to show the channel map.

I think there might be an additional bug in the handling of 250 kHz channels -- I don't yet see how the code takes into account the wider channel width (250 kHz uses, essentially, two adjacent 125 kHz channels).

Note to future readers: One confusing thing about the LMIC is that the use of DRs doesn't quite match the LoRaWAN terminology as adopted. The DR for 250 kHz in the spec is DR6; DR7 is FSK. However, EU868_DR_SF7B is, in fact, numerically 6.

I'm continuing to research, will update this comment as I get more facts.

[jpmeijers]

Just a note from my side after some more experimentation. If you force the FSK datarate, there is firstly an assertion error, but ignoring that assert one gets the following:

20:25:05.204 -> Packet queued
20:25:07.131 -> start single rx: now-rxtime: 26
20:25:07.131 -> 6136568: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
20:25:07.430 -> rxtimeout: entry: 6149593 rxtime: 6136492 entry-rxtime: 13101 now-entry: 10 rxtime-txend: 119240
20:25:07.430 -> 6149991: engineUpdate, opmode=0x900
20:25:07.430 -> 6016703: EV_TXSTART: ch 3 rps=0x0 (FSK BW125 CR 4/5 Crc IH=0), datarate 7, opmode 888
20:25:07.430 -> 6078400: EV_RXSTART: freq=867.1 rps=0x80 (FSK BW125 CR 4/5 NoCrc IH=0), datarate 7, opmode 888, txend 6017252, delta ms 978
20:25:07.430 -> 6136376: EV_RXSTART: freq=869.5 rps=0x83 (SF9 BW125 CR 4/5 NoCrc IH=0), datarate 7, opmode 888, txend 6017252, delta ms 1905
20:25:07.430 -> 6149988: EV_TXCOMPLETE: ch 3 rps=0x83 (SF9 BW125 CR 4/5 NoCrc IH=0) txrxflags 0x20

As can be seen here the FSK channel is also on 867.1MHz rather than the 868.8MHz. But as has been stated in the main readme there is a couple of issues with FSK that needs to be looked at at some point.

[terrillmoore]

According to section 2.2.4 of the regional spec, the JoinAccept CFList doesn't provide any channels that are safe for 250 kHz comms. Starting at line 356:

[... The] CFList is a list of five channel frequencies for the channels three to seven whereby each frequency is encoded as a 24 bits unsigned integer (three octets). All these channels are usable for DR0 to DR5 125kHz LoRa modulation.

From this, I conclude that 250 kHz operation is already somewhat operator specific. It seems that it can be enabled via a LinkAdr request, more in next note.

[terrillmoore]

LinkAdr requests for enabling 250 kHz are defined in two places. See section 5.2 of LoRaWAN 1.0.3 for the first part, and 2.2.5 of the regional spec for the second part.

To enable DR6 (== EU868_DR_7B), the network must prepare a LinkAdr request with the following contents:

1. Byte 0 set to DataRate_TxPower of 0x60 | k, where k indicates max EIRP.
2. Bytes [1..2] set to little-endan uint16_t bit mask of "enabled channels". This must indicate the channels for which 250k is valid, and disable any 125k channels that overlap.
3. byte 3 set to the "redundancy" value, which includes a 3-bit channel mask control in bits 6:4. This is defined by regional spec 2.2.5 as having two valid values: 0, and 6.

The core spec says that the channel mask can "be used to globally turn on or off all channels using specific modulation" (line 694). But that's region specific, and the EU868 doesn't indicate that this is supported.

[terrillmoore]

For debugging, we need to see what's in the channel map.

For that, the following code should be added in a convenient place. I'll use Arduino prints, but of course this is easier to do if there's a printf handy.

Serial.print("Channel enable mask: 0x"); Serial.println(LMIC.channelMap, HEX);
for (unsigned i = 0; i < MAX_CHANNELS;  ++i) {
  Serial.print("Ch "); Serial.print(i);
  Serial.print(": Freq="); Serial.print(LMIC.channelFreq[i]);
  Serial.print(" DrMap=0x"); Serial.println(LMIC.channelDrMap[i], HEX);
}

This should be printed after join, and after each time you call LMIC_setupChannel or receive a downlink MAC message. So maybe it would be convenient to make it a function.

[terrillmoore]

Looking at the code, the only way to enable a channel for 250 kHz or FSK is to enable it as part of device initialization. The LMIC never updates LMIC.channelDrMap[] based on downlink info, If the channel is not enabled for 250 kHz or FSK, then the code in LMICeu868_nextTx() will say "no feasible channel, and will simply use whatever channel index (LMIC.txChnl) was selected.

So there's a bug in how 250kHz and FSK are handled; if you select 250 kHz or FSK, but you have no channel enabled, the LMIC will blindly transmit on the previously-selected channel. This is true for all EU-related bandplans.

@jpmeijers does your code have any calls to LMIC_setupChannel() to enable (LoRaWAN) DR6 or DR7 (250k or FSK)?

[jpmeijers]

My code did not have any calls to LMIC_setupChannel(). But I have added two calls to enable the 250kHz and the FSK channels. In my onEvent function I have changed the EV_JOINED as follows to enable these channels after the channel map is changed by the OTAA join.

        case EV_JOINED:
            Serial.print(F(": ch "));
            Serial.println(unsigned(e.txChnl));
            {
              u4_t netid = 0;
              devaddr_t devaddr = 0;
              u1_t nwkKey[16];
              u1_t artKey[16];
              LMIC_getSessionKeys(&netid, &devaddr, nwkKey, artKey);
              Serial.print("netid: ");
              Serial.println(netid, DEC);
              Serial.print("devaddr: ");
              Serial.println(devaddr, HEX);
              Serial.print("artKey: ");
              for (int i=0; i<sizeof(artKey); ++i) {
                if (i != 0)
                  Serial.print("-");
                Serial.print(artKey[i], HEX);
              }
              Serial.println("");
              Serial.print("nwkKey: ");
              for (int i=0; i<sizeof(nwkKey); ++i) {
                      if (i != 0)
                              Serial.print("-");
                      Serial.print(nwkKey[i], HEX);
              }
            }
            // Right after join change channels and DR for the experiment.
            LMIC_setupChannel(1, 868300000, DR_RANGE_MAP(DR_SF12, DR_SF7B), BAND_CENTI);      // g-band
            LMIC_setupChannel(8, 868800000, DR_RANGE_MAP(DR_FSK,  DR_FSK),  BAND_MILLI);      // g2-band
            // LMIC_setDrTxpow(DR_SF7B,14); //Tested and is working.
            LMIC_setDrTxpow(DR_FSK,14); // Does not work.
            printChannelMask();
            break;

For the 250kHz SF7 channel this works correctly and the data is received on TTN. For the FSK channel nothing is received, even though the debug prints state that we are transmitting on the correct frequency.

21:18:10.369 -> Channel enable mask: 0x1FF
21:18:10.369 -> Ch 0: Freq=868100001 DrMap=0x3F
21:18:10.468 -> Ch 1: Freq=868300001 DrMap=0x7F
21:18:10.468 -> Ch 2: Freq=868500001 DrMap=0x3F
21:18:10.468 -> Ch 3: Freq=867100000 DrMap=0x3F
21:18:10.468 -> Ch 4: Freq=867300000 DrMap=0x3F
21:18:10.468 -> Ch 5: Freq=867500000 DrMap=0x3F
21:18:10.468 -> Ch 6: Freq=867700000 DrMap=0x3F
21:18:10.468 -> Ch 7: Freq=867900000 DrMap=0x3F
21:18:10.468 -> Ch 8: Freq=868800000 DrMap=0x80
21:18:10.468 -> Ch 9: Freq=0 DrMap=0x0
21:18:10.468 -> Ch 10: Freq=0 DrMap=0x0
21:18:10.468 -> Ch 11: Freq=0 DrMap=0x0
21:18:10.468 -> Ch 12: Freq=0 DrMap=0x0
21:18:10.468 -> Ch 13: Freq=0 DrMap=0x0
21:18:10.468 -> Ch 14: Freq=0 DrMap=0x0
21:18:10.468 -> Ch 15: Freq=0 DrMap=0x0
21:18:10.468 -> 19089691: engineUpdate, opmode=0x908
21:18:10.468 -> Packet queued
21:18:12.393 -> start single rx: now-rxtime: 26
21:18:12.393 -> 19210818: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
21:18:12.592 -> rxtimeout: entry: 19223971 rxtime: 19210742 entry-rxtime: 13229 now-entry: 9 rxtime-txend: 119240
21:18:12.692 -> 19224379: engineUpdate, opmode=0x900
21:18:12.692 -> 19090953: EV_TXSTART: ch 8 rps=0x0 (FSK BW125 CR 4/5 Crc IH=0), datarate 7, opmode 888
21:18:12.692 -> 19152650: EV_RXSTART: freq=868.8 rps=0x80 (FSK BW125 CR 4/5 NoCrc IH=0), datarate 7, opmode 888, txend 19091502, delta ms 978
21:18:12.692 -> 19210626: EV_RXSTART: freq=869.5 rps=0x83 (SF9 BW125 CR 4/5 NoCrc IH=0), datarate 7, opmode 888, txend 19091502, delta ms 1905
21:18:12.692 -> 19224376: EV_TXCOMPLETE: ch 8 rps=0x83 (SF9 BW125 CR 4/5 NoCrc IH=0) txrxflags 0x20

But as stated before FSK might be due to something else.

From what we found, is this still considered an LMIC bug? Or is this an issue with TTN? In the latter case we can close this ticket.

[terrillmoore]

So.. the original bug report was, roughly "I request 250 kHz, and LMIC transmits on channel 3". That's still a bug, because TTN doesn't send any info about 250 kHz or FSK, and this then triggers #345. We can close this now, or close it when we close #345. Up to you, @jpmeijers.

There are some LMIC issues anyway, Your bug #344 is a problem.

Also, we need an (architectural) way to put in network specific knowledge like your two calls:

LMIC_setupChannel(1, 868300000, DR_RANGE_MAP(DR_SF12, DR_SF7B), BAND_CENTI);      // g-band
LMIC_setupChannel(8, 868800000, DR_RANGE_MAP(DR_FSK,  DR_FSK),  BAND_MILLI);   

(I'll file an issue)

Also, if you use ch1 at 250 kHz, there's no accounting that prevents using ch0/ch2 at 125 kHz "soon thereafter" -- but ch1 definitely leaks into ch0/ch2 bandwidth, so we need to be updating their usage/duty cycle counters. (I'll file an issue.)

And I have no idea about the regulatory reqts for FSK vs the overlapped channels.

[terrillmoore]

Offline, @jpmeijers sent me this trace of a normal channel setup after join.

TTN only sets up DR0..DR5. It looks like it doesn't try to set up DR6 or DR7. This plus bug #345 caused the spurious transmit on channel 3 that triggered this bug report.

21:02:51.556 -> Channel enable mask: 0xFF
21:02:51.556 -> Ch 0: Freq=868100001 DrMap=0x3F
21:02:51.556 -> Ch 1: Freq=868300001 DrMap=0x3F
21:02:51.556 -> Ch 2: Freq=868500001 DrMap=0x3F
21:02:51.556 -> Ch 3: Freq=867100000 DrMap=0x3F
21:02:51.556 -> Ch 4: Freq=867300000 DrMap=0x3F
21:02:51.556 -> Ch 5: Freq=867500000 DrMap=0x3F
21:02:51.556 -> Ch 6: Freq=867700000 DrMap=0x3F
21:02:51.556 -> Ch 7: Freq=867900000 DrMap=0x3F
21:02:51.556 -> Ch 8: Freq=0 DrMap=0x0
21:02:51.556 -> Ch 9: Freq=0 DrMap=0x0
21:02:51.556 -> Ch 10: Freq=0 DrMap=0x0
21:02:51.556 -> Ch 11: Freq=0 DrMap=0x0
21:02:51.556 -> Ch 12: Freq=0 DrMap=0x0
21:02:51.556 -> Ch 13: Freq=0 DrMap=0x0
21:02:51.556 -> Ch 14: Freq=0 DrMap=0x0
21:02:51.556 -> Ch 15: Freq=0 DrMap=0x0

[terrillmoore]

Closing this now. See other FSK bugs that arose from this.