Question: US915 SF12/500kHz Yay or Nay?

[ehogeweg]

Hi,

These are actually 2 related questions.

1. What does the CR postfix in the DR_SF value stand for (Like DR_SF12CR)? It seems there is a correlation with the 500MHz BW.

2. Is DR_SF12CR a valid configuration for US915? If I set that data rate and enable debug logging I DO see SF=12 and BW=500kHz, so that seems ok. The gateway doesn't pick it up though.

    // Set data rate and transmit power for uplink
    LMIC_setDrTxpow(DR_SF12CR, 14); // Seems to work, but is this even valid?

I found a lot of websites discussing the (in)validity of SF12 for US915 but nowhere a conclusive answer.

• Version of LMIC being used:
  3.2

• Version of Arduino IDE being used:
  1.8.13

• Network provider (The Things Network, Swisscom, ChirpStack, etc.):
  TTN

• Region (EU868, US915, etc.)
  US915

• Board (MCCI Catena, Adafruit Feather M0, Heltec Wi-Fi LoRa 32 v2, etc.)
  Uno and Mega2560

• Radio (HopeRF, SX1276, etc.)
  SC1276

Kind Regards,

Erwin

[terrillmoore]

@ehogeweg, thanks for your question.

What does the CR postfix in the DR_SF value stand for (Like DR_SF12CR)? It seems there is a correlation with the 500MHz BW.

This is something that came from the original IBM LMIC. I am not really sure, but the names of these codes are mnemonically intended to select "whatever data rate corresponds to spreading factor N". (I suggest that user code should really not use these; user code should use the LoRaWAN specified "data rates", LORAWAN_DR0..LORAWAN_DR15.) However, this runs into a problem; there are multiple DR codes that use SF12, for example, differing only by bandwidth. So they added the CR (or C or B in the Europe region) suffix; and I just followed the pattern when adding more regions.

Is DR_SF12CR a valid configuration for US915? If I set that data rate and enable debug logging I DO see SF=12 and BW=500kHz, so that seems ok. The gateway doesn't pick it up though.

It's valid. Its used during downlink, and is used during join. I've not tested it during uplink; I'm a bit fuzzy this morning but I think it's not intended for this purpose. Depending on what you're printing, you can get the uplink frequency, which will tell you what is really going on.

For uplink, you should try US915_DR_SF8C. This is in DR4, which is intended for uplink, but is 500 kHz -- but it's SF8. It's used during join, and I know it works.

Again, I've not tried this, as the 8-channel networks don't encourage it -- if you use 500kHz you interfere with all uplink traffic for the duration of the uplink.

It is possible that 8-channel gateways are configured to listen on DR0 through DR4 only; and the DR8..12 are intended only for downlink. I confess that this is one of murkiest parts of the spec to me. There seems to be no clear way for the network to tell a device to use, or not to use, DR4 for normal data. And I find nothing that says that DR8..12 are for downlink only -- except this chart (from the 1.0.3 regional spec):

I also find this, which implies that DR8..13 have limited function:

So.... I recommend you try LORAWAN_DR4, but in general be cautious about using 500 kHz for uplink.

Best regards,
--Terry

[ehogeweg]

Terry, Thanks for your comprehensive answer.

So I tested all the LORAWAN_DRx values and printed the TX params. This is what it looks like:

