New FrSkyX protocol

sfersystem wrote: I bridged the rx and tx pin from my F303 V3.1 and connected to smartport of the xsr...

i forget something ?

You only bridge the pins using softserial, you're using a hardware serial port (UART3) so you only need the TX pin. Most likely yours doesn't work cause you need to make sure you enable SET telemetry_inversion=ON in the CLI and enable telemetry (in general) under the main page GUI setup, then you must setup your port under the PORTS tab.


Personally I run (and recommend you do to) S.Port telemetry on softserial, no need to waste a HW UART for that. In this instance [using softserial] is when you bridge the RX and TX pins on the FCB, again using UART3 like you are you only use TX.

All this info is found in the cleanflight documentation on the telemetry page and IMO is one of the clearest parts of all the docu! It'll walk you step-by-step with the exact CLI commands and wiring and everything.

Edit: I recommend you follow the section titled "SmartPort on F1 and F3 targets with SoftSerial"

Cereal_Killer wrote: You only bridge the pins using softserial, you're using a hardware serial port (UART3) so you only need the TX pin.

That was my light !!

Thank you so much for your help !
it works now

@hexfet,
You may want to change the RSSI calculation on deviation FrskyX.
We(in fact Mike B.) came out with a better calculation of RSSI on multiprotocol FrskyX telemetry.
*********************************************
if(pktt[4] & 0x80)//yes Bit 7
rssi=pktt[4] & 0x7F ;
else
RxBt = (pktt[4]<<1) + 1 ;
******************************************************

Thanks for the heads up midelic

I've tested with my XSR and interpretation of the MSb and RSSI works fine. I've pushed that change. But to get the correct receiver voltage display in deviation the battery voltage still must be interpreted as hundredths of volts (i.e. pkt[4]==36 means 3.6 volts) to get the correct displayed value. I tested with XSR supply voltages from 3.6 to 8.4.

I see the DIY multi code is reporting the RxBt value with s.port application id 0xf104. The s.port documentation I have does not have any info on the units or interpretation of that id so I would guess the code you show is correct for that application. If you have a link to where this was discussed I'd like to read that.

Rxbt calculation in multi is specific Er9x ersky9X.Opentx display,
For Devo you may do your own calculation...I was pointing highlighting only RSSI problem The RSSI values on Devo where too high and not real..

midelic wrote: The RSSI values on Devo where too high and not real..

+1
I've lost signal 3 times and crashes with a RSSI about 75 db, I assumed that it came from there without being totally sure

Can you tell us when nightly with modification is available ?

Edit : Think it's done now.

Thx for help and the good work.

I am trying to bind a FrSky XM+ receiver with my Devo 10 with 4in1 mod and latest nightly build.
I tried the bind process as described in the FrSky XM+ manual several times but I cannot get the receiver to bind. Basically,
I select FrSkyX in Menu Setup, click on the bind button in Menu Setup, then keep the bind button on the receiver pressed while powering it up. All I get is a blinking red light rather then the flashing green and solid red.

What am I doing wrong?

Thanks!

Sounds bound to me... Have you tested it?

I have the xm+, and last week tried to bind with an old nightly that didn't sport frskyx, in that process the rx powerd up with the bind button pushed showed solid red and green leds.

I've updated my 7e to deviation 5.0, and up to the nightly from 20th jan. All looks good the current model i had remained boundand responded to the switches. So tonight ill swap the xm+back in and try to bind

It was "almost bound"... I tried the same process after tweaking the frequency in steps of 20 (under FrySkyX options). It started to bing with at -10 and it kept binding up to -120.
I ended up choosing -60, as it is somewhere in between the min and max. Not sure whether that matters though.

I can confirm that the new FrySky XM+ works fine with the nightly of Jan 20 and the 4in1 mod on a Devo 10. All controls are working great as well as the switches. I also get RSSI on channel 16, which is then displayed in my OSD (Betaflight 3.1 compatible).

I will try to fly it today and see how it behaves. So far, I'm very pleased with the outcome of the mod.
Good job guys with the FrySkyX protocol and thanks for the help.

Use the LQI telemetry value as a guide to the fine frequency adjustment. Should be able to achieve a value below 50. On the Devo 10 telemetry test page LQI is in the last row left column.

Thanks for the info. I will try that.

