New FrSkyX protocol

protocol_frskyx is a branch from default 667678fbcff5 - the nightly before I added JJRCX1 back in. I usually push changes to my repo when I update the test build.

I didn't find any issues with the byte-splitting code for channels. That's consistent with Alexandro's latest feedback, which seems to indicate that pwm is fine but none of the channels are correct on SBUS. Not sure what's going on as there's only one way to send the channel data. I've used test data in the emulator and the generated packets look like the captured ones. midelic or Pascal, did you encounter a similar issue?

I've uploaded a new test build. I changed the rxnum constant to match the captured data. The rx telemetry (volt1 and rssi) should work now. I implemented my guess at the packet sequence numbers. Don't think any of these changes would affect the sbus data.

Thanks for the testing. It can be tedious when the developer doesn't have the targeted gear...

deviation-devo7e-v4.0.1-fbeac2a

Sorry, this is not working properly. The lock is very intermittent and servos are very jerky. Also, I cannot seem to get any telemetry.

Hello, GOOD NEWS

done some deep Testing with a Servotest Tool
i found a little work around for SBUS.
It is the same Bug with i have reported for Delta Mix.
I changed the Cannel Output from 100% to 99 % (at the left side of the mix menu) and than Cannel 1-12 is working perfect on SBUS and the Servos Sound normal when moving.

Telemetry does not show the RX Volt it shows 0V

Greetings Alex

Hmmm. Alex, can you confirm your latest testing was with version deviation-devo**-v4.0.1-fbeac2a.zip? If so, your results are different from djdazzy's. Can you confirm the PWM 1-8 also still works?

Alex, can you check the PWM and sbus channel values? I'd like to know the pulse width/value that correspond to Deviaion output values -100, 0, and 100. Sounds like might be overflowing something. I'll check on the emulator too.

I've uploaded test build d6d4e14., which backs out the sequence number change. Both versions on on the test build page, so please be sure which you download and include the version when you post test results. djdazzy, would you see if this version works for you?

Edit: Found a problem with the channel scaling, so the d6d build now has a fix for that also.

Hello,
yes it was the fbeac2a.zip

the idea from you to check the pwm Numbers was the right way.
PWM
Channel 1 1983->1362->819 and then it over shots to 2170 ->2101 ( on 100 -> 0 -> -100 Stick input)
other Channel 2-8 is ok with out the Overshot, but if i move Booth Sticks the Channel 1 does bleed into the other Channels at the Point of Overshot.
This is the same on the SBUS. The Overshot and the following bleeding into the other Channels does trigger the LED flicker ,Servo buzzing and going to crazy moving on Stick input

Edit -> 6D6 latest Testbuild
Done the same on Ver. 6d6
Channel 1 1089->1501->2046 on -100 ->0 -> 100 Stick
Now the Movement ist better and the bleeding and overshoot does not Trigger.
But the Stick moving way does not run hand in hand with the Numbers of PWM
At -75% the PWM is 1089 and on the following way to -100 the Servo does not move (and the PWM stands on 1089 with out moving to)
Same on SBUS, at -75% PWM is standing on 1089 and does not move
On PWM and SBUS the moving from 0 to 100 is ok with out any jumping or holding Points. Only the 0 to -100 does stop at -75% and then it holds the 1089

Edit2
Sticks fresh Calibrated and getting the same Numbers for 6d6 testing

Telemetry do show 0 V and rssi show 0c

greetings Alex

Something is wrong with channel mapping
Taranis max channels values from 860-2140 (125%) translated to PCM/PXX value 64-1984
860 to 64(Taranis -125%)
1500 is corresponding to 1024(this is zero neutral)
2140 to 1984(Taranis 125%)

1362 on zero is not good..On zero should be 1500

edit:
If packet[21] dos not get 0x80 it wlll not receive telemetry from RX

@hexfet

