Modify FrSky D-series telemetry for compatibility with Lua script

[alexeystn]

This PR makes old FrSky D-series telemetry receivers fully compatible with Lua Telemetry script by @teckel12.

Please, add 'In progress' label. I've run successful bench tests with D8R-II Plus receiver, but need to test it out in the field to make sure everything is ok.

[alexeystn]

The only difference with X-series is a distance sensor ID: X-series use 0420.
D-receivers cannot use 16-bit ID's, so I've chosen 07 which is not busy for any other purpose and can be transmitter to TX.

[fiam]

@alexeystn could we move the common code to a separate file? It looks like there’s quite some duplicated code in sport and d8 telemetry (I’m viewing on mobile, so I might be wrong)

[teckel12]

@alexeystn Nice! I don't have a D-series Rx to test, but it seems solid. So the distance sensor on the transmitter will by default be named 07, which needs to be changed to Dist to work with LuaTelemetry. Is that correct?

@fiam Yes, there is a bit of duplication between smartport.c and frsky.c. How would you suggest this be dealt with in the smartest way? Should a smartport_shared.c, sport_shared.c, frsky_shared.c or flightmodes_shared.c file be created that would house this duplicated code? It seems that would be most appropriate. Wouldn't be much effort to go that route, but the most logical file naming convention would need to be nailed down.

[fiam]

I’d suggest we rename frsky.c to frsky_d8.c and we use frsky.c to put the common code. @digitalentity?

[alexeystn]

@teckel12 Yes, that is correct.
I have both D and X receivers in my iNav fleet, so I can check if they works equally.

[DzikuVx]

I second the rename. It's very confusing

[teckel12]

@fiam @DzikuVx Not that anything we do won't be confusing. But, making it frsky_d8.c is equally confusing because the D4R would also be compatible. Further, putting the unified S.Port and FrSky logic in a frsky.c file seems confusing as well, as historically we've referred to the D-series as FrSky and the X-series as S.Port.

Maybe frsky_d.c instead of frsky_d8.c?

[fiam]

frsky_d.c seems like a better idea to me, but either way is good enough. I think we should stop using just brand names like just frsky because that's confusing (like e.g. "FrSky" in the telemetry combobox in the ports configurator tab).

[teckel12]

@fiam 👍 For FrSky telemetry options it should be D-series, S.Port & F.Port. That makes far more sense now that there's 3 different FrSky telemetry options. But I'm sure that will cause just as much confusion with people that don't know that D-series is FrSky.

[alexeystn]

Today I have checked these changes with D8R-II-Plus in the field. Telemetry screen worked correctly.
Now file naming is the only question.

[teckel12]

I reviewed the D-series telemetry and didn't notice the dummy values, good catch!

[teckel12]

@alexeystn Do you want to create the frsky_d.c common code file or should I take a stab at it? My only issue is testing, since I lack a D-series receiver.

[alexeystn]

@teckel12 That was my mistake, I left them after bench-testing inside the house without GPS accidentally.
Excuse me, I didn't understood our final decision from the foregoing discussion. Rename frsky.c with D-series telemetry to frsky_d.c and put common code to frsky.c, is it right? If so, I can do that.

[teckel12]

@alexeystn I believe that's right. frsky.c for the unified code, frsky_d.c for D-series specific, and smartport.c for the S.Port stuff. I can test S.Port, you can test D-series, and I'm sure someone can test F.Port, if that's touched at all.

[teckel12]

Visual inspection seems correct. Will compile this branch and test in the next couple days.

[teckel12]

@alexeystn I also wanted to bring up the issue with the 16-bit variable overflow for the flight modes.

Do you happen to know if it's unsigned or signed? If it's unsigned there's probably an easy fix. But if it's signed, the D-series would never get a FAILSAFE notification.

[alexeystn]

@teckel12 I assigned Failsafe to the aux channel in configurator so that I could test it without real signal loss. When I toggle the switch, I see "Failsafe" notification on Taranis' screen. It means, unsigned 16-bit variable is sent correctly to D8R-II.
The only thing that concerns me is the fact that hypothetically value may exceed 65535, but it can be prevented with this fix.

[teckel12]

Still haven't tested the code, but I like the 16-bit overflow fix.

[teckel12]

@alexeystn Would this be more readable and more in line with the code standard to be

    else if (FLIGHT_MODE(AUTO_TUNE))
        tmpi += 20000;

[teckel12]

Maybe a note to clarify why it's being done this way (as a year from now someone will probably see this as a mistake and "correct" it). Something like this:

// intentionally reverse order and else if to prevent 16 bit overflow

[teckel12]

@alexeystn I compiled your branch last night and was planning on testing tonight, but something came up. Will test on Wednesday. Sorry for the delay.

[teckel12]

@alexeystn Tested this PR on two quads today (SmartPort telemetry) and both worked without a problem.

[teckel12]

Works good with S.Port

[teckel12]

@alexeystn For Lua Telemetry distance support I need to verify the exact distance sensor name. Delete the Dist sensor, search for sensors which will re-add the distance sensor. It was noted that the name was 07. I want to be sure it's exactly that, for example 0007 would be different as the value is a string not an integer.

I need to know this for two reasons. First, documentation. And secondly, so the script can use the default sensor name instead of needing to rename it (making it easier for users).

Thanks!

[alexeystn]

@teckel12
Sorry for my delay too. Tested it with D8R-II Plus on a flying wing, everything works good, including distance:

Even though D8-receiver operates with 8-bit sensor IDs, Taranis displays it as 0007, not 07.
That's how it looks when I remove all sensors and discover them again:

Since it is a string, not a number, it makes difference. You are right.
Good idea about automatic name detection!

[teckel12]

👍

[teckel12]

@alexeystn Perfect! SPlissken has also agreed to test D-series receivers with Lua Telemetry.

[teckel12]

@fiam @alexeystn I got a third confirmation from @SPlissken that this branch is functional with both X-series and D-series receivers. I'd say it's good to merge.

[fiam]

Can you resolve the conflicts so we can merge it for 2.0?

[alexeystn]

Yes, I'll try to resolve them within a day or two.

[fiam]

Thanks @alexeystn. Feel free to ping me after doing so and I'll merge right away.

[alexeystn]

@fiam I think it's done.

[fiam]

Thanks @alexeystn! Merging.