expressLRS

I agree that's the most concerning, but I can't attribute it directly to a problem I've fixed. The code is definitely better now and it does not use the change that was in 7d14d15.

I can replicate the issue with the parameters not changing if there was a long delay before clearing the throttle warning. Won't have time to look at it until later today.

It's rainy all week so I'm not sure when I go out flying again.

Looks like the parameters not changing is because the TX has gone into WiFi mode. What is the setting for AUTO_WIFI_ON_INTERVAL on your TX? Mine is at 60 seconds. If I dismiss the throttle warning at 58 seconds everything's fine. If I wait for 62 seconds then the parameters cannot be set, receiver is flashing, and elrs_tx device is on my WiFi network. I flashed a build with the AUTO_WIFI... option commented out, and then I could leave the throttle warning on for several minutes and still connect to the receiver. This does make sense - since Deviation is not sending any signal to the TX it looks to the TX like it's just powered on without a handset.

There's a note on the Dynamic Power page of the ELRS website that says if telemetry is not being received then the power will be set to maximum. That seems to still apply if the TX is in WiFi mode.

Ah you are right. Auto WiFi is on 20 seconds. So that means I don't see any issues left.

I will try model match this week. Are you coming with a new test build soon?

Having the arm switch raised or not also has influence on the TX power.

I mis-remembered exactly what the ELRS page on dynamic power says. The exact quote is "Dynamic Power relies on telemetry. If no telemetry is received while armed, then the power level will be kicked up to the maximum configured power level." So makes sense the arm switch changes behavior.

Last thing on my list is doing something with the model match error message. Not sure if I'll have a test build before the weekend but won't be too long. Thanks for testing!

Test build available - d00091a

This build has support for the ELRS info message. The ELRS device pages display the bad/good packet ratio and connection status in the title at the top of the screen. Similar to the Lua script, the connection status is either 'C' for "connected to receiver", or '-'. This information is updated about once per second only when disarmed (AUX1 low).

A dialog with text "Model Mismatch" displays when model mismatch is reported in the ELRS info message. The main use case works well - T8 turned on, then turn on aircraft power, if mismatch the error dialog displays. Some other cases I'm not sure the behavior is correct. For example when changing packet rates sometimes the receiver connection is lost momentarily. If model mismatch is active this may cause the dialog to display again. If the receiver is powered up before the T8 sometimes the dialog does not display. Let me know if you notice anything else that's not optimal. The dialog will only display when disarmed.

The reason the data is updated only when disarmed is that Deviation has to request an ELRS info message. The request means a sticks packet is skipped, and extra telemetry bandwidth is used. So the ELRS info is not requested when armed.

It seems to work very well. I saw the bad/good and connection in the title of TX and RX page. I'm flying 4 lipo's on quad this afternoon to see if there are any "failsafes".

When I turn off and on model match the RX is updated both on and off. Seems to work perfectly. Is this according the design? I've never used model match before so I don't know what is required/expected.

Something I haven't been able to reproduce yet. I once had during reckless turning of T8, TX, etc during connection that model match spontaneous was turned on, on the T8 and as expected the connection wasn't set up and I got the model match popup.

Yes, my understanding is that the RX is updated when the TX parameter Model Match is turned on and off. I don't use model match either so it's unfamiliar. One thing I find confusing is that the TX stores some other parameters besides fixed id on a per model basis, like packet rate and telemetry ratio. So those can change when the fixed id is changed.

Shouldn't be any way a parameter would spontaneously change. Is it possible a button was pressed while things were moving around?

Hope the flying goes well!

Flights went smooth as silk.

So the TX can store setting per model? So over 60 storage places? That makes it a little more interesting. I might want 2 model types, race quad and plane.

Great. Thanks for all the testing. I've merged the PR. Please let me know if anything crops up.

Need to get the manual updated, and I'm trying to get nightly builds going again. Until then I'll post a test build named "nightly_build".

The parameters that ELRS keeps separate per model id are listed on this page .

Any chance of CI-driven builds so this can be accessible to users on the normal download page?

Thanks for developing! And congrats with the result! I hope many people will enjoy ELRS on T8v2. It's a jump of a light year into the future.

I haven't seen anything disturbing on d00091a for 6 flights and a few hours of clicking around. The flickering menu buildup is not an issue but maybe something to note.
If I notice anything worrying in the future I will let you know here. If you want me to test or develop something for you, you have my email.

Thanks again!
~ Mooiweertje

Hexfet,
Fantastic work! Thanks do much for keeping Deviation alive and well. I've been following this thread since the beginning and using your last 2-3 test builds . I probably should have chimed in earlier, but I didn't have any issues with any of the test builds while flying.
I was considering an open tx radio, but no need now! I've been using my T8v2+ as a daily driver for years, just keeps going.

One thing crossed my mind earlier. Maybe ELRS should be disabled/blocked in CRSF and vice versa to be sure people use the optimal protocol.

Thanks for keeping deviationTX alive HexFet!

I've had no problems with recent builds either.

Thanks all! Glad i could help out.

I'm spending some time on getting the CI going but don't have credentials to update the nightly builds page. I can set something up for test builds.

The idea for warning about protocol not matching the module would be nice to have. I'd like to eliminate the ELRS protocol but need a way to set the serial datarate. One thought is to add a "handset" device to the CRSF config page where the bitrate could be set. It makes some sense to put it there because the handset has it's own CRSF device address. In Deviation the bitrate would be stored in the model file.

New test build is available - 0150291 . It implements the idea in the previous post - it works well. After clicking on the protocol name the current model name will appear at the bottom of the device list. Clicking on the model name allows.the bit rate to be set. I chose to display the model name to emphasize the bit rate is stored separately for each model.

The available bitrates are 400K, 1.87M, and 2.25M. The ELRS PR #1435 is needed to run 2.25M, or just add 2.25M to the baudrates array in the code. This is the fastest I could get the serial link to run.

The ELRS protocol is no longer needed but I left it in the test build so as not to break any model files. It is now identical to CRSF so it needs to be removed before a merge to master. With the test build any models with ELRS as the protocol will revert to 400Kbps. While the rate can be changed with ELRS still set as the protocol, please change to CRSF so models won't be affected by a future upgrade to a nightly build.

Comments invited! Maybe the bitrate selections should use abbreviations instead of showing the full bitrate number?

I installed 0150291 and #1435. All seems to work.

Any bitrate format is fine with me. It fits in the screen so.. You can also say, legacy, megabaud, multimega or something to make it more snappy.

From a ui design it may be nice to have the baud rate setting part of the TX module settings since that is where the setting is for. From a technical point of view that may be tricky so I understand why better not.

We have terrible weather, storm and rain so I am not sure when the next flight is going to be.

Thanks for taking a look. Yes there are a few reasons not to put the bitrate setting with the TX module.

Test build is updated - 9c4e73b . I did decide to change the bitrate settings to use abbreviations - it looks better. This build also has a change to support 1000Hz packet rate. Looks like that will be coming soon in ELRS.

I've seen some videos of the storms over there. Not flying weather.