Advanced Search

Durete wrote: Totally agree with you guys. I can't express my satisfaction contributing with this project.
This thread is a perfect example everyone can contribute to this project. We left a lot of information and records of the whole process for people interested in known the hard work involved to hack a protocol.
I am proud of this great team job.
Thanks guys

If you want a bad news, there are at least 5 other XN297 protocols to hack MJX X's serries for example

Totally agree with you guys. I can't express my satisfaction contributing with this project.
This thread is a perfect example everyone can contribute to this project. We left a lot of information and records of the whole process for people interested in known the hard work involved to hack a protocol.
I am proud of this great team job.
Thanks guys

Very windy morning here for a maiden flight
At least I could test outside



Great team job guys .

Just return home from some flights outside using latest Hexfet's code (with trim packets at zero). Super funny using my Devo instead the stock TX .
I only observed a weird behaviour changing the power setting after bind the quadcopter. When you change the power setting, the quadcopter loose bind, and you need to reset everything (quad and TX) to recover connection. In fact, I think the power setting is not working since I tried some range test and I could walk for about 70 meters at 100uw without loose bind

@Greenfly, in case you want to test latest code using trim packets, here is my compiled version:
www.dropbox.com/s/i0w7m25qwvqxfn6/deviat...ith%20Trims.zip?dl=0
Only to confirm you have drift using this build.

Great team job guys!

@Mike
Is it Nightly-Build from deviationtx-team? Not Indigo latest test build?
You could not bind / connect when powering on or was it in between (ground)? I may be able to re-test your issue with my AR6210+TM. I also have AR600+TM.

@PhracturedBlue:
Are your plans to do a V4.1 release with the current DSM + telemetry code as of nightly-build (deviationtx-team) which seems to be somehow rocking solid with my AR8000 + TM1000 so far

or

are your plans to already merge in pull request #48 Indigos DSM + WK protocol changes

without

further multiple weeks / months further ground + in-flight tests?


I would like to suggest go the route with small steps (V4.2, 4.3...), that is to rls current code as of V4.1 and have a little bit more time for tests on Indigo's code improvements.

I definitly have to re-test the "Fades A 255->0 number reset" issue which is working fine so far with nightly-build with latest test build.


My feeling is that there are not that many testers with the appropriate Spektrum receiver equipment + time
My understanding is, that ground tests alone with 100uw/300uw/1mw are not enough alone when you are doing bigger protocol code changes as of the test builds.

Thomas

I've got a WLToys V959 Pro (Package has Sticker with "PRO 6 Axis Gro" on it)
and found that its not yet deviated (at least I did not find any hint about that).
I've captured SPI on the transmitter (bind and some 'flying' where I was holding the quad), see attached file.


Protocol is YD717 variant, and after finding that v252 pro should work with 'Sky Walker' option, I gave it a try.
I was able to bind and control it using fresh build from team repos on my Devo 8S, but commands were choppy
- which may be caused by my mulimodule, or due to the fact that I can see that the original is performing some channel hopping,
which I only see a note about in the source code, which says channel hopping is missing for Ni Hui quad.
My TX sends bind packets
29 EF A1 11 56 AA 40 00 F5

My capture shows a channel hopping over RF_CH 3C, 02, 21, 41, 0B, 4B, 3C, 02, 21, ...
But time between these are *strange* ... 0.01597 seconds between at the end, but at init it stays even 4.5 seconds on channel 02
( I REALLY do not understand why the YD717 code IS working with the 959 pro at all ^^ )

I'll dig into this tomorrow

SeByDocKy wrote: Great team job HexFet & Durete

... and Greenfly

Thanks!


I will start to test pitch/roll trims packets when return home from work.

Great team job HexFet & Durete

Thomas.Heiss wrote: I am currently using

deviation-devo10-v4.0.1-fcd0669
offical nightly-build from deviationtx team repository - linked in downloads section
with DSMx, 100mw, AR8000 + TM1000
with a 450 CP Heli (Paddle CCPM mixing).

Rocking stable so far for 6,5-8min flight time.

Fades A (main) < 50
Fades L (Sat) < 80
FrameLosses 0
Holds 0

I will do (repeat) some ground range tests with 100uw/1mw next days to test for 30-35m and 60-65m distance.

I have a Devo10. Can I read Fades FrameLosses and Holds ? Where?

Hi,

I am currently using

