Yes that was also my idea to modify the packet forwarder ,but without any success.
I found some similar use cases , but with no clear solution and description.
I think to modify the Packet forwarder could be the easier than creating my own code .
Do you have any References ?
Thanks
This is only a project you can accomplish if you are willing to dive into the code yourself, and only if you do that after investing time to understand the fundamental issues.
Really this is not a worthwhile idea.
If you wanted to do it, yes changing the IQ polarity configured into the baseband chip would be a requirement. Finding what in the code does that is the least of your problems.
You also have to consider the air settings used in a particular region. In some, downlinks use the same frequencies and bandwidths as uplinks. In others, dowlinks use distinct frequencies and bandwidth from uplinks.
If you invest time in understanding the capabilities of the Semtech baseband chip, you’ll learn about a few key limitations. For example, the chip can only receive in two tightly clustered regions of spectrum, traditionally these are set to be adjacent and cover the uplink frequencies utilized. Next, the chip can receive on multiple frequencies and spreading factors, but only at 125 KHz bandwidth; in some regional settings downlinks do often use 125 KHz bandwidth, but in others they are always 500 KHz. There’s also the ability to monitor a single frequency and single spreading factor at wider bandwidth - but only one, not the variety that a LoRaWAN network actually uses for downlink.
So if the gateway baseband chip can monitor most of the possible downlink modes, this might work. Otherwise the baseband chip (and possibly RF as well) would have to be dynamically reconfigured to catch each downlink. Nodes do this: but nodes know what to expect because of the rules mapping uplink settings to those of possible downlinks. A gateway trying to intercept other people’s traffic can’t know that. In a way, you’d be better off with a normal gateway to catch uplinks, and then you could steer a node radio or two to catch any potential downlinks corresponding to the uplinks you heard - but only those where you actually intercepted the uplink. And in a busy setting you could run out of radios to assign to possible downlinks.
Really, this is a complex project that would require a lot more effort and self sturdy on your part than you seem prepared to invest, and the results would generally be poor and useless. If you want to go ahead anyway, that’s up to you - but don’t expect anyone here to walk you through building it.
The one vaguely related thing that can actually make sense is sending gateway-to-gateway pings for test purposes. This however is fairly simple, because gateways already dynamically configure for each downlink, so all you really have to do is tell the sending gateway to transmit on one of the uplink, rather than downlink channels and IQ setting and it will be picked up by any gateway with ordinary configuration in range.
Ok thank you for your opinion.
Maybe i should figure out another way to solve this Problem …
More likely you should reconsider if there’s actually a problem at all.
Typically the concern with air capacity would be uplink utilization, not downlink, because in LoRaWAN downlink is necessarily much rarer than uplink, because it inordinately expensive for gateways to do since they stop being able to service multiple nodes during the time they are responding to just one.
If you want to monitor spectrum usage by other LoRaWAN networks, monitor uplinks not downlinks.
You’ve described the issue you have with technology as a possible solution, but you haven’t actually told us what the problem you are trying to solve is.
In other words, it’s a problem wrapped in a problem and as we don’t know your why, it’s wrapped in an enigma.
1 Like
The Problem is that i can´t receive downlink (Messages from a gateway to a node) with my gateway, which should work as a man in the middle.
To monitor Downlink could help me to see if there is a running Connection between Node an Gateway…
Hi @jazz, there is no connection between “Node an[d] Gateway”. The node is connected to the network and downlinks could be sent via any available gateway.
Trying to monitor traffic between a specific node and a specific gateway and derive any useful information is unlikely to result in anything other than a wild goose chase. (lots of chasing, lots of honking, no goose)
This reflects a basic misunderstanding of LoRaWAN.
Anyway, to practically monitor downlink without buying around 64 node radios, you’d have to first monitor uplink with an ordinary gateway configured in the ordinary way, and use that for queueing.
But once you’ve taken time to understand LoRaWAN, you’ll realize that capturing the uplinks alone would give you 95% of the information.
And 100% of the information you have any business knowing as someone not a party to the communication
I already have a device to capture uplink traffic.
I thought that a configuration to capture downlink packets, can’t be so difficult…
But i should overthink the whole situation and gain more knowledge.
Thank you for your responses !
1 Like
@jazz I have built a similar device to capture gateway downstream traffic. I used a simple LoRa node (a NEXUS in this case) to create a single channel receiver, listening to RX2 messages because they are transmitted on a fixed frequency (869.525 MHz) and on a fixed SF (SF9).
The RFM95 is quite simple to program: you set it to the right frequency and spreading factor, you invert I and Q (from the normal upstream config) to catch the gateway traffic, and then you set the RFM95 to a mode called continuous reception. Then by monitoring either the interrupts or one of the DIO outputs, you can detect every LoRa message sent in RX2.
This way you cannot detect traffic in RX1 (that would require a much more complex multi-channel receiver) but listening to RX2 over time also gives you a relative indication of how busy the network in your area is.
2 Likes
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