Eachine E010 and JJRC H36 now being issued with different protocol

[BadRaven]

Both the Eachine E010 and the JJRC H36 65mm Quadcopters are now being issued with Revision 5 (REV5) circuit boards (which are red colour, all previous being green).

Reason for the change unknown, just stumbled across. Not even Banggood knew!

Poss change of supplier or increased number supported or even poss bind change to "Listen before Talk" to meet Euro regs????

These will not bind using existing Module settings.

[benlye]

Are you able to identify the RF components on the new board or TX? That's usually the first step to figuring it if it can be reversed. Post some close up pictures if you're not sure.

[BadRaven]

The only IC I can read is the 10 pin on the connector side, which appears to say

RF2600 2021

Though its very feint!

[BadRaven]

The Transmitter is single chip, and is marked

RF 2618 2027

The top black strap and cut tracks (and removed yaw pot) is to move yaw to roll to make a two stick Hovercraft use Tx.

[pascallanger]

I would need to have access to the hardware TX+RX, nothing I can do from the pics.

[pascallanger]

I'm going to close this issue since there is no way to move forward with the given information...

[Maik93]

Hi @pascallanger, I'm facing the same problem. If I can be of any help, please instruct me and I'll be glad to collaborate!

PS: can I use an Arduino as ISP (powering the target with 3.3V instead of 5V) to program the Mega328P? Should I use a logic level converter for MISO/MOSI too?

[pascallanger]

@Maik93 There is no SPI to dump. You need a SDR tool to look at the communication to see if this can be hacked or not...

[Maik93]

@pascallanger I've got one of this: https://reference.digilentinc.com/reference/instrumentation/analog-discovery/start I could attach it to the pins that run toward the antenna on the radiocontroller and collect both analog or digital signals. Can this help?

[kilrah]

Nope

[BadRaven]

The E010 and its renamed but identical boards alternatives like the JJRC H36 and H36F (there's a Cheerson, too, but don't know its code) must be the highest selling 65mm Quadcopter worldwide and are also widely used for micro racing hovercraft, etc. It would be a great shame if their latest electronic iterations were not multi-module suitable. This would need to be done retaining the older 1-3 Rev option since there are literally millions out there!

I currently have two on the way to me, and assuming they are the new Rev5 boards, I'm prepared to send one onward to be the test item. I assume I could remove the 1S Lipo to make posting system choice easier and cheaper? The battery is an extremely common plug as you'll see from the above pics.

If this is acceptable contact me with address privately?

Edit:- In addition, sellers are now sending out replacement boards that are not usable with the original Transmitters, so having a Multi-Module option is a way of keeping existing models in use!

[pascallanger]

The E010 and its renamed but identical boards alternatives like the JJRC H36 and H36F (there's a Cheerson, too, but don't know its code) must be the highest selling 65mm Quadcopter worldwide and are also widely used for micro racing hovercraft, etc. It would be a great shame if their latest electronic iterations were not multi-module suitable. This would need to be done retaining the older 1-3 Rev option since there are literally millions out there!

I currently have two on the way to me, and assuming they are the new Rev5 boards, I'm prepared to send one onward to be the test item. I assume I could remove the 1S Lipo to make posting system choice easier and cheaper? The battery is an extremely common plug as you'll see from the above pics.

If this is acceptable contact me with address privately?

Edit:- In addition, sellers are now sending out replacement boards that are not usable with the original Transmitters, so having a Multi-Module option is a way of keeping existing models in use!

Contact me in PM (hpnuts) on rcgroups: https://www.rcgroups.com/forums/showthread.php?2165676-DIY-Multiprotocol-TX-Module/page1387 The board is not enough. I need the TX + quad to test.

[fe-copter]

oncemoretime: if you want to get TX, quad for test - please, give me your private address. It's all ready to ship.

CU frank

[pascallanger]

Here is a preliminary look with the SDR. Normal packets are sent using GFSK at 1Mb on channel 48 and others. They send the same frame 6 times on each channel with the following timing: 1.183ms, 1.183ms, 3.399ms, 1.183ms, 1.183ms and then switch 3.4ms later to the next channel. Channels in use are in order: 48, 69, 64, 53. 46.181ms for a full loop on the 4 freqs.

Here is the signal:

That's 75 bytes!!! The only RF component on multi which could send this is the cyrf6936 which is a real pain :-( I'm not sure if it's even going to work in the end so not sure if it's worse it...

