Eachine e129

[undingen]

Hello I bought this helicopter recently and would like to add support for it.

I opened up the transmitter and receiver unfortunately it seems like this is not one of the standard ICs :(. (Sorry for the bad photos but I found it really hard to read/photograph the label on the IC):

Transmitter: (looks like RF2518 to me - could not google a datasheet)

Receiver: (looks like RF2500 to me - could not google a datasheet) (Maybe there is another chip hiding besides the barometric sensor under the foam?!? I left it on because I thought it likely only the IMU)

Does anyone have seen this before? What can I do to reverse it or hopeless case? I do have HackRF if this could be useful.

[pascallanger]

Never seen this before. Since you have a HackRF, find one channel where the TX is transmitting, do a capture on that specific channel and post the file here.

[pascallanger]

Any progress?

[pascallanger]

I have access to a E129. The RF chip is sending payloads using GFSK with a bitrate of 1Mb. It uses 4 RF frequencies in normal mode: 60,73,75,65. It sends 2 times on the same channel with 1260µs in between then switch to the next channel. Each channel change is separated by 5200µs. The bind is done on channel 45 with the same timing as normal just always on the same channel. Addresses are on 4 bytes: bind = E2,32,E0,C8 and normal = C1,22,05,A3 The payload is FEC encoded same as the component of the E010R5 does. Same RF chip but the markings are different.

The issue compared to the E010R5 is that the payload is scrambled... Most likely a constant xor string is applied on top of the payload making it unreadable. Since we don't know what is sent it's going to be hard to go back to the source...

There might be a hope in the sense that we can see which bits are changing for the control for which we should therefore be able to find the xor value. If the CRC is done after the xor is applied then we should be able to alter the content, calculate the CRC and make it get through even without knowing what is in the payload.

[pascallanger]

The good news is that the CRC is calculated on the XORed payload and then it is XORed with AE E4. So I should be able to reverse this protocol.

The not so good news is that the NRF can only read the first 32 bytes of the payload which is 74 bytes long so 42 bytes that I can't see using this method. From my tests I only see the Aileron channel which is coded on 10bits shifted and xored, all other channels are not seeable. 2 ways to move forward:

• try to receive the signal with the cyrf
• ask help from @goebish on how to decode GFSK using GNURadio with my PLUTO SDR and C like I've seen in his videos ;-)

[goebish]

If you can use the Pluto SDR with GNURadio using my program should be (almost) straightforward: https://github.com/goebish/XN297_dumper You'll have to modify the gnuradio flowgraph first because the preamble detection is for xn297 (011100010000111101010101) ... and in the C (Qt5) code you'll have to rewrite the decode functions since they're made for xn297 as well.

Just ask if you need any specific info :)

[pascallanger]

@goebish I have your flowgraph working with the PlutoSDR and I can see the XN297 decoded data on the graph (once enabled) using Bayang as a source for now. Moving to the app.

[goebish]

This is a Visual Studio project (.sln), to build as it is you need Visual Studio + Qt VS Tools (https://marketplace.visualstudio.com/items?itemName=TheQtCompany.QtVisualStudioTools2019) + an installation of Qt5 for msvc

[goebish]

... or if you don't (or can't) use this project, all you need to do is listening to udp port 1234 on localhost (when the flowgraph is running). Each captured bit is sent as a byte (0x00,0x01), and the first bit after preamble detection is masked with 0x02 (0x02 for a 0, 0x03 for a 1)

[pascallanger]

... or if you don't (or can't) use this project, all you need to do is listening to udp port 1234 on localhost (when the flowgraph is running). Each captured bit is sent as a byte (0x00,0x01), and the first bit after preamble detection is masked with 0x02 (0x02 for a 0, 0x03 for a 1)

Thanks, this is what I've done and it's working to receive the Bayang payload. I'm now going to try to capture the E129 payload, stay tuned.

[pascallanger]

So no problem to receive the E129 payload of 74 bytes. Here is an example after the FEC is removed: DF	38	A4	33	D8	C7	6B	76	2F	B5	28	81	9B	A3	69	55	06	D2
len like E010r5=0x0F?	bind indicator? 38/3A	--	--	--	--	--	--	--	--	--	--	--	--	check	constant?	CRC16	CRC16

All this is XORed so nothing can be read directly.

[pascallanger]

Bind packet:

DF	3A	F3	F6	5B	FE	A2	4F	6D	F4	3B	FC	71	A3	1C	55	1B	39

[goebish]

It's believed that the "scrambling tables" of those chips is not hardcoded but are rather the output of an 9 bit lfsr with xor taps or something like that (some chips such as the hs6200 allow setting the seed). see https://mrmekon.tumblr.com/post/17824495815/rf-transmission-whitening I tried to crack it for XN297 (just for fun ...) but I didn't try hard enough ...

[pascallanger]

On a total of 18 bytes, I've found so far 10 XOR values.

[pascallanger]

XOR table

From the data I have captured I can't find all the payload XOR values. But I can build the xor values with some constants in the payload which works.

