New FrSkyX protocol

The Mixer output displays the values being sent to the protocol so if it's jumping around there it's not a protocol issue.

Click Right on that screen to display the Stick input. If those are dancing then it's likely noisy pots or some problem in the analog circuitry. If those are quiet then lets have a look at your model file to check how the mixes are set up.


The question about 8 channels was to check if the problem might be in the transfer of the data to SBUS, but that's not the issue.

Don't think any data capture is needed yet.

bampi2k wrote:

CesiumSalami wrote: bampi2k - that's pretty weird ... neither my X4RSB nor my XM+ do that with my Devo 7e with the 4-in-1 on the FrSkyX protocol ... both nearly same fine frequency adjustment.

Could you tell me the build that you are using then I can try that out and post the results.

I'm using: Devo7e-v5.0.0-685f7e
I don't even know how you'd find that... but it's not sounding like this is the problem anyways.

CesiumSalami wrote: I don't have that "Format" option, though ... is that associated with the failsafe?

That's there in the latest nightly. It is in response to the fact that the new FrSky RXs are coming with atleast 2 versions of the firmware: EU (LBT) and FCC. There seems to be some change in the format. It also affects legit Taranis radios and is detailed on the FrSky website.
For specific technical details of the 'Format' option, Hexfet could tell. I guess he implemented it in DeviationTX!

Oh, that's good to know for the future.

bampi2k wrote: This very much looks like a electronics problem than a software one, Yet I would suggest the following checklist: (or post the details here for people to help you or debug)

bampi2k wrote: 1. What is the CC2500 module that you are using? sure it has a PA on it?

i think yes

bampi2k wrote: 2. From the CC2500 to the antenna: UFL/ipex connector? + the SMA/RPSMA connector for antenna.

i think it's a good one

bampi2k wrote: 3. Sure the antenna is a 3dbi or 5dbi antenna for 2.4GHz?

The 3dbi was sell as 2.4ghz one, the 5dbi is the stock antenna from the DEVO10

bampi2k wrote: 4. Did you do the fine freq adjustment for FrSkyX on your radio? (I guess Hexfet describes how to do it a few posts back)

yes, i'm about 0, my range is to -62 to +64

Should i maybe give a try with another CC2500 from BG that seems to be a bit different


I've just ordered an X4R-SB to see if there any range difference.
Thank you for help.

CesiumSalami wrote: bampi2k - that's pretty weird ... neither my X4RSB nor my XM+ do that with my Devo 7e with the 4-in-1 on the FrSkyX protocol ... both nearly same fine frequency adjustment.

Could you tell me the build that you are using then I can try that out and post the results.

I am using this build: www.deviationtx.com/downloads-new/category/696-2017-03-06

Hopefully you can still find this build. Great that you can try it out. (While I hope I can try yours. Maybe you can send me the 7e build if u downloaded the whole thing!)
I think there would be a way to get to older nightly... Maybe go to that version and compile, but I am too much of a noob at github surfing!

sfersystem wrote: I've just ordered an X4R-SB to see if there any range difference.
Thank you for help.

I think all the equipment looks good. I wonder what could be going wrong.

PA and LNA hookup from the module? I don't think so since u use the PCB to mount.
If you use foam sheet to insulate, careful on that, they give way under pressure and don't leave any sign of fatigue when disassembled. I suggest electrical tape.

Also check the berg connector. I have had problems with those going dry-contact when packed up/bent.

hexfet wrote: The Mixer output displays the values being sent to the protocol so if it's jumping around there it's not a protocol issue.

Click Right on that screen to display the Stick input. If those are dancing then it's likely noisy pots or some problem in the analog circuitry. If those are quiet then lets have a look at your model file to check how the mixes are set up.


The question about 8 channels was to check if the problem might be in the transfer of the data to SBUS, but that's not the issue.

Don't think any data capture is needed yet.

Thanks for the clear explanation.
I would point out additionally:
1. To keep the testing clean, I started with a fresh flash + format USB drive (no old files) + calibration + hardware.ini
2. I did try making 'model2 as a dsm2 and there was absolutely no twitch in the channel monitor. (Just dumb me, I did not check the sticks screen!!) 3. I am using the same tx for flying quads on dsm2, I think I would see analog glitches in the BF blackbox.i have not till now.
4. IMO, Analog glitches will rarely be periodic like in this case!