deviation-devo10-v4.0.1-fcd0669
offical nightly-build from deviationtx team repository
with DSMx, output power set to 100mw
using Spektrum AR8000 including sat (vertical mounted) + TM1000 telemetry mode
with a Blade 450 3D CP Heli (Paddle CCPM 120 degree mixing).

Rocking stable so far for 6,5-8min flight time.

Fades A (main) < 50
Fades L (Sat) < 80
FrameLosses 0
Holds 0

Nightly version fcd0669 is based on nightly-version 92e1705 (PhracturedBlue repository) for DSMx protocol but with major telemetry bugfixes and improvements.

This nightly version does NOT yet contain the big pending DSM and Walkera protocol changes the team is working on and (still) continually testing.


I will do (repeat) some ground range tests with 100uw/1mw on fcd0669 next days to test for 30-35m and 60-65m distance and compare DSMx FlightLog of this nightly-build vs Indigo test version 36cce5c DSMx protocol changes (e.g maximum of Fades A, handling switching FlightLog numbers, handling FrameLosses/Holds from my previous test of Indigo test version 36cce5c).

Nightly-build version 92e1705 + some telemetry bugfixes has been stable for me with my 200QX quad too.
The telemetry bugfixes and improvements went into the DeviationTX team repository + test builds only.

I have plans to repeat ground + 200QX flight tests at a later time with one of the latest offical test versions the team (Indigo / vlad / PhracturedBlue...) is working on. But I will definitely not use the 450er CP heli for this. May try to reactivate a glider for this.


Changes in CCPM mixing in nightly-build:
You need to be aware that there are two (small) CCPM mixing bugs and lately changes again in the CCPM mixing.

1) Nightly version v4.0.1-fcd0669 suddenly changed normal/reversed for pitch servo (CH6).
I was flying with multiple Indigos test versions (latest devo10-v4.0.1-36cce5c) and nightly-version starting devo10-v4.0.1-92e1705 and for sure pitch servo CH6 had a DIFFERENT sign before.
Suddenly in fcd0669 my CCPM stopped working because pitch servo was travelling wrong.
After I changed the sign normal/reversed it was back working.
Had multiple flights since day 1 and all good.

Not sure why the mixing code (sign normal/reversed for servo channel) suddenly changed between nightly-build versions.

WARNING:
If you upgrade to new nightly-build versions ALWAYS test your servos before flying.
You should do this especially for CP helis anyway, for each new lipo pack you plug into before starting up the engine.


2) CCPM mixing was not working with the simple GUI in nightly build for me.
This is because cyclic channel order is wrong assigned.
I had to remap elevator servo to cyclic channel 1. Has been set to "cyclic 2" by simple GUI configuration.
When you change from simple GUI to advanced GUI you can see that the cyclic channel order is assigned wrong.

Setup:
elevator needs to be cyclic 1 (was cyclic 2)
aileron needs to be cyclic 2 (was cyclic 1)
pitch (CH6) needs to be cyclic 3

I was on a nightly-build Indigo test version devo10-v4.0.1-36cce5c before when the CCPM mixer for paddle CP heli was not working.
If the cyclic channel ordering is interchanged, you will never manage to get the up/down servos right, even not with channel reversing normal/reverted or +- in CCPM mixer.
Will re-test a new CCPM heli modell with nightly-build fcd0669 and simple + advanced GUI screens.

No pdfbuilder.py found. No *builder.py found, either.

Python version 2.7.9.

Here's sys.path

>>> pprint.pprint(sys.path)
['',
'/export/mwm/src/bitbucket/deviation/team-manual/build/venv/lib/python2.7/site-packages/rst2pdf-0.93.dev_r0-py2.7.egg',
'/export/mwm/src/bitbucket/deviation/team-manual/build/venv/lib/python27.zip',
'/export/mwm/src/bitbucket/deviation/team-manual/build/venv/lib/python2.7',
'/export/mwm/src/bitbucket/deviation/team-manual/build/venv/lib/python2.7/plat-freebsd10',
'/export/mwm/src/bitbucket/deviation/team-manual/build/venv/lib/python2.7/lib-tk',
'/export/mwm/src/bitbucket/deviation/team-manual/build/venv/lib/python2.7/lib-old',
'/export/mwm/src/bitbucket/deviation/team-manual/build/venv/lib/python2.7/lib-dynload',
'/usr/local/lib/python2.7',
'/usr/local/lib/python2.7/plat-freebsd10',
'/usr/local/lib/python2.7/lib-tk',
'/export/mwm/src/bitbucket/deviation/team-manual/build/venv/lib/python2.7/site-packages',
'/export/mwm/src/bitbucket/deviation/team-manual/build/venv/lib/python2.7/site-packages']

