Hello ChirpStack Community,
I’d like to propose an enhancement to ChirpStack v4 that would optionally include gateway RX information (such as RSSI, SNR, timestamp, etc.) in join events. Currently we can view the rxinfo on join requests in the frames but these are omitted from the join event.
Background & Use-Case
In our deployment, we sometimes encounter devices that fail to join. We’ve found that having access to gateway RX info can be invaluable for estimating the locations of these assets, which in turn aids in diagnosing coverage issues and optimising network performance (and locate the assets).
Benefits of Including RX Info in Join Events
Asset Localisation:
By correlating join attempts with gateway RX metrics, we can better estimate the positions of devices, especially those that fail to join. This is critical for troubleshooting and refining network coverage.
Enhanced Diagnostics:
Access to detailed RX data during join events would provide a more complete picture of the radio environment. This helps in identifying interference, suboptimal link quality, or other issues that may impede successful joins.
Improved Network Planning:
Additional data points from multiple gateways could inform decisions about gateway placement and overall network design. This would allow operators to fine-tune their setups based on real-world reception data.
Optional Payload Enhancement:
To maintain the current lean design for those who don’t require extra diagnostics, this feature could be implemented as an optional configuration. That way, users can choose to include or exclude the RX information based on their needs.
Considerations for Implementation
Multi-Gateway Scenarios:
In environments where a join request is received by multiple gateways, there should be a mechanism to either forward all relevant RX data or to select the most representative set. This would help avoid ambiguity and ensure that the data is actionable.
Backward Compatibility & Performance:
Any changes should be made in a way that preserves the performance and backward compatibility of existing deployments. The optional nature of this feature would help maintain the balance between enhanced diagnostics and payload efficiency.
I believe that forwarding gateway RX information in join events could provide significant benefits for troubleshooting and network optimisation. I’m looking forward to hearing any thoughts and ideas on this and if it’s feasible. Also interested to hear if anyone else tried workarounds or custom integrations to get RX data for join events? I’d love to hear about your experiences or any suggestions for improvement.