Frsky compatibility

The data in the files in the update are good. I've attached the decoded telemetry as it's a small file.

Cleanflight is sending time updates every 5 seconds. The packets don't have timestamps (shows 0 as I reused the same decoding program), but the GPS times are printed out as decoded and are mostly 5 seconds apart.

Somewhere between the d4r-ii rx pin and the received packets in the devo things are going awry. That doesn't leave much to check.

The latest nightly has the LQI and LRSSI telemetry. Please try that and see what values you get. Should be able to get LQI under 50 by adjusting the fine frequency protocol option.

If that's not the issue can't think of much else to try. Probably by end of the year I'll have the hardware to try this setup myself.

Checking this data did reveal that commit b9afce9 was an error, and I've pushed a commit to revert. This just swaps the hour and minute values in the GPS timestamp. Turns out the hub emulator I was using has it wrong. Cleanflight and opentx and multiwii all agree that minutes is in the high byte.

Cleanflight only sets the minutes and seconds values, with a comment in the code "if we fly for more than an hour, something's wrong anyway". It also does not use the time from GPS, but elapsed time from when cleanflight started.

Hi cheers for looking into that,
I've just flashed your latest test build. But the telemetry still behaves like before My LQI stayed always below 50 and it didn't really make much of the difference if I played with the fine freq tuning ( tried from -35 to +10 ) and within that range i was always staying under LQI 50.
Am I really the only one interested in making this to work (of course apart from you Hexfet - thanks a million for looking into that)?
I thought the biggest advantage of frsky receivers is their full extended telemetry. Also my FC is not any exotic. My setup must be the most common one for all of us here : D4R-II, naze32 F1, devo 7e 256... Seeing your speed, altitude right on your screen is quite interesting, is it not?

I think cereal_killer posted that configuration is working for him...however...

Due to unplanned ground interactions my main quad ended up on the bench. I decided to upgrade and do a little testing. It had been running great on cleanflight 1.9.0 for a year or so. It has a naze rev5 (F1). Also made the same tests on a bare board of the same revision. i installed the latest cleanflight configurator (1.2.4), and then...

• Configurator only supports cleanflight version 1.13.0 and greater so must upgrade
• Bootloader not recognized. Must short bootp pins to force firmware to flash. This is required every time even after successfully flashing cleanflight 1.14.1
• Enabled frsky telemetry on default port (uart1). Cleanflight stops working as soon as armed. Usually see a 0x5e out the telemetry port right before the lockup. Board will not respond until powered off and on.
• Enabled frsky telemetry on softserial1 (pin 6). Telemetry data appears on pin 6. Set telemetry_inversion=on and d4rii recognizes and sends telemetry, but screen updates are irregular.
• On bare board put frsky telemetry on hardware uart2. The telemetry_inversion setting has no effect so d4rII doesn't see valid data.
• tried cleanflight 1.13.0 (oldest version supported by the configurator). Same results.
• tried betaflight 3.0.1. Same results.

At this point I flashed back to cleanflight 1.14.1, put frsky telemetry on softserial 1, and started comparing the data out of cleanflight to the data received at the tx. Cleanflight does send a time update every 5 seconds, voltage every second, and others at 500ms and 125ms intervals.

About once a second all these timers align and cleanflight sends about 20 telemetry packets in about 100ms! Each packet is 4 bytes so that's around 800 bytes/s. Over the air telemetry packets are sent at 36ms intervals with 10 bytes of hub data. However the d4rii generally sends 8 packets containing hub telemetry followed by 6 containing only RSSI and analog voltages. That's 80 bytes every 504ms for a max over the air hub telemetry data rate of 160bytes/s. Add the fact that the d4rii likes to send every serial packet five times over the air and I begin to suspect this may be a problem.

The GPS time update from cleanflight every 5 seconds is always at the end of one of these large packet streams which may explain why it's rarely received at the radio. My theory is that the d4rii is dropping telemetry packets it doesn't have time to send or space to buffer.

The hub telemetry emulator code I used for testing avoids sending a bunch of telemetry at once by skipping the high frequency updates whenever a low frequency one occurs (e.g. if it sends a time update it skips sending voltages till the next scheduled update). And on deviation the screen updates as expected when receiving from the hub emulator.

