Frsky compatibility

sfersystem wrote:

aMax wrote: You can add 2dBm for a normal antenna, so you will
have +19dBm overall ( 79.4 mW).or in your case even more.

I have already a 2db antenna, you say i can add a second antenna to solder on the CC2500 chip and let the cable in the TX ?

aMax wrote: Remember, both should have the same polarization as the antenna on the transmitter!

Usually i fly with my TX antenna curved, but if i understand, it is better to fly with the TX antenna straight ?

Another thing come in my mind, i bought my dr4-II last month. Normally it should have the 27ms firmware. I'm using the DR4-II in ppm mode with only 4 channel
Does that make something to the range ?

I'm so sad that the x protocol have ever dropouts, i have a XSR waiting to be mounted on my quad

Thank all for help

I think I will not give so many details in future as is might be confusing and misleading , e.g the output calculation for the BG module.

No,you cannot have a second antenna on your module. The UFL or the soldered, that´s the choice. Beside this. the trace to the solder pads is not accomplished with a capacitor, so this is not ready to play.
Yes , the best direction is straight upwards like your tx antenna. If you curve them you are losing on both some receiving strength (polarization)...look at the video one more time.
This is a test with a self build receiver from our RCgroup. Surprising, isn´t it`?



As long as your are upscaling the first four channels only and not all Aux, you will be fine with the normal firmware.
I even scaled my aux channels down when I used PPM in the beginning.

aMax wrote: I think I will not give so many details in future as is might be confusing and misleading , e.g the output calculation for the BG module.

No,you cannot have a second antenna on your module. The UFL or the soldered, that´s the choice. Beside this. the trace to the solder pads is not accomplished with a capacitor, so this is not ready to play.
Yes , the best direction is straight upwards like your tx antenna. If you curve them you are losing on both some receiving strength (polarization)...look at the video one more time.
This is a test with a self build receiver from our RCgroup. Surprising, isn´t it`?

As long as your are up scaling the first four channels only and not all Aux, you will be fine with the normal firmware.
I even scaled my aux channels down when I used PPM in the beginning.

Really incredible, this tips with the antenna is really good !

hexfet wrote: The FrskyX dropout issue is fixed in recent nightly builds. petsmith found the problem.

And thank you again for the good work, this is an awesome news !

Hi again got some updates on the telemetry problem on my Afrofligt32 rev.6 (naze32) and D4R-II. No matter what i do i can't make it work. Checked on 3 different FC boards(same type) and two D4R-II receivers runnin the latest FW, gps had 3d lock, tried few versions of cleanflight, baseflight, inav, few versions of happy harrys Ultimate Devo 7E FW (including the latest) :
- i have disabled gps autoconfig/ autobaud in CLI , I've set it manually as per Cleanflight manual - no joy
- i did try to run telemetry from softserial1 , sofserial2, I even build hardware inverter in order to run it from UART2 ! - no joy ,still very slow and dropping out constantly
- i had it on both soft serials i made sure both are running the same baud speed 9600 (i did try auto, and any other baud rate without a success)
- i set my FC in FlyingWing mode thinking that maybe it only happened in QuadX - someone said it works fine on his flying wing, it does not for me
- i did try every single combination of telemetry / gps port/baud rate - always with the same result. The telemetry shows up and then disappears few seconds later , shows up and greys out again . Most of the times right after powering up the receiver i got all my telemetry information but few seconds later they grey out and re-appearing randomly. Please check my videos from previous posts they show how my transmitter behaves.

BUT when I use my X4R-SB (in Sbus and also in PPM mode) it works like a charm from any softserial - even on auto baud! It updates my telemetry screen every single second once I got 3d lock on GPS, but I've noticed it has less sensors available (not an issue for me I got exactly what I need) - maybe that's the case? Maybe D4R-II has too many sensors available and overflows devo7e hence drop outs?? I don't have a taransis to check if it works as it should... Why D4R-II can't handle the telemetry with my Ultimate 7E ? Please help

Looked at this a bit tonight as I saw something similar when testing with a telemetry simulator. I'd attributed it to having all the sensors turned on so put it at the bottom of the list. The number of sensors does have an effect, and there are a couple other considerations. These comments are based on looking at the code so would appreciate review - haven't made any test builds yet.

