0x657373656C6C
commented
2 years ago Here are some encouraging and objective evaluations after some sustained use.
Environment 1: RAK7258, Chirpstack, and Elsys ELT2 sensors w/ADR enabled on AS923-1
Notice the odd spectrum usage and distribution of channels which just seems to me to be a recipe for channel congestion at some point in the distant future.
Environment 2: RAK7268, Chirpstack, and RAK4631 w/ADR enabled on AS923-1
Here we have much more fair use of the spectrum and fantastic distribution of channels.
I could not be happier :)
beegee-tokyo
This PR fixes #59 by removing the extra frequencies forward-declared in RegionAS923InitDefaults remaining only with LC1 and LC2 as per the regional parameters.
The presence of this declaration created a static channel -> frequency map that was not forgiving of vendors such as TTN who would specify a specific channel and frequency order. Consequently, during NewChannelReq, these additional frequencies would fail and would not be added to the channel list. To rectify this the checking of frequencies has been removed.
The presence also impacted ADR requests where the channel mask was incorrectly mapped to the forward-declared frequencies which were neither in CFList nor NewChannelReq. The culmination results in a device transmitting on frequencies not intended and not specified causing lost frames.
Resultantly specifying only the two required regional frequencies and delegating the remaining frequencies to be provided by the network correct operation is observed in TTN and Chirpstack where AS923 is concerned.
To aid in testing and debugging I have also introduced additional debug logging in some relevant areas.