FrySky telemetry test build

I just upload a test build with a number of FrSky telemetry fixes. You can download them from deviationtx.com/downloads-new/category/1...rskytelemetryupdates

Kerzin's hub voltage sensor and bind fix are in this.

I've fixed the list of display names that show up in both telemetry configuration and main page configuration so they no longer have blank names for some values.

Finally, the the RSSI value from FrSky is a dBm value. It doesn't measure some kind of percentage as is implied by the current formating. That the handling translated the dBm value to a value between 0 and 100 (sort of - the chosen end points don't match FrSky's docs) makes interpreting them really painful. So instead of transforming them and adding the misleading '%', it just reports the dBm value directly. I hope.

mwm wrote: I just upload a test build with a number of FrSky telemetry fixes. You can download them from deviationtx.com/downloads-new/category/1...rskytelemetryupdates

Kerzin's hub voltage sensor and bind fix are in this.

I've fixed the list of display names that show up in both telemetry configuration and main page configuration so they no longer have blank names for some values.

Finally, the the RSSI value from FrSky is a dBm value. It doesn't measure some kind of percentage as is implied by the current formating. That the handling translated the dBm value to a value between 0 and 100 (sort of - the chosen end points don't match FrSky's docs) makes interpreting them really painful. So instead of transforming them and adding the misleading '%', it just reports the dBm value directly. I hope.

I did this linear scaling into [0-100%] to make thing more simple. Even with the direct output in the dBm value, in close range, you will have a huge variation of this value ...
Now you will ahve to know a lower value to set an alarm... with pourcantage, to set this threshold I find it's more obvious IMHO..

SeByDocKy wrote: I did this linear scaling into [0-100%] to make thing more simple. Even with the direct output in the dBm value, in close range, you will have a huge variation of this value ...
Now you will ahve to know a lower value to set an alarm... with pourcantage, to set this threshold I find it's more obvious IMHO..

Except that you're the only one who knows what those values mean. They aren't documented anywhere, and my requests for information about how to interpret them on the FrSky protocol thread went unanswered. In particular, it's labelled as a percentage, but it's not at all clear what it's a percentage of. Checking the source shows it's a a linear map of the dB, but the value that maps to 100% is slightly lower than the documented maximum value from FrSky, and the value chosen to map to 0 seems to be arbitrary. Since it appears that it's possible to get values above 100% and below 0%, calling it a percentage just seems wrong. So even after looking at the source, I still have no idea what they mean.

Using the values from FrSky mean that all the FrSky documentation, the FrSky telemetry wiki, the various youtube videos on setting up FrSky telemetry warnings, and a host of other sources all apply to this value. Given that information, the best way to figure out what the displayed values meant was to undo the mapping done in the software, which is just silly.

I flashed this test build, so far so good.. however, how do you best read the dbi value now? i.e. what would a good RSSI range alert value be?
The setting goes up into the thousands.

The point of changing the RSSI values back to the FrSky one is that you can now use any documentation about FrSky telemetry in interpreting the value. The FrySky Wiki page on telemetry has a section on RSSI . I recommend reading it.

From that, the answer to your question is that FrSky has three different RSSI alerts at 45, 42 and 40. 45 is just a heads up. 42 is a warning that you are approaching the edge of the range but still safe. 40 is a maximum range warning. I'd say any of those would be good values, depending on how paranoid you want to be about your reception.

Alright, thanks. Just wanted to be sure that the scaling matches that info.

Thanks for uploading this. I can confirm that this works on my 7e with the multi module. Also the RSSI values make a little more sense to me now.

JaiCee wrote: Thanks for uploading this. I can confirm that this works on my 7e with the multi module. Also the RSSI values make a little more sense to me now.

Turns out I was wrong I'm getting incorrect voltage readings where they worked fine before. On a fresh 3s pack I'm getting 8.xV slowly decreasing during use. Battery info is coming from a naze32 running clean flight.

I'm sorry, but I'm not sure where your battery voltage is coming from. Under no conditions should a battery voltage displayed via the FrSky telemetry be coming from a naze32. It should either be coming from an FBVS connected directly to a FrSky Rx, or from an FLVS connected to a sensor hub or FAS.

If you can tell me which version you were running that was working fine, and what "working fine" means to you, it might speed up diagnosing the problem.

mwm wrote: I'm sorry, but I'm not sure where your battery voltage is coming from. Under no conditions should a battery voltage displayed via the FrSky telemetry be coming from a naze32. It should either be coming from an FBVS connected directly to a FrSky Rx, or from an FLVS connected to a sensor hub or FAS.

If you can tell me which version you were running that was working fine, and what "working fine" means to you, it might speed up diagnosing the problem.

The RX is connected to the naze by a serial port and while I've not looked at the code I'm guessing that means it is using the same protocol as a sensor hub. I was previously using the build below and got the correct voltage of a single cell showing as voltage 3 on my devo 7e.
www.deviationtx.com/forum/protocol-devel...lity?start=340#34323

I apparently dropped a cast when I transcribed the fix for telemetry hub voltages. Serves me right for not pulling it in with hg.

I've uploaded a version that should fix this. Please let me know, as I have no way to test it.

mwm wrote: I apparently dropped a cast when I transcribed the fix for telemetry hub voltages. Serves me right for not pulling it in with hg.

I've uploaded a version that should fix this. Please let me know, as I have no way to test it.

I've just uploaded it an it worked perfectly - missing things like casts are always the most annoying problems to find sometimes I wish when programming the computer would do what I mean not what I say. Thank you very much!

JaiCee wrote: I've just uploaded it an it worked perfectly - missing things like casts are always the most annoying problems to find sometimes I wish when programming the computer would do what I mean not what I say. Thank you very much!

Good to hear.

And that's why I've started writing in languages that modern type systems. At least they can warn me at compile time when what I say isn't what I mean.

I just noticed that with the original build at least, I don't get V1 displayed anymore (the 5v supply voltage to the receiver). However, the battery voltage V2 still shows fine (voltage divider to A2).

Edit: And the new build fixes that, despite not using a hub. All good.

Ok, all these changes have been merged into the main branch, but the nighly builds are currently broken (see deviationtx.com/forum/builds/4633-please...of-testing-protocols for details).

I've uploaded my nightly build as test build. If you had problems with any of the tests - or just want the latest fixes as well as the FrSky telemetry stuff - could you give those a test to make sure the changes were all merged properly?

Nightly builds with this changes have appeared. Please report issues. And it's always nice to hear about successes.