Hello,
I’m trying to receive Gateway Downlink Traffic with another Gateway.
I know that i have to invert the polarity to receive the downlink traffic, but i dont know how to do that.
Can anybody help me with that problem ?
Thanks
Hello,
I’m not quite understanding what you want to achieve:
What do you mean with Gateway Downlink? Do you want to receive downlink messages to devices with other gateways?
Do you want to invert polarity on a specific Gateway? I’ve never heard of inverting polarity in this context.
Yes exactly, i want receive and forward messages sent by other Gateways to nodes.
Downlink and Uplink messages are inverted in IQ Polarity, so i thought that my gateway which only receives Uplink Messages is configurated to receive Uplink(Node to Gateway).
To receive donwlink you should be invert the received message, so that preamble and sync word is in the right polarity…
But maybe my thought is wrong…
I don’t think that that is possible using LoRaWAN especially TTN. The messages sent to the nodes are encrypted and the gateway would not be able to decrypt it.
Maybe your thought can be implemented using only LoRa with some custom protocol.
What is your usecase for forwarding those messanges? Why should other Gateways receive the message you send? If the message is coming from some kind of application cant you directly forward it to another application behind the other gateway if it is not also connected to the same network?
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