Possibly easier to figure out what you're looking for:

>>> pprint.pprint([x[len("/export/mwm/src/bitbucket/deviation/team-manual/"):] for x in sys.path if "deviation" in x])
['build/venv/lib/python2.7/site-packages/rst2pdf-0.93.dev_r0-py2.7.egg',
'build/venv/lib/python27.zip',
'build/venv/lib/python2.7',
'build/venv/lib/python2.7/plat-freebsd10',
'build/venv/lib/python2.7/lib-tk',
'build/venv/lib/python2.7/lib-old',
'build/venv/lib/python2.7/lib-dynload',
'build/venv/lib/python2.7/site-packages',
'build/venv/lib/python2.7/site-packages']

OK, manual work:

I gave up on Google Docs. It isn't up to the job.

It seems that LibreOffice has an Edit->Compare Documents feature. I used that to (try) and merge the changes in PB's manual repository into the team repository. While that's not as simple as doing a merge in a good VCS, it does work. The downside is that I wasn't sure whether a a difference was a change made in the team repo or by PB, so I picked those that I thought were best. Please review!

If we are reduced to asking for text changes, then some of the reasons for using LibreOffice go away, as we don't need those suggesting changes to be able to run the word processor. In that case, I would say that generating both documents (or do the new Tx's mean there are now more?) from a single source should be an important consideration.

Rst doesn't seem to provide conditional text, but sphinx seems to have an "only" directive that's been added via the extension mechanism. Personally, if we're going to go with a markup format, I'd vote either LaTeX or DocBook. LaTeX works well if you're willing to let it do the formatting - but the formats were designed by professional, and I find them absolutely lovely. As for DocBook, two decades of working with SGML has left me with a nice collection of tools that leverage machine readable schemas. So I can write valid HTML or XHTML or pretty much anything with an SGML schema faster than I can write markdown.

But for now, I'm going to see what I can do about using LibreOffice's conditional text facilities to merge the two documents. With an eye on making it generate one manuals specific to each supported Tx.

And now my fleet floats!

https://goo.gl/photos/oyqB5m9dgF8P3ww89

The two Llama's mentioned earlier are now on the wall. The V959 is on the bench for dissection or a project, probably never to return. The 200QX now has a clear polycarbonate frame. And there's a V323 with the cafe steamers mod.

New breeds include the Sport Cub S, which I've flown with floats off of snow. Haven't tried it on water yet. And on the right there's an Orion, which has been wet. On the left is the top half of the mast and foresail for a Focus. All controlled with the D10 but the Focus, which is awaiting testing with the RTS Tx before converting to the D10.

Ok. I finished.
Try out the 'joysway' branch in the deviation team repo.
It is quick and dirty, and I locked the txid to the same one in your logs, but it should make it easy to verify if it works or not. If not, you probably need to capture the startup sequence from the devo radio so we can see what is different.

Pull requested. Wasn't confident about forcing a rebase, but currently no conflicts.

This was interesting. Not royal, but maybe knightly Feeling more sympathy for the GUI team at the day job - their framework isn't as nice.

Thomas.Heiss wrote: FlightLog 0xFF / 255 max value
Do the latest pull requests (without protocol changes), which are merged into deviationtx team repository (trunk), have some more code changes / reviews for displaying 0xFF/255 values?
Have you been already working on this Indigo?

0 and 255 are displayed as a real values. If 255 overflows and becomes 0 again, it must be fault in receiver.
The min/max values in deviation are only used to limit range of telemetry alarm.

Thomas.Heiss wrote: Do you guys have an idea why for some received (bogus) telemetry data F and H show (switch to) 0 in the monitor instead of a real number e.g 32767 or 65535?

Deviation only displays the value it receives. If value is not the special "not connected" value 65535 (-32768) then it is treated as a real value (even if greater than max value, or less than min value), if real value then display "as is".
Currently as a interim measure 32767 is also treated same as special "not connected" value 65535. (I think this can now be removed)

vlad_vy wrote:

