expressLRS

Failsafes and telemetry not working are not good. Was there any strange behavior on the T8 screen or with the buttons after these incidents?

The flashing when you go on the device page happens because the screen is repainted as the parameters are received from the TX (or other CRSF device). These packets are received at the same rate as the packet rate, so lower rates take longer. For the TX it's a little over 1K of data.

The issue with the 250/500 packet rate display apparently wrong is puzzling. I can think of a couple of possibilities though neither seems likely. First a question though - when you say " packet rate shows 250 while 500 is selected" do you mean the bad/good ratio shows 0/250 while the packet rate is 500? or that the packet rate config box shows 250 when you know the last time you left the menu it was 500?

If it's the first case it's because the bad/good ratio is not updated while on the device page. If you enter the page at 250, change to 500, then look at the bad/good ratio it will still show 250.

The other way I could see this happening is if the setting is changed while the parameters are still loading. This should be almost impossible in practice, but be sure the screen stops flashing and the LOADING tag on the top line disappears before navigating the menu. I'll look into disabling the buttons until all parameters are loaded.

For the issue of starting up with throttle warning the info about 250 and 500 behavior suggests something to try. My mention of opentx was just to note that the hardware it runs on has a different power-up behavior than Jumper hardware in that with Jumper the TX powers up immediately even if no serial data is being sent from the T8. Maybe that interacts with the TX baudrate detection in some way that causes a problem. Also the baud rate change that Deviation does may be involved. I'd like to be able to just set the baudrate in Deviation instead of trying to detect when the module is ELRS, but since the protocol options are taken over by the CRSF pages there's no good place to put a baudrate selection.

From what I can see in the code ELRS keeps trying different baud rates forever, but maybe there's a timeout somewhere that depends on packet rate. Easy enough to test. Please try test build 1610498 . This build has the baudrate fixed at 1.87Mbps, instead of elevating to that rate only when ELRS module is detected.

When I tested this build there was a strange behavior with model match. I had model match on with the previous version of Deviation, installed the build above, and powered on the T8. The RX LED started flashing the model mismatch code. I went to the 900TX device page, turned model match off and the RX connected, then I turned model match back on. Next I changed Deviation back to the previous build, which bumps the datarate from 400K to 1.87M when ELRS is detected. Again the model ID setting was lost! Finally I changed back to the test version above, but this time model ID was not lost! Still puzzled about this behavior.

Ah bad/good I didn't look at because it was always showing the same. On 7d14d15 shows good/bad 0/±250 on 250Hz and 0/±340 on 500Hz.

When 250Hz shows in the menu while 500Hz was actually selected I see good/bad 0/±340. When I try to switch to 500Hz the menu keeps showing 250Hz. When I switch to 150Hz the menu actually switches to 150 and good/bad shows 0/±150.

On 1610498 the CRSF menu doesn't show

Do you think this is going to work? Maybe I can send you a 2.4Gz ELRS module to develop 500Hz on? Do you perhaps live in The Netherlands?

I am not testing model match now because the connection is not stable yet. Is that ok?

Testing without model match is fine for now. Need to get the other issues worked out.

One concern is that bad/good is 0/340 at 500Hz. The good needs to be at 500, otherwise packets are being lost. Can you please check what it shows on 6659b95 when the packet rate is 500Hz? Set the rate to 500Hz, then exit the menu, wait a couple seconds, then go back into the menu to check. I'll also look at adding the "good" value to telemetry so we can see what it is during normal operation. It may only be dropping packets while transferring the parameter data so it may not be a flight issue.

I'm very puzzled why 1610498 wouldn't work as the only changes were removing the debug beep and always running the serial port at 1.87Mbps. You said the CRSF menu doesn't show - does the build work other than that? Does the menu show up at lower packet rates?

Thanks for the offer but unfortunately I'm not in The Netherlands . I'm in the US. I did look into running my module at 500Hz and I think I'll try that. The serial packet rate is tied directly to the air packet rate so not sure what it'll do to the TX. It may not run and if it does I doubt it will connect to the receiver.

I'm hopeful we can get everything working at 500Hz. I've got a couple optimizations in mind but they're not quick to implement.

6659b95 on 250Hz bad/good is 0/251 and on 500Hz it's 0/501. The 6659b95 seems to run smoother yet superfast while flying but that could be imaginative cause I have had no issues with it and love it.

