First of all, I love that this project exists. I have done some custom LoRa mavlink RTK correction links and have been wanting to do a generic LoRa based telemetry radio. I used the STM32WLE5JC with the built in LoRa radio and STCubeMX radio middleware.

I would be interested in producing hardware using this module and getting mLRS running on it.

https://www.seeedstudio.com/LoRa-E5-Wireless-Module-p-4745.html

Hi @olliw42,

Here you will find a cleaned version of the first PR.

PS: For the time being the R9MM is my favorite target as "Sik-radio-replacement". It's even smaller and lighter. And I have a few laying around here back from the days you got one free with any Frsky-order.

The cause of the large bursts of lost frames on the R9 Tx side turns out to be a problem on the Rx side. But it's not a difference with the radio chip. It's a difference with the STM32 controller used. The code in clock.h assumed that TIM2 has a 16 bit wide counter, but on the STM32L4, TIM2 is 32 bits wide. So, when Reset() is called, after CNT is larger than 2^16, the timer never fires and the receiver looses sync when the next frame is lost.

Note, I was unable to test this code on other receivers so this still needs testing. I'm guessing that passing 0xFFFFFFFF in tim_init_up is ok even for 16 bit timers and that it will be truncated, but I haven't actually checked to be sure.. This is probably also not the only way to fix this bug.

I still see many more lost frames on the Tx side than on the Rx side. Do you see this with other transmitters?

@Imen-D wrote here https://github.com/olliw42/mLRS/commit/92bcd2f914d1a90380ead24ed95fde947141a73e#commitcomment-67754991

Hi olliw, with this commit I can't do write fast mission anymore, is this related ?

hmmm .... it all should work as before

can you pl tell me what "write fast mission" is? you mean, writing missions is not fast anymore, but very slow?

not sure you've noticed: the setup parameters have changed, you need to set now BOTH SETUP_RX_SERIAL_LINK_MODE and SETUP_RX_SEND_RADIO_STATUS to 1. Maybe it's just this?

@Imen-D

it would be great if you could test this:

it is about these code lines https://github.com/olliw42/mLRS/blob/main/mLRS/CommonRx/mlrs-rx.cpp#L729-L736

#ifdef DEVICE_HAS_SX127x
      if ((connect_state >= CONNECT_STATE_SYNC) || (link_state == LINK_STATE_RECEIVE)) {
#else
      if (connect_state >= CONNECT_STATE_SYNC) {
#endif
        sx.SetToIdle();
        sx2.SetToIdle();
      }

for the SX1276 I found that one needs to call SetToIdle() also when link_state is being switched to LINK_STATE_RECEIVE in the doPostReceive handler. I wonder if the code can be simplified, i.e., if the define can be removed and the same code be used also for the SX1262

I thus would kindly ask you if you could test it for your system if it would also work with this change

      if ((connect_state >= CONNECT_STATE_SYNC) || (link_state == LINK_STATE_RECEIVE)) {
        sx.SetToIdle();
        sx2.SetToIdle();
      }

Secondly, I wonder if calling SetToIdle() is needed at all for the SX1262, that is, if it would work if one would just remove (out-comment) these lines completely (in this case one could define SetToIdle() to be just an empty function for the SX1262)

THX!

Hi Olliw, this is me jinchuuriki on rc groups As we enter the rx function, I forgot to re start the rtc timer, so interrupt based on rtc timer (time out) can't fire anymore.

… eliminate occasional lost frames on the R9M!

I have not even compiled this for targets other than R9M and R9MX. Please let me know if I broke anything and if this eliminates lost frames on the R9M as it seems to do for me.

https://github.com/olliw42/mLRS/blob/e0f8f91486ef010261720bb82fdebf697f5ff374/mLRS/CommonTx/gdisp.h#L110

It is suspected that the gdisp variable is created here. The gdisp variable is defined in gdisp.c file, and in disp.h file "extern tgdisplay gdisp;" Can be compiled and passed.

@Imen-D

I have just pushed support for the 31 Hz mode. On the Sx1280 it appears to work great. Could you test it also for the SX1262? All you need to do is setting the mode in common_config.h

THX in advance :)

Sx1262 setTxParameter (power) use actual value in dbm. with set PA config to max 22dbm we have range -9 to 22 dbm and value we pass on setTxParameter is actual value (-9 ... 22)

I have been paying attention to the progress of the mlrs project, the hardware preparation is completed, but the radio configuration still does not understand the working principle. I noticed that the author is testing the mlrs hardware on the opentx mavlink branch. Does it mean that the opentx main body is not supported? Currently using edgex2.6 Chinese version, FM30 transmitter and DIY E28-F103C8T6 receiver, the hardware is working normally FM30 transmitter green light flashes, receiver 3 serial ports only have debug content, serial No. 1 is not detected SBUS signal. Does the FM30 hardware need additional modification?

I tried myself on flashing a r9m tx module with just a opentx remote, or rather like elrs is doing.

What I found out:

• fkr files are bin files with a header that can be used for flashing an app (not bootloader), this works with the original and the elrs bootloader. The files have a 16byte header that is detected by opentx and the app in binary. (This pr adds a modified version of the elrs script)
• elrs files are bin files without a header that also can be used for flashing an app, this only works with the elrs bootloader.
• The elrs bootloader is flashed by using an app that overrides the bootloader on first startup.
• I don't know what exactly is different between the two bootloaders (appart from the elrs files), but one is opensource https://github.com/ExpressLRS/ExpressLRS/tree/master/src/bootloader/src so that one should probably be prefered.

It sadly doesn't just work to convert the mlrs hex file to a bin file and then to a frk or elrs file, I guess because the mlrs hex file also includes a bootloader (and maybe other offsets are wrong). I think the preferred way is to use the eLRS bootloader and provide elrs files that only include the app. I have no clue on how the use the stm32cubemx software, so it would be nice if someone could help me with building an app only bin file.

When a frame is lost, the parser may be in the middle of parsing a message. We should reset it to start looking for the next frame so it doesn't discard all or part of the next message(s) while trying to finish accumulating the damaged message.

@olliw42 , you didn't say yet what you concluded after our call. Perhaps you are still thinking about it. But, I'm submitting this here anyway for further discussion.

The high frame loss of the current R9M seems at first a good environment for test, but the loss is so inconsistent that it's hard to judge the improvement. When I averaged the time required to download parameters for 12 runs with and 12 runs without this change, the average showed a little less than a second improvement, so, at least this code didn't make it worse.

In any case, this needs a good code review before possible merge.