FLRC high rate mode

[olliw42]

@jlpoltrack has added FLRC support to the sx1280 library, see PR olliw42/sx12xx-lib#6, and also did a basic proof of principle, see his branch https://github.com/jlpoltrack/mLRS/tree/FLRC-Proof-of-Concept.

This thread is for discussing details of a possible implementation of a FLRC mode.

Some random notes:

• It was noted that one needs to pay attention to rates handling, Note | High Frame Rates #84
• the disp handling on tx moduels need so attention too, but this hopefully is already adressed in commit 628ad35
• @jlpoltrack's work suggests a 100 Hz mode. I would be more fond of a 150 Hz mode, looks feasible to me but may be somewhat more challenging. This discussion here may sort this out.

[jlpoltrack]

I spent some more time on this - I've got 125 Hz working on the bench (well almost 100%) and think this would be a good compromise. Details below:

From the RF side, I mocked up some FLRC configs that would work. Limitations are that frame time (1 / rate) is defined as an integer https://github.com/olliw42/mLRS/blob/main/mLRS/Common/setup_types.h#L321 so are somewhat limited in what's available and 2100 uS is reserved for overhead on each packet:

If had to choose one, 125 Hz makes the most sense to me, as:

• 125 Hz only sacrifices 1 dB of sensitivity vs 100 Hz FLRC and 2 dB vs 50 Hz LoRa
• 143 Hz + sacrifices at least 3 dB of sensitivity vs 125 Hz FLRC, more vs others

125 Hz would also have plenty of capacity for even a 230400 baud connection to the FC:

I got this working by increasing the Tx to radio connection to 921,600 baud which allowed for 2ms gaps in this switch statement: https://github.com/olliw42/mLRS/blob/main/mLRS/CommonTx/crsf_interface_tx.h#L317 and borrowing the 50 Hz mode slot for testing.

The only issue is that the Lua seems to need further throttling as I always get a few errors at 125 Hz. 100 Hz had issues as well but did work roughly 1 out of 3 times. Any hints on how to slowdown the Lua would help - should this be a bigger number? (https://github.com/olliw42/mLRS/blob/main/lua/mLRS.lua#L489)

[olliw42]

interesting!

first off, I guess you are using the same frame structure. I would think need a new frame since the FLRC frame has already a syncword (and even 32 bit) and a crc, so 4 bytes are obsolete. Not a lot, but on the order of 5%

I think we only should consider 0.65 and lower, not 1.04 or 1.3, sinc ethen the bandwidth is larger than 1 MHz and we probably would also have to fool with the fhss table.

for some reasons I can't get your OTA values. Could you specify the other relevant settings?
I have 1, 32, 91, 2, disabled in the CalculatorUI.

the connection radio <-> tx module is going to be a bit of a problem. You metion raising to 921,600 baud. I'm not sure I can do this with OpenTx, need to test. I'm also not convinced that such high baudrates will help with the reliability. EdgeTx has put in some specific code to "better" parse CRSF frames since they see misses (whichthey apparently can't really explain, or mitigate otherwise). So I'm not yet totally convinced that's the way to go. Note that I would also want mbridge to work, here the reliability requirements are higher, like 100% reliable :).
I think that we rather should go to an approach where we do not send e.g. a link statistics every cycle. I mean, we are not really in the bussiness of this 1000Hz craziness, getting the linkstats to the radio every 2nd or 3rd cycle shoud be really fine.
Along the same line, I think it's the wrong approach to tame down the lua script, I think one should tame things down in the tx c code.
I'm not sure that's all one would have to do, but like calling the crsf handler just every 3rd cycle if it's 150Hz mode.

my "objection" to 100 Hz is that it isn't like "wau", I mean, so what, a factor of two in the rates ... I would be more impressed with 150Hz ... the next lower margin maybe is 133 Hz LOL ... for sure that's pure psychology and not technical argumentation at all LOL

I'm not really concerned about even -3 dBm as compared to 50 Hz ... I mean, it actually would better fit the pattern:
19 Hz = -112 dBm
31 Hz = -108 dBm
50 Hz = -105 dBm
xx Hz = ???
Q: What is the next value? LOL
so we would have modes which give you more for each 3 dBm...

If we have to fool with the frame, we also could consider using e.g. 127 bytes payload. Just as a thought for exploration.

Also, do we really need 2.1 ms gaps? These >2 ms came about since for the LORA modes there wasn't really much to gain so I rather played it a bit safe.

[jlpoltrack]

for some reasons I can't get your OTA values. Could you specify the other relevant settings?
I have 1, 32, 91, 2, disabled in the CalculatorUI.

Will read through more later, but at least for this question I used 4 bytes for AGC Preamble and 91 bytes for payload (this is 1663 uS above)

Per the datasheet need at least 2 bytes for AGC Preamble and since there is extra buffer in the time figured that it couldn't hurt to have 4:

[olliw42]

ah, the 4 bytees makes the diffrerence :) THX
but we can go to 87 bytes payload. So let's settle for the discussion - just for the moment - on these 4/32/87/2/disabled
:)

