search

jgromes / RadioLib

Universal wireless communication library for embedded devices
https://jgromes.github.io/RadioLib/
MIT License
1.49k stars 378 forks source link

CRC errors when sending more than 1 packet per second #179

Closed Niels-Clayton closed 4 years ago

Niels-Clayton commented 4 years ago

When using the library to send packets from one ESP8266 with an RFM98 to another, It is possible to transmit a packet more than once per second, but not possible to receive the packets without CRC errors. To correctly receive a transmission, a 1000ms delay must be used on the receiver end to decrease the sending rate.

Do you know of any ways to increase this sending rate? I would ideally be able to send upwards for 20 packets a second.

I am using the default settings on both of the RFM98 modules:

Module type Carrier frequency Bandwidth Spreading factor Coding rate Sync word Output power Preamble length
RFM96/98 434.0 MHz 125.0 kHz 9 4/7 private network 10 dBm 8 symbols

Additional info (please complete):

jgromes commented 4 years ago

It's hard to guess without seeing the code, but the better question is - why do you want to do this? LoRa was designed for low data rate, and long range, it seems that something like FSK (which can be done with RFM9x modules) would be better suited to your needs.

jgromes commented 4 years ago

Closed due to inactivity.

whoim2 commented 1 year ago

Perhaps this topic is best suited for my questions. In short - I am building a radio control system, both one-way and with the preservation of the transmission of back telemetry data. And back and forth I send packets of 16 bytes. One way mode I call rx_silent. Initially, I used two versions of FSK to make the "further slower" and "closer but faster" modes, and everything works well. Now I decided to add an "ultra far" mode using LORA. I used 125 width, 7/5 sp cr. And here is the strangeness.

If I'm working in two-way mode, everything is fine. TX (ground side) sends data, RX (RC side) receives this data and after 10ms sends a response packet with telemetry, which is successfully received by the TX side. But as soon as I turn on rx _silent - the TX side sends packets at a certain frequency and that's it, the RX side only receives them and does not send a response - I get the RADIOLIB_ERR_CRC_MISMATCH error on the RX. Although the timings are all the same. In the two-way version, during this time, TX and RX manage to exchange data in both directions, and in the one-way RX cannot receive a single packet from the TX. This is weird.

whoim2 commented 1 year ago

An interesting result of the experiment. I used implicitHeader to save a little time. In two-way mode this works well, but in one-way mode it throws an error as described above. If I exclude the implicitHeader call in rx_silent, then everything works. I definitely don't understand what's going on.)

jgromes commented 1 year ago

@whoim2 I would need to see the code. In general, both sides of the link have to be configured in the same way (e.g. both must have the same header mode).

whoim2 commented 1 year ago

I found the problem it seems. It has something to do with startTransfer, the second parameter is the size of the transferred data. When I fiddled with fsk, I found that I had to transfer one more byte for the reception to succeed. Perhaps this has something to do with the fact that char buffer must end in 0x00? I am using byte buffer type.

When I switched from beginFSK to begin (lora mod), everything worked stably without a header with a predictable size of the transmitted data. The rest of the problems, apparently, due to my poor-quality approach to testing and confusion.

I also found that I could not change the frequency at any time in Lora, as I do in FSK. Calling setFrequency or begin, even if the same frequency is specified after a successful reception, causes no further receptions.

I'll sleep and continue experiments, maybe I don't see my mistake ) The code quickly grew, became big..

jgromes commented 1 year ago

It has something to do with startTransfer, the second parameter is the size of the transferred data

Depends on which startTransfer you are using. For strings, the length is inferred from the string length. For byte arrays, it must be set explicitly.

When I fiddled with fsk, I found that I had to transfer one more byte for the reception to succeed (...) I also found that I could not change the frequency at any time in Lora, as I do in FSK

Again, I would have to see the code to comment on that.

The code quickly grew, became big..

Then I would suggest to get just the communication working right in the minimum needed configuration, and then build off of that.