I tried building cleanflight v1.14.1 from source so I could test this theory but get an "out of flash memory" error :/ Anyone had any success building it on Ubuntu 16.04? I agree it seems like this telemetry configuration would be in use by many people so I'd really like to test a modified cleanflight to verify if this is the problem.

It's very likely what you're saying that something wrong may be going on in the D4R-II itself. As everything else seems to be working fine. There are only 2 firmwares available for D4R-II - I'm running the latest , the previous one is like 3 or 4 years old and as far as I know I wouldn't be able to use 8 channels if I've flashed that , so not even worth trying for me as it's not an option. As far as I remember I did try X4R-SB (sbus) and it worked fine with the same setup. I even put X4R-SB in PPM mode (same as D4R-II operates in) instead of sbus and it worked as well! but obviously the telemetry was setup to use S.port instead of FrSky - less sensor were available (perfectly fine with that) that's why i suspected that either dr4-II or devo get's clogged up with too much data being transferred/received. I would be more than happy to flash my naze with whatever code you will give me to try if it works. Let me know . Thanks!

I've tried a few strategies in cleanflight to spread out the data but so far some still gets missed. It's sending a lot of sensors. While the average data rate is okay it seems the D4Rii can't handle the bursts. Wonder if a D8R receiver does better...

Tested both the 18ms and 27ms D4Rii firmware and they behave the same.

What sensors are you interested in? I can make a cleanflight for you to use with just those enabled.

S.port telemetry doesn't have this issue because the receiver polls the sensors when it's ready for data.

Can anyone tell me what settings to use to bind to an X4R? I've got a solid green and flashing red light, so it should be in bind mode. I tried all 3 Frsky protocols, but couldn't bind.

My CC2500 line is uncommented, and seems to be found on startup on A13, not found on A14. Has PA is uncommented as well.

It's a SI4432, wired up like this:

static.rcgroups.net/forums/attachments/5...ectionDiagram_R3.jpg

I'm running a nightly build as of October. I can't remember the exact date.

Power is 100mw.
I have not yet tried other channels.
I read something about playing with fine shift, but I do not know what that is.

I am trying to provide as much info as I can, and any help would be greatly appreciated.

First of all your in the wrong section of a forum. Your protocol in Devo 7E should be FrSkyX as you're trying to bind Sbus receiver from x- series (X4R-SB i suppose). When you enter the FrskyX protocol settings try Fine frequency tuning -try -10, -20, -30, -40 and +10, +20 etc.... and you should be good to bind. Next find the sweet spot in the middle of the range and that's it.

That would be great hexfet if you could try making fw with fever sensors- maybe that would work?. Ps would it be any difference to prepare iNav instead ? It's cleanflight based so it should be exatcly the same process as i will most likely end up using iNav due to better gps support / return to home function which works fantastic. If not i will try cleanflight. Maybe just to see if it works. The sensors i'd be interested to see are:
-Alt: baro based
-Curr : actual current comsuption, in amp.
-VFAS : actual vbat value.
-GAlt : GPS altitude, sea level is zero.
-GSpd : current speed, calculated by GPS.
-GPS : GPS coordinates.
Thank you in advance

raketemensch wrote: It's a SI4432, wired up like this:

static.rcgroups.net/forums/attachments/5...ectionDiagram_R3.jpg

That diagram is a bit confusing. Since you're running a nightly build pins 9 and 10 should have only the black and white connections, not the green and brown. If that's right then everything else seems correct.

Pegaz wrote: That would be great hexfet if you could try making fw with fever sensors- maybe that would work?.

Please try the file in test build frsky_inav. It has only the sensors you listed and adjusted timing. The LatLong data comes out in a burst of 6 packets - let's see if that works.

I included the changed source file in case you want to make changes. I won't be doing any testing till after thanksgiving.

raketemensch wrote:
It's a SI4432, wired up like this:

static.rcgroups.net/forums/attachments/5...ectionDiagram_R3.jpg

One other change to consider: I had to use the ground on the CYRF module pin 7 to get reliable results. When I used the ground pin next to VDD I had problems, and when I moved the ground (that was the only change) my problems when away.

