Eachine EAT15 car support? #1054
Labels
Comments
|
Without access to one of these cars I can't really do anything...
|
|
Thanks for the info. I will take it as an backup option. At first I will try to look into it myself, at least it's a more fun and opportunity to learn something new :). And I will also donate the project according to my possibilities, because I like the project. You can keep this issue open as an tracker for others searching for the car support. I could also share here my progress and ask for help if I got stuck, because I am quite familiar with the RF engineering and SDR (and have the 2.4G sniffing equipment), but I am a real newbie in the RC cars and their 2.4G protocols. So it will take time. Or feel free to close it if you prefer clean issue tracker. I will open PR if I would have anything usable. |
|
You can use your multi module to scan and possibly listen packets over the air using a debug firmware and the XN297Dump protocol like on this other issue: #1048 (comment) |
|
Thanks for the tip, I didn't know it. |
|
I had trouble to flash the debug firmware from the release mm-stm-xn297dump-ftdidebug-v1.3.4.0.bin. On the radio it shows error: The other firmwares from the release flashed and worked OK, including the usbdebug variant. Unfortunately, my module doesn't have connected USB lines to the STM32 and there is built-in CP2102 bridge, so I need the FTDI debug firmware variant. I will try to compile it myself |
|
@yarda we currently don't have a way to compile an FTDI debug image which can be flashed from the radio. I'm working on it but have a few issues to resolve in the build process first. For now you have two options:
|
|
@benlye thanks, it's pretty cool. Your debug firmware works as expected. Maybe you could pin it somewhere or mention it in the readme/dump docs? I think there could be more people hitting this. |
I was tempted to flash the ftdi debug firmware from the release through the USB adaptor, but I discarded this idea due to the failed firmware check in the radio. Maybe it could be also mentioned in the readme. |
|
The protocol seems pretty easy, channel 45, 250k: I need to capture the bind sequence, I had some trouble with it, maybe it is (I am not 100 % sure): It seems it has also telemetry built-in and probably returns car battery status to the remote, but currently I have no idea how to reverse it. |
|
I don't know whether it sticks to channel 45 or can autoselect different channel e.g. in case it's used/noisy, I tried several times and every time I got channel 45 (I will also recheck). It seems there is no hopping. |
|
The model is autobound each time the model and remote is switched on. |
If I powered on the car (not the TX) I dumped nothing. If I powered on the TX (not the car), I also dumped nothing. If I explicitly listen on channel 45 and power both the car and the TX I got the following: So IMHO the address is F6 96 01 00 81. |
|
It seems the channel can change, after dozens dumps (steps are: power on the car and TX, control the car, power off the car), I got the following: I am not sure what the channel 67 is, noise, interference (remotes too close)? But it's now probably on channel 59. |
Correction the packet structure is usually easy. The difficult part is usually the ID and associated RF frequencies(y), bind negotiation and sometimes timing.
That's a good start.
I highly doubt that it has anything to do with a bind packet...
You are not sharing any dumps so can't see anything of what's really going on or help...
It can't autoselect... There must be a negotiation or pre established frequencies that are switched to in case of interferences.
That's a wild statement. I'm wondering how you can be sure of that... May be the TX sends bind packets each time but the car might remember the TX and connects to it without going through bind... Without experimenting I can't say.
You are not saying what you do to "dump". But I can tell you that either the TX or the car is sending something.
I don't think that's anything useful.
The frequency change might be due to a detected interference
First time you are sharing what you are seeing. The output timing on channel 59 is not consistent and a really low packet rate. So something is not right. |
|
First, few questions:
Ok so let's capture the bind packet first to see the content:
|
|
Thanks for the reply and tips.
I guess channel 59 can be interference, I did the dump when the remotes were cca. 50 cm far apart. If they were cca. 2 meters far I was seeing only channel 45. I will retry multiple times to be sure here. I don't have anything more at the moment, all the dumps were similar as the one I provided and didn't reveal anything more (apart the sticks mapping).
Manual quote: After the car power is turned on, the transmitter and the car will carry out automatic frequency matching. When the indicator light of the transmitter and the car lights are always on, the frequency matching is successful. In the process of frequency matching, the car lights will flash rapidly. At this time, the gyroscope is being calibrated automatically. Please place the car on the level ground to complete this operation. After calibration, the car lights return to normal. Full manual for the reference (it's for UDIR 1601, but IMHO it's the same car, I will recheck with the EAT-15 original manual when at home):
cca. less than 2 seconds, I will measure it precisely
yes and also the car battery status
OK, thanks for the tip, I will try the manual scan, that's the only thing I haven't tried yet. |
There are things you didn't share like the output of channel 45 with the car telemetry.
That could mean that the bind packets are sent every second or 2 seconds. Which is why you miss them with a quick scan.
Please post dumps of the slow manual scan of the tx on only, car on only, and both car and tx on. That will give hopefully a picture of what's going on. |
|
It's the first time I am using the MULTI-Module dump feature and I am still learning, so please be patient :) I like the project, so I sent a small PayPal donation according to my possibilities, get a beer or two on me :) I can confirm the EAT-15 manual is nearly the same to what I linked. In the EAT-15 printed manual some pages are reordered and formatting differs, but the information there is the same, including the text about the frequency matching which is literally the same. The radio and HW seems to be the same on all cars labeled UD1601-UD1608 / PRO variant (and probably also the SG1603-SG1604 variants and maybe others). The only visible difference on the cars is probably the different body shell and different shock tower assembly, but this can be easily cross replaced. I measured time of the bind process. It usually takes cca. 1 - 2 seconds. The transmitter knows if the car is switched on and in range and if the battery level on the car is OK, this is signaled on the transmitter. Dump of the manual channel scan, at least 10 seconds on the channel (usually more), transmitter (TRX) on, car off, not bound: If I understand it correctly the following is the bind request with the TRX address F6 96 01 00 81? Dump of the manual channel scan, at least 10 seconds on the channel (usually more), transmitter (TRX) off, car on, not bound: Unfortunately, somewhere around channel 50, the car battery died :) and I didn't have the charger with the car :). I will charge the battery over the weekend and rescan on Sunday. Earlier, I was able to do few scans with TRX on, bound to the car, car then switched off, I did 2 successive rescans without switching on the car: And another one, again TRX on, car switched on, bound, car switched off, two sucessive rescans without switching on the car: So it's still the same channels. Is it possible it's doing some sort of very slow FHSS? According to the way the control sticks and checksum are coded I expect it to be something very simple. I will redo the manual scan with the TRX off / car on ond Sunday. Then I can manually scan the channels 42, 44, 45, 51, 52, 58, 59, 66, 67 and while listening on each channel try to bind the car to get the full binding sequence. Am I right? Or should I do different thing? |
Sorry if I sounded pressing to get the data. It's just that you need to share as much details as possible to get to the bottom of it.
Thanks!
The TX initiates the bind by sending it's ID and at the same time sending data. I think the car might not reply to the TX bind packets but instead to the normal packets by sending telemetry back which indicates to the TX that the car is there and therefore exits bind. The timing and RF channels are still a bit fuzzy, I need to dive in the data to see. The bad CRCs and the channels receiving low number of packets are usually harmonics or crosstalk. It's kind of usual with the NRF24L01 and noise we need to deal with... If you have a spectrum analyzer, sure check which channels are really in use and if you can get channels usage overtime that could be perfect.
TX off and car on is not going to give anything since the car seems to only respond to the TX. |
|
Using XN297 250K Enhanced/Scrambled Bind packetsBind packets alternate with normal packets Normal packets250K C=45 Enhanced pid=1 S=Y A= F6 96 01 00 81 P(15)= 08 64 50 00 00 00 00 00 00 00 32 A4 00 00 92 P[0] = 08 = data packet Telemetry |
|
Ok I knew I've seen these packets before... That's the Pinecone protocol which I've failed to reverse the first time... May be with your additional TX/RX and dumps we will be able to get to the bottom of it. If I remember I was able to bind the car, get answers from the car (telemetry) but never found how to control it = the LED on the car kept blinking. |
|
Can you open your tx and check if you have a separated RF chip? The pinecone tx is an all in one so no way to spy the spi bus... |
|
It has the FCC ID, so here are the full docs (I like the US FCC guys :): As the applicant name there is written: UDIRC TECHNOLOGY CO., LTD. According to the internal photos, it's a single chip. More interesting information from the docs: Regarding the RF: I guess the channel numbers maps to the last two frequency digits, which means channels: 45, 52, 59, 67. They also have nice spectrum screenshots for all used channels, so probably no need for me to duplicate their work :). But maybe I could use the SDR to find the channels sequence order. |
|
More dumps: Manual channel 45, while listening, car switched on, TRX switched on: I guess the following is the telemetry? Manual channel 52, while listening, car switched on, TRX switched on: Manual channel 59, while listening, car switched on, TRX switched on: Manual channel 67, while listening, car switched on, TRX switched on: Auto scan, car on, TRX on: Identifying Sticks and features returned nothing. |
|
Correction, from the photos it seems there are three chips near the antenna. |
|
The TRX from the FCC photos has three more trimmers, maybe it's for three more channels that is unused on my model and hence the 00 in the packets. |
Correction of the correction, my TRX has single chip: PAN186CV. Not sure what are the other two chips on the FCC photos. |
|
It's probably PANCHIP, datasheet in chinese: Machine translated datasheet: The datasheet doesn't seem much useful. |
|
With the SDR I can do 16 MHz bandwidth PHY GFSK dump, unfortunately, this beast has over 22 MHz bandwidth, so I am unable to capture the whole hop sequence in the realtime :). |
|
I probably got the difference of the TRX shown on the FCC site. In the initial version for the certification they probably used 4WD version of the TRX. It has 4WD mode switch and status LEDs for the modes (front drive steering, rear drive steering, front/rear drive steering, front/rear drive steering reversed) and in addition to the dual rate / trimmer it has also front steering and rear steering trimmers. These are probably causing the most of the zeroes in the payload from my dumps. |
|
And the PAN186CV doesn't have enough ADCs/pins, so they used external ADCs for the trimmers, hence the two more ICs on the FCC photos. |
If necessary I could probably borrow SDR with wider bandwidh from the local university or I have HF SDR with cca. 30 MHz bandwidth and I could homebrew 2.4 GHz downconverter for it, but both approaches would require some time. |
Or maybe I could sniff 2-3 successive channels per time. I suppose the hop sequence is static with the constant delay between hops, so from multiple sniffs I should be able to verify the hop sequence. I will try to play with it during Tuesday. |
|
The scans with both the TX and RX on seems to show a few things:
Based on these assumptions, I think I could try to code the behavior I've described. |
|
Using XN297 250K Enhanced/Scrambled Bind packetsAddress = 01 03 05 07 09 Bind packet from another TX: P(15) = 01 D0 06 00 00 81 00 00 00 69 5F C8 00 00 E8 Notes:
Normal packetsAddress = F6 96 01 00 81 / D0 06 00 00 81 TelemetryRF channel -> same as normal
Telemetry packets seen: Getting this when using a bound TX ID but no control: 01 03 03 FF FF B8 CF 0A 6C 37 BC 31 DF 06 78 |
|
I guess the |
|
For the car telemetry, we will see when we can receive them within the protocol. For now, no need to spend time on this... |
|
I can see in my code that I already tried to send normal packets to only one channel... The only thing the code is not doing is to alternate bind and normal packets. But if I remember the car was replying with P(0) to the normal address meaning it took the bind info. |
|
I will try to build the test code and will give it a try. Is there anything special I need to do for the STM32? Other than installing the board into Arduino IDE? I will also try to provide the PHY GFSK dumps. |
|
I've pushed my latest code and renamed the protocol from Pinecone to UDIRC. I can't test anything and doubt it will work as it is. |
|
I can't push to github anymore... It is stuck with the message "Pushing to origine. Please hang on"... Since the latest windows patches some stuff aren't working anymore. Not sure what I should do as I can't really find anything useful online. |
That's sad. Unfortunately I cannot help, I am on Linux. In the meantime feel free to send me the patch (or pastebin somewhere), I will experiment with it. It will be the first time I will build and cable flash the firmware. I have stm32 MCU. If there are any tips, best practices which could save me some time, please share. |
|
Using git in command line works but not using the GUI... The repo is now up to date. |
|
One question: As far as I understand, when this protocol here is implemented, also the Pinecone protocol should work (see #952) right? |
|
Yes same troublesome protocol... |
|
I sniffed the GFSK PHY. I can confirm the channel sequence is: |
|
Was the car powered on during your observation? |
It matches what I've found and my code:
I assume the car was on, correct?
So your observations match with the prior dumps if the car was on. |
|
No, the car was switched off, unpaired, just the TRX was on in the binding mode. It was my first attempt to correctly setup/fine tune the GFSK demodulator. I will provide detailed information and probably also some signal timing sketches later. For now I am able to demodualte the signal and I can also see the XN297 packets preamble It's also interesting that cca. 1/3 of the packet on the PHY is some dummy prefix with more or less stable sinus signal which is demodulating to the stream of FFs. I guess it's for temperature stabilization of the TX, because it fluctuates a bit (mostly at the beginning). It's probably there to allow usage of cheaper oscillators. |
|
I think I will be able to distinguish the individual parties according to the different RSSI, so it should be clear what's the TRX packet and what's the car packet. |
|
What hardware/software are you using? I'm now back home and can test on the RX I have. |
|
If I turn on the original TX, turn on the RX, turn off the original TX, send with my module packets with the same ID, I can control the car. |
|
After spending hours, the RX is finally accepting my normal packets!!! You need to "ack" what the RX is sending. The "ack" is done by sending a packet with no payload P(0). |
USRP / GNURadio |
Good job. I will play with it during Thursday. I will try to sniff the telemetry when battery is depleted over the weekend. |
|
Never had to send an empty payload in enhanced mode. There was a bug in the emulation layer that I've fixed (2 bits were not getting xored). I don't know how the TX decides to switch from one RF channel to another. I'm wondering if it hops to the next channel when it doesn't receive telemetry for a couple of packets. So if out of 50 telem packets you receive less than let's say 10 you switch. Finding the telemetry flag that indicates low batt is easy. I'll take care of this. |
|
Using XN297 250K Enhanced/Scrambled Bind packetsAddress = 01 03 05 07 09 Bind packet from another TX: P(15) = 01 D0 06 00 00 81 00 00 00 69 5F C8 00 00 E8 Normal packetsAddress = F6 96 01 00 81 / D0 06 00 00 81 TelemetryAddress-> same as normal At least one telemetry packet must receive an ack (packet with an empty payload P(0) ) for the receiver to consider the connection established (same goes for the original TX). P[0] = 01 = bind, 08 = normal, 10 = telemetry |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In the recent firmware 1.3.4.0 the EAT14 support was added (XK/cars). Any chance to add support for the quite popular EAT15 car (also known as UDIRC UD1603)?
The text was updated successfully, but these errors were encountered: