Australian Frequency plan

[mutton74]

Add support for AU915-925 please

[johanstokking]

Can you file a PR based on https://github.com/TheThingsNetwork/arduino-device-lib/blob/master/src/TheThingsNetwork.cpp#L627-L649?

We don't have a AU915 gateway at hand to test with either.

[mutton74]

Sorry I don't have the skills to write the code but could test on a AU915 gateway if somebody can put it together It could be based on this https://github.com/TheThingsNetwork/gateway-conf/blob/master/AU-global_conf.json

or just use the info provided here https://www.thethingsnetwork.org/forum/t/ttn-australian-communities/4068/9

[jpmeijers]

I can implement this, but it will be writing code in the dark as I do not have the correct module to test on. What I can do is to add it to a branch and let you test the branch on your side.

[mutton74]

Happy to help in every way possible.

I have 6 TTN gateways being setup with over 30 RN2903 nodes being deployed for a start.

This library looks to make things a lot less complicated than the Sodaq or standard RN2483 library

Cheers Paul

[johanstokking]

OK, @jpmeijers can you make a start? I can help wherever possible. Would be great @mutton74 if you can help testing. I'm sure @tftelkamp can do some sanity checking too.

[johanstokking]

@jpmeijers what is the status?

[mutton74]

Hi Guys, @jpmeijers @johanstokking @tftelkamp still willing and able to do some testing

Does any of this info help - https://github.com/TheThingsNetwork/ttn/issues/120

cheers Paul

[johncaipa]

some advance with this feature? I have tried to add this by making changes in the library, but it does not accept the changes in the frequencies of the channels:

Sending: mac set ch status 8 on Sending: mac set ch freq 8 916800000 Response is not OK: invalid_param ...

[johanstokking]

@johncaipa which RN module do you have exactly, what is the result of sys reset ?

[johncaipa]

@johanstokking Model: RN2903 Version: 1.0.3

[johanstokking]

Thanks. Let me reach out to Microchip

[johncaipa]

hi, any response from Microchip?

[johanstokking]

Yes, it needs a custom AU915 build; not the 1.0.3.

You have the latest 1.0.3 but apparently it doesn't support AU915. Unfortunately I don't know where to get that build.

[leogaggl]

Have there been any developments on this? Reading https://www.thethingsnetwork.org/forum/t/ttn-uno-rn2903-firmware-upgrade/10720/11 there seems that some work has been done. But can't see anything relating to this on Github.

[johanstokking]

I'm asking Microchip again.

[kiwi64ajs]

Hi Guys, Has this been resolved yet?

I'm setting up some TTN Gateways in New Zealand and I understand we are to use AU915 as well, so I'm keen to resolve the RN2903 support for AU915 as well.

I have a couple of TTN Uno boards and a TTN Node, which I've upgraded all the RN2903 modules to FW 1.0.3 ok, using the Java LoRa.jar tool.

I've modified the TheThingsNetwork.[hc] files to configure the AU915 frequencies as per the link above, but I think the instructions are incomplete with missing the actual frequencies, but I seems the RN2903 1.0.3 FW is still not up to the mark yet.

Regards Alex Shepherd

[johanstokking]

Yes, I'm not going to wait longer for a proper download page from Microchip, so here you go:

Programming RN2903A module.docx RN2903A UART Bootloader.docx RN2903 SA1.0.3 Hex.zip

[leogaggl]

Thanks, Johan!

Can confirm the Uno's now working with that firmware on TTN AU915. Most of the time was actually spent getting the Microchip LoRaUtility to work. For those on Linux (or Mac I believe), I have documented https://www.gaggl.com/2018/04/microchip-lorawan-development-utility-on-ubuntu/

Still using the TTN_FP_US915 frequency plan in the Arduino sketch though.

Will there be a void TheThingsNetwork::configureAU915(uint8_t fsb) function in future to separate the frequency plan?

[johanstokking]

@leogaggl great to hear that, I will pass your findings back to Microchip.

Indeed, when this hex file is officially available, we will add support for it in this library.

