New FrSkyX protocol

this may be a dumb question but do you actually have a gps module on your quad? if so is it showing successful finding of satellites?

Yes, the gps is connected correctly to naze32 rev.6 as it shows up after a few seconds in cleanflight. Today i was testing at home so didn't catch 3d lock, but other data like main battery was missing too- this surely is not gps related parameter and should come up. I can only see rssi, i believe receiver voltage as it shows around ~5v , and some other voltage that shows ~0.18v

Replied in the Frsky thread...

I've done some testing with the FINE variable. I can bind with the range from -60 to +65. FINE value at 0 seems to be the best in my case. Anyway, dropouts still occurred no matter what FINE value I had.

I've noticed some strange behaviour as explained below.

1. When the transmitter & receiver are closed together (tested within 10 feet), I got a solid green on the receiver. It seems there are no dropouts in such close proximity.

2. When there is a concrete wall in between the transmitter & receiver (still within 10 feet), the green LED is not very steady and I will sometimes lose signal as indicated by the red LED on the receiver (see video 1 for details). The RSSI on the transmitter fluctuates a lot, between 41 to 106 (refer to video 2). In comparison, I also tested FrskyD protocol with the same concrete wall and never got any dropouts. In fact, I tested the FrskyD with 2 concrete walls and still worked fine.

Thanks for the testing. Videos are nice.

The code to set the transmit power level is the same for Frsky and FrskyX so not sure why the difference in "wall count". Does seem to be a good test though.

The frskyx_drop test build is updated with some changes that shouldn't change dropout behavior, but might. Please test and let me know.

Looking into midelic's comment about dynamically updating the FINE protocol option, I finally dug into the CC2500 datasheet. The test build has several changes based on what I found. Had a nice long writeup but firefox lost it and now it's bedtime. Changes are in the frskyx_drop branch in my repo.

hexfet, you nailed it! Your frskyx_drop test built fixed the dropout issue. Excellent work! I've placed the transmitter & XSR receiver around 30 feet apart in my apartment with 3 concrete walls in between and there were no dropouts at all. The range should now be comparable to FrskyD. I will do some field test this weekend to reconfrim.

Your last commit (2704370) "Change freq synth calibration method to automatic" is the modification that fixed the dropout issue. I've verified that the changset (3042a96) before the last commit still had dropout issue (I compiled the source myself).

However, there is one minor issue. The telemetry with the last commit isn't working properly. It will now take several minutes to receive the first telemetry update. The extended telemetry is also missing.

Thanks again for bringing the FrksyX protocol to devo!

Petsmith does hexfets build your using have u7e code for the extra switches and pots? If not can I use your custom build with fixed FrSkyX dropouts?

Have you tried data logging on your u7e?

Cereal_Killer wrote: Petsmith does hexfets build your using have u7e code for the extra switches and pots? If not can I use your custom build with fixed FrSkyX dropouts?

Have you tried data logging on your u7e?

I believe hexfet's build has code for extra switches & pots, but not the latest bug fix version from silpstream. Silpstream's latest version is still in the pull request and hasn't been merged in the nightlies yet. My current custom build is exactly the same as hexfet's. I only did a recompilation and tested a version without the last commit.

I never use the data logging on the Devo before.

BTW, I can create a custom build with silpstream's latest version after the Telemetry is fixed, provided HappyHarry doesn't beat me to it.

Sounds like progress The test build is current with the latest nightly, plus the frskyx changes.

The last commit changed freq calibration chip setup to work like Frsky. The latest DIY-Multiprotocol code has been updated in that area since the port but for space saving - not to fix an issue. Perhaps I introduced a bug in the port.

petsmith wrote: However, there is one minor issue. The telemetry with the last commit isn't working properly. It will now take several minutes to receive the first telemetry update. The extended telemetry is also missing.

Do you mean the extended telemetry boxes are not shown on the screen, or that you're not receiving extra data? I built the 7e-256 emulator and things look fine there.
The temperature display (Misc row 2) in the video looks funky. Is it always like that? Maybe there's an underlying telemetry bug.
Does telemetry work fine if you build without the last commit? If not, would you please try a build with the change in commit 857f6c3 reverted? Want to rule that out as a possible problem.
The freq synth calibration change means it takes 720us longer to enter TX/RX mode from IDLE so perhaps that is why telemetry is problematic. Plan to make a change in the state machine to address that. If that doesn't work I'll revisit the calibration method used in DIY-Multiprotocol.

There's a couple minor differences between Frsky in deviation vs DIY-Multiprotocol which are in turn different than FrskyX. These are for enabling address checking and CRC checking. Plan to investigate that as well. It's helpful you can make your own builds with commits included or not