[jlpoltrack]

Certainly agree that what you've outlined is a better way to do the Tx<>radio piece, so will leave that for the moment.

my "objection" to 100 Hz is that it isn't like "wau", I mean, so what, a factor of two in the rates ... I would be more impressed with 150Hz ... the next lower margin maybe is 133 Hz LOL ... for sure that's pure psychology and not technical argumentation at all LOL

ELRS terminology counts all of the packets, so what is called 100 Hz would be 200 Hz and 125 would be 250 :)

I'm not really concerned about even -3 dBm as compared to 50 Hz ... I mean, it actually would better fit the pattern:
19 Hz = -112 dBm
31 Hz = -108 dBm
50 Hz = -105 dBm
xx Hz = ???
Q: What is the next value? LOL
so we would have modes which give you more for each 3 dBm...

If 2 modes make sense, then could have 125 and 143 Hz (using no FEC, see note below about packet size):

The sensitivity options for .65 bandwidth are -99, -103, -104.

first off, I guess you are using the same frame structure. I would think need a new frame since the FLRC frame has already a syncword (and even 32 bit) and a crc, so 4 bytes are obsolete. Not a lot, but on the order of 5%

If we have to fool with the frame, we also could consider using e.g. 127 bytes payload. Just as a thought for exploration.

I tried a few things with packet size and found that because the frame times aren't very granular at these high rates can actually get away with the current packet size. Although there must be some theoretical gains from a packet that is smaller.

Also, do we really need 2.1 ms gaps? These >2 ms came about since for the LORA modes there wasn't really much to gain so I rather played it a bit safe.

I'm not sure how to test this, perhaps could measure this with debug or a GPIO changing state that could be measured on the scope?

[olliw42]

