LoRa rylr890 packet receiving issues and SoftwareSerial question

[joshua_kolby]

Hello. I am working on a Arduino Nano based flight computer (I would classify myself as an intermediate at Arduino ide, I know what I am doing for the most part, but there is a good possibility that I missed something obvious). I am working on ways to send data from the flight controller to the ground computer (gps position, altitude, and speed). I am currently trying to get the Reyax Rylr890 to send this data. I followed this tutorial: https://how2electronics.com/reyax-rylr890-lora-module-with-arduino/ For simplicity before I add the rylr to the rest of my project, I am currently set up with the same exact code, wiring, and hardware that the guy in the tutorial uses. Both devices are plugged into the same computer through different com ports of course, but I tried using two different computers with no change in results.

This tutorial got me to successfully send data between the two rylr890s, however, I have run into an issue that I can not figure out. The incoming data is quite often corrupted. For example:
This is the correct data:

This is the next packet I receive with incorrect data:

You can see in the corrupted packet a period is turned into a /, a space is turned into a @, and a comma is turned into a /. I live in a rural area, so there is no radio traffic, and the devices are sitting about 1m apart with no obstructions, so the issue isn't that the data is getting corrupted on the way across the two devices. If I were just reading this data, it wouldn't be an issue because I would just be able to tell which packets were correct and which were not, however, in my case, I need all the packets to be correct. The receiving data is going to be sent to an SD card once received, then from there uploaded to google sheets or a similar program. Google sheets reads commas as where to put data into the next row. If the comma is switched out for a slash or period, sheets will not put the next data into a new box which will screw up the charts. I should note that this also happened in the tutorial I followed, but he didn't seem to care.

The next issue, or rather question, I have is for my project, I have to use SoftwareSerial because the gps already takes the default tx and rx pins. I know that if you use the default tx and rx pins with the rylr890 for AT commands, all you have to do it type AT+(whatever you need) into the serial monitor and you will get a response. However, it isn't that simple with SoftwareSerial. I assumed I could just use

  while (Serial.available()) {
    lora.println(Serial.read());     //I have also used lora.write(Serial.read()); here
  }

(lora being the SoftwareSerial) to put AT commands into the Serial, however, that doesn't appear to work since I get no response back. I can't imagine it is that hard of a fix, but I can't seem to figure it out.

Let me know if I missed any critical information necessary to fix my problems.
Thank you for your time!

[srnet]

@joshua_kolby

however, in my case, I need all the packets to be correct.

Then you need to be checking for packet CRC errors.

And mixing softwareserial with standard Serial output can cause problems that are difficult to deal with.

These UART based modules, such as the RYLR896, have unique interfaces, so unless someone has worked with that particular module, you may not get a lot of assistance.

However there will be plenty of examples of the type of setup you want, checking if packets are correct etc with the SPI based LoRa libraries. There are even fully worked and tested examples that will transmit and receive GPS co-ordinates etc.

[joshua_kolby]

Thank you for your reply!
This morning I started fresh and dived into a deep read of everything SoftwareSerial, Serial, and UART related. Instead of using the tutorial's code, I decided to make my own (which I probably should have done from the beginning). The first thing I fixed was the serial reading AT commands, as I figured it was an easy fix by just adding changing.

Serial.read();

to

Serial.readStringUntil('\n');

then sending this to the SoftwareSerial.
I was still getting bad data, even the AT commands were giving me stuff half the time like +O? instead of +OK. The rylr890 default baud is 115200, so I had everything set to 115200, but then I gave it the AT command to switch to 9600 baud then switched my code also over to 9600, and it started giving good data all the time. Why the change in baud made a difference, I don't know, but I won't complain.

[srnet]

@joshua_kolby

Why the change in baud made a difference, I don't know

Softwareserial is unrelaible at more than 38400baud

[Klaus_K]

@joshua_kolby

Why the change in baud made a difference, I don't know, but I won't complain.

Serial is an asynchronous protocol without a clock signal. The master can start a transmission at any time and there is no clock signal that tells the slave when a bit value is valid. Master and slave have a fixed baudrate but the clock source is not identical e.g., because of crystal tolerance.
After the first high to low transition the slave can assume when the bit data is valid within a time window that gets smaller and smaller for each bit. With higher bit rates that time window is smaller to begin with. This is true even for hardware UARTs. With software serial you get additional inaccuracies (depending the processor and chip architecture used) lowering the possible baudrates even further.
There are additional issues e.g., when the baudrate cannot be created exactly from the oscillator frequency.