New FrSkyX protocol

With the scale of 100% set to 2000 us, the width at 125 must follow the same scale - it's linear. With the current channel scaling the absolute max limit will be at about 136. Setting 100% to mean 2000 us makes sense so I think we're done with that.

SBUS 1-12 are buged (Deviation) , if the Bug show up.

What is on SBUS 13-16 at this time? I couldn't find any information on the LEDs on that decoder. I wonder if they mean anything specific like an error code.

One more check I can make on packet content is to force a chanskip value and make sure the channel hopping is correct. Another possibility is that I made a mistake porting the radio setup code. One other thing I can think of is the packet[21] byte might be involved somehow, but if setting it to 0x80 works sometimes why doesn't it work all the time. Other possibilities?

It seems unusual to me that if the rx is receiving enough packets to put good values on the pwm pins that it doesn't put those same values on the sbus.

it will help also to hook up the servos on the the SBUS to PWM decoder see physically how servos behave after the SBUS interface.
I checked the manual for that decoder ,there is no relevant info for the LED flickering or not.
chenskip have nothing to do with channel data even if channels are skipped ,...data is received whole on the available channel,And I see the data is received very well. when tested with servo on PWM.
Data frame are alternating, one time channels 1-8 and the next frame channels 9-16.
When I get back home I will do a full test on SBUS with my multimodule.

Hello,
the SBUS Channel 13-16 is not gainable at the Deviation Menu. It only goes to 12 Channel ( is this the source of the SBUS lock up ? missing Channel Data ?)
-> is the Data line for SBUS directed from the RX Chip to the SBUS to PWM Converter with out a filter and does this Trigger the Bug ? and the 1-8 PWM out going trough the Cpu for Fail save and filter it ?


The led does not show an Error Message , they light solid on successful SBUS working and they do fast blinking ( sometimes faster and slower) on restart Bug.

On the other things (packet and handshake) my knowledge is to small, sorry.

greetings Alex

Good afternoon everybody.
I finally received all the hardware necessary to upgrade my devo 12S to frSky protocol.
A friend more informed that i am will do the job ; tunings to.
I am lost now in the course of discussions in the subject.
I would be sure of few datas before going forwarfd
1) Is this one the most recent file for Devo12S : deviation-devo12-v4.0.1-4fc5268.
2) in this file i will find all software necessary to add FsSkyX potocol to my devo 12S ? A tutorial somewhere ?
3) with this FrSkyX protocol i will need to use only D receiver such as the D8 one.?
4) X one in project ? by upgradind the 4.0.1 deviation ?
5) Wiil I be able to use it with an APM 2.8 in PWM or PPM sum protocol ?
Thanks for helps and answers.
Regards

Interesting
maybe it can be initiated in the code channel data array for 16 channels(use neutral channel values for all 16) .Maybe those blinks are from the rest of the channels till 16 are not in the required SBUS range 0-2047.
Sbus packets are using bits from 2 channels.It is possible that if sbus data missing to activate SBUS flag on signal lost and FS values.

The implementation sets channels 13-16 to 1024 and I see those values in the emulator packets. Curious to know if they were correct but it really sounds like the sbus is just free-running.

I started looking at the sbus protocol to see if it might yield some clues. Found some old pdfs, and some newish looking code that I'm downloading Visual Studio to look at.

One interesting bit from the pdf isI interpret that as telling the downstream hubs/servos that the rx has "lost frame" with the tx. Since the protocol channel data is not framed I'm not sure what that means. Maybe just not receiving valid packets.

Another bit is for sbus2 only: "I've only captured the following 4 variations of endbyte data. I've tried everything I can think of to generate something different, but these are the only ones I can create. They appear in rotation in the order shown, which appears to form a two bit 0-3 counter (remembering that the high order bit is to the right)." Sounds like a sequence number, but don't know what purpose it might serve in a one-way protocol where every frame repeats the same information. Interested to see if the VS code does anything with those bits.

let's summarize from previous page
In fact the ch11 is working (it was adapter problem) and the SBUS is working on all 12 channels ,,but the problem is the bug that appears on Power up of TX or RX and consists on jumping values.

These SBUS jumping values are happening only at stop/start or also on normal running?

Alexandro wrote: 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

Hello,
the jumping of the SBUS values is most random , it is triggered on Startup ( i switch on the TX, waiting for Deviation Screen and then i switch on the RX) and it can be triggered with switching the RX off an on again.

If it is not triggered ( sometimes it will power up without any Problem) then the SBUS run without any jumping and the moving of the Servos are ok.

If the Bug is triggered the PWM on the Decoder show 0023 and jumping +- 10 (with moving the Stick) or on 2nd Trigger jumping 1100 to 1800 on the Center of the Stick.

greetings Alex

This is an important remark.it happened only at start.That may show at start the Tx sends out wrong or corrupt values.
if you start RX first and TX next the bug is the same?

On Power up the RX first it is the same ( The Bug shows random)

The off ,on of the TX does not change the state of the Bug.
Only the off, on of the RX does change the state of the Bug ( sometimes the Bug disappear after RX power cycle )

