Arduino / RYLR998 - serial drop out

[Bnorm]

I have a problem wit my camera trap project. When an Infra red beam is broken a signal needs to be sent to a master box which in turn controls the camera. The problem is that not every event results in a signal getting through. About 7% dont. (randomly, not regular).
I rigged up a test code to repeatedly send the signal every second to study the situation more closely. FYI The problem existed before I introduced Software Serial.

There is a period of 150ms between TX and Rx which I understand is caused by the use of UART rather than SPI. I can live with this but I would much prefer it not to be there. I did not know about his issue until after I had spent my money. Live and Learn.

Tx code

#include <SoftwareSerial.h>
SoftwareSerial mySerial(6, 7);  // RX, TX
int LED = 4;
int IR_sensor = 2;  // input from IR sensor

void setup() {
  Serial.begin(9600);
  mySerial.begin(57600);
  pinMode(LED, OUTPUT);
  pinMode(IR_sensor, INPUT);

  Serial.println("serial working");
  mySerial.println("mySerial working");
}

void loop() {

  mySerial.println("AT+SEND=2,1,H");
  digitalWrite(LED, HIGH);  // setting led to high
  delay(50);
  digitalWrite(LED, LOW);
  delay(1000);
}

Rx code

//running on a nano on 5V 16Mhz
#include <SoftwareSerial.h>
SoftwareSerial mySerial(6, 7); // RX, TX

#define LEDPin 4

void setup() {
pinMode(LEDPin, OUTPUT);
Serial.begin(9600);
mySerial.begin(57600);
digitalWrite(LEDPin, LOW);
Serial.println("serial working");
Serial.println("RYLR_RX_v3.ino");
}

void loop() {
if (mySerial.available()) {
char c = mySerial.read();
if (c == 'H') {
digitalWrite(LEDPin, HIGH);
Serial.println("H received");
delay(50);
digitalWrite(LEDPin, LOW);
}
}
}

Circuit diagrams

Scope view

I have tried sticking capacitors across the RYLER power lines but it does not make much difference.
Any help greatfully received

[Bnorm]

sorry!
That was the wrong scope picture. Here is the right one.

[Bnorm]

The yellow trace is from the Rx pin of the Tx RYLR and the blue trace is from the Tx pin of the Rx RYLR

[J-M-L]

@Bnorm

There is a period of 150ms between TX and Rx which I understand is caused by the use of UART rather than SPI

what do you mean ?

Sending "AT+SEND=2,1,H" is sending 15 bytes, at 57600 bauds it will take ~2.6 ms

@Bnorm

The problem existed before I introduced Software Serial

how were you testing before? what really is the signal?

57600 is high for SoftwareSerial if you send lots of data and remember you can't receive and send at the same time. Is the module talking back to you?

[Bnorm]

This is what made me think that the delay may be caused by UART's

" srnet

6dpost #3

There will also be latency caused by the UART serial interface on the RYLR998 module which first has to receive the serial instructions and convert the data into instructions for the SPI based LoRa module, then the reverse happens on the receive side.

For minimum latency, use the standard SPI based LoRa modules which eliminate all the potential delays caused by the RYLR998 UART conversions."

Its a reply I got on an earlier post entitled "RYLR998 and Pro mini - Huge latency"
I assumed that this was the cause of the 150ms latency, it seems I may be wrong. As I said, I can live with that, but if its possible to be rid of it, I am all ears.

I rigged up the code that repeatedly sends the signal every second just for convenience. The proper code relies on a signal from an IR sensor to initiate the radio transmission.

[Bnorm]

I am not sure what you mean by "what really is the signal".
I chose H to represent te HIGH singnal from the IR sensor. The rest of the transmission is the required AT format needed to send the data.

The default baud rate for the RYLR modules is 115200. I saw on a youtube vid that some arduinos cant do this. So, just like on the vid, I reduced it to 57600. If this is still too high, I can reduce it further.

I am only using one way data. From Tx to Rx

[Bnorm]

PARTLY SOLVED
The page below, from the REYAX website explains the 150ms gap I was seeing. Well, sort of. My parameters wer 9,7,1,12 so I should have got 190ms delay. Close I suppose.
I am still suffering the 8% loss of transmissions though.