I am making a Lora-USB passthrough device using arduino and somehow I want to indicate that a stream over some data has ended.

So far I have done:

void onLoRaReceive(int packetSize) {
  if (packetSize == 0) return;          // if there's no packet, return

  byte[packetSize] buffer=[];

  while (LoRa.available()) {
    site_t recievedData=LoRa.readBytes(buffer,packetSize);

So what I want to know is how the software reading from the serial interface will know that a packet has ended; One way I thought is by sending an EOF byte but I am afraid of "rogue" EOF values in packet data.

An another way is to send the packet size through the Serial interface as well but how I will make it understand that what I am sending now is the size and expect X size of data?


LoRa has a moderate data rate and typically substantial gaps between packets, so a simple thing you can do is send the data as printable ASCII hex with newlines or other terminators.

This will just short of double the amount of data you have to move, but do so in a very simple and deterministic way, and you can crank up the serial baud rate to handle it, especially as the baud rate only actually "exists" between two ATmega chips within the Uno.

Another plus is that the data becomes human readable, which is handy for debugging, especially if you might want to intermix advisory messages and data.


What you need is some form of protocol. Some system that both ends of the communication channel agree on.

Most serial protocols use certain characters to indicate certain things, and indeed the ASCII character set has certain characters earmarked for certain jobs in communication, so it makes sens to use those.

One you can use is EOT - End Of Transmission - character 0x04. Note: there is no such thing as an "end of file character 'EOF'". That's purely a DOS construct.

And yes, you may wonder about a rogue 0x04 in the data stream triggering the end, and you're not the first to think about that. That's why there's character 0x10 - DLE. That's Data Link Escape. Its purpose is to tell the receiving end "The next character I send is a data character. Don't interpret it as a control character.".

So for every 0x04 in the data stream you should send 0x10,0x04 instead. Your receiver code then sees the 0x10 and makes a note that the next character should not be interpreted as a control character, but raw data.

Problem solved.

But what, you ask, about there being a rogue 0x10 in the data stream? Isn't that going to cause the same problem?

Yes. And you deal with it in exactly the same way. Just prefix it with 0x10. Since the receiver should then know to always interpret the next character as data, regardless of what it is, it will see the next 0x10 as data.

So as an example, sending the following data stream:


would be done as:


(Added 0x10s highlighted with brackets).

It can be good to use some of the other control bytes as well, such as SOH for Start Of Header, STX for Start of TeXt, ETX for End of TeXt, etc. You can then do such things as tell the receiver where the start of your packet is, and what the different bits of it are. Adding a header with the length and a checksum can also be worthwhile too, for increased reliability and data integrity.

  • I wonder also if FTDI devices also have in-protocol serial transmission handling and Arduino Serial interface offers these type of handlings out of the box. – Dimitrios Desyllas Apr 24 '18 at 22:07
  • Also in case of calues that are over a 7-bit ASCII range ( >128 ) should I escape it with 0x10 as well for example the 0xFF value? – Dimitrios Desyllas Apr 25 '18 at 20:56
  • 1
    Why would you want to? You only need to DLE the bytes that your protocol uses. – Majenko Apr 25 '18 at 20:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.