New FrSkyX protocol

Idk I see in OpenTX fixed channel values for FS_HOLD
and no pulses,....not the last data transmitted

for (int i=0; i<8; i++) {
if (flag1 & PXX_SEND_FAILSAFE) {
if (g_model.moduleData[port].failsafeMode == FAILSAFE_HOLD) {
chan = (i < sendUpperChannels ? 4095 : 2047);
}
else if (g_model.moduleData[port].failsafeMode == FAILSAFE_NOPULSES) {
chan = (i < sendUpperChannels ? 2048 : 0);
}
else {
if (i < sendUpperChannels)
chan = limit(2049, PPM_CH_CENTER(8+g_model.moduleData[port].channelsStart+i) - PPM_CENTER + (g_model.moduleData[port].failsafeChannels[8+g_model.moduleData[port].channelsStart+i] * 512 / 682) + 3072, 4094);
else
chan = limit(1, PPM_CH_CENTER(g_model.moduleData[port].channelsStart+i) - PPM_CENTER + (g_model.moduleData[port].failsafeChannels[g_model.moduleData[port].channelsStart+i] * 512 / 682) + 1024, 2046);
}
}
else {
if (i < sendUpperChannels)
chan = limit(2049, PPM_CH_CENTER(8+g_model.moduleData[port].channelsStart+i) - PPM_CENTER + (channelOutputs[8+g_model.moduleData[port].channelsStart+i] * 512 / 682) + 3072, 4094);
else if (i < NUM_CHANNELS(port))
chan = limit(1, PPM_CH_CENTER(g_model.moduleData[port].channelsStart+i) - PPM_CENTER + (channelOutputs[g_model.moduleData[port].channelsStart+i] * 512 / 682) + 1024, 2046);
else
chan = 1024;
}

if (i & 1) {
putPcmByte(chan_low, port); // Low byte of channel
putPcmByte(((chan_low >> & 0x0F) | (chan << 4), port); // 4 bits each from 2 channels
putPcmByte(chan >> 4, port); // High byte of channel
}
else {
chan_low = chan;
}
}

I have tested failsave from Tx with original Frsky DHT-U Tx and D4R-II Rx. (D protocol)

And just to confirm, the Failsave set by push button on the Tx, it is permanently stored in the Rx.
Switching off the Tx and for the Rx battery removed, when switching back on the failsave positions still in place as set.

Maybe someone can confirm it works same for X protocol?
I would suggest a set failsave button, in Frsky protocol, menu under AD2GAIN?

Good find midelic. Nice to have source code. Looks like the channel endpoint values are reserved for setting the type of failsafe. The code that sends the normal channel data limits the values to 1-2046 and 2049-4094 so there's no chance of setting failsafe to NoPulse or Hold when setting failsafe by sticks.

How best to translate this to Deviation? Easiest would be a protocol option to choose NoPulse or Hold. Any channels with failsafe turned off would send this setting. To make a per-channel setting would mean adding NoPulse and Hold options to the channel failsafe settings. I'll take a look at that but suspect it might be difficult to add those options in a way that they only show up for frsky.

Not sure about the button on the DHT-U to save the transmitted failsafe permanently in the rx. There's nothing equivalent in the opentx code. We need to know what the DHT-U transmits when the button is pressed.

The bug that kept channels 5-8 stuck at idle value had that effect because the unused channels 13-16 were incorrectly being sent without the high bit set. This confirmed something alluded to on the rcgroups thread where it was stated that if the number of active channels was less than 9 then the upper channels weren't sent at all. Evidently the receiver always checks bit 11 to determine whether the channel is 1-8 or 9-16 and the position in the packet selects within that range.

So it should work to always send the lower channel value if the corresponding upper channel is not used (and vice versa). These channels would have a 9ms update rate instead of 18ms. Not sure if that makes any real difference at the sticks, but something we could play with. For example you could set up your model with sticks on channels 5-8 and always get a 9ms update rate since 13-16 are always unused.

@hexfet
See attached pxx_arm.cpp file ,It is the last updated,There is more info bind ,rangecheck and FS.

I think the no Pulse Option (sending no PWM value) is a waste of time, 99% of the 2.4 Ghz RX uses Hold an around 80% are programable with Failsave. If there is no Failsave programmed then the RX uses automatic the Hold Funktion . There is no need to set it on Deviation Menu.

Only my old Picolario Vario does read a RX loss with the PWM loos. The newer Systems has Channel to activate the Return to Home or other save Routines and this is done by setting the Failsave Channel to a 100 Value to activate.

my 2 cnt.

greetings Alex

Thanks midelic. Good info. Looks like OpenTX does set any unused high channels to repeat the low channel data. I updated the test build with this change. The bind and rangecheck commands probably just affect the tx DJT module, right?

Alex, not sure if there's much use for NoPulse these days. Maybe we'll hear some other opinions. I'm inclined to support it if for no other reason than it's available in the protocol. Based on your input a protocol option seems fine and Hold will be the default setting.

Test build is updated. The new failsafe protocol option can be set to one of three values.
Hold: on channels with failsafe off, commands the receiver to hold last received channel value if signal lost. This is the default.
No Pulse: on channels with failsafe off, commands the receiver to not send pwm pulses on the channel if signal lost
RX: no failsafe packets are sent. The receiver settings determine how it behaves on signal loss

Channels with a configured failsafe value command the receiver to move to that value on signal loss unless the protocol option is set to RX.

These are equivalent to the opentx options, including having RX mode affect all channels. Wouldn't be difficult to omit sending failsafe for particular channels but not sure how the receiver would handle it. Probably not worth spending time on.

Everything I read on this says the tx failsafe packets override any failsafe settings in the receiver until the receiver is powered off. They are not stored permanently. The RX option was added to opentx for people who prefer to use the receiver settings.

Hello,
Test Ver.76c

The Failsave Menu show Off and the Value to change ( Hold,No PWM Option ? )

On Test the Channel 1-8 are going to PWM 2180 on Failsave ( Menu Failsave Off ) . Here they has to Hold the last Pos
Channel 9-12 are doing right, they Hold on Failsave Off.

greetings Alex

Deleted

For D series, (tested RX d4R-II), I 100% can confirm that failsave set from Tx is strored saved in RX. Failsave still operate correct after removing battery from Rx.
For X series, I can possibly check failsave later next week, a friend of my own a brand new Taranis and X6R Rx.

I have no means to capture the raw data, from tx rx.

I was off by one bit on the HOLD value for the low channels. Picky computers. Test build is updated.

The option to choose Hold, NoPulse, or RX failsafe mode is a protocol option. Click on the protocol name in the model config to see the protocol options. This sets the failsafe treatment for channels that have the channel failsafe set "Off". Except for RX, which means don't send any failsafe values at all on any channel. That causes the receiver to use whatever values have been saved in the receiver. The default is Hold so users who don't change the protocol option will see that behavior.

Fernandez do you think your friend will let you bind to the X6R? Another confirmation things are working in deviation would be good.

Hello,
Test on Ver. 653

- SBUS goes on NO PULSE to PWM 877 on all SBUS Channel
- HOLD overwrite RX (Button on RX to save Failsave)
- RX at Menu does not overwrite HOLD ( only a Power Cycle clear the HOLD on RX and then the RX work with his one setting (Programed by pressing the Button on RX)
- The Failsave Value on Menu overwrite all 3 other Settings ( HOLD , RX , NO PULSE) and stays until a Power Cycle is done

The Failsave refresh time is around 10 Sec.
Can You do a reset on RX after changed Failsave Settings on Deviation ?

greetings Alex

yes will try to let you know by next week, if we are able to set and store failsave setting from taranis to x6r recever permanently.

Alexandro wrote: Hello,
Test on Ver. 653

- SBUS goes on NO PULSE to PWM 877 on all SBUS Channel

Not sure what the expected behavior would be on SBUS for NoPulse. On the PWM outputs there are no pulses? The SBUS protocol has a separate flags byte to indicate frame loss and failsafe since there's always some value in the channels. What are the SBUS LEDs doing in this state? Do you know if this the same behavior if bound to a Taranis with failsafe set to No Pulses?

- HOLD overwrite RX (Button on RX to save Failsave)

I think that's the expected result.

- RX at Menu does not overwrite HOLD ( only a Power Cycle clear the HOLD on RX and then the RX work with his one setting (Programed by pressing the Button on RX)

This is curious. Is it the same if you have the setting at NoPulse then change to RX? How about changing from Hold to NoPulse and vice-versa?

According to the Taranis manual it is not necessary (at least it's not mentioned) to power off the receiver when changing between Hold, NoPulse, and RX modes. It just says to wait 9 seconds to be sure at least one failsafe cycte has gone by. However I can imagine that the firmware in the RX might keep the failsafe settings it had received from the tx if the tx stops sending failsafe packets until the receiver is powered off. Would be interesting to know if Taranis behaves the same. It's also possible different receivers react differently.

- The Failsave Value on Menu overwrite all 3 other Settings ( HOLD , RX , NO PULSE) and stays until a Power Cycle is done

That is the expected behavior

The Failsave refresh time is around 10 Sec.
Can You do a reset on RX after changed Failsave Settings on Deviation ?

I haven't seen anything like a command to reset the rx in the protocol.

As always, much thanks for the testing and reporting.

Good news: Test build is updated with support for hub telemetry sensors. Please let me know what telemetry values are being received. No need for now to change the AD2GAIN setting. Anything received should be shown in the same boxes used by the Frsky (D8) protocol.

Middlin' news: The hub telemetry support is pulled straight from the frsky2way code, which includes the changes in the protocol_combo build. Hopefully it works.

Bad news: No build for the 7e. I get the error below which I haven't seen before so if it's familiar please let me know. Usually I see a rom overflow if the build won't fit a 7e. Will have to look into it...

Sorry for offtopic.
I think the processing hub telemetry packets in Frsky D8 is not the correct one.Not sure if this is in the last modified file.
Telemetry frame has 18packets+2 appended packets=20 packets ,so len=20.So it looks like only one Hub frame in telemetry frame is processed.One frame can contain max 10 hub packets,One hub frame is 0x5E,ID,XX,XX ,0x5E(5 bytes)
I think PB only processed only one hub frame not take care of the other.It can be 2 hub frames in one telemetry frame.


How many Hub packets do you see they are processed in deviation frsky D8?

static void frsky2way_parse_telem(u8 *pkt, int len)
{
u8 AD2gain = Model.proto_opts[PROTO_OPTS_AD2GAIN];
//byte1 == data len (+ 2 for CRC)
//byte 2,3 = fixed=id
//byte 4 = A1 : 52mV per count; 4.5V = 0x56
//byte 5 = A2 : 13.4mV per count; 3.0V = 0xE3 on D6FR
//byte6 = RSSI
//verify pkt
//printf("%02x<>%02x %02x<>%02x %d<>%d\n", pkt[1], fixed_id & 0xff, pkt[2], (fixed_id >> & 0xff, len, pkt[0]+3);
if(pkt[1] != (fixed_id & 0xff) || pkt[2] != ((fixed_id >> & 0xff) || len != pkt[0] + 3)
return;
len -= 2;
//Get voltage A1 (52mv/count)
Telemetry.value[TELEM_FRSKY_VOLT1] = pkt[3] * 52 / 10; //In 1/100 of Volts
TELEMETRY_SetUpdated(TELEM_FRSKY_VOLT1);
//Get voltage A2 (~13.2mv/count) (Docs say 1/4 of A1)
Telemetry.value[TELEM_FRSKY_VOLT2] = pkt[4] * (132*AD2gain) / 1000; //In 1/100 of Volts *(A2gain/10)
TELEMETRY_SetUpdated(TELEM_FRSKY_VOLT2);

Telemetry.value[TELEM_FRSKY_RSSI] = pkt[5]; // Value in Db
TELEMETRY_SetUpdated(TELEM_FRSKY_RSSI);

for(int i = 6; i < len - 4; i++)
frsky_parse_telem_stream(pkt);
}

Now you are working on this would it be possible to make the ADGAIN, higher resolution, so one or two digits behind the comma.
Would be very handy if we can tune voltage accurately at Tx using Gain parameter. Otherwise need a variable resitor at my devider to tune voltage accurately, often I use 4k7/22k which is good till 4s.

Hello,
Test Ver.75b
- On NO PULSE the normal PWM outputs (on RX) does switch to no PWM, the SBUS 1-12 goes to PWM 877. On Taranis with latest 1.XX it is the same 877 on SBUS
- From NO PULSE to RX the NO PUSE stay until RX Power Cycle
- From RX to NO PULSE the NO PULSE is used.
-> The Deviation setting (NO PULSE, HOLD ,FAILSAVE Value) stay until RX Power Cycle. Failsave Value is Master until RX Power Cycle, all other Menu Settings are ignored.

Telemetry:
With Vario on SPORT i get RSSI,Volt1,Volt2 (jumps random 0 to 2.5). With out Vario the Volt2 does nothing (may be this is the AD2 Vario Altitude gain without a filter ? )
Telemetry restart with out anny Problem on RX Power Cycle.

-> As always, much thanks for the testing and reporting. <- You are always Welcome ! If i want something i has to do somthing

greetings Alex

midelic wrote: Sorry for offtopic.
I think the processing hub telemetry packets in Frsky D8 is not the correct one.Not sure if this is in the last modified file.

You're right that code is not correct but it is still the latest in the nightly build. It's fixed in the frsky_telemetry branch in my repo, and those changes are included in the protocol_combo test build. As far as I know it's as yet untested. I haven't made a pull request because a build with both that fix and frskyx won't fit on the 7e. I'll have to see what can be done when we're closer to finished.

The common part that I pulled out is the switch statement below the code you posted that puts the value in the Telemetry struct based on id. The old hub sensor telemetry data (id and value) is carried in the sport telemetry packets with the old sensor id in the low-byte of the sport id and the high-byte set to zero. The sport value field is interpreted as 16-bit sensor value. For these id's we can just share the code in frsky2way and frskyx. It's equivalent to whats in the opentx processHubPacket function.