For example, if a PC (a software) communicates with a sensor over Ethernet, how can I replace this connectivity with Lora? I’m aware of the low bitrate, but monitoring the packets exchanged between them shows me that it’s only 1kb of information (measurements, handshakes, SYN requests) every 2-4 seconds.
How could this be done? I have two Raspberry Pi’s. Maybe I could connect a RPi to PC over Ethernet and route the traffic to RPi’s UART and then transmit it with Lora and do the opposite on the other side.
Transporting Ethernet packets over LoRa wouldn’t be a good plan. Transporting the actual data over LoRa would be fine. There are various USB devices that can give a PC access to a LoRa radio chip for either point 2 point or LoRaWAN.
But we only deal with LoRaWAN here, so point 2 point would be off topic.
I only care about sending the measurements data and data that are essential for the communication (syn requests, handshakes). I consider the latter as lower level data, that’s why I said “packets”. What would be an example product of such a USB Device?
I eventually going to end up sending those data to a wider network, I’m just going step by step.
The LoStik would be an example of USB PC device, there are others.
I’m not a network stack programmer but I suspect transferring the IP packets will be more hassle than just extracting the actual data and passing it along.
This will be an essential task if you want to send data over LoRaWAN as I can’t imagine it will meet duty cycle requirements.
Not really, once you get beyond a few 10s of meters, LoRa is actually faster than a lot of FSK based systems.
However legal duty cycle limits are what really resticts the amount of data you can move.
LoRa can operate on 2.4Ghz too, no duty cycle limits to worry about there. Its a shame there is not a 2.4Ghz LoRa concentrator, it would be a good medium for a short range high bandwidth TTN style network.
I see. I wasn’t aware of duty cycles limitations. So I suppose it’s impossible
I believed that it could be done, because I participated in a big Security system infrastructure which was able to receive video stream from security cameras in long distances wirelessly and I’m still wondering how is that possible.
I miss the “why” in your question. Is it a purely hypothetical question (is it possible) or do you have a specific application that requires this type of communication, e.g. distance to the sensor, etc.
The question ‘how can I bridge two networks with Lora’ is not really a question about Lora as such.
Lora devices at the microcontroller level just deal with packets of bytes. In that sense Lora devices are no different to many of the other radio devices out there, RFM22, RFM69 etc.
Its the bridgeing microcontroller that would have to deal with the higher level protocol issues involved when bridging ‘networks’ and whether the physical layer device is Lora or some other radio device probably makes no difference.
It’s actually all about turning a wired (Ethernet) sensor to wireless, and the distance should be long.
In my mind converting Ethernet packets to Serial, feed them to a Lora node and transmit them should be possible. For sure there are a lots of others parameters to consider.
If it is outside and you have a line of sight to the sensor, it might be better to do this with a point-to-point WLAN connection. They can reach up to several KM / miles with the right devices.
If you use a private lora point2point connection to bridge the gap and create a lot of traffic (airtime usage), you may also harm other lora devices, who communicate on the same frequency.
No, that’s really not workable at all because LoRa is a far narrower “pipe” than such protocols are designed for.
What can work in specific select circumstances is to extract the actual meaning from the Ethernet traffic, condense it to a bit-optimized essence, and send that over a LoRa link. But only if it can be condensed into a sufficiently compact and infrequent message to meet applicable regulations.
You can’t just blindly proxy a fat-pipe scheme over a thin-thread link - that only works the other way, from thin pipe to fat. For example, almost all LoRaWAN networks do blindly proxy the LoRa air traffic through the Internet to the actual network server, with the LoRaWAN protocol terminating at the network server, and not at the gateway where it merely transitions from air modulation to IP network encapsulation.
This type of situation is common in the use of satellite networks for industrial use. The situation is commonly called “the fire-hose and the drinking straw”. You CAN connect them together and the result is extremely entertaining for anyone who is not directly involved and often provides career opportunities due to sudden vacancies.
The “fire-hose and drinking straw” metaphor destroyed every hope I had on using Lora
But it definetely made it clear to me that Lora can’t be used under these circumstances.