[kiwi64ajs]

Hi Johan,

On 16/04/2018, at 8:50 PM, Johan Stokking notifications@github.com wrote:

@leogaggl https://github.com/leogaggl great to hear that, I will pass your findings back to Microchip.

Indeed, when this hex file is officially available, we will add support for it in this library.

In order to test this beta HEX file, can we have the required changes included in a branch so we can test it now?

I think I’ve pieced together the required changes from forum posts but maybe I’ve got it wrong…

Alex

[johanstokking]

@leogaggl do you have your code available for sharing?

Indeed, it would be nice to have it available here already on a branch.

[leogaggl]

Hi @johanstokking

Would be happy to share, but at this stage I don't think it would be adding anything useful to this context. All I have done to test the Uno on AU915 was to flash the firmware with the HEX file you provided and used the TTN "OTAA Send" example (https://github.com/TheThingsNetwork/arduino-device-lib/blob/master/examples/SendOTAA/SendOTAA.ino) with the correct AppEUI and AppKey and used the TTN_FP_US915 constant as frequency plan (hence my question above). Have duplicated this on a second Uno as well. So it is definitely consistent.

OTTA join and data sending seem to work fine on my local Multitech AU915 GW and we have also tested at our meetup on a RAK/RPi gateway.

Testing a few sensors this weekend if I can find some time, but I have not made any mods to this library. The radio part of this is not really part of my comfort zone ... :)

[johanstokking]

Thanks @leogaggl. I looked briefly at the code and indeed AU915's format is very similar to US915. FSB 2 renders different channels, but we're using FSB 2 on both AU915 and US915 so that works as well. I need to double-check the data rates though.

Can you dump the entire log trace that you see in the serial monitor when running the SendOTAA example? I need the full one, including the reset, to be sure what the module returns.

[xenek]

@leogaggl I also have an TTN 'the things node', and need to update the Microchip firmware. I've put SA v103 from Microchip on a Sodaq One ok, as per https://www.thethingsnetwork.org/forum/t/ttn-uno-rn2903-firmware-upgrade/10720/15

• this SA version 103 hex is reported to be AU915 good by Microchip, but I am not sure of the windows procedure to try update my Things Node using the hex file because it's a Sparkfun not a Sodaq and my update tool https://github.com/SodaqMoja/RN2483FirmwareUpdater references a sodaq library. I'm scared to try it on the sparkfun based Things Node

. @johanstokking I am also happy to jump hoops each evening to get this AU stuff locked down and confirmed good using the Microchip SA 103 firmware.

I am running a Things Network Gateway confirmed working on AU915 using the Meshed server.

[xenek]

@johanstokking Good news. I decided to try the passthrough, and was able to update the things node that Darryl Lyons originally purchased.