vlad_vy wrote: if 'Holds'=255 -> Telemetry Range Warning
if 'A' or 'B' or 'L' or 'R' not equal to its previous value and >=512 (usually =65535) -> Telemetry Range Warning

-> A, B, L, R, F, H -> not valid (must be filtered)

Probably will be worth to filter these values.

Thomas.Heiss wrote:
FlightLog 0xFF / 255 max value
Do the latest pull requests (without protocol changes), which are merged into deviationtx team repository (trunk), have some more code changes / reviews for displaying 0xFF/255 values?
Have you been already working on this Indigo?

As posted before in this thread I had the problem that the Fades A, B, L, R reset to "0" suddenly once "255" had been reached.
The valid max value (fades) for AR6210/AR600 is 255. It went no further on DX8 so it is receiver hardware.
It is fine to display 255 therefore. It is not a bad value (for fades).

AR8000 and probably 9-12CH receivers can go >255 for fades (I tested this on AR8000 on L before).

You must NOT reset or suppress flightlog data 0xFF (at least not for fades).

Is 255 reset to 0 fixed yet?

In my AR8000 + TM1000 video you can see that I successfully tested showing fades value >512 (e.g 2217) on Fades L as well on FrameLosses.


So:

"if 'A' or 'B' or 'L' or 'R' not equal to its previous value and >=512 (usually =65535) -> Telemetry Range Warning"

-> is not correct??!?? I was in range when display showed >512 (so real fades, real FrameLosses).

"F, H > x -> not valid (must be filtered)"

-> i had successfully tested F 859 in my video as a real number (real losses).

So >512 does not apply for FrameLosses too.


Do you guys have an idea why for some received (bogus) telemetry data F and H show (switch to) 0 in the monitor instead of a real number e.g 32767 or 65535?


I think we have to test it a bit more if there is any fixed number applying for F which triggers a real "telemetry range warning".

Pull Request #42 RangeTest:
Pull request comment about 100uw: bitbucket.org/deviationtx/deviation/pull.../add-range-test-page
Thread DSMx range test link: www.deviationtx.com/forum/3-feedback-que...ions?start=120#31014

100uw does not seem to match Spektrum 30-35m test range.
Even 60-65m has been successfully tested by me on AR6210 with Spektrum DX8 with "range test mode" / pressing trainer button.

Is it possible to make the range test page configurable to 1mw too and not hard code 100uw into the code?

Is it possible to include DSM telemetry monitor for the range-test just like Spektrum does it when you receive telemetry data?
So I need a "test mode + telemetry monitor" <100mw which is able to show DSM flightlog.


FlightLog 0xFF / 255 max value
Do the latest pull requests (without protocol changes), which are merged into deviationtx team repository (trunk), have some more code changes / reviews for displaying 0xFF/255 values?
Have you been already working on this Indigo?

As posted before in this thread I had the problem that the Fades A, B, L, R reset to "0" suddenly once "255" had been reached.
The valid max value (fades) for AR6210/AR600 is 255. It went no further on DX8 so it is receiver hardware.
It is fine to display 255 therefore. It is not a bad value (for fades).

AR8000 and probably 9-12CH receivers can go >255 for fades (I tested this on AR8000 on L before).

You must NOT reset or suppress flightlog data 0xFF (at least not for fades).


Not sure about holds and framelosses (and jumping telemetry data).

Framelosses: should be <40 normally (best up to ~20), could go 50-90 on AR6210 or higher on AR600 with only one receiver antenna (antenna diversity still counts up FrameLosses)
Holds: <10 (0) expected

Bigger numbers on FrameLosses / Holds are "telemetry jumping numbers" or telemetry out-of-range errors?
Earlier in the thread there had been an explanation about telemetry out-of-range (that does NOT!!! mean the Spektrum receiver has lost connection / bind too) and possible high numbers.

vlad_vy wrote: PB, can you change at main trunk next things?