This could be the binary translation of the signal but it could well be inverted or shifted: AA	AA	AA	A8	39	52	5B	BB	0F	0F	0F	30	CC	CC	CC	CC	CC	CC	CC	CC	CC	CC	CC	CC	CC	CC	CC	CC	CC	CC	CC	CC	F0	CC	CC	CC	F0	CC	CC	CC	F0	CC	CC	CC	CC	CC	CC	CC	CC	CC	CC	CC	CC	CF	0F	0C	CF	0C	F3	0C	CF	0F	0F	0F	0C	F3	30	CC	F0	CC	F3	30	F0	F3
Preamble	Preamble	Preamble	Address	Address	Address	Address	Address	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--

The payload seems to have multiple things applied to it:

• a FEC consisting of each bit being sent twice ? which could give this once removed:

33	34	AA	AA	AA	AA	AA	AA	AA	AA	AA	AA	CA	AA	CA	AA	CA	AA	AA	AA	AA	AA	AB	32	B2	D2	B3	33	2D	4A	CA	D4	CD

• there are a lot of AA so I'm wondering if the payload is not fully xored with AA then if removed:

99	9E	0	0	0	0	0	0	0	0	0	0	60	0	60	0	60	0	0	0	0	0	1	98	18	78	19	99	87	E0	60	7E	67

That's a lot of bytes (33) being sent...

It could also be code word based where the TX and RX have a dictionnary.

I need to do other dumps to get an idea.

[pascallanger]

The FEC seems to follow this rule: aabbccddeeff... -> each letter represents a bit a: bit0 b: !bit0 c: bit1 d: !bit1 e: bit2 f: !bit2 ....

[pascallanger]

Given the above the original signal looks to be more (bit shifted by 2 from previous post): AA	AA	AA	AA	0E	54	96	EE	C3	C3	C3	CC	33	33	33	33	33	33	33	33	33	33	33	33	33	33	33	33	33	33	33	33	3C	33	33	33	3C	33	33	33	3C	33	33	33	33	33	33	33	33	33	33	33	33	33	C3	C3	33	C3	3C	C3	33	C3	C3	C3	C3	3C	CC	33	3C	33	3C	CC	3C	3C	C0
Preamble	Preamble	Preamble	Preamble	Address	Address	Address	Address	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--	--

That's 67 bytes for the payload FEC encoded. There are 2 bits per FEC byte so the original payload is 16.75 bytes in total. So I have either too many bits or some are missing or something else in play...

[pascallanger]

I'm now receiving and decoding live the start of the message using the NRF24L01:

5	0D	00	00	00	00	20	20	x0
unk?	len?	THR	AIL	ELE	RUD	Ail trim?	Ele trim	Rud trim

THR: 00..FF, AIL/ELE/RUD: 7F..01..center=00..80..FF

Based on the above the payload seems to be 16.5 bytes long: unk=0.5+len=1->13+crc16=2 => 16.5 . Which looks to match what I said on the previous post.

bool ok=true;
//realign bits
for(uint8_t i=0; i<packet_length; i++)
    buffer[i]=buffer[i+2];

//check for validity and decode
memset(packet_in,0,packet_length);
for(uint8_t i=0; i<packet_length-2; i++)
{
    for(uint8_t j=0;j<2;j++)
    {
        packet_in[i>>2] >>= 1;
        if( (buffer[i]&0xC0) == 0xC0 && (buffer[i]&0x30) == 0x00 )
            packet_in[i>>2] |= 0x80;
        else if( (buffer[i]&0xC0) == 0x00 && (buffer[i]&0x30) == 0x30 )
            packet_in[i>>2] |= 0x00;
        else
            ok=false;   // RX error
        buffer[i] <<= 4;
    }
}

Next step is to decode the end of the payload and find out the CRC...

[pascallanger]

The payload from 2 post above is decoded like this:

5	0D	00	00	00	00	20	20	20	00	00	00	45	46	95	23	AE
ctrl	len	THR	AIL	ELE	RUD	TAIL	TELE	TRUD	flag1	flag2	?	ID?	ID?	check	CRCL	CRCH

flag1=0x00 low rate, =0x01 high rate, 0x10 headless, 0x20 one key return, flag2=0x01 flip

check=sum of all bytes after len (excluded) until check + 0x9D

The 16 bits CRC is calculated from len (included) until end with Input reflected, Result reflected, Polynomial: 0x1021, Initial Value: 0x00, Final Xor Value: 0x00.

[pascallanger]

Bind packet, frequencies 48, 56, 64, 72 (next hop +8):