-- STATUS EUI: 0004A30B001B63E4 Battery: 3253 AppEUI: 70B3D57EF0004875 DevEUI: 0004A30B001B63E4 Data Rate: 0 RX Delay 1: 1000 RX Delay 2: 2000 -- JOIN Model: RN2903 Version: SA1.0.3 Sending: mac set deveui 0004A30B001B63E4 Sending: mac set adr off Sending: mac set deveui 0004A30B001B63E4 Sending: mac set appeui 70B3D57EF0004875 Sending: mac set appkey 0936A064A56A65958274DBD9CA3C6877 Sending: mac save Sending: mac set ch status 0 off Sending: mac set ch status 1 off Sending: mac set ch status 2 off Sending: mac set ch status 3 off Sending: mac set ch status 4 off Sending: mac set ch status 5 off Sending: mac set ch status 6 off Sending: mac set ch status 7 off Sending: mac set ch status 8 on Sending: mac set ch drrange 8 0 3 Sending: mac set ch status 9 on Sending: mac set ch drrange 9 0 3 Sending: mac set ch status 10 on Sending: mac set ch drrange 10 0 3 Sending: mac set ch status 11 on Sending: mac set ch drrange 11 0 3 Sending: mac set ch status 12 on Sending: mac set ch drrange 12 0 3 Sending: mac set ch status 13 on Sending: mac set ch drrange 13 0 3 Sending: mac set ch status 14 on Sending: mac set ch drrange 14 0 3 Sending: mac set ch status 15 on Sending: mac set ch drrange 15 0 3 Sending: mac set ch status 16 off Sending: mac set ch status 17 off Sending: mac set ch status 18 off Sending: mac set ch status 19 off Sending: mac set ch status 20 off Sending: mac set ch status 21 off Sending: mac set ch status 22 off Sending: mac set ch status 23 off Sending: mac set ch status 24 off Sending: mac set ch status 25 off Sending: mac set ch status 26 off Sending: mac set ch status 27 off Sending: mac set ch status 28 off Sending: mac set ch status 29 off Sending: mac set ch status 30 off Sending: mac set ch status 31 off Sending: mac set ch status 32 off Sending: mac set ch status 33 off Sending: mac set ch status 34 off Sending: mac set ch status 35 off Sending: mac set ch status 36 off Sending: mac set ch status 37 off Sending: mac set ch status 38 off Sending: mac set ch status 39 off Sending: mac set ch status 40 off Sending: mac set ch status 41 off Sending: mac set ch status 42 off Sending: mac set ch status 43 off Sending: mac set ch status 44 off Sending: mac set ch status 45 off Sending: mac set ch status 46 off Sending: mac set ch status 47 off Sending: mac set ch status 48 off Sending: mac set ch status 49 off Sending: mac set ch status 50 off Sending: mac set ch status 51 off Sending: mac set ch status 52 off Sending: mac set ch status 53 off Sending: mac set ch status 54 off Sending: mac set ch status 55 off Sending: mac set ch status 56 off Sending: mac set ch status 57 off Sending: mac set ch status 58 off Sending: mac set ch status 59 off Sending: mac set ch status 60 off Sending: mac set ch status 61 off Sending: mac set ch status 62 off Sending: mac set ch status 63 off Sending: mac set ch status 64 off Sending: mac set ch status 65 on Sending: mac set ch status 66 off Sending: mac set ch status 67 off Sending: mac set ch status 68 off Sending: mac set ch status 69 off Sending: mac set ch status 70 off Sending: mac set ch status 71 off Sending: mac set pwridx 5 Sending: mac set retx 7 Sending: mac set dr 3 Sending: mac join otaa Join accepted. Status: 00000001 DevAddr: 26022762 -- LOOP Sending: mac tx uncnf 1 00 Successful transmission

Join request:

{ "gw_id": "xeneksttn2018", "payload": "AHVIAPB+1bNw5GMbAAujBAC4GK8y5Yg=", "dev_eui": "0004A30B001B63E4", "lora": { "spreading_factor": 10, "bandwidth": 125, "air_time": 370688000 }, "coding_rate": "4/5", "timestamp": "2018-04-23T14:23:59.251Z", "rssi": -77, "snr": 7.5, "app_eui": "70B3D57EF0004875", "frequency": 917200000 }

Join Accept:

{ "gw_id": "xeneksttn2018", "payload": "IOdfBxMf2KQG6UyhEtGlaQM=", "lora": { "spreading_factor": 10, "bandwidth": 500, "air_time": 82432000 }, "coding_rate": "4/5", "timestamp": "2018-04-23T14:24:03.252Z", "frequency": 924500000 }

[xenek]

And the basic sketch also works, using AU 915.

Sending: mac join otaa Join accepted. Status: 00000001 DevAddr: 2602262C -- SEND: SETUP EUI: 0004A30B001B63E4 Battery: 3253 AppEUI: 70B3D57EF0004875 DevEUI: 0004A30B001B63E4 Data Rate: 3 RX Delay 1: 1000 RX Delay 2: 2000 Light: 106 Temperature: 27.38 C Temperature alert: No Moving: No Button pressed: No Color: Green USB connected: Yes Battery voltage: 4724 MV Sending: mac tx uncnf 1 128000670AB2 Successful transmission Sending: sys sleep 60000

Let me know if there's anything else you need.

