Adds proper eu433 frequency channels configuration#259
Conversation
brocaar
left a comment
brocaar
left a comment
There was a problem hiding this comment.
Could you please elaborate why EU433 did not work for you without these changes? This is odd, because in the ChirpStack EU433 config, only the first three channels are configured and thus the additional channels (the ones you have added) are not sent using the CFList.
Also, adding more uplink channels should not change the RX2 downlink frequency behavior as the downlink TX can be on any frequency that is supported by the gateway radio.
| # Beacon frequency / frequencies (Hz). | ||
| frequencies=[ | ||
| 434665000, | ||
| 433875000, |
There was a problem hiding this comment.
This seems incorrect, please see the regional parameters spec:
There was a problem hiding this comment.
Without the full 8 CFList, the CS GW will use only the 3 specified channels, while the rest will simply not be available/used.
To put it simply, I have two identical gateways side by side, one is running the RAK stock firmware (which works perfectly out of the box) and the other one is running the custom build CS GW OS, both are connected to the same CS cloud instance and configured to use eu433 region. I made a wild guess during my research, while comparing the eu433 config with the rest of the configurations (I also have eu868 gateway), that not all CF were added, because eu433 is not so popular and maybe it was not tested enough. I might be wrong, but adding all the CF resolved the issue where not all channels are being utilised. To be more precise, the CS GW will not allow all channels on the gateway unless specified in the concentratord configuration, where the RAK will without any changes.
The CFList is not related to the broken Rx2 I mentioned, but is to the Beacon frequency (somehow), I didn't explain correctly. By using the 434665000 frequency, the Rx2 is not working at all, so whenever the Rx1 is missed, then the downlink fails completely. This one bothered me for some time, I wasn't able to find a solution until I finally decided to try 433875000 instead, which the RAK uses for Rx2 by default. Changing this value fixed the problem completely, but to be honest, I didn't check with the specs, so thank you for pointing that out. Maybe the Rx2 issue is specific for the hardware I use or there is something else that I am completely unaware of.
To make it all work, I also had to make a custom eu433 region on the cloud CS (replicating the stock values from RAK local NS) with all the CF taken from the RAK (same CFList, including 2 more), and also provide specific UI configuration lists for the eu433 region for both UI - Contentratord and gateway mesh.
So, with all these changes I made, both gateways are now working exactly the same way and fully operational with Class A and Class C, unfortunately, I haven't tested Class B, which might have some issues, now that I have seen the documentation.
| # Spreading factor. | ||
| spreading_factor = 9 | ||
| # Spreading factor. | ||
| spreading_factor=8 |
There was a problem hiding this comment.
Could you please explain this change?
As you can see from the specifications, the beacon data-rate is DR3, which maps to SF9.
| # TX power. | ||
| tx_power = 12 | ||
| # TX power. | ||
| tx_power=27 |
There was a problem hiding this comment.
Please explain, as the specification defines an EIRP of 12 dBm:
There was a problem hiding this comment.
Hey, it has been a while, at the time of making this pull request, I was not sure of everything that I am missing, since from the beginning of my current project, I did not expect to have unimplemented configurations for this region. I have done much more work since I opened this pull request, and I have revisited the LoRaWAN spec, so confirmed I made a few mistakes, which you pointed out. The reason I made them was because I was out of ideas why it is not fully working (not using all channels, not working RX2 downlinks for either class a, class c).
Since that, I have made many more changes, improvements and experiments, which include changes to the concentratord, mqtt and mesh packages, mostly related to the 433 region not fully implemented.
So to put it simply, my pull request was a WIP and I think should be discarded at this point. When I have the time, I will clean a little my changes and will create new pull requests to make it properly.
For the beacon, I was not able to make use of the Class C on the RX2 window which eventually turned out to be related to a misconfiguration at the end node firmware. So there is no problem with this exact frequency channel. But there are many problems related to the implementation of 433, which is missing in concentratord, mqtt and mesh.
If you are interested to check the changes related to this issue, my work can be found at
https://github.com/fakedob/chirpstack-gateway-mesh/tree/v4.1.3.21
https://github.com/fakedob/chirpstack-concentratord/tree/v4.7.0.5
https://github.com/fakedob/chirpstack-mqtt-forwarder/tree/v4.5.1.12
I can confirm, that currently all 433 LoRaWAN specs are implemented properly and the system has been fully tested and confirmed operational as expected.
Since I am not focused so much on solving the 433 anymore, I focused on implementing Class C in the mesh package, which is taking significant time, I did not yet have submited new pull requests.
2 participants
Working on RAK7289V2/RAK7289CV2 WisGate Edge Pro V2 on the EU433 model would not work until I made a custom build with the following changes in the frequency channels configuration. The missing channel frequencies made it possible to use all 8 channels of the gateway and fixed a broken RX2 downlink.
Values were taken from the stock RAK firmware and were tested with a custom build of latest Chirpstack GW OS. Please note that there are further changes made to the Chirpstack GW OS source in order to have this region and frequencies fully utilised.