New FrSkyX protocol

djdazzy wrote: Can someone confirm what level of D16 telemetry is included in the nightly build please? I agree with mwn about the temporary branch until the development of fixes in version 5.0 stabilises.

The nightly has the full implementation. There's a pending pull request for D8 telemetry which might affect old sensors.

Cereal_Killer wrote: I appear to be having some sort of protocol based issue...

I'll be flying, hovering or whatever and all the sudden I'll get a single failsafe engaged beep and the model will fall a foot or two then control will come back.

It doesn't appear to be range related as I get it happening regardless of distance. I also experience the opposite: again I'll be hovering still and for one second it'll climb like I'm commanding high amount of throttle.

Neither happen with taranis.

Sounds like it's something different. Detective time.
What do you mean by failsafe engaged beep? Is that coming from the rx?

How do you have your failsafe set up? Are there any channel failsafe values set? Does the behavior stay the same if you set the failsafe protocol option to RX? Does it happen at regular intervals? If so how long between episodes?

Do you get any RSSI alarm on the tx? Can you turn on datalog for RSSI and see if there are any dropouts?

hexfet wrote: Sounds like it's something different. Detective time.
What do you mean by failsafe engaged beep? Is that coming from the rx?

☆Beep coming from the model, by FS beep I mean the longer single beep that it makes when you switch off tx while armed. Note it's not a continous beep but a longer beeping, when this happens I get a single one of those longer, higher priority beeps and the model falls for .5 to 1sec the recovers it self.


How do you have your failsafe set up? Are there any channel failsafe values set? Does the behavior stay the same if you set the failsafe protocol option to RX? Does it happen at regular intervals? If so how long between episodes?

☆ FS is setup for no pulses. No ch values ever set as I prefer cleanflight to handle FS. Not at regular timed / precise intervals no but it happens every few minutes or more often (a few times its happened repeatedly within one or two minutes, other times 5 minutes between events). It does this regardless of range, from a couple hundred meters to as little as a few meters.

Do you get any RSSI alarm on the tx? Can you turn on datalog for RSSI and see if there are any dropouts?

