SX1278 LoRa exmples compiling. Transmitter emits signal but Receiver getting timeout in a loop

[kocinski15]

Doing simple test of library usability i tried a pair:
[SX127x_Receive_Blocking] / [SX127x_Transmit_Blocking] in LoRa mode
Mcu used is STM32 with Arduino lib.
Code compiles fine. Transmitting side seem to emmit some signal visible on the SDR receiver in the correct band.
Receiver goes into an endless loop of Timeout error.
Example code used as it is from the directory.
Tested on two different types of SX modules. Ra-01 and RFM98HW
Modules work fine when used with other library eg. LoRaRF.
Arduino latest / RadioLib library latest as of this moment.
Library does not allow any control over paket size, or am I missing something?

[jgromes]

Please fill in the information requested by the issue template.

Receiver goes into an endless loop of Timeout error.

Timeout is not an error, it just means that the receiver did not hear anything in the time window it was receiving, that's it. Did you try with interrupts?

Library does not allow any control over paket size, or am I missing something?

I don't know what you are trying to say here - the library transmits the packets you provide, if you reqeust to send 15 bytes it will send a 15 byte packet + preamble/header/CRCc, which again is set by yourself. You have absolute control over the packet size being sent.

[kocinski15]

Receiver goes into an endless loop of Timeout error.

Timeout is not an error, it just means that the receiver did not hear anything in the time window it was receiving, that's it. Did you try with interrupts?

No I haven't tried with interrupts. I would like to stick with one interrupt (is it interrupt or poll ? ) line DIO0 which is required. Polling mode on the receiving side is fine for me.
Without DIO0 declared and connected transmitter signals Timeout. So in the test setup both sides use DIO0.
If not being forced by library requirement I would be fine without DIO0 on the trasnmitting side too.

Data is being sent in the loop by the transmitter device every second and once it is received by the receiving side SX1278 it should be seen in the nearest receiver's loop . It isn't. It always ends up with continuous timeout regardless of trasmitter being on or off.

I don't know what you are trying to say here - the library transmits the packets you provide, if you reqeust to send 15 bytes it will send a 15 byte packet + preamble/header/CRCc, which again is set by yourself. You have absolute control over the packet size being sent.

That is clear now. In other devices with UART like Ebyte E22 they use predefined packet length so i thought there is some distinction between stream and packet modes. As I now understand there are always packets of arbitrary length that can be different every transmission event.

[jgromes]

is it interrupt or poll ?

In interrupt mode, it's an interrupt, as the name suggest. In blocking mode, the pin is polled.

No I haven't tried with interrupts. I would like to stick with one interrupt (... ) line DIO0 which is required.

Packet reception is signaled on DIO0. On the contrary, timeout is signaled on DIO1, or handled by software if you did not provide DIO1.

Polling mode on the receiving side is fine for me.

Then you will see timeouts. That's just what blocking mode is.

once it is received by the receiving side SX1278 it should be seen in the nearest receiver's loop

That's not how this works. If the receiver is not receiving while you are transmitting, then you will not get the packet. And when the receiver times out, it will no longer receive, until reception is restarted. That's the base of the blocking mode. With interrupts, the receiver is listening continuously and triggers an interrupt when it receives a packet.

Also, this is not an issue in the library, but a generic question about usage, so I'm converting this thread to a discussion.

[StevenCellist]

There is a large difference in how timeout is handled internally between SX127x and SX126x. You can generally assume that RadioLib is working fine - it already has for at least hundreds of people, including myself.
The SX127x series timeout is given in number of symbols, while the SX126x series timeout is given in microseconds. There are a lot of fundamental differences that you can't just compare between one and the other.

[StevenCellist]

I think you should really take a look at your 'wiring' - either the actual wiring, or the pinout that you provide to RadioLib. The problem is definitely not with RadioLib is that really works fine - it is the interface between the MCU and the radio that is the critical point here, very likely.

[kocinski15]

I made small modification to the library code to print calculated Timeout value. It shows 409 in my setup case.
It seems vary small number. It is compared to microseconds to check for Timeout. I think something is miscalculated. Timeout of 0.4msec is definitely wrong.

// if no DIO1 is provided, use software timeout (100 LoRa symbols, same as hardware timeout)
uint32_t timeout = 0;
if(this->mod->getGpio() == RADIOLIB_NC) {
float symbolLength = (float) (uint32_t(1) << this->spreadingFactor) / (float) this->bandwidth;
timeout = 100*symbolLength;
Serial.print(timeout);
}

[StevenCellist]

Once again: the SX127x series uses a timeout in number of symbols which is not equal to number of milliseconds nor microseconds. The length of a symbol depends on spreading factor and bandwidth, but can last anymore between less than 1 milliseconds to 10s of milliseconds. Please, assume that RadioLib does this right and look for solutions in your hardware.

[kocinski15]

The hardware is checked as much as it can be. It is working nicely with other example code 'Receiver with Interrupt'. So I can assume it is more than enough for "Receiver Blocking" example.

[kocinski15]

The SX127x series timeout is given in number of symbols, while the SX126x series timeout is given in microseconds. There are a lot of fundamental differences that you can't just compare between one and the other.

Looking and the code I can not agree with this statement. Timeout values are compared to microsecond clock in both cases and they are calculated in the same algorithm. There is just this 1000 factor outstanding.

[jgromes]

@kocinski15 thanks for pointing this out, that is indeed incorrect. The bandwidth is in kHz for both SX127x and SX126x, so the resulting symbol time is in ms, hence the multiplication by 1000 in SX126x which is missing for SX127x. I pushed a fix addressing this.

I think the issue went unnoticed mostly because blocking mode is rarely used, since it does not offer any advantages over interrupts.

[kocinski15]

I am glad to contribute to your ingenious piece of software.

[kocinski15]

blocking mode is rarely used, since it does not offer any advantages over interrupts.

I agree. To make it useful another mode could be done to name it Poll as oppoosed to Blocking. Basically Poll mode would be similar to interrupt with one exception. Instead of interrupt signal, 'Ready' condition would be determined by polling status. It could be useful in cases where interrupt line is not available.
That is how I initially wrongly assumed your Blocking mode is working.