Eachine CG023 protocols - what are they?

Hi
I use / have as fixed ID "NONE". It binds every time at first try.
Just tested again with 4100 build and can barely see, if any, the automatic reduced rate in filming mode like i mentioned yesterday.
A thought, could the "start recording" getting triggered by the "take picture" channel pulse? The picture channel pulse invokes no reduced rate on the quad with stock tx..That can also explain when cam is filming there are no continious flashing leds in the arms.
Perhaps if I swap for ch7 and ch8 the virtual 1 and virtual 2 in the ini it will work ok with 4100 build. I'm going to try it.

goebish wrote: What if you lower output power ?

I will test when return home. I tested previously to increase and decrease power output, but without put too much attention.
Something I noticed when you change the power output without fixed ID and reset the TX, probably the TX ID change, because don't rebind with the quad and you need to reboot the quad also. I guess this is just fine.
About how this quadcopter handle the rates when you start video recording, mine lower rates ALWAYS when I started video.
No matter what build I use, always works just fine lowering the rates clearly at start video, and recovering the previously configured rate when you stop video.

Strange, mine when filming (automatic lower rate and leds continious flashing) was only ok with 2050 build. 4100 build no rate change when filming and no flashing leds but it was filming i found out.
I just swapped for the 4100 build the virt1 and virt2 for ch7 and ch8 and now it works. Meaning with 4100 build when I start filming now the leds keeps continuous flashing and the rate go lower until I switch off video.

goebish wrote: What if you lower output power ?