First a little about the telemetry implementation (Devo10 perspective). When a new telemetry value is received, that value is marked as "updated" with a single bit instead of a "last updated timestamp" to save memory. This updated flag is cleared for all telemetry values every 5 seconds, regardless of when the value was updated. Before clearing the current updated status is moved to the last_updated array. So the last_updated array shows what telemetry values were updated in the previous 5 second interval, while the updated array is cleared and individual flags will be updated as telemetry values come in during the next 5 seconds.

A telemetry value is displayed with a normal background (black on white for Devo 10) if its flag is set in either the last_updated or updated arrays - if it was updated in the previous 5 second interval, or during the current 5 second interval. Otherwise the font is reversed. The display is updated every 100ms.

So one issue is the updated status is reset every 5 seconds, regardless of when the last update was received. A telemetry value updated just before the reset could be moved to the last_updated array before ever being shown on the screen and if not updated again would only display as updated for 5 seconds.

Another issue is that setting of the updated flags occurs in an interrupt service routine without synchronization with the clearing of the updated flags. Likely a design choice for speed of execution So if the telemetry value is received just after the last_updated value is updated, but before the updated value is cleared, an update could be entirely missed.

But neither of those issues matter much if the telemetry values are being updated frequently (every few 100 ms). I looked at the latest cleanflight master. Voltages and GPS position are sent once per second, while GPS time sent every 5 seconds.

I set up the simulator to duplicate this timing. On my display the lat/long always stayed valid, while the timestamp alternated between valid and invalid fonts.

So I'd guess there's some issue along your chain of getting telemetry from the FC to deviation, though it seems to be working somewhat. If deviation is receiving lat/long values every second you shouldn't see the font reversed.

Telemetry works differently in S.Port. In S.Port the receiver polls sensors for data, while with hub telemetry the sensors send data asynchronously. I don't know if an Frsky hub applies the same update timing as cleanflight.

Dear hexfet, thank you for the detailed explanation- it was very technical , maybe a bit to technical for such a guy like me In simple words: is there anything i can do to make it work ?? Or I will have to change all my FCs for a F3 ones? I'd like to avoid that as I've got my pdb boards designed specially for naze32 layout. I could also buy another x4r-sb but that would mean that the money spent on 2x d4r-ii will go to waste... Can't understand how some people said that it works for them (naze32+d4r-ii)?

