Eachine E010 inductrix clone data captures

Well,

Seems my reply from two weeks ago did not get through so here is the comparison/results of Taranis based flights:
I have been flying the E010 exclusively with my other devo7e (discrete modules) and my Taranis (multimodule) without any issues.
The 4-in-1 RF stage on the multimodule for module bay TX's and on the Devo daughterboard are the same, so that is why it strikes me as odd to see it only on Devo happening.

I didn't want to do the soldering job suggested in the other thread @goebish linked to (interesting, thanks!) so I contacted BG support and they were so kind to dispatch a new (supposedly 'fixed') version. It did not arrive yet, so no result on that.

Once I have that one I will try the fix suggested in the other thread, just to make sure that it was indeed the problem they encountered and fixed.

Thanks a lot so far!

Playing a bit more with my E010 today. Firmware on the Devo 10 w/ 4in1 probably 2 months old. 5.0.0-cca3757
It will bind fine, BUT the LEDs keep blinking, like low battery. Turn off and try with stock Tx and all OK.

It is set for fixed id 123456, 12 channels. Anything to change ? Using a downloaded profile

Any way I can calidate my antenna connection on the Devo 10 ?
Or an idea about other ID ? Is it always 6 digits ?
Well, just bound to a FlySky iA6B. 100uW. Walked to another room, so shortest path is 10cm steel inforced concrete, and other way is bouncing off multiple walls. Keeps the bind. When I turn off TX the Rx starts blinking. So my high-gain antenna seems to work.

So what you are saying is, that it likely is a clone chip on my 4in1 module ? Am I better off with the old 3in1 ? (I have one, never mounted)
I tried everything from 100uW to 100mW.
Is there anything I can do to help troubleshoot ? I don't have much equipment for this, only clone logic analyzer (used to help hack Flysky proto for sensors, and for my iBus2PPM to get better understanding), and my SDR is the standard RTLSDR, so not going to 2.4GHz. Not sure if 1.2GHz spectrum.

I have a clone H8 - Locally given away as Q8, I have an UDI 818A as well, any way to see/guess what protocol it is using ? To see if I can test the NRF24L01 on any of these.

I am not so much of a hardware guy.

Did not come further. Just got an idea. If I have swapped 2 radios, either by wire or in hardware.cfg, would the wrong radio then work good enough to cause this behaviour ? Or are the radios so different that it would just completely not work ?

And another thought, frequency shifting a bit is not possible, as you reported. But as I can see the channel table seems to allow selecting a channel with a 1MHz resolution. So it should be possible to shift all channels 1MHz up or down ? I did not look at the source code, so I am not sure. Not too much into this low level stuff.

But to me it seems possible to add/subtract one to RF_CH, unless that value is just a seed to some frequency hopping ?

Take this line 258 in mjxq_nrf24l01.c
NRF24L01_WriteReg(NRF24L01_05_RF_CH, rf_channels[rf_chan++ / 2]);
Shouldn't it be possible to add/subtract one to the value here ?
Then possible create 2 more targets - E010Above / E010Below.

Is it worth for me to try - Just with +1 / -1 ? Since there is a docker build container, it should be easy to try just hard-modding my own firmware.

povlhp wrote: Playing a bit more with my E010 today. Firmware on the Devo 10 w/ 4in1 probably 2 months old. 5.0.0-cca3757
It will bind fine, BUT the LEDs keep blinking, like low battery. Turn off and try with stock Tx and all OK.

It is set for fixed id 123456, 12 channels. Anything to change ? Using a downloaded profile

The LEDs will blink if you enter headless mode. You can also try calibrating the gyroscope: both sticks bottom left.

Even with LEDs blinking, calibrating gyroscope works.
Did another test today, and now it seems to work. Did not fly, only bind test.
Started at 30mW, all OK. At 100mW I get the blinking again. 30mW and 10mW will make the blinking stop.
Since headless mode is one of the switches, there is a chance that I never had any issues, just the wrong FMODE, as I used a downloaded model where FMODE is used for headless/RTH. Something I would never use anyway

Some hobbyists also reported that their quad did not work at high transmit power. The root cause is not yet known. I however cannot reproduce this issue with several 4-in-1 modules.
Did you connect the radio module with long wires? Although it may not help but you can try shortening the wires or re-routing them further away from the antenna, etc.

As I told earlier, now it works. Likely it was the FMOD switch in headless mode.
Will see if I can get the time to try again during lunch break.

Could the 100mW issue be caused by the fake chip?

I cannot reproduce the 100mW issue regardless of the chip, clone or genuine.

It was likely the FMOD switch that caused the blinking. Flew 3 batteries around office space with plaster walls without any issues. Switching FMOD I could get the blinking again, and erratic flight behaviour (aka headless mode). Maybe this is what others are seeing as well. A high value on channel 6 (?) causing headless mode = blinking.

Still, moving 1MHz up/down would be doable. But it might be too big a step. But still only 0.05% - But I don't seem to have that problem, sp I will not do more on that.

Hellо.
What version of deviation must i use to bind my Devo 7e (nrf chip only) to Eachine E010? I've tried the 5.0.0 and no luck. None of the nightly builds seems to do the trick.
Edit: Oops my bad. Had forgotten to turn of nrf chip on in confiig.ini. Will try it tomorrow.

Well I have read through and tried everything(i think). Different ID, all the protocols, different ini, different craft types, different channels but I still cannot bind. Devo 7E, 30/1 nightly, Nrf no pa from online. Works with syma clone and eachine h8. I have not been able to bind to xn297 chips before either.

I have tried the e010 format and all other protocols. If I find the pinout will this one work? www.banggood.com/Multiprotocol-TX-Module...8.html?utm_design=19
I was just trying to confirm that it would be the module rather than some setting. Sorry if I missed a previous post that says what would cause a problem.