this is wrong
if (pkt[1] == (fixed_id & 0xff) && pkt[2] == (fixed_id >> && pkt[0] == len-1) {
}

pkt[0]cannot be len-1.

---

pkt[0]=len-3;
Maybe for this reason telemetry not working.

Thanks for the feedback! New test build is available

The channel scaling is fixed (again). Had forgotten how to subtract negative numbers

I changed the packet length test back to len-3, but I'm not sure why it's not 1. I'd changed it to match the test packet data I'd put in for the emulator. Looking at the spi capture it seems 15 bytes are being read on the SPI bus, and pkt[0] ix always 14. What am I missing, midelic?

The new build sets tx packet[21] to 0x80, as did the 6d6 build. Still want to try the sequence numbers later

I changed the telemetry display to Frsky format, which I'd previously forgotten. I've implemented the sport decoder for basic sensors (Volt2=ADC1, Vold3=ADC2, VoltA=BATT). They don't seem to show up in the correct positions or scaling on the telemetry screen, but really don't know what they should look like. Once the protocol is working can spend time on the display. And not sure how to handle the many sensors that are supported...

You are missing the appended bytes at the end of the 15 bytes frame the RSSI and LQI/CRC bytes.These bytes are calculated and added automatically by the chip.
Alsio your TX/RX handshake doesn't look good to me.


it starts always with TX(0x08)
RX answers with 0x88
and TX reply with 0x80.

see here.
www.rcgroups.com/forums/showpost.php?p=34080310&postcount=169

Anyway for test better start directly with 0x80 packet[21] and see later.

Just finished a reply on rcgroups then came here to check for an update. I'm not certain of the startup handshaking with the msb of the nibbles set, but I think we're on the right track. The rcgroups reply shows the sequence numbers fit the theory

it starts always with TX(0x08)
RX answers with 0x88
and TX reply with 0x80.

That matches the capture in the last post on rcgroups, right?

packet[21] is fixed at 0x80 until the rest is working

All captures I have show the same sequence at start.
TX(0x08)-RX(0x88)-TX(0x80)
after this sequence the following bytes are exchanged in different pattern not always the same.Probably it depends on what telemetry data arrived in RX buffer.
When I get back home in 4 weeks I will do more tests.
Without this problem fixed we cannot implement successfully full telemetry,For this reason I implemented only the RSSI,A1.A2 telemetry.
Imo it is easier to implement in Deviation full telemetry than multiprotocol.The code already exists.
For multi I need to extract the SPORT valid data and to repack them in SPORT frames that Er9X/Opentx can work with.

BTW for info the valid SPORT telemetry data is split in 2 telemetry frames...9 bytes(6+3).The maximum number of valid bytes in a telemetry frame is 6.
So it takes 2 telemetry frames to make one SPORT frame.

The existing deviation telemetry definitely makes things easier. We'll get the handshake logic eventually - enough to be compatible.

The latest version handles the sport packets being split across telemetry packets. The sport packet is built in sportRxBuffer. Need to add CRC checking. Most of that code comes straight from opentx.

Hello,
next Test Round on Ver.243627c

PWM on Channel 1-8 is 953 -> 1500 -> 2046
SBUS 1-8 is the same.
9,10,12 is working to with out big changes of the Numbers. Channel 11 is dead , no Signal !
Telemetry show the internal Voltage wrong -> 0.38 is on Display but has to be 3,8. No other things on Display for Telemetry

If i simulate a RX power los with pulling the Batt and plug in again, the SBUS is sometimes not right.
It jumps fast around with adding +- 300 counts to the normal numbers.
on repeating the Power loss Test it will sometimes work normal, but most it gone Wild .
-> mid Point is 1800 to 1500 jumping very fast at his monent.
The PWM is at this Stage not jumping on 1-8 but the complete SBUS is involved at this jumping Thing

greetings Alex

I suggest disable telemetry data processing function for the moment.Keep only the telemetry check .
Build one version and test till you get working good servo PWM and SBUS.

Does the PWM scaling need to be changed? I mapped the entire protocol channel range (0-2047) to -125% to +125% on Deviation. Should the scaling be changed so that -100% produces a 1000 us pulse on PWM? Alex, what was the channel scale when you were testing?

No idea about the bad channel 11. It looks fine in the emulator, and is not handled specially in any way.

The power loss should be no different than just turning the tx on first, then powering up the rx. Have you had to go through the bind procedure each time to get the tx and rx connected? Does Frsky require the rx be powered down after binding? Seems strange the pwm and sbus would be different. Haven't been able to deduce any change to make...

I can make a version tonight with telemetry disabled.

Hello,
the PWM scaling is good with this Numbers. Servos running good and follow direct to the Stick movement .
I used -100 0 100 for the Test ( Channel 1 953 1500 2046). I think 1500 is the normal Midpoint of most RC RX
on -125 0 125 it shows 816 1500 2181

I done a Cross check with an original FS-i10 TX ( Flysky )

-125 0 125 = 897 1500 2098 ( Deviation at moment 816 1500 2181 )
-100 0 100 = 997 1500 1998 ( Deviation at moment 953 1500 2046 )

it looks that the Deviation Numbers are a bit to high, may be better to go to max of :

-> -100 0 100 = 1000 1500 2000
-> -125 0 125 = 900 1500 2100

The Binding on booth ( Taranis and Deviation) require to power down the RX after Binding, this is a normal procedure .
After this first Bind it reconnect automatic after Power on .

i doent have the knowledge to overlook this Protocol but i think the most user of it want it on Planes and Quads.
Here is the need for SBUS ( for the Quad Brain in combination with the light wight RX ) and the Telemetry for RX Volt and RSSI to fly save.
The Plane Pilots like me like the good Range and the thrustful Protocol (no prob on brown and blackout on RX, fast reconnect )

Greetings Alex, sorry im missing so manny English words to tell the direct Point on my sentence . Im from Germany

Your posts are very understandable. Very much appreciate the testing you're doing

Test build is updated. Telemetry is disabled. Channel scaling changed to set Deviation 100% to produce 2000 us pwm (hopefully! did the math three ways and only got two different answers).

On the power loss testing, what is the test procedure? Do the tx and rx connect fine when first powered up? Then later remove and reconnect power and then see sbus problems? Just trying to get a better picture of what might be happening...

Hello,
i updated the TX with your latest Upload ( i has the same Serial Number on File? )

It must be a New File, because the Telemetry is off and the PWM Counts are on Spot now.

PWM on -100 0 100 is ok now (998 1503 2000)
PWM on -125 0 125 is a bit to much (873 1528 2125) -> 20-25 Clicks to High

-> The SBUS Problem and Blackout Test
To test the Power loos Recovery i pull the Battery on the RX ( i use a BEC with 5 Volt on the Test Bench ) and then after a schort Time ( +- 1 sec ) i plug it return to simulate a total Power loos on the RX
after this Test the SBUS does most Time not recover right from the Reboot. On the SBUS to PWM Decoder (Original from Frsky) are 4 LED . This LED are a Indikator for the Programming of the PWM Outputs and
they show the Action on the SBUS Outputs. If they all 4 are Solid on, then the SBUS is running ok. But if they are Flicker (i think they show the Direct Frequency of the SBUS) then the SBUS does not work correct.
I have seen some variations of the Flicker at the Reboot, some times all 4 LED flicker together and some times they are not sync (may be a other Frequency who come up on a not sync refresh Rate or a not sendet Start Signal for sync on SBUS ? )

On the first Start of RX and TX the same SBUS Bug can appear, it is total random how it show up. If i switch only the TX on and off the Bug (SBUS) does not change his state.
If the SBUS is on Flicker then the Reboot of the TX will not change any thing on the RX, the RX flicker on the same Way all the Time ( may be it comes direct vom the CPU of the RX who is not right instructed from the Protocol ?)

EDIT:
@midelic

This was a good Point !
1. The Channel 11 Problem is a broken Output on the Converter, the 2nd Converter is running with out any Problem on Channel 11 ( if the Bug dont show up)
2. The SBUS is working with out any Problem if the Bug dont show up, but the Bug is very often and this on complete Power up of RX and TX to (at switching on the complete System)
Cross Check:

PWM 1-8 are Ok and not show the Bug
SBUS 1-12 are buged (Deviation) , if the Bug show up.
On Taranis the LED of the Converter are sometimes does a little Flicker to ( on the Black out Test ) but the Servos do there work without jumping.

Greeting Alex

It will help to see how the Taranis TX wroking in the same conditions with the same RX for comparison.
SBUS testing.
Also how the SBUS channels are behaving?Aside the power loss problem.
Step by Step.
PWM 1-8 are Ok
SBUS 1-8?
SBUS 9-12(16)?