Here is the xor table I came up with: D0	9E	53	33	D8	BA	98	08	24	CB	3B	FC	71	A3	F4	55	AE	E4
unk	unk	--	--	--	--	--	--	--	--	--	--	--	unk	--	unk	--	--

On 18 values I'm pretty sure 14 are valid. I've selected the 4 unknowns to match the most likely payload values but this is a guess.

Bind packet with the XOR table applied

0F	A4	A0	C5	83	44	3A	47	49	3F	00	00	00	00	E8	00	B5	DD
?payload len?	?bind mode?	addr0	addr1	addr2	addr3	rf_ch0	rf_ch1	rf_ch2	rf_ch3	--	--	--	?00?	check	?00?	CRC16	CRC16

Values with question marks are the guessed most likely content.

rf_ch are the RF channels used in normal mode which needs to have 2 added. 3A 47 49 3F => 3C 49 4B 41

addr is a bit reversed and byte swap of the normal address. Bit reverse of A0 C5 83 44 -> 05 A3 C1 22. Byte swap 05 A3 C1 22 -> C1 22 05 A3 => address used for normal packets

check is the sum of all bytes before it

Normal packet with the XOR table applied

0F	A6	F4	00	00	7D	F3	7E	0B	7E	13	7D	EA	00	9A	00	9E	F8
?payload len?	?normal mode?	Rate	Mode 1/2	take off/land/emergency	Trim Ail (6bits)/Ail	Ail	Trim Ele (6bits)/Ele	Ele	Trim Thr (6bits)/Thr	Thr	Trim Rud (6bits)/Rud	Rud	?00?	check	?00?	CRC16	CRC16

With that said the protocol can now be implemented ;-)

[pascallanger]

I can fly the E129 ;-)

[goebish]

Good job!

Someday I really have to dive into Linear-Feedback Shift Registers, it shouldn't be very hard to brute force the seed and taps of those generators once we have a few (or most for the instance!) known output values as you have here.

[pascallanger]

Even multiple IDs are working. Ok I've only tested my global ID and associated random freqs.

Trims can't be done through the AETR trims otherwise you can't arm it anymore putting the sticks down and outwards... I'll therefore add separated channels for the trims. But I've been able to trick the calibration by adding plenty of papers underneath one side of the landing gear so now it flies straight with no trims.

[pascallanger]

Since I've seen this component 2 times in a row, I've now added an emulation layer called RF2500.

[pascallanger]

E129 protocol is available in v1.3.2.3. The test firmware is available here: https://downloads.multi-module.org/latest-test/ Please test and report.

[goebish]

[OOT but still cyrf related] I've to confirm with an actual transmitter (stored during winter) because I'm only testing with a raw module on the bench but I think I've the E012 (HS6200 transceiver) working with CYRF6936 ! You made me want to get back to it 😛

Also, I started playing with LFSRs, I've not been able to reproduce the xn297 or hs6200 XOR sequence yet but I'm having the hang of it, perhaps I can succeed with a bit more work ...

[pascallanger]

If it's working fine then we can create a separate emulation layer like I've done with the RF2500 and update all the protocols using this component (there is only a few).

[goebish]

I will, I've already removed nrf24 versions of the E012 and E015 in PROTO_E01X since they've never been working fine. I've both. Work in progress https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/compare/master...goebish:e012_cyrf6936?expand=1

[pascallanger]

I have reports that it works for both the E129 and E130 so this protocol is done!

[azkingcreator0912]

Hello I bought this helicopter recently and would like to add support for it.

I opened up the transmitter and receiver unfortunately it seems like this is not one of the standard ICs :(. (Sorry for the bad photos but I found it really hard to read/photograph the label on the IC):

Transmitter: (looks like RF2518 to me - could not google a datasheet)

Receiver: (looks like RF2500 to me - could not google a datasheet) (Maybe there is another chip hiding besides the barometric sensor under the foam?!? I left it on because I thought it likely only the IMU)

Does anyone have seen this before? What can I do to reverse it or hopeless case? I do have HackRF if this could be useful. Can you find the value of the 2 smd capacitors and the pins of the reciver ic and the pins they are connected to the capacitors are covered by the antenna cable in the picture so i cant find how they are wired. i also have the same pair of transmitter and reciver chip set in which i accidentally broke of the first cappacitor and i dont know the value

[pascallanger]

I don't really understand, the e129 is supported now for me than two years I'm sure... Protocol e129 https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/blob/master/Protocols_Details.md#e129---83

[azkingcreator0912]

does anybody know the value of these 2 smd capacitors beneath the antenna

[yakacm]

I know this is years old, but just wanted to say thanks for your work. The E129 protocol works so well on my TX16S, I fly the thing for hours indoors. I particularly like the way the E129 has trim available on ch7, ch8 and ch9. The E129 is a very cheap heli, so the trim is awful on the thing, I have aileron and elevator trim channels set up on the sliders on the shoulder on the TX16S, which means I can trim easily on the fly without taking my fingers off the gimbles. The E129 won't arm if you have too much trim set on the normal trim switches so doing trip via the sliders has the added bonus that you can arm and fly the thing with trim set.