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…
Okay, so the gateway sending the donwlink messages is not under your control and you want to sniff the messages being send for their metadata?
Why do you need another gateway to do this?
Would not do a custom node the same thing?
Yes
Using a costum Node should be the same Problem only with the Uplink.
Also the concentrator of a gateway can listen to every Freq and all SF at the same time.
Before I used a Gateway i tried with costum Node but there was a limitation of SF an Freq at the same time
The Device should be passive, that means only listenling
I’m sorry but i don’t think I can help you there.
I guess you need to write some custom firmware for a gateway.
You could also have problems finding any help in this forum as it is focused on TTN and what you are describing is pretty out of scope for TTN.
Good luck on your search.
Thats right maybe this is the wrong forum,but thank you!
You will need to modify a packet forwarder source for your use case or create your own code based on the Semtech libraries that drive the concentrator card. I vaguely recall someone looked at doing something similar but you probably googled already and didn’t find anything?
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