Frequency plan: Australia and New Zealand using LoPy

I wanted to post this information somewhere on TTN forum as accessible as possible to users of the AU915 frequency plan. If anyone has a better Topic area; please suggest.

For those who use Pycom’s LoPy (or Pycom’s Micropython fork on other microcontrollers) you will no doubt be happy at their recent firmware upgrade which takes the hassle out of selecting the regional LoRaWAN frequencies.
Or so I thought…
Unfortunately, you still need to restrict the frequencies in code. For those lucky enough to be programming in Micropython, the code below does the job.

# Initialize LoRa in LORAWAN mode.
lora = LoRa(mode=LoRa.LORAWAN)

# credentials
APP_EUI = 'XXXX'
APP_KEY = 'YYYYYYY'

print("Joining LoRa")

# remove default channels
for i in range(0, 72):
lora.remove_channel(i)

# adding the Australian channels
print("add channels")
for i in range(8, 15):
lora.add_channel(i, frequency=915200000 + i * 200000, dr_min=0, dr_max=3)
lora.add_channel(65, frequency=917500000, dr_min=4, dr_max=4)

for i in range(0, 7):
lora.add_channel(i, frequency=923300000 + i * 600000, dr_min=0, dr_max=3)

# create an OTA authentication params
app_eui = binascii.unhexlify(APP_EUI.replace(' ',''))
app_key = binascii.unhexlify(APP_KEY.replace(' ',''))

print("Joining")
# join a network using OTAA if not previously done
lora.join(activation=LoRa.OTAA, auth=(app_eui, app_key), timeout=0)

# wait until the module has joined the network
while not lora.has_joined():
print("attempt...")
time.sleep(2.5)
1 Like

Very useful to a newcomer to TTN / LoPy in particular!

Re the channel adds, shouldn’t the range statements be as follows to get ch15 & ch7?

# adding the Australian channels
print("add channels")
for i in range(8, 16):
lora.add_channel(i, frequency=915200000 + i * 200000, dr_min=0, dr_max=3)
lora.add_channel(65, frequency=917500000, dr_min=4, dr_max=4)

for i in range(0, 8):
lora.add_channel(i, frequency=923300000 + i * 600000, dr_min=0, dr_max=3)

Also, should the dr_min/dr_max align to the following or should they be tailored by use-case?

AU ISM 915	
Ch#	| direc	| f/MHz	| BW/kHz | data rate
8	| up	| 916.8	| 125	| DR0 - DR3	
9	| up	| 917.0	| 125	| DR0 - DR3	
10	| up	| 917.2	| 125	| DR0 - DR3	
11	| up	| 917.4	| 125	| DR0 - DR3	
12	| up	| 917.6	| 125	| DR0 - DR3	
13	| up	| 917.8	| 125	| DR0 - DR3	
14	| up	| 918.0	| 125	| DR0 - DR3	
15	| up	| 918.2	| 125	| DR0 - DR3	
65	| up	| 917.5	| 500	| DR4	
0	| down	| 923.3	| 500	| DR8 - DR13
1	| down	| 923.9	| 500	| DR8 - DR13
2	| down	| 924.5	| 500	| DR8 - DR13
3	| down	| 925.1	| 500	| DR8 - DR13
4	| down	| 925.7	| 500	| DR8 - DR13
5	| down	| 926.3	| 500	| DR8 - DR13
6	| down	| 926.9	| 500	| DR8 - DR13
7	| down	| 927.5	| 500	| DR8 - DR13

Very much in the early stages of working out what is ‘standard’ / convention and what is a hard MUST to connect. Shame the pycom LoRa.AU915 doesn’t align with this. Does it make any sense to try to align pycom lib with this (even if a TTN subset like LoRa.AU915.TTN)?

Hi,

I think you are right with the ranges. They should be range(0,8) for 0-7, and range(8,16) for 8-15.

