Professional serial to LoRaWan bridge

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.

Any hint is very welcome.

This might fit your need.
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

I have the same requirement for industrial equipment using RS485 though
just about to try

I’ve not used it, but while searching for M-Bus LoRaWAN devices, I ran into

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.

If only for future readers:

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.

Hey EFthings01, As opposed to you I am looking for a non-professional solution based on Arduino. How did you solve this? is there a library available?



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() {
    if (mySerial.available()) {
      if (written)  mdc=0;  // delete after sent
      u =;
      mydata[mdc] = u;
      if (mdc<52) mdc++;
      myTimer.setInterval(1000); // reset timer for the next 1000ms
      written = false;

    if ( myTimer.timer() ) {  // fires after 1000ms
        if (mdc <= 0)
          Serial.println("Empty buffer...");
        else {
          Serial.print("Sending (");
          for (int i=0; i<mdc; i++) {
            if (i<mdc-1) Serial.print(", ");
          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?

Serial.print is only the debug output. The buffer “mydata” ist sent here:

os_setCallback(&sendjob, do_send);

as mentioned, it´s only to give a general idea.

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 =;
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.

1 Like

Ah, my bad, that code is printing as decimal values! :+1:

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.