Thanks for all the effort again!!

I will do the two tests, stick screen and also post model file.

bampi2k wrote:
I am using this build: www.deviationtx.com/downloads-new/category/696-2017-03-06

Hopefully you can still find this build. Great that you can try it out. (While I hope I can try yours. Maybe you can send me the 7e build if u downloaded the whole thing!)
I think there would be a way to get to older nightly... Maybe go to that version and compile, but I am too much of a noob at github surfing!

Heh! I actually do have the whole thing! [attached to this reply - little hard to see - look in the lower left]

CesiumSalami wrote:

bampi2k wrote:
I am using this build: www.deviationtx.com/downloads-new/category/696-2017-03-06

Hopefully you can still find this build. Great that you can try it out. (While I hope I can try yours. Maybe you can send me the 7e build if u downloaded the whole thing!)
I think there would be a way to get to older nightly... Maybe go to that version and compile, but I am too much of a noob at github surfing!

Heh! I actually do have the whole thing! [attached to this reply - little hard to see - look in the lower left]

deviation-devo7e-v5.0.0-c85a02a_2017-03-06 Vs. deviation-devo7e-v5.0.0-685f7e5(file used by CesiumSalami and he reported XM+ works fine without twitching as observed by me)
Did a quick compare of the binary mod files (FrSkyX.mod)... there is definitely difference between the 2. I will check out this build today evening and report the characteristics on my setup.

Here are the tests I ran and the observations from them: (they are in the same order that I did them. I might have done something stupid, please point out to me if so)

deviation-devo7e-v5.0.0-c85a02a_2017-03-06
1. Check if the values are twitching in the 'sticks' screen.
Yes, they are. BUT when I change to DSM2 or DSMX there is no twitching in the channel monitor and stick screen.

deviation-devo7e-v5.0.0-685f7e5 - File posted by CesiumSalami
2. Bind and check for twitching. Yes. The channels still twitch. 3-5us (as observed on BF configurator - receiver tab). Variation of 1%(point) is seen on the channel monitor(devo 7e) and also in the sticks screen.
3. Change to DSM2 / DSMX and that vanishes!

NOTE: in the latest nightly (c85a02a) the fine freq setting was optimised to -20. Whereas in the previous(older) version from CesiumSalami(685f7e5) the fine freq setting was optimised to 0. Additionally I think the older version was randomly losing bind with bright red LED on the XM+ coming on.

Back to deviation-devo7e-v5.0.0-c85a02a_2017-03-06
4. General test for stability: Yes, the RX never unbound. Fine freq was calibrated to -37 this time!
5. some other protocol other than frskyx. no twitching! (including frsky, frsky v8)

Note: Unlike other protocols, when I change To FrSkyX in the protocol selection, I need to reboot the TX for it to bind(With already bound RX). (Before reboot no twitching values in channel monitor). Once I reboot the TX, it instantly locks on to the RX and we see twitching values on the channel monitor. The strange part is, as described by Hexfet, the stick screen shows analog values and logically there is no chance that the protocol mod-file/code could affect that!!

I will be attaching the model file along with this post. as suggested by Hexfet.

My contension, Is it possible that the protocol file is making the RF module(including the PA) reboot or restart every few ms or so which in turn is creating rhythmic ripples in the 3.3V bus; which again happens to be the same used by the pots -> A2D for the sticks (I tried to roughly time it using a stop watch. I am pretty sure its periodic)

The twitching continues.

Yes, I can do an RC-interpolation setting in the flight controller and ignore this and go fly. But I am just not comfortable with it. As it could be an indication of an impending failure!

Additionally if all others using FrSkyX on devo7e say that they dont see anything like that, I would have to assume that it is just faulty hardware on my side.

Still I would really like this investigation to end in positive results!

Regarding the what you name "twitches", could you verify your tx battery voltage readout in the devo 7e screen.

I have especially with frsky protocol fluctuations in the voltage readout, it might be related. I can't really point out were its from there are topics on that.

The model file is straightforward - no issue there.

As you suggest a power problem seems likely. Other users have posted about strange behavior that's solved with additional power, including different behaviors with different protocols. The model file has the tx power at 150mW. Do you see different stick input monitor behavior if it's set to 1mW?

Not sure about the bind behavior you describe - have to try this evening. Am I understanding correctly that the stick inputs are quiet if the tx is on and the receiver is off?

Hmm. Perhaps it's worth pointing out that I'm at 100mw power... Haven't tried 150mw... I never use that setting, honestly.
As I mentioned above, the range on this rx is pretty remarkable. My needs aren't that great, but it'll run my 5" quad (with a 600mw 5.8ghz VTX) to ~150m with brick buildings / trees in the way with the TX at 3mw and not dip below ~80% rssi.

@all with twitchy channels
the power consumtion of the cc2500 modul is messsing up the 3,3v, witch is internally used for reading the analog inputs (stick pots)
Therefore its only on the channels used with analog inputs.

Try to assign switches to the first 4 channels....is the problem gone?
More TX Power = more twitchy

i had this problem with Devo12s and a cc2500 from banggood
www.deviationtx.com/forum/3-feedback-que...voltage?limitstart=0

I could get rid of the noisy inputs with a schottky barrier diode,Capacitors and a coil.

In the end i´m using a 4in1 with its own onboard regulator, and the problem is completely gone.
The original Cyrf Module is also using Battery voltage and his own regulator.

If you want to use the single cc2500 module, i think its best to grab the Batteryvoltage from the internal module header and use an extern regulator to feed the cc2500

Wene001 wrote:

---

cut

If you want to use the single cc2500 module, i think its best to grab the Batteryvoltage from the internal module header and use an extern regulator to feed the cc2500

I think it must originate from the concept of the module and the way the protocol works.
Between 1mW and 100mW setting the demand for power rises of about 40 mA. The fluctuation on the Devo V-display will
go up from 0.02 to 0,04V, but on the input side, the voltage stays and there is a constant 10mA fluctuation on current on both
power settings.

Power source for the test was a 2200mAh 3S Lipo and a stepdown 3A power power supply.
Maybe this is the reason the fluctuation is still there even with a Pololu mod,
.... or I am wrong, Fernandez?

Edit: The best way might be to display only two digits instead of three....no one will notice....
I will do the test on my DFT and my Taranis the next days.

i have discussed this with victh in another thread
its best to use one regulator for the prozessor things and another for the tx-modules.

The Devo 12s (standar setup) with its 1S Battery e.g. uses a stepup to 4,25V and two LDO... one for the prozessor and analog input readings and another on the Cyrf TX Module.

Wene001 wrote: i have discussed this with victh in another thread.
its best to use one regulator for the prozessor things and another for the tx-modules.
..........cut

You are right, at least for safety a decoupling is good.

unstable Tx-Voltage readings and noisy analog input readings are gone since i use the 4in1 (the version especially for Devo) with its own power regulator.
No problems with the same Module in my Devo 6s too

This a different module and not the common CC2500 module we use. Beside this it uses a RFX 2401c pa/lna which is more
simple than the RDAT212 with lna bypass. You will notice that when the transmitter is quite near to the receiver.
But this is different story.

i know
i only want to say that the common cc2500 powerded with the same regulator as the prozessor is causing problems.
Same on common a7105 but not that much.

I power my devo7e from a 2s Lipo. Have been running it with the same battery since 3years now.

I do confirm that I was seeing the voltage display being unstable in the initial setup.
And yes the an analog twitching does reduce significantly at 100uW! thus it proves that the problem is related to power

So here is what I tried and what has happened:
1. I soldered up a LT1764-EQ3.3 from the 'jumper' (points in the power stage that is output from FET.
2. Only the VDD of the module was disconnected from the main pcb and connected to output of the voltage reg.
3. I checked that the module was getting 3.34V
4. Tried binding and the bind just wont happen!

Next:
i must have done something very stupid. I think I burnt some components in the soft power off/on stage.
Now I cannot switch on the TX with the power slider switch. If I keep the switch in the powered on position and unplug and replug the battery it does turn on.
I did try to revert back to the VDD on the PCB. It binds normally (ad of course the analog disturbances are back!!)

Now unless I solve the power issue and get my radio back, cant do any further tests on the protocol.

I will go to another thread and try and solve the power issue (hopefully I can solve it!)
If any one here has pointers to where I should start reading please tell me.