I think we can go to 1.7ms gap and then use 0.65, 3/4, with 87 bytes at 150Hz
restriction from granularity should be resolvable, but I guess 125 Hz or 143 Hz might at the end turn out to be a good choice (as you say 125 Hz it is 250Hz in ELRS units LOL)
I'm not a fan of 1000-ends of modes, mLRS is complicated enough already, so I think one FLRC mode should really be enough
I did plenty (like in P L E N T Y) timing measurements, simply did printouts of timestamps (some results I've put into design decissions)

so should we for the moment go with 143 Hz and the said settings? When we find it's to tight we could easily lower to 125 Hz, or then it works well and issues got sorted out, we still can evaluate what it would involve to go to 150 Hz instead.

0.65, 3/4, 4, 32, 87, 2, disabled?

[jlpoltrack]

0.65, 3/4, 4, 32, 87, 2, disabled?

Works for me, I have 0.65, 3/4, 4, 32, 91 (original packet), 2, disabled at 143 Hz working on the bench and interestingly all the Lua problems went away (still using 921600 and 2 ms gaps). Only thing I'm noticing is that TQly is consistently in the 95 to 99% range.

Update:

TQly seems to stay in the 95% range when the Coding Rate is set to 3/4, I tried out 0.65 at 1/2 (at 100 & 125 Hz) and TQly didn't drop below 99%.

Note for self, RQly had no issues but it is only measuring up to crc1: https://github.com/olliw42/mLRS/blob/main/mLRS/CommonRx/rxstats.h#L33

Updated proof of concept branch: https://github.com/jlpoltrack/mLRS/tree/FLRC-Proof-of-Concept

[jlpoltrack]

Couple of quick notes:

• FLRC has no SNR, so this code needs logic depending on RF mode: https://github.com/olliw42/sx12xx-lib/blob/main/src/sx128x.cpp#L310 otherwise incorrect RSSI will be returned.
• Should consider raising the FHSS channel max: https://github.com/olliw42/mLRS/blob/main/mLRS/Common/fhss.h#L22 plan to try 50 hop channels next.

[olliw42]

Works for me, I have 0.65, 3/4, 4, 32, 91 (original packet), 2, disabled at 143 Hz working on the bench and interestingly all the Lua problems went away (still using 921600 and 2 ms gaps). Only thing I'm noticing is that TQly is consistently in the 95 to 99% range.
Update:
TQly seems to stay in the 95% range when the Coding Rate is set to 3/4, I tried out 0.65 at 1/2 (at 100 & 125 Hz) and TQly didn't drop below 99%.

I can't explain but this sort of arbitrary behavor strongly suggests that there is a fundamental issue somewhere in the code, probably timing

FLRC has no SNR, so this code needs logic depending on RF mode

this IMHO should be done higher up, i.e., here I would add a function GetPacketStatusFLRC

[olliw42]

@jlpoltrack
I'm trying to work on that and to make it fit a bit more into the structure. Questions pl

• the TOA is given as 3367. I calculate however 1663. So it seems your values is 2 times that. What's up?
• there is also the option SX1280_FLRC_CRC_DISABLE, why not using this? I think with crc enabled we would have to modify the ISR to check also for crc error, don't we?

I can't yet get it to work. it hangs up. As much as I could see there are only changes in sx128x_driver.h, and the baudrate for jrpin5. Or do I miss anything important, which would make it hang up for me?

[jlpoltrack]

• the TOA is given as 3367. I calculate however 1663. So it seems your values is 2 times that. What's up?

This was just a hardcoded value I forgot to update - is TOA used for anything?

• there is also the option SX1280_FLRC_CRC_DISABLE, why not using this? I think with crc enabled we would have to modify the ISR to check also for crc error, don't we?

Hehehe, the calculator doesn't have this option so I missed it. Yes, we should use this instead.

I can't yet get it to work. it hangs up. As much as I could see there are only changes in sx128x_driver.h, and the baudrate for jrpin5. Or do I miss anything important, which would make it hang up for me?

Did you see my changes to crsf_interface_tx.h ? The original logic will prevent these fast updates from working: main...jlpoltrack:mLRS:FLRC-Proof-of-Concept#diff-c2a2a9daf28d200b24703012c9c608597d9ce3b14d42f7e722a1ffe656417e15R310

[olliw42]

THX

it is working now for me!!! it was a totally dump mistake which I'm not going to tell LOL

Did you see my changes to crsf_interface_tx.h

I have set ChSource to none momentarily, to avoid any such issues. Want to go through it step by step :)

I'm using btw my sx1280 modules, i.e., naked sx1280 chips.
I currently have min power at -128 dBm. I do see also that LQ isn't so0lid 100%, and the rssi's are reported at -97 ... -101 dBm ... which is a staggering 30 dBm lower than what I get in the Lora modes!! So it seems that the power is not getting out ...

anyway, key message: It is doing something :):)

[jlpoltrack]

I currently have min power at -128 dBm. I do see also that LQ isn't so0lid 100%, and the rssi's are reported at -97 ... -101 dBm ... which is a staggering 30 dBm lower than what I get in the Lora modes!! So it seems that the power is not getting out ...

This is because the RSSI calc is wrong :), set the SNR to 0 here for real values: https://github.com/olliw42/sx12xx-lib/blob/main/src/sx128x.cpp#L310. This was fun to see while I was flying.

[olliw42]

ah, it needs to be changed in the sx12xx-lib .. THX

well, then we have that issue that LQ is not as solid as it is in lora mode ...

[jlpoltrack]

well, then we have that issue that LQ is not as solid as it is in lora mode ...

Are you seeing issues with RQly? I saw only TQly being not great. I also found much better results using 1/2 Coding Rate (at 100 Hz).

[olliw42]

Are you seeing issues with RQly? I saw only TQly being not great.

it looks as if the LQ reported by the tx is more often below 100% than that reported by the receiver (I don't want to talk about R/TQLy since I do not have crsf yet working, that's what I see on the OLED), but that's not really sicentifically taken data.
But the receiver's LQ can also jump below 100%, so it's not like it is absolutely just onesided

