search

pascallanger / DIY-Multiprotocol-TX-Module

Multiprotocol TX Module (or MULTI-Module) is a 2.4GHz transmitter module which controls many different receivers and models.
https://www.rcgroups.com/forums/showthread.php?t=2165676&goto=newpost
GNU General Public License v3.0
1.65k stars 439 forks source link

Eachine E016H v2 #469

Closed little-Beppo closed 3 years ago

little-Beppo commented 3 years ago

Hello, I'm new here. I've already dealt with the topic of multi-protocols a little and now my question. I bought the current E016H, but I cannot bind it with the DIY-Multiprotocol V1.3.1.69. I found the chip "FC298TX GS50XFN411" in the transmitter. Is this the wrong version or the wrong protocol? Please help me . Thank you

little-Beppo commented 3 years ago

P1001317-sm that is the picture from the transmitter chip. let me know if you need more information's.

benlye commented 3 years ago

Are you trying the correct protocol? I have an E016H and it works fine with the E01X protocol, sub-protocol E016H.

little-Beppo commented 3 years ago

Yes I think so. before I wrote the treat here, I asked goebish. He mean: "There's not much I can do. Your best bet is asking on the multi protocol thread for some guidance on dumping xn297 packets, but this is a unknown chip, no idea if it's xn297 compatible or not." That's what I'm trying to do here now

little-Beppo commented 3 years ago

are there instructions for reading out the log?

pascallanger commented 3 years ago

Load a debug firmware, get a serial connection to the module and run the XN297Dump protocol in auto mode: https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/blob/master/docs/Advanced_XN297Ldump.md

benlye commented 3 years ago

I opened mine up for comparison and, yep, it's a slightly different board with a different IC.

Here's the original, for reference...

little-Beppo commented 3 years ago

Hello,

First of all I want to say thank you for your support. The next thing is, my English is not as good as it should be, so the request again

I'm not sure if I got that right. should I load another FW into the 4-in-1 module? In order to generate a dump file with it? Is it possible to use the USB interface on the back of the module to load it into the module with the Arduino? I've already updated the boot loader. Or is it possible with the falsh-multitool, cause i get this DFU mode not working with the Arduino. flash-multi

benlye commented 3 years ago

Use Flash Multi to flash this firmware file to your module: https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/releases/download/v1.3.1.77/multi-stm-xn297dump-usbdebug-v1.3.1.77.bin

You then need to use the Serial Monitor in Flash Multi to see the debug output from the module.

  1. Flash the module using Flash Multi
  2. Turn the radio on and configure a model using the XN297 Dump protocol (protocol number 63)
  3. Open the Serial Monitor window and look at the output

After flashing the debug firmware the module will wait for a serial monitor connection for 30s after power on. During this time the red LED will be double-blinking.

little-Beppo commented 3 years ago

Thanks for your support, today I'm busy. I'll try it tomorrow.

little-Beppo commented 3 years ago

Hello benlye, i am sorry to say, i is not working correct, so i was flashing the dump FW but i can't get the tool in the Monitor Mode. Dump_mode The red LED is flashing fast the whole time. Whats my mistake?

pascallanger commented 3 years ago

The module is in bootloader not in normal mode... Unplug the USB cable, power on the radio wait that the module is powered then plug the USB cable. At that stage a com port should appear and then open the monitor.

little-Beppo commented 3 years ago

i think there is the USB-Driver missing.

pascallanger commented 3 years ago

The fact that the module fast blinks indicate that it is in bootloader because it has been powered with USB plugged in first. There are no drivers for the com port...

little-Beppo commented 3 years ago

ok, now its working. should I now turn on the drone and read out?

little-Beppo commented 3 years ago

so here is the result. I'm not sure what the log file should tell me? Dump_.log Dump

pascallanger commented 3 years ago

ok, now its working. should I now turn on the drone and read out?

Power on the E016H TX, exit from bind (usually throttle up down), leave the TX untouch. On the radio select the XN297Dump protocol, sub_proto Auto and watch the screen if there is any packets being received.

pascallanger commented 3 years ago

so here is the result. I'm not sure what the log file should tell me?

This does show that no XN297 compatible packets have been received. Was the TX powered on out of bind mode?

little-Beppo commented 3 years ago

no i'm so poor, i powered the copter.

little-Beppo commented 3 years ago

now i switched on the remote control of the copter and activated it in normal mode. Then the dump started, but it looks like no connection can be made here either. Dump_tx.log Dump-tx

little-Beppo commented 3 years ago

is it possible that there is a problem with the 9XD that xjt is flashed as an EU version?

pascallanger commented 3 years ago

is it possible that there is a problem with the 9XD that xjt is flashed as an EU version?

This comment makes no sense

pascallanger commented 3 years ago

now i switched on the remote control of the copter and activated it in normal mode. Then the dump started, but it looks like no connection can be made here either.

Probably not XN297 compatible chip. Need a SDR to investigate further. If you want you can send me the TX + quad for further investigation otherwise it's a dead end.