5	0D	00	00	00	00	20	20	20	00	80	00	45	46	15	7E	A0
ctrl	len	THR	AIL	ELE	RUD	TAIL	TELE	TRUD	flag1	flag2	?	ID?	ID?	check	CRCL	CRCH

flag2=0x80 -> bind

[pascallanger]

The protocol is now reversed at the exception of 3 unknown bytes which are most likely IDs and associated frequencies. The problem is now the implementation on the CYRF6936... I'm not confident it will work but I'll try...

[goebish]

That's something I had already tried for another protocol without success because gfsk deviation is different on the cyrf6936 and it cannot be set... but maybe you'll be more lucky with this chip https://www.deviationtx.com/forum/protocol-development/7150-eachine-e012?start=40#63021

[fe-copter]

Thank you very much, Pascal. Great. I hope you fix and manage the implementation. Frank

[pascallanger]

@goebish

That's something I had already tried for another protocol without success because gfsk deviation is different on the cyrf6936 and it cannot be set... but maybe you'll be more lucky with this chip https://www.deviationtx.com/forum/protocol-development/7150-eachine-e012?start=40#63021

I don't know what the deviation is on this chip but the NRF receives most of it fine... Do you still have your cyrf6936 source by chance? that could save me some time. I hate the cyrf6936 all together so just thinking to look into it make me nervous and there is a lot of coding work to be done... 75 bytes to transmit which is far more from what you had to do...

[goebish]

that's all I have, probably not useful at all: https://gist.github.com/goebish/f23d3bb95c3091def9253b410697c045

[pascallanger]

I don't know yet how it will work but the E010 stops blinking when I'm sending the same frame at the right pace. So it does receive something and seems happy. I need to write the frame myself now and not one from the dump.

[goebish]

Nice! If you can get it working that will be worth a try to port the E012 protocol to cyrf6936 since the nrf24 protocol has never worked properly except for 1 build of deviation (never really understood why).

[pascallanger]

I can fly the E010 ;-)

[pascallanger]

If someone understands the manual and can tell me how to flip this quad... I can't do it even on the original radio, pressing the "360° rotation" button while on the ground put rudder on the aileron stick and rudder doen't do anything anymore... Pressing it in the air does nothing...

I don't know how to capture the gyro calib flag. It must be a really short burst since I can't observe it depiste numerous trials...

[BadRaven]

Eachine E010

Controls (for Mode 2 Throttle Left:-

Flip, Press RH front button, Tx beeps (quietly) then move right stick in direction wanted to flip (times out if not used)

I'll put the rest down in another post!

[BadRaven]

Eachine E010

Controls (for Mode 2 Throttle Left:-

Flip, Press RH front button, Tx beeps (quietly) then move right stick in direction wanted to flip (times out if not used).

"Trim" toggle button under Throttle is not yaw trim as per a normal Tx! Left end is Return to Home (not very good!), Right end is Headless Mode, which they call Careless Mode. This is quad moves to stick regardless of its actual facing direction, so down right stick is always back towards Pilot, etc. Lights on quad change to show mode.

Front left button is "two speed" which is not flying speed, its effectively rate, how nervous the quad responds to Pitch/Roll/Yaw, again there is a toggle, a quiet beep (low rate) beep beep (high rate). This only works when the quad is linked, the std Tx will not beep if there is no quad connected.

JJRC H36 is the same (obviously) but the manual labels are better.

[BadRaven]

Eachine E010

Gyro Calibration is the same as old E010

Turn on Quad Turn on Tx, Throttle up and then back down to bind THEN with low throttle pull right stick down (towards you), then left, when there is a series of flashes.

[BadRaven]

Note: With Rev 5 Flip there is an increased automatic burst of throttle before the flip occurs to try to avoid the quad falling during the flip.

[pascallanger]

I will push the code soon and you will be able to test it by yourself since I can't get the flip to work even on the original radio (i don't understand what I'm doing wrong, it's usually straight forward)...

The problem is that I can't see live the flags being sent by the radio since the payload is way too long. May be I'll try them all to see if I can find something useful from outside.

I haven't tried to change the ID but it will most likely change the hopping frequencies so for now there is only 1 ID.

[pascallanger]

Latest test build is available here: https://downloads.multi-module.org/latest-test/ Doc: https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/blob/master/Protocols_Details.md#e010r5---81 Please test and report.

[goebish]

Thanks Pascal! I'll try to get my hands on the E012 (I've one somewhere) and try to make it work with cyrf6936, I'm not sure why I couldn't get the nrf24 to properly receive cyrf packets before, wrong init values ?

