My end node is measuring environment variables (temperature, humidity, pressure, etc…) and the LoRaWAN gateway are mounted in the same 19 inch rack very close. For me make no sense to use LoRa radio in the end node to communicate with a gateway 50 cm far from each other. The gateway LoRa radio will be necessary to communicate with the others end nodes far 5 km far from the gateway.
Do you know any commercial LoRAWAN gateway that it has a ethernet LAN to be able to use it to connect a end node with a ethernet port? I mean, like the draw below:
Every once in a while someone asks about “faking” LoRaWan traffic from a wired device and the answer is consistently that you should not do that.
Rather than route fake-node traffic through TTN, what you need to do is establish an independent feed from your devices to the same data platform where your TTN information is ending up, but this non-LoRaWan feed needs to be independent of and outside of TTN.
MQTT can be a good way to unify feeds; also most of the cloud compute providers have semi-proprietary IOT data solutions accepting their own protocols as well as common ones like MQTT, and there’s an unlimited range of other things you could do on your own.
But TTN’s servers are for LoRaWan compliant radio nodes only. Anything else you’ll need to do on your own outside of TTN. And of course once you’re doing it outside of TTN and radio, you’re no longer constrained by the regulatory and usage policy data volume limits of TTN.
Maybe I was not clear, let me try to clarify some important points:
I am not talking about “faking solutions”. LoRa is a layer 1 protocol, that a packet to be able to reach the LNS, it will be necessary to be encapsulated by a layer 2 LoRaWAN. I am talking to encapsulate ethernet with LoRaWAN.
As a mention, the end node and gateway has 50 cm from each other in a 19 inch rack. It will be mounted in a smartpole and LoRaWAN gateway antenna will be at 18 m high outside of the smartpole. Then I can´t use LoRa to create a communication between end node and the gateway. A ethernet connection would be a locagical and easier connetivity solution.
You’ve got the encapsulation backwards - LoRaWan is encapsulated in LoRa. But regardless, doing this with a wire rather than a radio as the underlying transport is “fake” in the sense that you’re taking something tuned to the details of the radio transport, and moving it some other way - not “fake” in the sense of misleading anyone, but still “fake” in the sense of replacing radio with a wire. And to get it to work, you would have to “fake” (as in actually mislead) by inventing details of a radio transmission that never happened as seen by a gateway radio that didn’t receive it. And that’s not what TTN’s servers are for.
A ethernet connection would be a locagical and easier connetivity solution.
I fully agree, but again, this is not what TTN is for.
You should by all means route your wire-compatible traffic over wires; the catch is that you need to route it around TTN to the same ultimate destination, and not through TTN’s servers
Putting “fake radio” traffic through TTN is not allowed - for all of the reason of it being easy to get wrong, being unecessary load, and especially because once it’s no longer on the radio people will inevitably decide to do traffic volumes inappropriate for radio.
What you have is a data platform / software problem not involving TTN.
There’s readily available reference code out there to take say, an ESP32 and publish to an MQTT broker over SSL, which would be the logical point to unify that feed and the one from actual radio devices arriving via TTN. That would get you a wifi option, but there are ways to do wired, too. If you want to re-use the same basic node, you can wire its debug serial to the ESP32 and simply have it print the unencrypted packet payloads it would have sent, rather than push them into the LoRaWan stack for actual sending.
Even if you want your “gateway” to be involved in the sense of routing the traffic through its Internet backhaul, that’s just a matter of having software and hardware able to function as a wired or wireless access point - an entirely distinct “service” from it being a LoRaWan gateway, since both the origin and server destination of the traffic is fully independent of TTN.
If you’re not willing to do it “right” by setting up an independent data feed to your ultimate destination, then rather than investing a lot of effort in “faking” radio traffic, you should probably just replace the node’s antenna connection with a 50 ohm surface mount resistor to prevent overload from being so close to the gateway - that would be a bad solution, but at least one that doesn’t have new engineering costs and consequences to others in the way that trying to fake radio traffic and the receiving gateway would.
