Support for US 915

[tftelkamp]

Some notes to highlight the differences with EU868.

We need to detect the region a gateway is located in. This setup applies to US915, but there will be other countries using 915Mhz with different rules, so you can't rely on frequency only (but we will to get started).

US915

Frequency band: 902 Mhz to 928 Mhz

Upstream

Channels 0-63

• 125kHz
• 902.3 to 914.9 in steps of 200khz

Channels 64-71

• 500kHz
• 903.0 to 914.2 in steps of 1.6Mhz

Downstream

Channels 0-7

• 500kHz
• 923.3 to 927.5 insteps of 600kHz

We will use Hybrid mode, with 8+1 channels per gateway. Because of this we need to limit the tx power.

Power:

• Upstream: max 21dBm (Hybrid mode, 125kHz)
• Downstream: max 26dBm (500kHz)

Duty Cyle:

Not applicable. However, it's still good to keep track of it, and limit it to say 10%, to prevent RX starvation on that gateway.
There is a dwell time limit of 400ms. This is taken care of by a maximum packet length for each SF abd BW setting (table 7.2.6 of R1 standard)

Sub-bands:

8+1 frequencies per SX1301. Band 1: channel 0-7 and 64, band 2: 8-15 and 65, Etc.
Pre-defined on the nodes because they need to transmit a join in the band the gateway is configured (there are no join frequencies).
We could use the ChMaskCntl field of the LinkADRReq to mask the channels we don't need (later, when we implement MAC commands)

Which sub-band to use? We seem to be using 7 a lot, but there's no science behind that. Sub-band 2 would be another good choice. Certainly not sub-bands 1 and 8.

RX1

Only initiate downstream if uplink frequency is > 902 and < 915 Mhz, and if the down_chan is an integer (do not round).

Downstream channel for upstream freq1 @ 125kHz:

down_chan = ((freq1-(902.3))/0.2) %% 8

Downstream channel for upstream freq1 @ 500kHz:

down_chan = ((freq1-(903.0))/1.6)

Convert to downstream frequency:

down_freq = 923.3 + (down_chan * 0.6)

DR Upstream -> DR Downstream

0 SF10BW125 - 10 SF10BW500
1 SF9BW125 - 11 SF9BW500
2 SF8BW125 - 12 SF8BW500
3 SF7BW125 - 13 SF7BW500
4 SF8BW500 - 13 SF7BW500

Upstream can only be DR 0 to 4, the reset below if just for reference.

8 SF12BW500 - 8 SF12BW500
9 SF11BW500 - 9 SF11BW500
10 SF10BW500 - 10 SF10BW500
11 SF9BW500 - 11 SF9BW500
12 SF8BW500 - 12 SF8BW500
13 SF7BW500 -13 SF7BW500

(yes, DR4 = DR12)

(reminder: investigate if we need to increase RX1DROffset due to hybrid mode power limitations 21/26).

RX2

freq = 923.3Mhz
datarate: DR8 SF12BW500

Join-accept message:

RX1DROffset: 0 (R1 default)
RX2 Data rate: 8 (R1 default)

Join Response CFList is not used. If present, it is ignored by the node. Better to not include it decrease message length!

[htdvisser]

Se also @tftelkamp's comments in 515a999

[htdvisser]

Implemented in feature/us-frequencies. It works, but still needs some (unit) testing before we can merge. We can field-test this on Staging.

[tftelkamp]

Please don't apply the EU RX1/RX2 logic to US and AU. For now, always send downstream in RX1. We'll deal with the RX2 settings and purpose later.

[htdvisser]

Done.

[franciscocabrera23]

Hi, OTA feature is supported by 915? Thanks

[htdvisser]

We have preliminary support for 915 OTAA on our staging environment. Full support is being implemented in the refactor branch and will be included in our production release.

[htdvisser]

Support for the US 915MHz frequencies has been implemented in the refactor branch. See #199 for more info.

[avbentem]

Join Response CFList is not used. If present, it is ignored by the node. Better to not include it decrease message length!

Just for future reference: LoRaWAN 1.1 does support the CFList for US915:

2.2.4 US902-928 Join-accept CFList

The US902-928 LoRaWAN supports the use of the optional CFlist appended to the Join accept message. If the CFlist is not empty then the CFListType field shall contain the value one (0x01) to indicate the CFList contains a series of ChMask fields. The ChMask fields are interpreted as being controlled by a virtual ChMaskCntl that initializes to a value of zero (0) and increments for each ChMask field to a value of four (4). (The first 16 bits controls the channels 0 to 15, ..)

But indeed, LoRaWAN 1.0.1 does not:

7.2.4 US902-928 JoinAccept CFList

The US902-928 LoRaWAN does not support the use of the optional CFlist appended to the JoinAccept message. If the CFlist is not empty it is ignored by the end-device.

[johanstokking]

We took care of this in V3.