I've made all this effort just to have the telemetry info displayed on my tx. Just for that purpose I bought devo 7e , then installed deviation, then went for Frsky receivers + tx modules, then found out that on top of all those extra switches I've added I also need to upgrade the processor to run ultimate 7e and now when I'm finally almost there I hit the wall I can't pass through since a month ;(

I spent some more time with a d4r-ii last night but didn't get to a final conclusion. There may be an issue in the hub telemetry decoding but need more test time. Won't be able to spend much time on it till next week.

Do you have a 3V FTDI adapter? I could make a test build that would send data out the trainer port when latitude and time are updated so you could see if it matches what cleanflight should be sending.

So you confirm that there is something goofy going on on such a configuration ( naze32+d4r-ii)?
I do have an ftdi with selectable voltage 3.3/5v but would need more info how to set the things up. So as far as i understood you correctly i would have to flash my 7e with your special test build, then connect the inner pin of 3.5mm jack plug to the trainer port, the other end would go to RX on my ftdi and i'd have to see on arduino serial console if whatever devo sends matches with what cleanflight says? Any settings to the devo 7e itself in order to enable that trainer port? BIG Thanks

No, what I can confirm is that I did not find any bugs in the hub telemetry code. It's working as intended. So if the telemetry data is getting to your Devo, it will be interpreted and displayed correctly. The D4R-II appears to repeat transmissions of new data several times, which can affect how long a particular sensor value shows an "updated" status.

I'll make a test build in the next day or two. The setup you described is correct. You won't need to make any changes to the 7e config - the data will always be sent out the trainer port.

I can't remember if you said you've tried adjusting the FINE protocol setting; if not that's something to try. I plan to add the LQI telemetry this week which should help in finding the best setting.

Test build frsky_telemout will send the following strings out the trainer port at 115200bps, 8, N, 1.

• DROP - telemetry packet rejected because of CRC, length, or fixed id mismatch
• SEQ - sequence error, which indicates a missed hub telemetry packet
• LAT - GPS latitude position updated
• TIME - GPS date/time updated

From the cleanflight code the LAT message should repeat about once per second, while TIME updates every 5 seconds. With my setup these are each repeated several times but not sure if that's due to the D4R-II or the simulator code.

Cheers hexfet for that build and support. I did what you've suggested. I played with the freq settings before without a luck. The data seems to be displaying randomly on my serial monitor definitely not every second. there are periods lets say max 5 seconds where the data is updated every second but after a while let's say for 10 seconds nothing. It's really random, that's why it doesn't work. So you think that the problem is in my boards? but why every single one of them? They are working cool with SB ,confused....

What is SB?

It is puzzling. The hub telemetry code is probably the least tested part of the chain but don't see a problem there. It's working for others with seemingly the same setup.

Did you see any drop or seq messages?

Can you capture the telemetry coming out of the naze? We could look at that to see that cleanflight is sending as expected.
If you can capture binary out the trainer port I can dump the raw packets and then look at those to double check the hub code again.

Hi again,
SB= sBus by that i meant FrSky X4R-SB receiver - sorry for beeing unclear.


How do I capture the telemetry coming out of the naze? Ftdi 3,3v and serial console?

I've seen some dropouts while capturing the data from devo's trainer port- here is a screenshot attached. Bare in mind that while i was doing that test the cable from tx to ftdi weren't soldered. I was just holding them connecting the pins hopefuly it wasn't an issue.

The s.port telemetry works differently so can't tell much from X4R results.

You'll need to invert the data from the naze I think before feeding it to the ftdi.

That's a lot more sequence errors than I see. The ones I do see are caused by a completely missing telemetry packet, not just missing hub telemetry data. That seems worth thinking about since with tx and rx nearby I'd expect nearly no missed packets.
- Are you testing in an environment with a lot of wifi RF around? I only have one nearby router in a wood frame building.
- What's your tx power level? I'm using the lowest setting. Shouldn't directly interfere with telemetry packets but want to avoid any issues caused by overloading the receiver.
- Does a D4R-ii sometimes not send a telemetry packet for some reason? Don't have an SDR to watch the RF. Maybe write something to just listen with a cc2500.
- Does deviation sometimes miss a telemetry packet? Timing looks okay in code, but can make some tests to verify.
- Do you see the same results with more separation from the tx? Not convenient for me to make a field test.
- Do you keep seeing sequence/drop messages during the intervals where you don't see lattitude/time updates? I'm seeing missing telemetry packets even without hub telemetry.

I'll do some more testing the next few days. No new test build yet.

I'll try to answer on some of your questions:
1. There are wifi networks etc however i had it outside with the same result -very laggy
2. I did try with the lowest /middle and various tx power level - no difference
3. I did try to go further away with my tx and it didn't make much of the difference

I wish i could be more helpful. I've done proper FTDI connection today and here is some of what serial monitor threw away:
LAT
LAT
LAT
SEQ
LAT
SEQ
SEQ
LAT
LAT
SEQ
LAT
LAT
LAT
DROP
SEQ
DROP
SEQ
SEQ
LAT
LAT
LAT
LAT
LAT
SEQ
SEQ
DROP
SEQ
SEQ
DROP
SEQ
LAT
LAT
SEQ
LAT
LAT
LAT
SEQ
LAT
LAT
LAT
SEQ
SEQ
SEQ
DROP
SEQ
LAT
LAT
LAT
LAT
LAT
DROP
SEQ
DROP
SEQ
SEQ
LAT
LAT
LAT
LAT
LAT
TIME
TIME
TIME
TIME
TIME
DROP
SEQ
SEQ
SEQ
SEQ
SEQ
LAT
LAT
LAT
LAT
LAT
DROP
SEQ
SEQ
DROP
DROP
SEQ
SEQ
SEQ
SEQ
DROP
SEQ
SEQ
SEQ
SEQ
SEQ
DROP
SEQ
SEQ
DROP
SEQ
DROP
SEQ
DROP
SEQ
DROP
SEQ
SEQ
DROP
SEQ
SEQ
SEQ
SEQ
SEQ
DROP
SEQ
SEQ
LAT
LAT
LAT
LAT
LAT
DROP
SEQ
SEQ
LAT
SEQ
LAT
SEQ
LAT
LAT
SEQ
DROP
SEQ
SEQ
SEQ
SEQ
SEQ
SEQ
I'm also including a video to see some time intervals between those messages:

drive.google.com/open?id=0B7SacC_0VeiwMzNlTlFTN2tzOUE

Did quite a bit of looking but not much finding. New test build described below if you want to skip the details. Mostly I was trying to figure out why sometimes no telemetry packet is received at all.

• Rewrote the frsk2way callback function with a switch statement to make sure I understood it. Did not find any errors. No change in rate of not receiving a telemetry packet.
• Changed the timing of when to start listening for the telemetry packet. Did not find any value that worked better than the current one.
• Added states to change the timing of when to end listening for the telemetry packet. Did not find any value that worked better than the current one.
• Changed CC2500_SetTxRxMode() to disable LNA before enabling PA when changing to TX mode. No significant change to rate of not receiving a telemetry packet.
• Changed some of the the cc2500 configuration registers as recommended by datasheet. No significant change.
• Checked D4R-II telemetry behavior. When it gets a hub telemetry update of GPS data on its RX pin it will send those values 5 times over the air.
• Looked at spi captures from a D8R. It never skips sending a telemetry packet.

The frsky_telemout test build is updated. It sends every received packet to the trainer port in the following format:

• if the length is invalid the string "len" is sent followed by the number of received bytes. Have only ever observed zero as the invalid length.
• if length is okay then first column is number of milliseconds since the previous non-zero length received packet in HEX. 24 = 36ms is normal.
• received data is is printed
• if the data fails any of the validity checks the word DROP is printed followed by error code and length
  
• if the hub telemetry sequence number is incorrect the text SEQ is printed followed by the expected value

One line is sent every 36ms, either the packet data or a "len" error.

I captured packets for a little over 4 minutes with the hub simulator sending nearly the same data as cleanflight. In 7120 packets there were:

• 166 packet length errors, all 0 (no data received)
• 8 drop errors, usually data length or CRC
• 82 sequence errors - one of the length or drop errors occured while hub telemetry was being received

That's an error rate of 2.5%. Not sure if that's high or low, but haven't found any coding errors yet.

Please capture some data from the trainer port so we can compare these numbers with what you're seeing. The data is ascii so any terminal program should work.

Hi,
There was a nice weather with clear sky out of my window so I was able to do some more gps / telemetry bench testing. I was getting a 3d lock in cleanflight and 5-8 satellites. Probably it doesn't matter but I've captured the data you've asked for in TeraTerm and serial monitor in arduino. The results are in txt files attached below. Each dump has been done with 3d lock and 6-8 satellites locked. There is also a screenshot of my cleanflight attached . Thanks!

Files:
drive.google.com/open?id=0B7SacC_0Veiwd0czSGFEQzB6Q0k

drive.google.com/open?id=0B7SacC_0VeiwM3dQTGVWOXc3VlU

Thanks for making the captures. Both files are fine and have good data.

The error rate is lower than in my setup. In the two captures there are 17,001 lines with 77 (0.4%) instances of a dropped packet that might have contained hub telemetry (i.e sequence errors). I think that eliminates a bad telemetry link as possible source of the issues.

There's just not many GPS telemetry updates in these captures. The TeraTerm capture has a single GPS_TIME update at 1:54 (one minute, 54 sec from start of capture). The Arduino capture shows time updates at 0:00, 3:14, and 4:50. Some other updates at:

Other telemetry values are being received a lot more frequently - VARIO, ALTITUDE, accelerometer values which deviation ignores, CELL voltages, etc.

The values being received for latitude and longitude match what's shown in the cleanflight screenshot.

The month/day/year GPS telemetry was never received. Only hour/min/sec values were in the captures.

I did find one bug in the hub telemetry code where the hour and minute values are swapped in the time telemetry.

At this point if it was me I'd check the data where it goes from cleanflight to the d4r-ii. If you can capture that I'm sure theres software around to decode it (if not I can help) and we can see if what's going in matches what we see coming out.

Files with decoded telemetry are here . Timestamp is in mm:ss.sss format, followed by the telemetry item raw value, then the telemetry ID. Remember that each update from cleanflight is received up to 5 times over the air.

I've got no idea how to capture the data coming out from naze's softserial telemetry port in a sensible/readable format. I'm getting complete mess in serial monitor (been set to baud 9600) Even using a little hardware serial inverted that i've built for tests doesn't make any difference. I need hints on how to capture the data . Switching in cleanflight telemetry_inversion = OFF is not helping either.

Cuz i guess this means nothing:

ñÆü
(·l€(µTü
1c
ñÆü
(·tÀ(m¦ü
1c
ñÆü
1ŠÇü
Ñcü
qÇ&†üü
(·t€(µDü
1c~†|ãü
(·l€(µLü
1#
ñÆü
(·|€(µLü
1£~†|ãü
(·l€(µTü
1c
ñÆü
1ŠÇü
Ñcü
qÇ&†üü
1Š?Åü
‘üü
1ô1Œ(‹üü
‘Œ
ñü
qüü
ÑÇü
ÑŽ2ÿ
ÑÜñ
яü
Qӟ
‘Ç<(ÉÌáŽ(¹Œñ
±Ç
±Om†ì#Å
1ÅEÿ
1ã~†|ãü
(·|€(µLü
1c
ñÆü
(·l€(µ\ü
1#
ñÆü
(·t€(µDü
1c
ñÆü
1ŠÇü
Ñãü
qÇ&†üü
(·l€(µLü
1c
ñÆü
(·|€(µTü
1#
ñÆü
(·d€(µTü
1£~†|ãü
(·|€(µTü
1#
ñÆü
1ŠÇü
Ñãü
qÇ&†üü
1Š?Åü
‘üü
1ô1Œ(‹üü
‘Œ
ñü
qüü
ÑÇü
ÑŽÇ
ÑÜñ
яü
Qӟ
‘Ç<(ÉÜáŽ(¹Œñ
±Ç
±Žm†ì#Å
1Š

£
1#
ñÆü
(·t€(µLü
1ã~†|ãü
(·l€(µLü
1ã~†|c€¡(·l€(µDü
1c
ñÆü
1ŠÇü
Ñ£
qÇ&†üü
(·t€(µTü
1#
ñÆü
(·t€(µLü
1c
ñÆü
(·l€(µTü
1c
ñÆ
(¿l€(m¦ü
1ã~†|ãü
1ŠÇü
Ñc
qÇ&†üü
1Š?Åü
‘üü
1ô1Œ(‹üü
‘Œ
ñü
qüü
ÑÇü
ÑŽâ
ÑÜñ
яü
Q¤ü
‘Ç<(ÉÜáŽ(¹Œñ
±Ç
±Žm†ì#Å
1Š:ÿü
ñŽ3ÿ
1ŠEÿ
1#
ñÆü
(·t€(µDü
1#
ñÆü
(·l€(µLü
1#
ñÆü
(·t€(µLü
1£~†|ãü
1ŠÇü
Ñcü
qÇ&†üü
(·d€(µ\ü
1#
ñÆ((·t€(µLü
1c
ñÆ((·

Looks like TeraTerm's logging feature will handle raw data. Go to File|Log and check the Binary checkbox. After the capture use the logging window to close the file. The screen will likely still show nonsense.

Would be good to get captures both with the d4r-ii connected and not connected just to make sure it's not loading the connection somehow.

The signal does need to be inverted before going into the ftdi adapter. Best to use hardware for that if you can so the cleanflight configuration remains unchanged.

Hi again, I'm sorry it took a while but finally got those files:
During the capture I had a nice 3d fix with 6-8 satellites for all the time. There are two files NO_RX and WITH_RX. I've done around 5min of each capture.
In the first scenario the rx has been disconnected and the transmitter had been switched off. In the second case i had the sniffer cable in-between the cleanflight and D4R-II telemetry port connected to FTDI's rx and the transmitter powered on for all the time.

Also - I've done the same thing with the transmitter ON and the ftdi cable in-between when the board was armed and the motors were running for all the time - this one is named teratermARMED.log (around 3 mins of capture)

Here are the results- they don't mean anything to me, but hopefully you'll be able to extract some useful information :
NO RX drive.google.com/open?id=0B7SacC_0VeiwSFp6SlUzN25oWDg

WITH RX drive.google.com/open?id=0B7SacC_0VeiwZlFjVU5ISkhGZlE

ARMED drive.google.com/open?id=0B7SacC_0VeiwOXFUVS1MbkFxRDA
=====================================
UPDATE: just realized that the files above are inverted in cleanflight (set telemetry_inversion=ON), i forgot to put a hardware inverter to un-invert the signal before feeding to the FTDI so here are zipped logs as above with a hardware inverter used this time:
drive.google.com/open?id=0B7SacC_0VeiwanNyeDNlc1k0Qzg