Thinking outside the square. If the OP wants to know if there’s congestion, run an SDR and look at the Chirps or just the noise floor.
1 Like
A typical inexpensive SDR lacks the instantaneous dynamic range to compare to a LoRa chipset, as such it’s usable for nearby sources only.
1 Like
I actually think your idea to monitor DL frames from other gateways is very interesting and completely relevant as an engineering investigation.
http://jultika.oulu.fi/files/nbnfi-fe201902064175.pdf
If I do a site survey for a client, I do want to know what other GW traffic is taking place in there area, both TTN and other LoRaWan networks.
Your Idea is worth developing. As gateways are often located and positioned in high sites, the signals (or noise depending on how you experience it) coming from both TTN and other network gateways are often at quite different levels and SNRs at the end-device as the RF link is not always reciprocal.
I would really like to be able to “flip” the IQ of my test GW and do a 7 day packet capture at a site.
TTN has a policy and design which we know and understand, however we are using ISM band spectrum and there may well be other lorawan networks around with entirely different configs, and making many more downlinks messages than TTN would.
So monitoring UP links of your own network is not going to tell the whole story.
Keep at it! and when you have a solution please share!
2 Likes
As explained earlier in the thread, gateway hardware only supports that in regions where downlink uses narrow channels just as uplink does. In regions where downlink uses 500 KHz channels, it’s unworkable.
I’m not aware of any multi-SF 500 KHz bandwith receivers apart from a custom implementation on an SDR. But it would have to be a good SDR likely with a nice 16 bit ADC, not one of the cheap low resolution ones with terrible dynamic range.
1 Like
Excepting we eventually established that the OP was trying to see the downlink from his gateway to his device and trying to create a receiver that could do that - as opposed to looking at logs etc.
1 Like
A re-reading of the thread will show that no, their goal was to monitor other people’s systems, not debug their own.
The comments about downlinks are a specific response to the suggestion of monitoring only the uplink side of those 3d party networks.
2 Likes
When challenged to articulate the actual problem they were trying to solve rather than the technical details of their chosen approach, this was the response:
1 Like
No.
Again, as I just explained, this was in response to the suggestion that they monitor only the uplink side of the 3rd party networks.
They objected claiming that they wanted/needed to see the downlink side, too.
Re-read the entire thread in context. It’s crystal clear that it is an interception of 3rd party traffic goal, not a debugging of own system one:
My usecase is to have system which can monitor LoRa Traffic in a specific Area.
My Attention is not at the Payload, only to monitor how much traffic is in this area and maybe the used Frequency…
1 Like
Thank you for your response,
The parameter of the IQ “flip” in the Paketforwarder seems to only change the Transmission.
So it was not really helpfull.
The gateway stops listening to a Message, if the preamble(+sync word) does not match with the Configuration
So maybe i could change the preamble configuration.
At the Console of TTN, you can see the RF Paramter of the Downlink Message and for my gateway its always send with BW=125kHz.
So my GW should be able to capture it …
That is the ‘configurable’ parameter, if you modify the source at the right place(s) you can flip it for reception as well. However, you won’t be able to capture the RX2 frequency as it falls outside the configurable ranges (or you need to shift one of the receivers upwards in the band which sacrifices the RX1 channels).
1 Like
One could rig an extra node radio for continuous reception of RX2
That is certainly an option, but requires additional hardware and software. Can’t be done by changing a few lines of code in the packet forwarder.