According to the CC2500 datasheet section 14.1 the FREQEST register can be used to automatically set the fine freq adjustment. (Why don't they just do that in the chip?) Want to try that and hopefully eliminate the protocol option.

Thanks for testing!

petsmith wrote: BTW, I can create a custom build with silpstream's latest version after the Telemetry is fixed, provided HappyHarry doesn't beat me to it.

o/j lol, if you do one pm me the link or post it in the u7e builds thread, no point in duplicating work

hexfet wrote: Do you mean the extended telemetry boxes are not shown on the screen, or that you're not receiving extra data? I built the 7e-256 emulator and things look fine there.

All telemetry boxes are shown, including extended telemetry. It's just that it takes a long time to receive telemetry data.

Normally, once I provide power to the receiver, I should immediately get telemetry data displayed on the Devo telemetry screen. With the last commit (2704370), there were nothing being displayed upon receiver power up, not even RSSI or receiver voltage. If I wait a few minutes, I may get either RSSI or Receiver Voltage on the telemetry screen. However, extended telemetry data were never being displayed.

Without the last commit, the telemetry is working properly, including extended telemetry.

The temperature display (Misc row 2) in the video looks funky. Is it always like that? Maybe there's an underlying telemetry bug.

lol, I don't even know it's for temperature. It's always like that for all the test builds that I had tried, including the nightlies.

I'll be happy to test as many versions as you want.

HappyHarry wrote: o/j lol, if you do one pm me the link or post it in the u7e builds thread, no point in duplicating work

haha, I would rather have you do the the custom u7e builds, since you can put them in the proper download area. I don't have that privilege.

The frskyx_drop test build and branch are updated.

I changed the cc2500 configuration to automatically go to RX mode after sending a packet. No calibration delay occurs during this transition. The state machine is updated to watch for this transition and change the PA/LNA enables accordingly.

On the telemtest page the Misc row 3 value is a bit of debug info for the transition detection. Would like a video of that whether this works or not.

This version isn't working properly. The XSR receiver just keeps flashing Red & Green (see Video #1 below). Binding works though.

I do receive Telemetry with this test build (refer to Video #2), but only RSSI & Receiver Voltage. Extended telemetry are not being received. The 3rd row of Misc always displays 26C. At around 6 seconds into the video, you could hear some beeping tones where I plugged the battery into the quad and provide power to the receiver. The RSSI is also a bit low compared to previous versions. I used to get around 105 when transmitter & receiver are closed together, but this version I only got 81 max.

I've done some more testing. The dropout problem seems to be related to Extended Telemetry. The following tests are based on the nightly build on Sept 15 (0ad4374). This is the code before the test build frskyx_drop (2704370) on Sept 21.

Test 1:
Compiled for Devo 7e (non Ultimate version). The standard Devo 7e version doesn't has extended telemetry due to memory constrain. Result: No dropout

Test 2:
Compiled for Devo u7e (Ultimate version). The u7e version has extended telemetry enabled by default. Result: random dropouts

Test 3:
Compiled for Devo u7e (Ultimate version) with HAS_EXTENDED_TELEMETRY set to 0. That is, disabling Extended Telemrtry. Result: No dropout

This may explain why some people have dropout issues, some don't. As for why the changset 2704370 (Change freq synth calibration method to automatic) exhibits no dropout, I believe it's because this version somehow disabled Extended Telemetry by accident. My previous test indicated that this version doesn't has any extended telemetry data displayed.

Okay, I found the code that caused the dropout problem. In frskyx_cc2500.c, around end of the function frsky_check_telemetry(), the original code looks like this:

pkt[6] contains the len of sport stream data. However, there is no checking whether the actual packet really consists of that much data. It seems sometimes we may receive invalid packets (maybe due to long range) and pkt[6] may contain any arbitrary number. I've added some safeguard as below to ensure that we don't process any data outside the actual packet. I've tested the new code and it seems to fix the dropout issue.
However, this may not be the best way to handle. I think we should also check if the telemetry packet is valid or not, and discard invalid packets instead of processing them.

Thanks for looking into it. I'll take a look at your comments in more detail soon. Anything that increases robustness is fine with me.

On the current test version, the diag telemetry of 26 is not a good number. I expected around 2 or 3, so something's not working correctly. The cc2500 errata sheet notes a problem with the method I used to check the status byte, so maybe that's it. Best to put this approach on hold til I get hardware because it'll likely take several iterations to get right. I've ordered a 4n1 module from taobao, and will be getting an x-series receiver for a new quad.

I'll make a new version based on the current DIY-Multiprotocol implementation in the next day or two.

Added some logging into the code to dump the pkt[6]. When the signal is weak, such as passing walls or long range, the telemetry packet received will sometimes corrupt, which resulted in an exceptional large value in pkt[6]. The pkt[6] indicates the length of sport stream data. I've seen the value as big as 192, but the length of the packet is only 7. This will result in the system spending a lot of time in trying to process the invalid stream data. It's this extra long processing time that caused the transmitter to miss its next window to transmit signal to the receiver and caused the receiver to timeout. Hence the dropout issue.

My previous code segment will stop the above from happening. Thus, solving the dropout issue. However, if the packet is corrupted, we will still process it and will result in corrupting the telemetry display. This will also explain why sometimes the telemetry data are corrupted in previous builds.

We really need a way to identify invalid packet and not to process them, so as not to corrupt the telemetry display. Do we know the checksum algorithm of the telemetry packet?

Below is the test build based on the latest nightly with the dropout fix that I had posted above. If you had dropout issues, please test this version. I only compiled for the most common platforms. If you need another platform, please let me know and I'll generate one for you.

Devo 6


Devo u7e (Ultimate 7e)


Devo 8


Devo 10

in no doubt forward transmission is the only priority for every r/c transmitter. So a safe transmitter is one that can disable telemetry. To the least, only a predefined time slot to be allocated for telemetry data receiving and in absolute no circumstances should it be allowed to extend.

cmPang