I flew the quad today... or better, I attempted to fly it. In fact, it did not take off at all. As soon as I got past 25% throttle it began to roll without control on the left side. I had to disarm it in order to stop it.
That happened consistently in the three attempts to made.

The only thing that changed is the receiver on the quad and the 4in1 mod on the transmitter. Everything else was working fine before when I used the original Walkera DSMS module and the Orange RX R620X v2 receiver.

Any idea on what it could cause that and whether there is a way to remediate it?

Thanks

Use the deviation channel monitor to check that only the throttle channel is changing when you move the throttle stick.
The flight controller probably has a similar function to show what's being received on each channel.

Guesses based on my past mistakes:
- Frsky channel order is different than DSM so need to change model file or FC setting accordingly
- Props put back on to wrong motors

Channel scale may also need adjustment due to differences between FrskyX and DSM channel encoding, but unlikely to cause the symptom you describe.

Use the deviation channel monitor to check that only the throttle channel is changing when you move the throttle stick.
The flight controller probably has a similar function to show what's being received on each channel.

Guesses based on my past mistakes:
- Frsky channel order is different than DSM so need to change model file or FC setting accordingly

I did check that in Betaflight yesterday when I setup the quad with the new receiver. It was all working perfectly, main channels and aux channels. I did calibrate the sticks and set the correct endpoints for min, center and max (1000 - 1500 - 2000).
I check the deviation channel monitor today too, when the issue happened and it seems all good to me.

I will definitely recheck it tonight, just to be sure that something has not been messed up by mistake.

- Props put back on to wrong motors

That is definitely possible (noob mistake, but it can happen at 3am). I was in a rush today when I did the test, so I missed that check.

Channel scale may also need adjustment due to differences between FrskyX and DSM channel encoding, but unlikely to cause the symptom you describe.

I've done that as part of the model setup on my Devo.


I really hope I put the props in the wrong order

I tried binding to the xm+again tonight with no success, i will need to test the rx separately with a friends taranis than have another go of is all working.

I don't have any issue binding in non x frsky receivers, just this xm+

I tried binding to the xm+again tonight with no success, i will need to test the rx separately with a friends taranis than have another go of is all working.

I don't have any issue binding in non x frsky receivers, just this xm+

This is what I did to pair my FrSky XM+

1. TX off and RX off
2. Power on the TX and go to Model Setup menu > Bind
3. Make sure FrSkyX is selected, then click on FrSkyX and set the frequency to -60 (it appears to work from -10 to -120).
4. Click on Bind
5. Switch on power to RX while pressing the bind button
6. Green RX light flashes once
7. Bind complete
8. Power off RX and TX

When you power on the TX and RX, the RX red light flashes until the green light turns solid.

Note that there is a better way to figure out the optimal frequency as pointed out in a previous post.

Hope this helps.

thanks, ill give that a go tonight, and i will also test the xm+ rx this weekend on another radio.

ps i am using a 7e, so i hope the process works the same. i have not had to fine tune my module before using midelics diyfrsky (airwolf) rxs or the hobbykign fr8 nano.

It should be as it should depend on the receiver.

I can confirm that the FrSky XM+ works with Devo 10 and 4in1 mode. I flew my quad today in LOS and worked very well. The issue I had yesterday was indeed a wrong prop mounted on a front motor... I really have to stop working on my quads late at night!

Hey guys can anyone confirm that latest build got range for X protocol, I have also doubts if I can trust it. I had 2 crashes on near range 50m....
but was using test build voice of Moeder (not sure if it is his build or something with CX protocol changed....)

Now I am loading latest nightly I see also behavior RSSI stays low in the past it could easily go over 100 when on the table nearby.
Please any body can confirm he is flying the 20 januari nightly on a racer and got full range?


(and yes some older builds with X protocol I have good range...)

midelic wrote: Rxbt calculation in multi is specific Er9x ersky9X.Opentx display,
For Devo you may do your own calculation...I was pointing highlighting only RSSI problem The RSSI values on Devo where too high and not real..

Omino wrote: It should be as it should depend on the receiver.

I can confirm that the FrSky XM+ works with Devo 10 and 4in1 mode. I flew my quad today in LOS and worked very well. The issue I had yesterday was indeed a wrong prop mounted on a front motor... I really have to stop working on my quads late at night!

Same result here, before nightly from 20.01 update i have 107db and now i have not more than 85d, and sometimes at devo10 start i have the message that CYRF6936 or Multimodule missing.