little-Beppo commented 3 years ago

Send only the TX or also the copter? so i need your address.

little-Beppo commented 3 years ago 
is it possible that there is a problem with the 9XD that xjt is flashed as an EU version?

"This comment makes no sense"

that's probably true, was just one thought
little-Beppo commented 3 years ago

yes i can send you the TX + quad, let me know your address.

pascallanger commented 3 years ago

yes i can send you the TX + quad, let me know your address.

Contact me on the email address used for the donate button or by MP on rcgroups.

pascallanger commented 3 years ago

I've finally received an E016H. Here is the phase of the RF signal captured using SDR for a bind packet: Capture

This is not a XN297 core, neither a NRF from the packet layout. The RF component is doing GFSK @250Kbps. The signal is not clean which is a bit of a worry or at least it's not fully what I'm used to see with GFSK... The good news is that scramble is not enabled which gives some hope to reverse this protocol. So, it sends a bunch of 55 or AA as a preamble followed by some data. I've decoded the signal manually since my normal script has a hard time to figure out the bits (ref comment above): E7 E7 E7 E7 5C A0 81 C9 B0 4C 4C 4C 4C 0 0 0 64 69
ID ID ID ID control field -- -- -- -- -- -- -- -- -- -- -- CRC CRC

First, there is a catch since it's missing 1 bit at the end for the CRC but that could be my human mistake reading the 0s and 1s. It could also be that there is a control field which is usually the payload length, pid and ack/no ack flag which is making the payload usually shifted by a couple of bits. Second I don't know what the convention is, so the bytes could be inverted (E7 becomes 18) and also swapped since I've used MSB first (A0 becomes 05). The first 4 bytes are interesting since they could be the 4 bytes of the bind address E7 E7 E7 E7 (note E7 is the same if you read it with MSB or LSB). Using these 4 bytes (or 18 18 18 18) I should be able to get the NRF to listen to the message and get live readings. More to come...

