The installation script needs to be adapted.
OK. If you don’t get to it, I probably can also handle that part manually. The channel plan is perhaps more interesting as whatever I do on the gateway has to match what the back-end will beg sending (so looks like coordination will be needed with @johan and @htdvisser will be needed).
Has the LoRa Alliance formalized AS923 in the specification?
My understanding is that this there is a “regional parameters” spec that accompanies the 1.0.2 spec. I don’t know whether it is published yet, but I heard that it was approved at the same time as 1.0.2. I have heard that there are two primary channels using LoRa modulation, both 125 kHz, centered at 923.20 and 923.40, at DR0 to DR5. Joining is supposed to happen (uplink) at DR2.
To comply with regs, we definitely need to get the additional channels from the back-end, and they have to be suitable for the Taiwan regs (which I have, and which seem to allow use from 922 to 928 MHz). My guess is that it would be fine to allocate 923.2, .4, adding 923.6. .8, 924.0, .2, .4, .6, and .8, at least at first. As you know (but for other readers’ benefit) the problem for the devices is knowing which channels the GW is listening on, and this can be solved “by hand” for ABP, but for OTAA must be solved by sending a downlink JoinAccept CFList, that matches the settings in the gateway. At least for the MultiTech gateways, I don’t think there’s an automatic way of getting the back-end and the gateway to match, after the gateway is deployed (though that would be a very cool thing to add).