I have noted that enabling the diversity did help quite a bit. So, at this moment it seems like the transmission is indeed just not so great.

I ownder if that's somehow related to the x-tal accuracy. I mean, the SxConfigurator gieves an estimate for how accurate it needs to be and it is essentially impossible to achieve, ± 0,15 ppm. Not even most TCXOs do that. There had been some noise on this in the web, but I haven't followed up and don't know what the final outcome/conclusion is.

anyway, I think we first want to get all the other pieces in the code working fine, and then come back to iron out what's up with FLRC

[jlpoltrack]

I ownder if that's somehow related to the x-tal accuracy. I mean, the SxConfigurator gieves an estimate for how accurate it needs to be and it is essentially impossible to achieve, ± 0,15 ppm. Not even most TCXOs do that. There had been some noise on this in the web, but I haven't followed up and don't know what the final outcome/conclusion is.

anyway, I think we first want to get all the other pieces in the code working fine, and then come back to iron out what's up with FLRC

This number also seemed small to me (OCXO territory) but I wonder if the calculator is wrong here, the relevant section in the datasheet says +/- 30 ppm or 10 ppm per radio:

Regardless, just glad to have made it this far :)

[olliw42]

yo, but even 10ppm is in TXCO range, normal XCO are substantially worse

just glad to have made it this far :)

ABSOLUTELY!

[olliw42]

I have pushed what I currently have to here https://github.com/olliw42/mLRS/tree/dev-flrc

It's basically your additions, just a bit better intergrated, i.e., there is a dedciated 143 Hz mode now, which you can set like the other modes (cli, lua, oled)

I also made an attempt at slowing down the crsf. And for much it appears to be ok. However, I consistently do get "IRQ2 RX DONE FAIL" hang ups when I have diversity activated and use the lua script. So, there is something not ok with the timing, and I guess it will be a difficult work to iron this out.
I'm not sure I will be able to do that soon, hence I thought IO should push it to share it.
I did the work on my tx-diy-sxdual-module02-g491re tx module (the rx is a rx-diy-board01-f103cb, but the rx code seems to work without issues).

I would like to encourage you to streamline your branch, since ventually this shoudl be a PR by you to keep teh credit.

[olliw42]

@jlpoltrack
I think I found the issue for the IRQ2 RX DONE FAIL hang up. Updated the branch dev-flrc. For me it seems to work great now, no lua issues anymore. you may want to try this branch.

when in 143Hz mode, bind doesn't seem to work anymore

and there remains the issue with the low LQ, which however is another beast, probably for you to figure out :)

again, maybe you want to update your FLRC branch, as eventually this really should be your PR :)

[jlpoltrack]

Spent some time this morning with the latest - only thing I found that helped TxLQ was to lower the rate down to 100 Hz. Am using STM32F1 - so not sure if that is a bottleneck or not. Will update my branch at somepoint and create a PR - will add a few small tweaks.

[olliw42]

so you are saying then going to 100 Hz, LQ stays at 100, while at 143Hz it does not ??

I would not have expected that ... I mean, there should be still plenty of time ... 7 ms - 2x1.67 ms = 3.66 ms ...

I guess we need to measure the timing, it appears to me that something in the main loop started to take up too much time ...

[olliw42]

the FRM303 will run at only 48 MHz ... so it will be a bench mark LOL

[jlpoltrack]

Here are the numbers that I recorded for TxLq (1 minute sample logged at 10 Hz on EdgeTx):

• 143 Hz | .64Mhz, CR 3/4: Average 97, Min 93
• 143 Hz | 1MHz, CR 1/2: Average 97, Min 93
• 125 Hz | .65Mhz, CR 1/2: Average 98, Min 94 (Slightly better)
• 100 Hz | .65Mhz, CR 1/2: Average 99, Min 97

Lower rates allow for increased coding rates so did that where I could. RxLQ (up to CRC1) was 99 for all of these.

the FRM303 will run at only 48 MHz ... so it will be a bench mark LOL

Will certainly be interesting to know what you see here :)

[olliw42]

thx for these data
so, it's kind of always not really good ... this IMHO suggests that it's indeed an issue elsewhere and not actually in the timing

[jlpoltrack]

Last one seems close enough to 50 Hz LoRa to me (would at least like to average 99)

50 Hz LoRa: Average 99, Min 96.

[jlpoltrack]

PR is here: #98