Noel wrote: Good afternoon everybody.
I finally received all the hardware necessary to upgrade my devo 12S to frSky protocol.
A friend more informed that i am will do the job ; tunings to.
I am lost now in the course of discussions in the subject.
I would be sure of few datas before going forwarfd
1) Is this one the most recent file for Devo12S : deviation-devo12-v4.0.1-4fc5268.
2) in this file i will find all software necessary to add FsSkyX potocol to my devo 12S ? A tutorial somewhere ?
3) with this FrSkyX protocol i will need to use only D receiver such as the D8 one.?
4) X one in project ? by upgradind the 4.0.1 deviation ?
5) Wiil I be able to use it with an APM 2.8 in PWM or PPM sum protocol ?
Thanks for helps and answers.
Regards

If you have D series receivers the nightly build works ok in FRSKY (D8) mode, FRSKYX (X series D16 mode) is currently in development so I wouldn't use it to fly at the moment.

@hexfet
Tested 7e on 243627c - green light flickers and PWM channels are very jittery with very slow servo updates.

djdazzy wrote: @hexfet
Tested 7e on 243627c - green light flickers and PWM channels are very jittery with very slow servo updates.

Curious that you're seeing different results than Alex. You're both using X8R receivers with international firmware? Does power levels and/or distance make a difference? Do you have any way to check the sbus?

I've uploaded a new test build. Setting protocol option AD2GAIN to 3 will enable the packet[21] sequencing code (and any other value turns it off). I'm predicting it will make things better or worse...or no change Really just hoping for some indication whether that byte is or is not meaningful for the sbus problem.

@djdazzy
The binding was ok? It looks like to me a problem of tweaking fine variable.Try give different values to fine variable negative -41 to 0.
Maybe they are using different CC2500 module,BTW which module do you use?

Hello ,
Ver. 949 Test
I done a new Bind and switched the Converter to 9-12 on SBUS .

it looks like the Black out Bug is now 50% ( 5 from 10 RX power cycle doing a good restart and the SBUS is working ). The last Ver. 243 does more look like 75% miss of good restart.
-> it can be the right way with 949, but the leds on the Converter show the same as ver.243. Only the Servo does better working on 949.

The Telemetry show 0.49 and has to show 4.9, here is a litte Error on calculation .

---

@djdazzy
if it helps, my CC2500 is this from BangXXXd
CC2500 PA LNA Romote Wireless Module CC2500 SI4432
it has a blue protection Foil on the Shielding at Picture, and it do not need a fine tweak for D8 (it is the same thats at the Info Page for wire it on the TX)

-> the Frsky RX does need a litte distance to work with the TX. I switched to lowest TX Power to prevent an overload at the RX Chip
-> sometimes the Telemetry from the RX does Trigger noise on Servos and BEC with his 2.4 Waves ( better to put the RX Antenna away from the BEC and Servos)
-> i updated my X8R yesterday to the latest Non EU Ver. to get the same Results and it does nothing change on my Test results ( may be it was the same Ver. from the delivering )

i hope it Helps

greetings Alex

I know there is a swamping problem when tx is too close to RX.This happens with X series receivers.
Can you test at a longer distance between TX and RX (>1m)and see if this bug coming back again.

@hexfet
you may put telemetry back .At least they can test RSSI;RXBTand A2.

Unfortunate i have to wait for 4 weeks to test myself to see if the same bug coming out on multi.

Hello,
done the Test with >1m and with out Antenna, it does not change any thing.
But if i power up the RX and then the Tx , the Bug free % will go to around 75%. I looks this way ( 1st RX than TX) does a bit better to get a good SBUS.
The LED on SBUS Converter do not show the same (better) result but the Servo does a better Job

if you need a Video i can try to show the bug and the led Flicker

EDIT:
i done a Test Check on SBUS with an low grade Scope and there is no big difference to see ( with or with out Bug )
It looks like a normal Digital Data transmitting

greetings Alex

Alexandro wrote: and with out Antenna

Do you use a dummy load to protect the PA?


Looks like maybe byte 21 is related but not certain. I'll try tweaking the sequence to more closely match the captures. midelic, do you know what byte 21 does if only the tx is on - no rx?

Good to know the telemetry is received. For now we should focus on the protocol. Cleaning up the display and scaling will be a subsequent effort.

What I know for sure is that the packet[21] is related with telemetry.
If no rx to answer TX sends out packet[21]=0x08 forever.
If packet[21] sends out 0x08 only ,....and rx is on. the SPORT telemetry is blocked,RX don't send out any SPORT packet.Only normal telemetry data till packets[6].
IMO packet[21] have no influence in current bug. only telemetry related.There is a similar thing in D protocol.with .packet[4].When received HUB telemetry this packet increments.In Deviation was always zero.
You can try if you want to send 0x08 see what happens. See if you have SBUS control.

Good info. Previous version sending fixed values on packet[21] were sending 0x80.

Test build is updated. Set protocol option AD2GAIN =1 to send packet[21] fixed at 0x08. Set to 3 to enable packet[21] sequencing. Some changes have been made in the sequencing to better match the spi captures.