Should EU868 gateways support DR6/SF7BW250 and DR7/FSK?

Gateways
1

The TTN EU868 frequency plan defines, emphasis mine:

Uplink:

  1. 868.1 - SF7BW125 to SF12BW125
  2. 868.3 - SF7BW125 to SF12BW125 and SF7BW250
  3. 868.5 - SF7BW125 to SF12BW125
  4. 867.1 - SF7BW125 to SF12BW125
  5. 867.3 - SF7BW125 to SF12BW125
  6. 867.5 - SF7BW125 to SF12BW125
  7. 867.7 - SF7BW125 to SF12BW125
  8. 867.9 - SF7BW125 to SF12BW125
  9. 868.8 - FSK

However:

  • The CFList in the OTAA Join Accept nicely adds 867.1 thru 867.9, but neither enables DR6/SF7BW250 for 868.3, nor adds 868.8 with DR7/FSK. Even more, the specifications do not support using CFList for that:

    In this case the CFList is a list of five channel frequencies for the channels four to eight 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. The list of frequencies is followed by a single RFU octet for a total of 16 octets.

  • After manually configuring DR6 and DR7, I can see through an RTL-SDR receiver that an RN2483 transmits just fine. But a nearby Kickstarter The Things Gateway does not receive the transmissions.

So, not a problem for me but curious: is all of the above expected?

Asides: I tried with both a The Things Uno RN2483, and MCCI LMIC/RFM95 with DR_SF7B and DR_FSK. (For DR_FSK LMIC never gets an EV_TXCOMPLETE and the RTL-SDR shows it keeps transmitting endlessly, for two Heltec WiFi LoRa 32 devices; could be some wiring.) On the gateway, an attached UART does not show LORA: Accepted packet nor something FSK-related, no matter how often I try. And for example the TTN LoRaWAN library does not support DR6 and DR7 for ABP either. (Even more, it only allows for changing the SF, while SF7 could be either BW125 or BW250.)

Enable DR6 and DR7 on RN2483

Microchip’s RN2483 manual states:

For the actual values of the data rates and the corresponding spreading factors (SF), refer to the LoRaWAN™ Specification.

So, as per the February 2017 1.0.2 Rev B Regional Parameters:

DataRate Configuration Indicative physical
bit rate [bit/s]
0 LoRa: SF12 / 125 kHz 250
1 LoRa: SF11 / 125 kHz 440
2 LoRa: SF10 / 125 kHz 980
3 LoRa: SF9 / 125 kHz 1760
4 LoRa: SF8 / 125 kHz 3125
5 LoRa: SF7 / 125 kHz 5470
6 LoRa: SF7 / 250 kHz 11000
7 FSK: 50 kbps 50000
8…15 RFU

The January 2015 LoRaWAN 1.0 specification defines the same.

Commands for an RN2483:

sys factoryRESET
--> RN2483 1.0.1 Dec 15 2015 09:38:09

mac get ch freq 2
--> 868500000

# After reset, it only knows the 3 default channels 0..2
mac get ch freq 3
--> 0

mac set deveui 0004............
mac set appeui 70B3D57ED.......
mac set appkey C491............................

# Required for mac save to work after OTAA join:
mac set devaddr 00000000
mac set nwkskey 00000000000000000000000000000000
mac set appskey 00000000000000000000000000000000

mac join otaa
mac save

# After join, it knows all 8 TTN channels, 0..7
mac get ch freq 3
--> 867100000

mac get ch freq 7
--> 867900000

mac get ch freq 8
--> 0

# Try DR6
mac set dr 6
--> invalid_param

# Try DR7
mac set dr 7
--> invalid_param

mac get ch freq 1
--> 868300000

mac get ch drrange 1
--> 0 5

# Make 868.3 use DR6 as well
mac set ch drrange 1 0 6

# Add channel 8 for DR7, FSK
mac set ch freq 8 868800000
mac set ch dcycle 8 799
mac set ch drrange 8 7 7
mac set ch status 8 on

mac save

mac set dr 6
--> ok
mac tx uncnf 1 123456
--> mac_tx_ok

mac set dr 7
--> ok
mac tx uncnf 1 123456
--> mac_tx_ok
4 Likes
2

It would seem so, at least these are including in the recommended gateway configuration:

https://github.com/TheThingsNetwork/gateway-conf/blob/master/EU-global_conf.json

Has SF7BW250 on 868.3 and FSK on 868.8

“chan_Lora_std”: {
“desc”: “Lora MAC, 250kHz, SF7, 868.3 MHz”,

“chan_FSK”: {
“desc”: “FSK 50kbps, 868.8 MHz”,

On a normal gateway with an operating system, putting this configuration in should be simple enough there’s no obvious reason not to; the less obvious reason is that in eliminating these, radio 1 could be tuned to a lower frequency putting the usual multi-SF channels at smaller IF offsets which might slightly improve performance - but it’s unclear that gateways without this are actually setting things up that way.

On more “embedded” gateways where the user doesn’t have the ability to change the configuration by simply editing the file, there tend to be other problems that dwarf this lack of support for something that’s probably not made use of anyway.

1 Like
3

Nice, that chan_FSK made it much easier to search. For The Things Gateway, it seems parsing of chan_FSK is supported in the code, and handling of bandwidth is simply the same for all channels.

Also, the configuration of my gateway refers to api/v2/frequency-plans/EU_863_870?filter=ttn, which includes the snippets you posted above.

So, I guess it should work…

(That ?filter=ttn is added in the code for fetching the config and fetching the frequency plan.)

4

For future readers, I just noticed this issue on GitHub:

2 Likes