[johanstokking]

OK that's great, looks perfectly working. I will dive into the data rates and downlink channels to be fully sure.

[leogaggl]

Thanks @xenek - I wasn't anywhere near a machine yesterday. Assume you won't need any more Serial debug @johanstokking ?

[johanstokking]

@leogaggl @xenek in AU915, SF12 and SF11 are supported, so I took that into account. See https://github.com/TheThingsNetwork/arduino-device-lib/pull/235

Can you test please?

[leogaggl]

Hi @johanstokking

Join and send works. But I am now getting a few "Response is not OK: invalid_param" - see serial debug output:

---

-- STATUS EUI: 0004A30B001B45C2 Battery: 3283 AppEUI: 70B3D57EF0006CE9 DevEUI: 0004A30B001B45C2 Data Rate: 3 RX Delay 1: 1000 RX Delay 2: 2000 -- JOIN Model: RN2903 Version: SA1.0.3 Sending: mac set deveui 0004A30B001B45C2 Sending: mac set adr off Sending: mac set deveui 0004A30B001B45C2 Sending: mac set appeui 70B3D57EF0006CE9 Sending: mac set appkey AF77FE426F7F03C6EDBFADC859C3B1F7 Sending: mac save Sending: mac set ch status 0 off Sending: mac set ch status 1 off Sending: mac set ch status 2 off Sending: mac set ch status 3 off Sending: mac set ch status 4 off Sending: mac set ch status 5 off Sending: mac set ch status 6 off Sending: mac set ch status 7 off Sending: mac set ch status 8 on Sending: mac set ch drrange 8 0 5 Response is not OK: invalid_param Sending: mac set ch status 9 on Sending: mac set ch drrange 9 0 5 Response is not OK: invalid_param Sending: mac set ch status 10 on Sending: mac set ch drrange 10 0 5 Response is not OK: invalid_param Sending: mac set ch status 11 on Sending: mac set ch drrange 11 0 5 Response is not OK: invalid_param Sending: mac set ch status 12 on Sending: mac set ch drrange 12 0 5 Response is not OK: invalid_param Sending: mac set ch status 13 on Sending: mac set ch drrange 13 0 5 Response is not OK: invalid_param Sending: mac set ch status 14 on Sending: mac set ch drrange 14 0 5 Response is not OK: invalid_param Sending: mac set ch status 15 on Sending: mac set ch drrange 15 0 5 Response is not OK: invalid_param Sending: mac set ch status 16 off Sending: mac set ch status 17 off Sending: mac set ch status 18 off Sending: mac set ch status 19 off Sending: mac set ch status 20 off Sending: mac set ch status 21 off Sending: mac set ch status 22 off Sending: mac set ch status 23 off Sending: mac set ch status 24 off Sending: mac set ch status 25 off Sending: mac set ch status 26 off Sending: mac set ch status 27 off Sending: mac set ch status 28 off Sending: mac set ch status 29 off Sending: mac set ch status 30 off Sending: mac set ch status 31 off Sending: mac set ch status 32 off Sending: mac set ch status 33 off Sending: mac set ch status 34 off Sending: mac set ch status 35 off Sending: mac set ch status 36 off Sending: mac set ch status 37 off Sending: mac set ch status 38 off Sending: mac set ch status 39 off Sending: mac set ch status 40 off Sending: mac set ch status 41 off Sending: mac set ch status 42 off Sending: mac set ch status 43 off Sending: mac set ch status 44 off Sending: mac set ch status 45 off Sending: mac set ch status 46 off Sending: mac set ch status 47 off Sending: mac set ch status 48 off Sending: mac set ch status 49 off Sending: mac set ch status 50 off Sending: mac set ch status 51 off Sending: mac set ch status 52 off Sending: mac set ch status 53 off Sending: mac set ch status 54 off Sending: mac set ch status 55 off Sending: mac set ch status 56 off Sending: mac set ch status 57 off Sending: mac set ch status 58 off Sending: mac set ch status 59 off Sending: mac set ch status 60 off Sending: mac set ch status 61 off Sending: mac set ch status 62 off Sending: mac set ch status 63 off Sending: mac set ch status 64 off Sending: mac set ch status 65 on Sending: mac set ch status 66 off Sending: mac set ch status 67 off Sending: mac set ch status 68 off Sending: mac set ch status 69 off Sending: mac set ch status 70 off Sending: mac set ch status 71 off Sending: mac set pwridx 5 Sending: mac set retx 7 Sending: mac set dr 5 Response is not OK: invalid_param Sending: mac join otaa Join accepted. Status: 00000001 DevAddr: 260424FB -- LOOP Temp = 21.58 Humi = 52.10 PIR = 1 Sending: mac tx uncnf 1 00 Successful transmission