pascallanger commented 3 years ago
The NRF has also a hard time to receive the signal properly, there are loads of errors in the dump... Here is one line which I think is accurate (I might be biaised by the fact that this is what I've deoded previously ;-) ): 5C A0 81 C9 B0 4C 4C 4C 4C 00 00 00 64 D2 <- the CRC is 64 D2 where I was reading 64 69 which is strange since I've verified and can't find the same result but anyway... Like I was thinking there is a control field with a pid which counts on 2 bits 0,1,2,3,0,1... : P: 50 A0 81 C9 B0 4C 4C 4C 4C 0 0 0 64 D2
P: 54 A0 81 C9 B0 4C 4C 4C 4C 0 0 0 64 D2
P: 58 A0 81 C9 B0 4C 4C 4C 4C 0 0 0 64 D2
P: 5C A0 81 C9 B0 4C 4C 4C 4C 0 0 0 64 D2

50,54,58,5C: xxxxyyzz where yy is the pid. Also the pid is not contained in the CRC since the CRC is constant.

Going from there I've tried to apply on the payload the standard CRC16_CCIT_ZERO which has a polynom of 0x1021 and bingo!!! The CRC of 0xA0 0x81 0xC9 0xB0 0x4C 0x4C 0x4C 0x4C 0x00 0x00 0x00 gives 0x64D2 !!!!

More to come...

pascallanger commented 3 years ago

A wild guess would be that the address used in normal mode is going to be: A0 81 C9 B0. 4C could be the RF channel if only one is used... But this is a tomorrow thing as it is 1:30am currently so time to go to bed.

little-Beppo commented 3 years ago

Thanks Pascal for the news. Do you think that a solution with the DIY Multiprotocol is possible?

pascallanger commented 3 years ago

Not sure yet, it will depend how well the quad is going to receive the data from the module. I'm going to use the cc2500 to emulate it so we can always try to tune the signal a little.

I also would like to see what your remote is sending. I'll post later a code on GitHub that you can launch the same way you've done the previous dump attempts.

pascallanger commented 3 years ago

The bytes in the payload seem to have their bits reversed and shifted by 1 bit based on the stick values. The address for bind and normal packets is the same E7 E7 E7 E7.

The bind packet is 11 bytes long sent on RF channel 5 0A 02 27 1B 64 64 64 64 00 00 00
Len? Bind? ID1 ID2 T R E A flag1 flag2 flag3
The normal packet is 11 bytes long sent on RF channel 44 0A 20 27 1B 64 64 64 64 00 00 00
Len? Normal? ID1 ID2 T R E A Flag1 Flag2 Flag3

T, R, E and A are 0x00..0x64..0xC8. Flag1: 0x01=Flip, 0x02=Headless, 0x04=One Key Return Flag2: Speed control 0x00:low, 0x01:medium, 0x02:high Flag3: 0x01=TakeOff/Land (momentary switch), 0x04=Emergeny Stop (momentary switch)

pascallanger commented 3 years ago

I'm able to fly the E016H with my TX16S ;-)

goebish commented 3 years ago

Well played !

pascallanger commented 3 years ago

Multi v1.3.1.87 has support for the E016H v2. You manually need to build from source to test it out. It is important to tune the frequency since mine doesn't even bind at 0. On my module and this quad I need to set the RF freq to +80. Only 1 ID is available so you can't have multiple quads flying at the same time (for now?). The protocol details are located here: https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/blob/master/Protocols_Details.md#E016H---80 Interestingly, this quad does not require a centered throttle. You can power it on with throttle at -100%. When you move throttle up the motor will arm. If you keep pushing it will lift off. To land simply lower throttle and it will auto shut off when touching the ground.

pascallanger commented 3 years ago

@little-Beppo Using the latest version on GitHub, can you do a dump of your remote? Notes:

little-Beppo commented 3 years ago

Hello Pascal, thank you for your great work, will test it today or tomorrow.

little-Beppo commented 3 years ago

now i get the module flashed, but i cant make a serial dump, cause there is no XN297 Dump setting for the TX and also no COM-Port for the serial monitor? Do you have any idea whats my mistake? flash_

pascallanger commented 3 years ago

now i get the module flashed, but i cant make a serial dump, cause there is no XN297 Dump setting for the TX and also no COM-Port for the serial monitor? Do you have any idea whats my mistake?

As you can see on your picture, you have a standard build not a debug one: "Serial Debug Enabled: False" On Arduino, Tools-> Debug Option -> then you have to choose the debug type you need for your module. If you have a iRangeX+ then select "Native USB debugging" otherwise you most likely want to select "Serial/FTDI debugging". You'll also have to comment far more protocols for the firmware to fit in Flash...

Have you tried the E016H protocol on your quad?

Pascal

pascallanger commented 3 years ago

@little-Beppo I think you can forget the dump since I've kind of found the rule for the ID vs Freq: Freq=(ID1 + ID2)%32 + 42 But there are invalid values which still needs to be found. For example, freqs 72 and 73 are not allowed, ID1=0 is not allowed. I'm going to poke around to see if I can spot other invalid values like ID2=0 or ID1=FF or ID2=FF or... But it's currently 2am so time to get some sleep...

little-Beppo commented 3 years ago

yes had tested the E016H2v protocol, did not work, Later today I'll try another dump, maybe it will help you to identify the gaps in the ID

pascallanger commented 3 years ago

yes had tested the E016H2v protocol, did not work,

The protocol works. As I said you must tune the frequency to even get a bind. Try to set "RF Freq. fine tune" to +40 or -40. On my module nothing works unless I set it to +40, +80 being the middle value.

little-Beppo commented 3 years ago

Yes, you are right. It works, i have done my first flight with the TX setting below. P1001333_TX setting

pascallanger commented 3 years ago

Great! You still need to tune it since 40 just gets the bind working. Mine ended to +80.

Please test the new version 1.3.1.91 which integrates support for full IDs and report. If you could try a few RX numbers as well and make sure it binds/works each time with this version.

little-Beppo commented 3 years ago

got some problems during the compiling.

Arduino: 1.8.12 (Windows 10), Board: "Multi X-in-1 STM32F103CB (128KB), Enabled, Serial/FTDI Debugging"

c:/users/dumbo/appdata/local/arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld.exe: C:\Users\DUMBO\AppData\Local\Temp\arduino_build_798342/Multiprotocol.ino.elf section .text' will not fit in regionrom'

c:/users/dumbo/appdata/local/arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld.exe: region `rom' overflowed by 16344 bytes

collect2.exe: error: ld returned 1 exit status

exit status 1 Fehler beim Kompilieren für das Board Multi X-in-1 STM32F103CB (128KB).

Dieser Bericht wäre detaillierter, wenn die Option "Ausführliche Ausgabe während der Kompilierung" in Datei -> Voreinstellungen aktiviert wäre.

do you have any idea?

kilrah commented 3 years ago

You must disable serial debugging for flying. Removing it should also make enough room for all protocols to fit.

pascallanger commented 3 years ago

Yes it means that the code does not fit... Disable debug which will free up some space.

little-Beppo commented 3 years ago

Okay thanks

little-Beppo commented 3 years ago

So I've now done some test work with the version 1.3.1.91: RF Freq. fine tune: / Result: +80 / bind ok, bad trim in Ail and Ele, engine speed for flying ok +40 / bind ok, verybad trim in Ail and Ele, engine speed for flying ok 0 / no bind possible -40 / bind ok,, engine speed to slow for flying -80 / bind ok,, engine speed to slow for flying

in my opinion version 1.3.1.89 was better at +40. what did you change?

pascallanger commented 3 years ago

Nothing... Are you really tuning the frequency or doing what here? You don't need to rebind, just find the middle value of the frequency range. Trim on ail and ele or slow motors has nothing to do with bind and freq tune, it looks more like a flat lipo...

Since you can bind on v1.3.1.91 I consider this protocol done anything else is your setup.