Also, for() cycle doesn't work. It seems all values are writed to Telemetry.p.dsm.flog.fades[0].

        case 0x7f: //TM1000 Flight log
        case 0xff: //TM1100 Flight log
            update = update7f;
            //Telemetry.p.dsm.flog.fades[0] = pkt16_to_u8(packet+2); //FadesA 0xFFFF = (not connected)
            //Telemetry.p.dsm.flog.fades[1] = pkt16_to_u8(packet+4); //FadesB 0xFFFF = (not connected)
            //Telemetry.p.dsm.flog.fades[2] = pkt16_to_u8(packet+6); //FadesL 0xFFFF = (not connected)
            //Telemetry.p.dsm.flog.fades[3] = pkt16_to_u8(packet+8); //FadesR 0xFFFF = (not connected)
            //Telemetry.p.dsm.flog.frameloss = pkt16_to_u8(packet+10);
            //Telemetry.p.dsm.flog.holds = pkt16_to_u8(packet+12);
            for(int i = 2; i < 14; i+=2) {
                *(u8*)&Telemetry.p.dsm.flog = pkt16_to_u8(packet+i);
            }
            Telemetry.p.dsm.flog.volt[1] = pkt16_to_volt(packet+14);
            break; 

Guys, you start killing me

That code block has been changed a long time ago with my first posting by Mike and Indigo: www.deviationtx.com/forum/protocol-devel...port?start=100#26681

Of course it never has been merged to team repository or PB repository - not yet.
Mike and I had to put back the "1st pull request" for PB repository.

It is now fixed in dsm-telemetry branch (Indigo repository - 2nd pull request team repository) FOR AGES - fixing the overwrite.
We had two tickets open, one opened by me (code change by Mike, taken over by Indigo with further improvements). See commit log.


May I ask you in how many repositories are you now changing and testing code in parallel?
How many developers change code in parallel? Three? In three repositories? Indigo, PB, Vlad?
According to your latest threads you change code on-the-fly (in threads), locally creating test build versions?
So there are now test builds with not equivalent source code too? Only small (debug) changes?

Why do you now have to fight with wrong - already fixed - code at team main trunk??? I really get lost!!

PhracturedBlue wrote: Where is this all going?
I have to admit I'm very skeptical of the process at the moment. When I look at Indigo's code, it has a lot of change compared to the trunk in DSM and Devo protocols. I don't really understand what much of that change is buying me. In Devo, it may result in eliminating the 'Reboot' condition, but at least at the moment, it will come at the cost of major refactoring of the callback loop, and the Reboot condition itself is not causing any issues (any more). In DSM2 the code refactor may reduce Holds? I belive the original intent was to improve reception rate (eliminate invalids and bogus data)? What else does it achieve? All of that change comes with inherent stability risk to the most commonly used protocols. It makes me very nervous, especially with 9 out of 10 builds seeming to have major issues that make it unusable. I really need to see concrete gains, and then I will wonder whether those gains can be had with less change to the protocol code.

And then there are at least two to three threads too: Walkera telemetry - DSM telemtry - OrangeRX DSMx range problems.

Your question is related to DSM - but posted to Walkera thread.


To answer your question PB, I want to answer in this thread:
1) It all started with the above DSM telemetry code fixes. FlightLog DSM telemetry is / was corrupted in (PB+team) trunk - see my above first post.
2) "9999" values improvement (see tickets 180CFX, 200SRX): AR8000 can have >255 Fades too!

3) And then in all versions (starting offical team trunk, Indigos test builds) there are (still) corrupt DSM FlightLog telemetry data - see my new videos.

Indigo wrote about point 3) in another thread - I believe it was "DSMx range thread" why he did it and for what reason (separating RX + TX buffers).

Indigo was working on point 3) to eleminate bogus DSM FlightLog data. It seems it is not fixed yet - at least I missed that success posting by other developers / Indigo / re-testers.
I have not done any Flightlog re-tests since my video with new test build versions with original Spektrum RX+TM either.

Thomas.Heiss wrote: Confirm 5) Temp value '18186C' for disconnected sensor (tested on AR8000)


New error: Fades will be reset to 0 after some time (max 0xFF/255 bit counter on A for 6CH RX a problem?)
Flightlog (fades): Jumping numbers as previously described (problem goes back to nightly version 92e1705)

FlightLog test videos 36cce5c with 100uw (not 100mw) output power:
modellbau.theiss-nbg.de/Deviation-TX-Nig...5c-DSmx_TM1000_Tests

All videos finished uploading.

4) A new problem rise with (some / one) of Indigos test builds: TX + RX lockout. DSM lock with no ever changing new telemetry data.
At least I had that issue once. See one of my tests back where I even got a DSMx TX lockout (lost of bind) with my 200QX at the table.

