I need to create an AS923 configuration / channel plan file for the Conduit. Does one already exist? Don’t want to duplicate work. Assuming I do have to create it myself, is there a repo that is accepting this kind of cotribution?
Best regards,
–Terry
I guess I should also ask a few higher-level questions.
In addition to changing the channel plan, do I have to make modifications to the poly-packet forwarder to accommodate the specific rules for AS923? AS923 appears to be an adaptation of the rules for EU868 in the higher frequency band. We intend to use OTAA. So somebody (during join) needs to send out the extra channels, and I wonder if that is actually an upstream network issue? We have a “go live” date for a research garden in Hualian of Nov 18. Equipment will be ready…
Hi Terry,
Yes, the gateway config repo contains the channel plans for the gateways.
The installation script the poly_pkt_fwd needs to be adapted so it stores the correct path for the channel setup downloaded from the github repo on startup of the forwarder. I’ve been meaning to make that change anyway so I’ll make some time in the near future.
However:
This requires changes to the back-end. @johan and @htdvisser are probably the ones to look into this.
Has the LoRa Alliance formalized AS923 in the specification?
Best regards,
Jac
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).
Thanks,
–Terry
As far as I know, the “regional parameters” document that @terrillmoore mentioned is final, but still under NDA. Therefore, we are not allowed to make this public yet. This obviously includes open source code.
Seeing that many countries in the region have ISM bands that include the 923-925 range, your allocation proposal looks okay to me, but we probably should do some spectrum measurements. I believe @Thomas did this for the EU channel plan.
The current packet forwarder protocol does unfortunately not have a way of telling the backend what its channel plan is.
We will have a dedicated backend address (router.as.thethings.network) for correctly handling traffic for the AS923 band. Until the LoRaWAN regional parameters are published, the backend will only accept uplink. When the specs are published, we will do our best to support the frequencies defined by the specification as soon as possible. After we standardize the TTN channel plan, we will include the correct CFList with OTAA.
The current poly_pkt_fwd start script downloads the configuration from github when starting the forwarder. So the only thing required to get the new configuration once deployed is a restart of the software. That could be done periodically with a cron job.
The 1.0.2 specification and the 1.0 of the regional parameters are available on request on Lora alliance web site.
I’ve been trying to setup a MTCDT for AS923 (NZ) as per the LoRa 1.0.2 spec, and I need a global_conf.json that will work with the MP Packet Forwarder. I’ve got several mDot modules running AS923 firmware but these aren’t able to join via the MT gateway because the channel frequencies are wrong - the gateway has the AU 915-928 config file.
The TTN documentation appears to be out of date relating to AS923 channel plan in New Zealand, say that we should use the AU915-928 frequency plan.
Is the backend address (router.as.thethings.network) available now, I have been using it temporarily and it worked well with NZ AS923 devices to join with OTAA. It seems to be taken out now, what other router address needs to be used for NZ AS923?