Reading up on the frequency plans (https://www.thethingsnetwork.org/docs/lorawan/frequency-plans.html) and note that there is a 9th channel for AU915 ( 9. 917.5 - SF8BW500), hence the 8 + 1 channels.
What’s it for and why do some frequency plans have it and others don’t?
Thanks.
@ElectronicallyE , I think you will find this is for the 9th Lora Demodulator found in a gateway.
As yet this is unused on LoraWan and as described on page 14 of the SX1301 data sheet. “This channel is intended to serve as a high speed backhaul link to other gateways or infrastructure equipment.”
The idea is a remote gateway with no internet connection can pass traffic to another gateway, one that does have an internet connection. As yet, this relay type solution has not been defined in the LoraWan specification but could be later this year.
This is pertinent for large spread out countries like Australia, I’ve been looking at this for some time with the idea of implementing a trial.
There is also a FSK demodulator which is also unused at this point in time.
So the take-away message, “Don’t get too excited, its not a 9th channel for a node to use”.
I’m super excited about the concept of a gateway to gateway back haul.
Like you mention, in Australia that’s a game changer in some “outback” areas where 50 - 100 km is needed.
This makes solar powered “repeaters with coverage” possible.
That’s simply not true, in actual fact, SF8BW500 uplink channels are defined in the AU915 regional parameters
That is also a theoretic possibility, but one not in practice usable without accommodating the delay of extra hops in the network timing. Default LoRaWan receive windows do not allow for this, TTN v3’s 5 and 6 second windows might in theory, but there’s no software support for such a thing: current gateways don’t have “pass this on” logic and neither they nor the network server know how to subdivide a 5 second round trip window seen at the ultimate node into shorter gateway-to-gateway timings.
On the contrary, a 9th uplink channel is exactly what it presently is, other uses are future rather than present possibilities.
Exactly, that’s why i have been looking at repeater operation off and on for a while.
To support this I’ve got my outdoor waterproof gateways down to less than 1 watt consumption so its ideal for a small pole mounted solar panel. Self contained, plug the solar panel directly into the gateway.
Sorry, to be more accurate “Don’t get too excited, its not a 9th channel a node can use right now”
UTTERLY FALSE
’
It is in fact a 9th channel a node can use right now.
Only if this is consistency programmed into the majority of gateways.
It’s in the official configurations.
I could easily see people not having tested it in all deployments, but then who writes a config file from scratch?
But it’s part of the spec, and thus would need to be implemented in any properly configured gateway.
I guess the most likely case of getting it wrong would be a gateway that uses a non-standard GUI rather than a traditional config file.
Take for example the SX1302, there isn’t a config file for AU915.
Exactly, but the file format is different and I had to write my own. Now the same occurred a number of years ago at the start of LoraWan/TTN rollout.
As a result there are numerous files, all slightly different,
which have become the seeds of the gateways installed around the country.
It’s really not different, apart from in Semtech’s version the json in the channels section being condensed onto a line rather than having line breaks which makes no difference to a json parser: and you could simply copy and paste. In fact I just added an SX130x_conf block to the file I was using with the sx1301.
One configuration file on the embedded computer, and a daemon tries to fire up an sx1301 forwarder, if that fails it tries the sx1302 forwarder, and if that fails too loops back and keeps going until one starts.
Comparing your existing sx1301 file and an sx1302 file for a different region should make short work of it.
And no need to be confused by these new optional fields:
“implicit_hdr”: false, “implicit_payload_length”: 17, “implicit_crc_en”: false, “implicit_coderate”: 1
Because “false” is the default for implicit header, and when that is false the rest does not apply and the code does not even look at it.