Thank you to take some times to discuss of this, and I agree with you.
But if you look into the spreadsheet above, my concern is the Lora STD channel (channel 64 under the channel column).
Based on the specs., DR4 is the only rate that should be used (min and max DR4; SF8 500 kHz BW).
Also just extracted this from the same section (2.5.2), which I think could be a problem if the SF is not properly defined into the GW other than SF8 (DR4);
If using the over-the-air activation procedure, the end-device SHALL transmit the Join Request message on random 125 kHz channels amongst the 64 125kHz channels defined using DR0 and on 500 kHz channels amongst the 8 500kHz channels defined using DR4. The end-device SHALL change channels for every transmission.
Again my objective is strictly to clarify this configuration into the GW, for the LoRa STD channel (64 to 71, 500 kHz).
What the gateway does is actually in accordance with spec.
In this bandplan, DR4 is SF8, perhaps that is the source of confusion?
The “standard channel” portion of the decode chip simply doesn’t support multi-SF, so while it’s unclear what is making you think it has been configured for a range of spreading factors, that actually isn’t possible.
At the end of the day, what the gateway does is what the silicon can do. And the silicon comes from Semtech, which is the company that lead the writing of the spec.
I agree with your point; …In this bandplan, DR4 is SF8…
My point was only concerning the Firmware for the RAK7249, does not reflect the spec for the SF that should be used for those channels, as you can see into this picture:
Doing so would mean that the gateway could only be used for LoRaWAN, and not for other LoRa protocols which the hardware is capable of supporting.
One could argue that having options is confusing, but in my view, that’s really an argument for sticking with the industry standard global_conf.json method where a given network scheme can simply provide the appropriate file such that users don’t need to wade around in these details in a GUI at all. If there were something worth improving on a particular gateway over the Semtech sources, it would be to make the software force the appropriate clock and transmit radio selections or warn if a file set those in a way unsuited to the particular board layout.
make sense to me… it would be to make the software force the appropriate clock and transmit radio selections or warn if a file set those in a way unsuited to the particular board layout.