[pascallanger]

I don't have an e012 so I can't help to troubleshoot. But what I can say is that the cyrf is sending LSB first where all the other RF components are sending MSB first. Check my code, this is the last operation I'm doing before sending. Could it be where you failed?

[goebish]

You're probably right, that would explain why it could only properly receive some byte patterns (which were the same if sent lsb or msb first, e.g. 0x00 & 0xff) iirc

[goebish]

Does that mean the nrf24l01 is useless now since we can do 250kbps gfsk with cc2500 and 1Mbps gfsk with cyrf6936, with the advantage of being able to finetune frequency for both ?

[pascallanger]

I haven't enabled freq tuning on the e010 because it worked on my bench without changing anything but yes we could fine tune the main frequency from now on.

There are still 2 things that the nrf does well:

• receiving: last time I tried to receive with the cc2500 I failed... I did receive some stuff but it was unusable. I haven't spent days either but if you are able to get something working please share.
• ack: the NRF is really quick to send an ack right after it has received the payload. This is an issue since most of the other components can't switch that fast. The ack can contain data which is what the OMP and Propel protocols are using.

[pascallanger]

No one providing a test result??? Really.... Since nobody seems interested I won't spend my time to add other IDs or find the missing flags.

[BadRaven]

I'm forced into shielding, cannot travel, and not where my Tx with MM's are, its not through apathy!

[grostim]

Bonjour à tous,

I will give it a try tomorrow.

[BadRaven]

Bonjour, Merci...............

[grostim]

hi again, I tried to flash the test firmware on my irangeX IRX4+ module.

The update failed with the following error :

 ./flash-multi -f ../multi-test-build/multi-stm-serial-aetr-v1.3.1.97.bin -p /dev/tty.usbmodem14101
flash-multi 0.4.3

This program is Free Software and has NO WARRANTY.
https://github.com/benlye/flash-multi/

Multi Firmware Version:    1.3.1.97 (STM32)
Expected Channel Order:    AETR
Multi Telemetry Type:      OpenTX
Invert Telemetry Enabled:  True
Flash From Radio Enabled:  True
Bootloader Enabled:        True
Serial Debug Enabled:      False

Proceed with firmware update? [Y]es or [N]o: Y

Attempting USB upload using dfu-util

ERROR: Specified firmware file was not compiled with USB support.
Flashing this file would make the MULTI-Module unusable.

I have already the updated bootloader (red led blinking fast).

I guess this problem is not related to the test firmware, but i would be grateful if someone could point me in the right direction.

[benlye]

You're using an old version of Flash Multi.

Download the latest version from here: https://github.com/benlye/flash-multi/releases

[goebish]

FYI I got my hands on the E012, now to port the protocol and HS6200 emulation layer from nrf24 to cyrf6936 ... The E015 is using the same transceiver and had the same issue iirc (I've got one as well). I'll report my progress (if any) to the forums.

[grostim]

https://github.com/benlye/flash-multi/releases

You're using an old version of Flash Multi.

Download the latest version from here: https://github.com/benlye/flash-multi/releases

Thanks. I have been able to flash the firmware. I am going to test it right now.

[pascallanger]

FYI I got my hands on the E012, now to port the protocol and HS6200 emulation layer from nrf24 to cyrf6936 ... The E015 is using the same transceiver and had the same issue iirc (I've got one as well). I'll report my progress (if any) to the forums.

Let me know if you need help.

[pascallanger]

Thanks. I have been able to flash the firmware. I am going to test it right now.

right now?

[pascallanger]

I've found additional flags flip, led and calib: https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/blob/master/Protocols_Details.md#e010r5---81 Still unsure of what the function is for the long press on the top right button but whatever.

If someone wants more IDs to be supported, I need original (now unused?) TXs to be shipped to me.

[grostim]

I have made several test yesterday. It's flying perfectly. However, i have not been able to use the "flip" function, but this may be related to a bad setting of my TX. I will investigate.

On Mon, Jan 11, 2021 at 12:17 PM pascallanger notifications@github.com wrote:

I've found additional flags flip, led and calib: https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/blob/master/Protocols_Details.md#e010r5---81 Still unsure of what the function is for the long press on the top right button but whatever.

If someone wants more IDs to be supported, I need original (and unused) TXs to be shipped to me.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/issues/457#issuecomment-757884987, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4K5QYTVB35GZDP4GIOT6LSZLM37ANCNFSM4S6QKN6A .