New FrSkyX protocol

What Tx are you using? The 7E build doesn't have the smartport telemetry due to lack of memory.

As it says in my post, I'm using a Devo 10.

I believe vlad_vy's build has the latest protocols, but I use the nightly on my 10 because the GUI changes don't affect the 10.

Main issue I've had is getting data from betaflight to the XSR. Use a scope or analyzer if you can to verify there's data on the XSR s.port pin.

Thanks for the input. From what you're saying, the code that handles the telemetry is the same code that implements the protocol, so if I have the protocol working fine then I should also have the various changes to decode the s.port telemetry.

Guess I'll have to fire up the 'scope then!

I think I used softserial just for that reason. Don't have that setup anymore to check though.

I am using F3 FPracing with Betaflight 3.1.7 Smartport on TX - UART2 (Softserial is disabled from the developers in ßF > 3.1.5 for my board)

On my Taranis i receive:
RSSI, RxBt ,A2 ,A4 ,VFAS ,AccX ,AccY ,AccZ ,Tmp1 ,Curr ,Fuel ,Hdg
i`ve tested international D16 Version (Multimodule) and LBT EU D16 (XJT), both work fine

On my Devo 12 s with Latest v5 Build from Vlad i receive:
RSSI, Temp1, Fuel, Volt1, Volt2, VoltA, Amps, DIS, LQI, LRSSI
Only int D16 version is working here.
LBT Eu version is interupting Telemetry Data
All Telemetry Data (inkl the values from the receiver like RSSI) is received every 10-20Seconds for a very short time.

@ hexfet
Do you know telemtry problems with the EU protocol?

of course X4R flashed with the latest version of EU or int Firmware

Nothing previously reported. I don't think I tested the extended telemetry when adding EU support as the changes weren't in that area. Having some trouble getting the firmware onto my XSR right now but will try to test in the next few days.

I can duplicate the behavior you reported. Still trying to narrow in on the issue but seems like packets going missing in both directions with the LBT firmware. With nonEU firmware everything is working well.

Thanks for help

Hi, I feel I should start with a massive thank you to everyone involved with Deviationtx. What an awesome piece of work!

I recently installed a CC2500 module in my Devo 7E. In my quadcopter I installed a XM+ receiver connected to a naze32 through a sbus inverter. I tested it to 500-600m with no problems. After no more than a few hours use the range has dropped to <15m on 150mW and <3m on 100uW.

I have removed the XM+ and tested it alone with the same results. I've tried playing with the fine freq to gain no extra range. I have also tried powering the CC2500 from a pololu - which has reduced voltage readout fluctuations - but it didn't fix my range issue.

Can anyone suggest which is likely to have failed? The XM+ or the CC2500. Unfortunately I don't have access to another Frsky receiver to test.

I am going to assume the CC2500 failed and ask; can anyone recommend a reliable CC2500 or 4 in 1?

Link to module: www.banggood.com/CC2500-PA-LNA-Romote-Wi...F24L01-p-922595.html

Andy.

Thanks, for the quick reply. Yes, all antennas are in good condition. I even tried replacing them just to be sure.

Would I be right in assuming that the PA will be an IC somewhere under the shield? Sounds like a bit of a faff just to rescue a £4 module... I think I'll try a new one before I go down that route.

Is anyone able to suggest a source of reliable CC2500 modules? Are the banggood ones normally ok? Maybe I was just (un) lucky enough to get the odd bad one.

Hi,

I have something like dropout like few month ago, can someone give a quick look on the datalog ?
Or maybe tell me how to decode the file

It arrived between the end of log and 30sec before.

Thank you.

Use the datalog2csv script in the repo's utils directory to decode the datalog file. The output from your capture is attached.

The datalog was set up to capture everything every second so there's less than two minutes of data, which is from the start of the flight. Set the config to only capture the values you need. The utility can also increase the size of the datalog.bin file. Put the larger file on the tx and deviation will use the extra space.

Investigated the EU telemetry on the XSR some more and found two things.

I could get reliable packet reception by moving the tx as far away from the XSR as test setup allows (just a meter), putting my body between the XSR and tx, and wrapping my hand around the tx antenna (it's a 4-in-1 installation). The tx power setting didn't make a difference. I think the XSR is just swamping the tx receiver. What was your test setup like?

Looking at the changes to radio setup between FCC and EU the main changes are GFSK vs FSK, continuous transmission, different center frequency, and different deviation. Not sure if that's enough to explain the observed difference in behavior from the FCC version..

The second thing is a change to the sequence number algorithm that reduces missed telemetry packet recovery time. All the missed packets provided a good test environment... Test builds are available - frskyx_seq .

Hi, guys
I'm following this interesting thread about FrskyX protocol, actually I have a devo 7e modded with cc2500 module, since than I used telemetry on pin 6 through d4r-ii. Since I would like to skip into sbus I'm asking if it supports telemetry (rssi, vbat), because I have read that Devo 7e has not smart port support coming on softserial from x4r-sb. Do I have understood correctly?

Thanks.

eikaf wrote: Do I have understood correctly?

Yes, the 7e only supports the basic telemetry, not s.port. You'll get RSSI and the readings from the analog voltage input(s).

I've now tested the sequence number change mentioned above with the non-EU firmware and it works well there too. Should get quicker recovery from s.port telemetry dropouts. Pull request submitted.