I also think that there are other problems with the add channels snippet – I’m planning on raising a ticket and submitting a commit – but I just want to be sure first :slight_smile:

With the new region aware firmware, the downlink channels are not needed. Instead they are setup directly in the file RegionAU915.c. So putting them in the TRANSMIT channel plan just means that we might be trying to transmit on a channel that the gateway isn’t listening too. Or, at least, that’s my current thinking – it could definitely be wrong.

Also, I think there is an issue with the method RegionAU915ChannelManualAdd::RegionAU915.c. It checks to see that dr_min is ALWAYS 0, which is true for the 125kHz channels but not for channel 65. So adding channel 65 with min dr = 4 will currently fail.

There is also a mismatch with RegionAU915ChanMaskSet (it requires 20 125kHz channels to be setup) but as the LoPy firmware doesn’t support the two commands which use it, it shouldn’t affect us for the time being.

I’m in the process of trying a simpler channel setup where the 8 uplink 125kHz channels are in 0-7, and the one 500kHz channel is on channel 65. Of course to get the channel 65 setup requires the change in the
RegionAU915ChannelManualAdd() function first.

Please anyone point out holes in my reasoning! Else I’ll report on my tests and if they are successful I’ll raise a ticket and submit a pull request.

Kind Regards,
Brian

Very handy information. Does anything need to be put into the TTN gateway setup, or is just selecting AU915 as the frequency plan in the console enough? Have a device sending join requests on 917.0 MHz SF12 BW125 at 4.5 SNR and the gateway is sending join accepts at 923.3 MHz SF12 BW500.

I thought the join accept response used the same frequency and SF/BW as the join request? Seems unlikely message is getting through if the BW has been pushed to 500 when I am only get SNR of 4.5

Any ideas?

thanks

Simon

Hi Simon,

I’m using a Multitech Conduit for my gateway, and I used the script referred to in the TTN instructions for that gateway - using the AU915 region when prompted. Then looking in /var/config/lora/global_conf.json all of the frequencies that it listens too are the same frequencies that we set for transmission in the lopy. But if you have a different gateway, then I’m not sure how it needs to be setup.

As for the join accept, it uses the same channels for downstream as a normal receive, except with longer delays.

For the first receive window, in AU915, it uses the upstream stream channel modulo 8 – 917.0 is channel 9(0-based) so it should use the second (channel 1, 0-based) downstream channel. That’s 923.9 (assuming that my calculations hold up). That is meant to be sent at the same SF as what you transmitted.

923.3 MHz / BW500 / SF12, is the second receive channel (it is always the same) so that is compliant. So it seems that you didn’t get the accept in the first join/receive window, but got it in the second. I don’t know if the gateway has to send in both windows or if it can choose only the second.

I haven’t looked at OTAA much myself – my knowledge is just from the LoRaWAN 1.1 documents. So there could be holes in my understanding.

Cheers,
Brian

Finished my testing with patched firmware to allow channel 65 to have a non-zero DR and now I’ve got good communications on all 9 channels! In fact now the channels can be setup as per the LoRaWAN regional parameters list. This means:
Channels 8-15 with DR 0 to DR 5, and
Channel 65 with DR6 to DR 6.

So setting the socket option socket.SO_DR to 4, will now use one of channels 8-15. To use channel 65 you must set the option to 6

Even better, you don’t have to wait for the patch to get everything working. With the v1.17.3.b1firmware all of the channels are correctly set up. Instead of removing ALL channels, and re-adding them (which is currently broken in the last firmware), you can just remove the channels that aren’t support on the TTN and Multitech gateways.

I.e. (with object lora of type network.LoRa):

# leave channels 8-15 and 65
for index in range(0, 8):
   lora.remove_channel(index)  # remove 0-7
for index in range(16, 65):
   lora.remove_channel(index)  # remove 16-64
for index in range(66, 72):
  lora.remove_channel(index)   # remove 66-71

(Note – I saw someone else on this forum use this method)