Pegaz wrote: First of all your in the wrong section of a forum. Your protocol in Devo 7E should be FrSkyX as you're trying to bind Sbus receiver from x- series (X4R-SB i suppose). When you enter the FrskyX protocol settings try Fine frequency tuning -try -10, -20, -30, -40 and +10, +20 etc.... and you should be good to bind. Next find the sweet spot in the middle of the range and that's it.

Apologies, the last thing I want to do is interfere with development. You guys rock, I really appreciate all the work that you do. I couldn't find much mention of the X4R in other threads.

hexfet wrote: That diagram is a bit confusing. Since you're running a nightly build pins 9 and 10 should have only the black and white connections, not the green and brown. If that's right then everything else seems correct.

Thanks! I pulled those two wires (ironically they were by far the hardest part of the install). I'm going to try to contact the guy who put that thread together, as that post is the first thing Google coughs up, and it seems to be pretty out of date. Once I get this working I'll put together a solid guide for it.

Deal57 wrote: One other change to consider: I had to use the ground on the CYRF module pin 7 to get reliable results. When I used the ground pin next to VDD I had problems, and when I moved the ground (that was the only change) my problems when away.

Also thanks! That's the one I went to in the first place.

Unfortunately I'm still unable to bind. What's truly odd is that when I start the receiver in bind mode, both red and green are solid. They don't go to the solid green and flashing red *until* my first attempt to bind. So it definitely seems that the tx is connecting, but it's not successfully binding. I'm running the 11/13 nightly now, and I've tried fine values from -100 to +100 in increments of 10, both with close proximity and ~10 feet of distance between the tx and rx. Power is "100mW," PPM In is "None," AD2GAIN is "100."

There is a dedicated thread here regarding FrskyX protocol development but since you're here i'll try to give u some hints...

I think i know what that is. There are 2 firmwares for x4r-sb availble. One is for eu and the other global/ china. They are not crosscompatibile. I bet you got your x4r-sb with EU firwmare. Obviously cc2500 runs chinesse specs and there is not much you can do here therfore you need to re-flash your x4r-sb to non-eu firmware. Firwmares are available on frsky website. Flashing it is a bit tricky without the flashing dongle. I've done it using diodes and ftdi with reversed signals on tx and rx. Look up google first regarding programmimg- i've done the same.

Hexfet you're a star ! It works (that modified iNav) !!!
I don't have any random greyouts anymore ! Everything gets updated. I don't know if that's how it suppose to be but let's say gps altitude gets updated after 5 seconds from when cleanflight change the number- can't really compare as I never had it working. Anyway there is a huge improvement in that matter and we're(you) definitely going in the right direction. I will not be bothering you till after the thanksgiving as you said We need to let know cleanflight and iNav people that there is a bug in the frsky telemetry. If you want me to do any more tests / captures let me know. THANKS !

You're welcome. It's not a bother.

I plan to verify the problem exists with a DJT module before raising an issue on cleanflight. Just to eliminate any question about deviation. Should be able to borrow a DJT before end of the year.

And our common sense intuition was correct - someone would have reported a telemetry issue from djt telemetry before. The problem is in deviation. The frsky_telemout test build is updated with a fix. Please test with a stock cf/bf/inav version.

Tested a djt module and it was pouring out data no problem. First thought was to get an spi capture, but the d4rii is too small for my equipment and the djt module is not mine. So guessing seemed a good option. The d4rii insistence on repeating every update 5 times seemed suspicious - maybe it was expecting hub packets to be acknowledged, similar to the sequence numbers in frskyx. So tried echoing the telemetry packet sequence numbers in tx packet[4]. That triggered the d4rii to send sequence numbers mod 32. With this change the d4rii does not repeat data so hub telemetry keeps up with what's sent from cleanflight.

Fantastic! I'm on holiday now and will test it as soon as possible! Great news, thanks a lot

I've made a pull request with this fix, and the frsky_update test build has just the PR changes. The telemout test build also has debug data coming out the trainer port.

In testing if the transmitter and receiver are too close many telemetry packets are missed (zero length errors). A meter or more separation seems to work well (at 100uW power).

It works !!! Finally !!! No more grey outs, gps data and all the rest updates almost immediately. Hallelujah . Tested on older version of inav and it works as should as well. I'm really thankful to hexfet for making this happen! Love my devo 7e again ! FrSky telemetry rocks!

Thanks for your testing and persistence The changes have been merged and are in the nightly build so I've deleted the test builds.