[johanstokking]

I was already afraid for that; US915 is limited to DR [0..3], while AU915 supports [0..5] (like EU868), but this firmware doesn't accept it.

I'll get back to Microchip about this issue.

[johanstokking]

I was mistaken about the DR; that is LoRaWAN Regional Parameters 1.1. It's done in #235, will draft a new release.

[leogaggl]

Excellent @johanstokking - will give this a test tomorrow as I am in Sydney today.

[sa-wilson]

@johanstokking AU915 uses DR [0..5] for the 125 kHz channels in both Regional Parameters 1.0.2 and 1.1. There is definitely an issue with the modules' AU915 support if it doesn't permit that.

2.5.2 AU915-928 Channel Frequencies
The AU ISM Band shall be divided into the following channel plans.
- Upstream – 64 channels numbered 0 to 63 utilizing LoRa 125 kHz BW varying from
DR0 to DR5, using coding rate 4/5, starting at 915.2 MHz and incrementing linearly
by 200 kHz to 927.8 MHz
-  Upstream – 8 channels numbered 64 to 71 utilizing LoRa 500 kHz BW at DR6
starting at 915.9 MHz and incrementing linearly by 1.6 MHz to 927.1 MHz
-  Downstream – 8 channels numbered 0 to 7 utilizing LoRa 500 kHz BW at DR8 to
DR13) starting at 923.3 MHz and incrementing linearly by 600 kHz to 927.5 MHz

[avbentem]

It seems that the 1.0.3 available for download above limits the application payload size to just 11 bytes in DR0 (SF12 BW125).

The very first LoRaWAN™ Regional Parameters v1.0 indeed defines at most 11 bytes for DR0, or even less if some MAC commands are included in the message as well:

But the later LoRaWAN™ Regional Parameters v1.0.2rB reads:

The release notes of version 1.0.5 from https://www.microchip.com/wwwproducts/en/RN2903 (dating back to November 2018, but only released a few days ago?) states:

Release for LoRaWAN specification 1.0.2 RN2903 1.0.5 Nov 06 2018 10:45:27

I don't know if this supports AU915. Full release notes as taken from the 1.0.5 ZIP archive are:

RN2903 FW revision history:

0.9.5   Initial release

0.9.7   Hardware rev H

0.9.8   Autobaud (awake mode) Issue Fixed

1.0.3   Fixed issues with LinkAdr, RxParamSetup, RX1 Receive Window, Channel Management, ESUART buffer sizes.

1.0.5   Release for LoRaWAN specification 1.0.2
        RN2903 1.0.5 Nov 06 2018 10:45:27

Changes since last release
- Added support for Class C and Multicast
- Added support for additional RN2903 commands
    mac set class
    mac set mcast
    mac set mcastdnctr
    mac set mcastdevaddr
    mac set mcastnwkskey
    mac set mcastappskey

    mac get class
    mac get mcast
    mac get mcastdnctr
    mac get mcastdevaddr

    radio get rssi
    radio rxstop

- Added new parameters to be saved in nonvolatile memory whenever a mac save
    command is triggered
        LoRaWAN device class
        LoRaWAN multicast application session key
        LoRaWAN multicast network session key
        LoRaWAN multicast device address

- Changed the pwridx range to support values from 4 to 10
- Changed the pwridx default value to 5
- Added support for Link ADR channel blocks