Just tested.
I tested at 100uw and 150mw power output using my own build with 4100 period (as stock tx)
At 100uw is almost perfect I can barely feel some delay at floor playing with fast changes at throttle. When the quadcopter take off is almost perfect . Maybe sometimes you could feel a very very minor delay, but really good, almost perfect.
I changed the power output to 150mw and resets the TX and Quadcopter (doesn't bind immediately, probably the TX id is different when you change the power output), and immediately you feel the delay . At floor playing with throttle's stick is almost the same as at 100uw, but as soon you take off you can feel very good the quadcopter is dropping packets sometimes (not continuous).

Alias_Hendrik wrote: Strange, mine when filming (automatic lower rate and leds continious flashing) was only ok with 2050 build. 4100 build no rate change when filming and no flashing leds but it was filming i found out.
I just swapped for the 4100 build the virt1 and virt2 for ch7 and ch8 and now it works. Meaning with 4100 build when I start filming now the leds keeps continuous flashing and the rate go lower until I switch off video.

The first test build was compiled using 4100 as packet's period. This build had swapped the video/picture channels, we figured after my first tests and your reply at RcGroups explaining how works the camera with stock TX.
Later Goebish swapped the camera channels, and next builds was compiled with the correct channel order, but as we started to see the delay at commands, Goebish start to compile builds using 2100 packet's period.
Probably the 4100 build you are testing is the first one, with swapped camera channels order.
That's the reason you need to change your ini file using the 4100 build.

goebish wrote: Ok, so looks like the problem is only when the transmitter is close to the aircraft.
Seems the aircraft miss packets when there's too much transmission power, that would explain why vasiliy_gr's Devo 10 is working because it's using a nRF24 module without PA
.
I think I can't explain that myself... Maybe someone more knowledgeable in RF area can ?

Only as info, the stock TX doesn't have PA.

Just tested now using Fixed ID, and same result At 100uw almost perfect (flying inside at living room)
At 150mw unflyable.

Thanks for the explanation about the builds.

A thought but you never know...About your different results with output power, could it be that at the higher output power there is just a little too much ripple on the 3.3V DC voltage causing the NRF to flip? Perhaps you can check with a scoop the ripple on the 3.3V between low and high output just to rule things out. I know in that case you should also have problems with other quads and they are fine but like i said, it is just a thought

Alias_Hendrik wrote: Thanks for the explanation about the builds.

A thought but you never know...About your different results with output power, could it be that at the higher output power there is just a little too much ripple on the 3.3V DC voltage causing the NRF to flip? Perhaps you can check with a scoop the ripple on the 3.3V between low and high output just to rule things out. I know in that case you should also have problems with other quads and they are fine but like i said, it is just a thought

And a good thought
I will check as soon I have some free time at work
Please, could you check with 4100 build using 150mw as power output?
Thanks!

Here is my experiment. It has a funny result...

So I set power to 100uw and tried with 4100 build. Oh - really a very little delay... Nearly good in general (but in throttle test delay is still visible). So I decided to test on 150mw... but my battery became low.

I changed the battery and turned it on with already 150mw set. The delay is huge - as it expected to be. But here I decided to test 100uw once again. Nothing changed - delay is still huge. Any intermediate power values - the same. I set it to minimum and restarted both the tx and quad - the delay is still huge.

So I can't again reproduce the previous good result... More than that - I have deja vu... I already had such situation when I did some changes that I think should reduce delay - the delay became low - I changed battery as it was also low - and the previous result can't be reproduced with new fully charged battery...

So, may be delay issue is somehow related to battery output current value and its charge level?..

I have set my tx to 150mW for test and held tx against quad and it binded no problem. I Kept the quad close flying within 1.5 meter and I noticed no problems. I had at that moment Dyntrims=On (I forgot to switch it off). I was curious about it in a former test and it's the reason why I had it switched on.

If I remember correct they used a L04A (and still?) in former 7E models and according to TI (they use the L04A marking) it is a 100mA one and peak current 300mA typical. I looked at it in mine weeks ago but the LDO I have has another marking on it starting with LPC and another number but could not see it because of unreadable.
From what i read in Arduino forums the NRF can be really picky about clean power and many had problems with connection and corrupt data. But actually it was in the days they sold NRF's without tantal cap en ceramic between NRF board power traces. Most of the later ones are sold with cap's.
But you never know perhaps some DEVO 7E LDO's have difficulties. I know your Devo is only few months older as mine but stil worth to check it and I figured you could do it at work

Forgot to mention, this is the 4100 build I use; deviation-devo7e-v4.0.1-ff43c45_4100

Alias_Hendrik wrote: Forgot to mention, this is the 4100 build I use; deviation-devo7e-v4.0.1-ff43c45_4100

If I remember good, that's the first version, with camera channels swapped.

Alias_Hendrik wrote: I have set my tx to 150mW for test and held tx against quad and it binded no problem. I Kept the quad close flying within 1.5 meter and I noticed no problems. I had at that moment Dyntrims=On (I forgot to switch it off). I was curious about it in a former test and it's the reason why I had it switched on.

If I remember correct they used a L04A (and still?) in former 7E models and according to TI (they use the L04A marking) it is a 100mA one and peak current 300mA typical. I looked at it in mine weeks ago but the LDO I have has another marking on it starting with LPC and another number but could not see it because of unreadable.
From what i read in Arduino forums the NRF can be really picky about clean power and many had problems with connection and corrupt data. But actually it was in the days they sold NRF's without tantal cap en ceramic between NRF board power traces. Most of the later ones are sold with cap's.
But you never know perhaps some DEVO 7E LDO's have difficulties. I know your Devo is only few months older as mine but stil worth to check it and I figured you could do it at work

I checked my internal Devo photos at work, but unfortunately can't see clearly the markings at LDO.
I will open to take a look and see the ripple at 3.3 output.
In the mean time, I ordered some LP2981 samples at Texas Instruments.
Thank you for your reports and thoughts Alias.

My 7E seems to work ok in the different power settings with the YD-829 but between lowest and full power I can see in the 7E display sometimes voltage variations up to 80 mV depending also if backlight is on or of.
Did test in 100 microWatt power setting and could walk with the YD-829 for sure 40 meters before the leds blink connection loss.

I could not find specs about the LP281
If you mean the LP2981 (L04A) that seems the one they used before (or still do?) in the 7E and from which I think it is sometimes not up to the task with his 100mA usual and 200 or 300 peak. I read the NRF+PA+LNA alone uses about 110 mA at full power... And other parts in the 7E take also current so perhaps a LP2981 gets stressed and provide a litle to much ripple. That is if you have a L04A inside. Perhaps you have one like me starting with the marks LPC for which I could not find specs for.

If you can get samples, (I thought about changing mine too because of the voltage variations in the display) perhaps you can ask for one, (a type which is suited to use the electrolytic caps in the 7E) , and with same pin connections and same SOT package but which can deliver a little more continious and peak current compared to a LP2981. But like I mentioned, in mine is no LDO with a L04A marking but has marking starting LPC.. Perhaps it's just the same, I have no clue. All those SMD markings..

Oopsss... sorry
I mean LP2981 not LP281
I ordered some samples because the LP2981 has a peak current from 150 to 400 ma at oficial specs. The full reference is LP2981AIM5-3.3/NOPB
Some units could be at lower limit causing too much voltage dropout.
I will update ...

The weird thing about this theory, I haven't any problem with none of my other Quadcopters using the nRF module All models works flawless with excellent range and never seen any Dropout.
Including my CX10/JXD395 using XN297 emulator layer.
The Hontai protocol is under development now, and this protocol also uses XN297 emulation layer.
Is not working yet, but maybe, if we have any similar problem, we could start to figure something related with XN297 protocols.

Comrades, it is a very interesting discussion, but how it can be related to YD829 protocol? All the same hardware works flawlessly with dozens of protocols and quads/helis. I personally have never seen such bad delays on 24 my other devices supported by 7e through this exactly NRF24L01...