5) Indigo had very good ideas how to further improve the telemetry monitor screen like alarming, flickering values, alarm stop by ENT button. Re-alarmings.
We also had to change code for the stepping of "1" (holds) and 10 (Fades) since the increments where wrong in the config screen in trunk. The config screen also had wrong comparator (<=0, >=0, >0) to check for holds >0!


If we can not fix points 4) and 3) we have no real benefit and we would have to rollback all changes. But we loose all new and fixed features of point 5)!
IMHO it is the wrong time to throw away all the hard work of Indigo and all the detail improvements which already went into!!! I want them!

I just can tell you that you can NOT use trunk version 92e1705 for DSM telemetry with all that bogus data and invalid stepping configurations and missing re-alarms on FrameLosses and Holds. All stuff the DX8 has - but I hate that Airware version. And I now own a Devo 10.


Point 3) bogus flightlog telemetry data is still open at my side.
Who of you could already take a deeper look in the recorded DSM flightlog telemetry vids?
What is your feedback? Did I miss it?


I had been flight testing trunk 92e1705 + 2-4 Indigo's further (early) test builds with the 200QX. Had no TX lockout during the flight(I could not fly that far away!!).

I have no idea if point 4) is something new introduced by all the new code changes or if that might even was already in 92e1705.
According to thread "DSMx range problem" problems may have already been there before we started re-engineering.
On the other side pilots even had no clue about if they had to choose 100uw/300uw/1mw for range testing before - so that might have given wrong results too?!? For Full-Range flight tests with 100mw and TX connection problems it is again different (results count).
But who would rely on test results for 3rd party Non-Spektrum RX like OrangeRX? Not me! They could have been problems because of SBEC ESC too just like I had once with DX8 and two ESCs.


One of the biggest problems:
You guys seem to have to code (almost) blind because of missing multiple original Spektrum RX, BNF quads + TM1000/TM1100. We would even have to test with 9-12CH receivers!
In the other "DSMx range problem" thread guys are testing wrong (TX lying on/above ground) or with Non-Spektrum equipment (OrangeRX/LemonRX) or without telemetry enabled (missing Flightlog DataPort).

One guy writes he wants now to test with 150mw, even within the EU only 100mw are allowed.
Why not compare each test build version with the same uw/mw and linked Spektrum TX (e.g 1mw on ground range-test) equipment.
So even all the testers - with all this different RX equipment - can not commit on a permanent testing pattern consistent over each test build version.


FlightLog Logging:
Maybe PB / a senior DeviationTX dev could tell me how to successfully record Flightlog DSM logfile data and publish all the bogus additional numbers which may or may not be an indicator of additional "TM1000 / telemetry out-of-range"?
Unfortunately I was never successful in enabling the log file and read from it in Linux once I rebooted into USB mode. It was empty always!

Because of all point 3) code improvements and re-engineering we now see values which were badly supressed before (>255 -> 255 fixed value).


I agree with PB's statement that it will probably still take a longer time to test thru all code changes by multiple testers with multiple RX equipment until we have a final working version which is ready for a public commit to team trunk.


However I am very delighted that Mike and Indigo took my code fixes and small 8bit/16bit improvements (9999 numbers).
Thank you working together!
All the "DSM Telemetry problems/enhancements" have got so many developers and testers active trying to further improve and help bugfix continuous.
I greatly appreciate all your efforts you put into.


I am sorry to see that new test builds might bring unforeseen new TX<->RX / lock or connection lost problems (when you trying to fix that initially) at this time or the code changes are already too big to be reviewed in steps and you now fear a final trunk commit. Please don't give up and keep trying.

Is there maybe any way to split the summary of "total code changes" to individual steps which may be safely committed one by one?
- Changes which are for sure
- improvements which are safe and
- RX/TX/connection/filtering code which needs to be tweaked and tested more in detail? Comparing Walkera + DSM code...

Do you have any idea how you might get away from "blind coding"?

Thanks again to all of you who stepped into helping to bugfix and trying to further improve.

Thomas

I have tried both my own builds of the dsm-telemetry branch on the team repository, and a download of your test build, even though both are 84cc0db.

I don't get a reliable telemetry connection with a LemonRX Rx. I can get it to bind and display data, but it won't reconnect after power cycling everything, and I have to hit bind again. Even then, it won't stay connected, but will drop the connection in a minute or two.

I was getting similar behavior from an OrangeRx Rx, but it's been installed in the Orion, so I haven't tested it on the new versions.