LORAWAN_DR0 - TXMODE, freq=904300000, len=19, SF=10, BW=125, CR=4/5, IH=0
LORAWAN_DR1 - TXMODE, freq=904500000, len=19, SF=9, BW=125, CR=4/5, IH=0
LORAWAN_DR2 - TXMODE, freq=904100000, len=19, SF=8, BW=125, CR=4/5, IH=0
LORAWAN_DR3 - TXMODE, freq=904300000, len=19, SF=7, BW=125, CR=4/5, IH=0
LORAWAN_DR4 - TXMODE, freq=904600000, len=19, SF=8, BW=500, CR=4/5, IH=0
LORAWAN_DR5 - —
LORAWAN_DR6 - —
LORAWAN_DR7 - —
LORAWAN_DR8 - TXMODE, freq=904600000, len=19, SF=12, BW=500, CR=4/5, IH=0
LORAWAN_DR9 - TXMODE, freq=904600000, len=19, SF=11, BW=500, CR=4/5, IH=0
LORAWAN_DR10 - TXMODE, freq=904600000, len=19, SF=10, BW=500, CR=4/5, IH=0
LORAWAN_DR11 - TXMODE, freq=904600000, len=19, SF=9, BW=500, CR=4/5, IH=0
LORAWAN_DR12 - TXMODE, freq=904600000, len=19, SF=8, BW=500, CR=4/5, IH=0
LORAWAN_DR13 - TXMODE, freq=904600000, len=19, SF=7, BW=500, CR=4/5, IH=0
LORAWAN_DR14 - —
LORAWAN_DR15 - —

None of the 500kHz signals, with the exception of the SF8 ones, are picked up by my (Rak) gateway. If I look at the packet log on the gateway I see CRC errors on the neighboring 125kHz channels.

Still trying to make sense of the fact that you can have SF12 down but not up. That doesn't seem to do much to increase the range then.

Just for fun and giggles I disabled those but that didn't make any difference.

	"chan_multiSF_3": {
		"desc": "Lora MAC, 125kHz, all SF, 904.5 MHz",
		"enable": true,
		"radio": 0,
		"if": 200000
	},
	"chan_multiSF_4": {
		"desc": "Lora MAC, 125kHz, all SF, 904.7 MHz",
		"enable": true,
		"radio": 1,
		"if": -300000
	},

Again, thanks for your help.

Cheers,

Erwin

[terrillmoore]

Hi again,

I think the root cause is implementation restrictions in the Semtech gateway chips. They have a DSP that is busy concurrently decoding all the stuff from all 8 125kHz channels at all 4 spreading factors concurrently. (As I understand it, once they catch a preamble for a given SF on a given channel, they ignore the other SFs until they finish receiving that channel. So SF7 on ch0 will never interfere with any SF on ch1, but SF7 and SF8 on ch0 will interfere, to the extent that if they're overlapping, only the first one gets decoded.)

Decoding all the 500 kHz SFs at the same time was probably not feasible in the gateway chips in the first generation. May happen some day, but... you'll need help from the network to know if you can use them.

Best regards,
--Terry

[cstratton]

It is true that the Semtech baseband chip can only monitor a single fixed-SF 500 KHz channel. Typically that seems to be assigned as SF8BW500, eg in the LoRaWAN regional paramaters.

This would not actually blank out all of the 125 KHz channels, it overlaps with some but there should be moderate immunity in the chirp scheme between distinct spreading factors as long as they don't have the same "slope".

Additionally, the demodulators aren't hard coded to channels, but are rather agile and somehow allegedly dynamically assigned. So you can monitor 8 multi-SF channels. And you can also decode 8 packets. But some of those packets can theoretically actually be on the same frequency at the same time, but using different spreading factors. Someday I should actually run a test to confirm that by throwing some time coordinated packets at a gateway.

On a practical level will also mention that all of the coding (and ultimately even tuning) aspects of limited dynamic range. I've actually seen that even a regular 125 KHz node close to a gateway can blank out distant nodes on all 8 channels.

In terms of downlink, SF12BW500K is the RX2 default, both during join and normal operation. Otherwise the downlink SF will not go higher than the uplink one, unless a datarate offset is configurated. Eg, SF10BW125 uplink gets an SF10BW500 downlink, and so on.

The RXParamSetupReq MAC command can set the RX2 to something custom, and can also set a downlink datarate offset (eg, with offset 1, SF10BW125 uplink becomes an SF11BW500 downlink)

The LinkAdrReq MAC command has fields not only to specify which 125 KHz channels are supported but also which 500 KHz one is.