Does anybody know a supplier, that sells a profesional grade “serial to LoRaWan”-Bridge?
We made a very simple Arduino-Node, that gets a payload data directly via USB/serial and sends this as a LoRaWan uplink message. This “bridge” works well on any Windows- or linux-computer, even an arduino can serve as a data source.
I was wondering, if some company already sells such a device in a nice housing, as our clients do not want to use DIY-devices. But I did not find anything usable.
This might fit your need. https://market.thingpark.com/catalog/product/view/id/339
You will need to implement network joins & connection state in your Arduino code
Network joins need managed in away that doesn’t kill the battery/overuse time on air in EU/other regions
Others that you might fit your need and do more of the LoRaWAN
That’s not really very possible, or at least not advisable.
While you can build a LoRaWAN protocol engine that interacts with a data source via a serial channel, the thing sourcing the data MUST be designed with an eye to appropriate LoRaWAN usage, particularly how much data to send how often. Something that merely tunnels a serial stream over the air is neither workable nor acceptable in the context of LoRaWAN.
There are many serial-connected LoRaWAN protocol modules on the market - no small number of LoRaWAN nodes incorporate one, rather than running the protocol stack on the main processor. As other commenters have pointed out, this requires the main processor to issue appropriate commands not just put data on the serial line.
Hy cslorabox, seems you misunderstood the task. The bridge is a full featured LoRaWan device, handeling the communication all by itself. Only the payload comes via Serial. Surely we have to respect the limitations of LoRaWan. But this is a simple way to transfer some sensor data if no other communication is usable.
As I mentioned, we did this on an arduino base. Just looking for a more professional solution.
Sounds okay if that is some compact binary payload, and if it only includes the details that are needed. But if it’s some text-based payload, then I agree that one-to-one translation to a LoRaWAN payload might not be a good idea, as that’s a waste of air time. Also, including things like a serial number in each uplink might not be needed, as the data can be matched to a DevEUI in the application.
we used the LMIC-Library to send data. Problem with serial is, that you do not really know if a message is finished. So we start a timer on the first byte from serial and reset the time with every new byte. The message is supposed to be finished, if there are no new data for one second. Then the buffer ist send.
Though I do not think it will help much, here is our main loop (myTimer is an own timer unit). We use softwareserial for communication, as it is handy to have some debug option.
uint8_t u;
boolean written;
void loop() {
os_runloop_once();
if (mySerial.available()) {
if (written) mdc=0; // delete after sent
u = mySerial.read();
mydata[mdc] = u;
if (mdc<52) mdc++;
myTimer.setInterval(1000); // reset timer for the next 1000ms
written = false;
}
if ( myTimer.timer() ) { // fires after 1000ms
myTimer.stop();
{
if (mdc <= 0)
Serial.println("Empty buffer...");
else {
Serial.print("Sending (");
for (int i=0; i<mdc; i++) {
Serial.print(mydata[i]);
if (i<mdc-1) Serial.print(", ");
}
Serial.println(")");
os_setCallback(&sendjob, do_send);
written = true;
}
}
}
}
Even though the characters are separated by commas: as this does not convert the bytes into, say, a hexadecimal format, and assuming this does not print garbage, this seems to indicate that the serial data was ASCII text. And that’s very likely to be quite a waste of bandwidth?
Sure, so you’re likely sending the same data that you printed to the debug output? And as apparently that debug output did not need any conversion to print it, that buffer seemed to be holding ASCII text? Unless the debug output showed quite a lot of garbage due to non-printable characters.
Anyway, @hediger and future readers: think twice before delegating a serial stream to LoRaWAN as is. If the serial stream is using ASCII text, then depending on the used characters, applying some inversed Base64 or maybe even Base32 might help decrease the payload length. But still then a serial stream, as is, might simply include data one does not really need to send at all. Also, when boldly forwarding data without interpreting it: how to determine which data can be dropped if the serial data exceeds the limits?
In many cases it will be better to have an intelligent bridge from serial to LoRaWAN, not some dumb forwarder. Or not use LoRaWAN at all. Just make sure to give it some thought before implementing anything.
Hello Arian,
no, we just sending the plain binary codes. This have to be decoded by a payload-decoder in ttn.
u = mySerial.read();
mydata[mdc] = u;
The debug output is just formattet for readability, like (50,22,17,10). It´s up to the payload decoder to convert these bytes back to JSON.
You are right, as LoRa bandwidth is limited, one should not forward plain ASCII. So, before sending, we have to encode our data, e.g. a temperature value as two byte binary etc… So in any case the “sender” (which is a raspi running node-red) needs some intelligence for the encoding and we need a fitting decoder on ttn.
The solution has big advantages for us anyway. We have been sending JSON before over WLAN and had lots of trouble with limited range. Now, we put an arduino LoRa-Head on the RPI, transfer decoded values to Serial and get the same data (encoded via TTN) as before. Al the lora-related stuff resides in the arduino, the solution is very transparent.
Shure, we need a decoder on the RPi and an encoder in TTN, but this is done in a minute on both sides, if you use NodeRed. So, we like the solution for its flexibility. Use LoRa where necessary, but also get the same results over WLAN is possible.
That was exactly what I said - your source has to produce a stream of data appropriate for LoRaWAN, it cannot simply ignorantly toss serial characters over the fence.
Once you have a serial source producing appropriate messages (length, rate, degree of redundancy), you should look at improving the interaction between the generator and the LoRa stack.
Probably you want to do this with a packet structure, ie, you have a reserved start sequence, then a byte count, then the actual payload, and then perhaps a checksum or terminating.
An even simple way to do this is to make the exchange on the serial line by printable ascii, with a hexdump of the actual message bytes, ie something like “SEND 2a 45 3c 59\n”. This not only solves the framing problem, it also gives you something that can be readily monitored during debug with a serial terminal.
The payload is a hex dump only on the serial line - the raw binary values the hexdump represent are what get put into the LoRaWAN packet assembler.
Also keep in mind that the maximum legal (in some places) or sensible (everywhere) LoRaWAN packet depends on radio conditions, so you may need feedback from the LoRaWAN stack to the data source.
For future reference: Dragino’s RS485-LN allows for configuring the RS485 commands that trigger one or more serial devices to do their work, and next allows for mapping their responses into a single combined small LoRaWAN payload:
3.3.3 Configure read commands for each sampling
During each sampling, we need confirm what commands we need to send to the RS485 sensors to read data. After the RS485 sensors send back the value, it normally include some bytes and we only need a few from them for a shorten payload.
To save the LoRaWAN network bandwidth, we might need to read data from different sensors and combine their valid value into a short payload.
I’ve not read all of that documentation, but that feels like a good approach if the sensor’s protocol is not ASCII based.
A bit late to the party, but maybe it helps you and/or others in the future!
COBS (Consistent Overhead Byte Stuffing) is a minimal overhead encoding scheme (2 bytes for short messages of less than 254 bytes, which a lot of LoRa packets should be I guess) that allows you to easily conclude the end of a transmission, and would probably work well in your situation.
Bytes with a value of zero end up being encoded as a non-zero value, and the message is then terminated with an actual zero byte.
Its very easy to implement the encoding and decoding in just a few lines of code, and means you dont need to rely on timeouts to assume the end of transmission. Probably you could use a timer to terminate a packet that is being received as an error if the zero byte is not received within the timeout period instead.
LoRaWan packets are encapsulated in LoRa packets in such a way that they already have length encoding. As such, sending another length encoding over the air is an inappropriate inefficiency (they also have about 7.5 bits worth of “purpose” encoding available for free in their port number)
The place a length encoding might make sense is on the local serial link between the data producer and the LoRaWan stack. But that’s so many orders of magnitude faster than the radio itself, and needs to consider contextual details of state, that convenience is more important than efficiency - there one might as well use something printable like hex encodings with newlines to describe the data that will then be sent in binary form as the actual packet contents.
The appropriate way to solve the actual application need would be to have something like an AT-command based LoRaWan stack interacted with over serial by a data source aware of the limitations of and proper behavior with LoRaWan, even if it delegates the actual implementation of LoRaWan to the canned stack.
Simply tunneling serial over LoRaWan doesn’t work - something that understands the limitations of LoRaWan first needs to produce appropriate messages.
Just to be clear: Surely there are strong limitations to the LoRaWan protocoll, so messages should be less than 50 bytes. That means, you will need an encodert for your messages and an appropriate deconder for TTN. But this is usually easy. Think of a simple thermometer. Two bytes are enough to send the data. But this is easy, if your deice is any programmable unit like an arduino or whatever.
The hard part is to enable your device to use LoRaWan. You may use some SX1272 board and start to download the LMIC.library, but this may be a bit tricky. Using a serial enabled LoRaWan unit and feed the data over serial would be much easier.
There are some options for this (beside the ones given above) with RS232 or RS485
Ursalink UC1152 and UC11-N1 (with akku) can do the job
USR-LG206-H
Dragino RS485-LN
A cheap do-it-yourself-solution can be
TTGO T-Display ESP32
I tried also
Dragino lsn50, a very nice package at an affordable price, but did yet not mange to reprogram the STM32
Using a serial enabled LoRaWan unit and feed the data over serial would be much easier.
That’s still mischaracertizing it.
You can’t put a serial stream through LoRaWan; what you can do is have something that truly understands the limitations of LoRaWan (both the uniform ones, and the contextual ones that depend on the currently needed spreading factor), which hands off suitable packet payloads at contextually appropriate times to a LoRaWan stack.
That handoff can indeed be accomplished over a serial UART, as many of the AT-command solutions do.
But it’s a serious mistake and misrepresentation to imply that there does or even can exist any LoRaWan box into which it is appropriate to feed generic serial data. Even if the source data size and rate is appropriate, it’s still unwise to have the flow not be contingent on the current state of the LoRaWan protocol.
Serial interfaced LoRaWan stacks are sensible and common; but serial to LoRaWan bridges cannot meaningfully exist - that’s like trying to make a car that folds into a backpack.
(not that misrepresentation of fundamental facts ever stopped a manufacturer’s advertising department…)