You should buy a 2.4Ghz module. Superfast and crazy range.

On 1610498 the menu shows on all packet rates except 500Hz.

New test build - 82c3a77 . I decided to go back to 6659b95, apply non-timing changes, and make one minor change to data handling. As far as I can tell this build behaves just like 6659b95. Please let me know how it is for you. The only problem I see is retries when loading parameters, with more retries at slower packet rates.

I would've preferred 2.4G but it's not in stock at the places I usually buy from. I just ordered one from a place I've never heard of - we'll see how that goes. Good excuse to build a new quad.

Build f848942 is also available in the test build page. This has some additional complexity to eliminate the retries.

Simple test report. I tried to add borders to the table for clarity but didn't succeed.

---

Build#|	Throttle high on boot|	BAD/GOOD|	Remarks
6659b95	OK	0/501	Flies nice
82c3a77	FAIL	0/501	-
f848942	FAIL	0/501	-

---

These builds are 400Kbaud or 1.8Mbaud?

All three of the builds listed start at 400K and switch to 1.8M when the module is detected to be ELRS. Same code in all of them in that area.

From the bad/good it looks like the serial data transfer is working well.

On the safety warning issue I'll have to think about something to try. Build 82c3a77 has the same serial errors as 6659b95, so that can't be it. If my 2.4 module order goes through it will help. I'm out for the weekend so maybe inspiration will strike. We can resume next week.

Have a good weekend!

On 6659b95 booting at 50Hz shows 0/50 when the menu builds up but often the menu doesn't build up. A connection with RX is not established. After going to 150Hz the connection with RX comes up and 50Hz can be selected and works. When leaving RX on and booting TX at 50Hz the connection stays. Good/bad is 0/50 when the menu builds up but often the menu doesn't build up. In Betaflight configurator the RX values jump of and on continuously while the RX led is solid green.
The 82c3a77 and f848942 do not have this issue but here the power is increased to 1W. I have dynamic power turned on.

I'm a little surprised 82c3a77 doesn't behave the same as 6659b95 at 50Hz because the code is nearly identical. Nearly but not exactly. The f848942 change should be the one that fixes receiving multiple messages at once.

Is the increase to 1W not expected? If the RX is connected and close by I would expect the power to be low.

The 2.4G module I ordered should arrive today. I want to try a few things before putting out another test build.

If the RX is connected and close by I would expect the power to be low. So as it seems the connection is at 50Hz is poor but not poor enough to make ELRS decide the connection is lost. Why good/bad is still 0/50 seems strange to me.

May I ask which 2.4GHz module you bought?

What is the link telemetry showing when the power goes to 1W? That might give some clues. The bad/good numbers refer to the packets going from the T8 to the TX. If serial errors occur they will be on the data from TX to T8 so won't affect the bad/good number.

I bought the HappyModel TX with an EP1 receiver.

Do you mind when I wait with testing for you to receive your HM TX and see what's going on yourself?

I don't mind but that happened today. Didn't take long to see the same issues you have described. Test build available - 88d5ea7 .

Trying to detect an ELRS module and then switching baudrates causes issues, especially when startup is delayed by the throttle warning. Also found a mistake in the previous test where I tried to fix the baudrate to 1.87Mbps. I decided to remove the baudrate switching. I created an ELRS protocol which is the same as CRSF except it runs at 1.87Mbps. After installing the test build, go into the model and change the protocol from CRSF to ELRS. Then power off and on the T8. This fixes the issue of turning on power with throttle not zero.

I turned on Dynamic Power and set the max to 250mW (highest it would go). But the telemetry said the power was 10mW the whole time. Don't know if that's a related issue or something else.

On the TX I'm running a build from master, and 2.2.0 on the RX. I only saw the issue of the Packet Rate setting jumping from 500 to 250 one time, immediately after installing the module.

Super! Things seem to work better now. I installed a master build of today on TX too and 88d5ea7 on T8 and switched to the ELRS protocol.

The throttle high issue now only persists when keeping it high for a longer time, let's say 20 seconds. The menu now does show but values are incorrect and can change nothing. RX led blinking slow. BAD/GOOD shows 0/500 while packet rate is set lower, 250/150/50.

I'm worried most about the fail-saves I had on the 7d14d15. Is that issue under control now?