☆ no alarm, of course I can't look at the display and fly at the same time but best I can tell it's got good rssi when it happens (no alarms, when I can look at the display rssi is reading that it's plenty strong)

I'd be happy to datalog, how?
☆ direct replies to all your Q's in quoted text.
Thanks

The datalog setup is in the model config section. Set it up to save TelemRSSI every second and choose an enable signal - the channel you use for throttle is a reasonable choice. Would be good to also log that channel to see if the tx is sending max/min throttle for some reason. I haven't used this feature before. I think there may be a tool in the repository to decode the resulting datalog.bin file.

Doesn't sound like an RSSI issue though, if you've got an alarm on the tx and it doesn't trigger. What's the typical RSSI value do you see? Does changing the fine frequency adjustment 10-20 in either direction give a higher value?

Can you try setting the failsafe protocol option to RX? If you program the RX to "no pulses" then cleanflight should still behave the same.

Don't have any guesses as to what might be happening. Nothing in the protocol happens on a minutes timescale...

may not be relevant to this case. I do experience dropout on version 5 nightly in KN and DSM2 protocol.

I reverted back to version 4 for the moment

hexfet wrote:

djdazzy wrote: Can someone confirm what level of D16 telemetry is included in the nightly build please? I agree with mwn about the temporary branch until the development of fixes in version 5.0 stabilises.

The nightly has the full implementation. There's a pending pull request for D8 telemetry which might affect old sensors.

Thanks Hexfet

hexfet wrote: Does changing the fine frequency adjustment 10-20 in either direction give a higher value?

Thanks for reply, no time for testing this week but I'll get to it and enable logging ASAP.

I have fine gain at 0, I'd seen it mentioned but couldn't find a good explanation of what it is / how to adjust it. Rssi is typically 88 to 103 now.

Is >100DB real or a reading / display error? I've never seen it >100 on taranis.

Cereal_Killer wrote: Is >100DB real or a reading / display error? I've never seen it >100 on taranis.

It's correct and is the raw value received. The SPI captures with telemetry data show those values. From what I can tell in opentx it's not scaled in any way. But opentx gets the value after it's been through the tx module so maybe some change happens there.

Hi

I have a issue accessing the Telemetry Config, using FrSkyX, when on the latest nightly build from 10-JUN-2016

Is it just me?

Is shows a "1" and resets

Devo10

Don't see this issue in the emulator. Does it happen with other protocols?

Did you upgrade your filesystem when changing from 4.0.1 to 5.0.0?

hexfet wrote: Don't see this issue in the emulator. Does it happen with other protocols?

Did you upgrade your filesystem when changing from 4.0.1 to 5.0.0?

Thanks for the reply. I fixed it by making a new model from scratch. The error also happend in the emulator.

Is it possible to get the VFAS reading via telemetry

I run a SPRacingF3 board together with the Smartport on UART TX and the reading I get is 4.80V 2.88V on 2 cells from the flight controller and the values does not change with other batteries with less voltage

mickkn wrote: Is it possible to get the VFAS reading via telemetry

Yes? VFAS is called VOLTA, about the 6th (or parameter down.


If you want to display it on the main screen look for the parameter called "TelemVAmp".

Important fact: Telemetry and Softserial need to be enabled on the FC

mickkn wrote:

hexfet wrote: Don't see this issue in the emulator. Does it happen with other protocols?

Did you upgrade your filesystem when changing from 4.0.1 to 5.0.0?

Thanks for the reply. I fixed it by making a new model from scratch. The error also happend in the emulator.

Was the old model file previously working? Please post it if you still have it. Curious about what file content could cause the issue you described.

Here is the filesystem with the error model on startup

dl.dropboxusercontent.com/u/53726931/Dev...eeze_Tele_Config.zip

I'm getting dropouts on Devo10 5.0.0-b4dfc5e FskyX using a X4RSB (tried 2 different X4RSBs). When I move the sticks, I can see modulation in Cleanflight. However, there are dropouts where there's no signal. I can also see the light on the receiver go from green, to no light at all, red, then back to green.

I tried to datalog using hexfet's instructions, but I'm not sure if I did this correctly. The log can be downloaded:
www.speedyshare.com/UASaK/datalog.bin

Thanks! Nice complex model

The issue was caused by missing definitions for max values of Cell1-6 telemetry, combined with the model file having Cell2 defined as the source for telemalarm1. This put the code into an infinite loop, leading to the reset.

The Cell2 max value was defaulting to 0, so it wouldn't have appeared as a choice in the GUI. Was it an existing model file you brought forward to 5.0?

I've pushed a fix which should be in the next nightly. The Cell1-6 max values are now 5V, which allows them to be used as sources for alarms in the telemetry config page. So the model from the zip now works.

Can't remember, but it's possible that I transfered it from 4.0.1 to 5.0.0

dude wrote: I'm getting dropouts on Devo10 5.0.0-b4dfc5e FskyX using a X4RSB (tried 2 different X4RSBs). When I move the sticks, I can see modulation in Cleanflight. However, there are dropouts where there's no signal. I can also see the light on the receiver go from green, to no light at all, red, then back to green.

I tried to datalog using hexfet's instructions, but I'm not sure if I did this correctly. The log can be downloaded:
www.speedyshare.com/UASaK/datalog.bin

This datalog file has Volt1 telemetry, and all the values are around 10V. Does that make sense, or should it be the X4RSB receiver voltage?

Please set the datalog to record RSSI, and record through at least one dropout event.

Is this happening in the field or tabletop? If close to the receiver please try reducing the tx output power.
Are there any actions on the tx correlated with the dropouts, or do they seem to be just random?
Does changing the Fine freg adjustment 5-10-20 in either direction make any difference?