Eachine E58,

Hi; help me please; I looking for help about protocol for E58 with my T8SG; I can't find who protocol binding

You are not alone. I have the same problem.Anybody out there who knows the answer?
Benny Jensen Pedersen

Has anyone found the protocol for the E58

Seems like no one has found an answer. I can open the stock TX, but would not know what to look for to determine the protocol. Can anyone give me some advice on this.

No markings on the IC.

I attached some pictures of the board.

And this is the other side of the board with the IC visible

I've been looking at this from a few different angles for a while. And it's looking more and more as this machine sets up it's own wifi hotspot "WiFi-720P-51667B" (The final digits may be drone specific) and you can use the JY-UFO and many many other spin off wifi drone control apps designed for other drones that signals might be going over wifi. Tried doing some packet sniffing and getting a lot of Lewei_cmd which led me to a security article about how a lot of these drones are on an open network and can be stolen or information off their memory cards. The drone locks itself onto an IP of 192.168.0.1

www.utdallas.edu/~juniavalente/valente17iotsp1.pdf

but all the lewei_cmd protocols I think are sending video info. Which led me to another article and this guy has done all the hard work.

blog.horner.tj/hacking-chinese-drones-for-fun-and-no-profit/

So it looks like the phone is just blasting out UDP datagrams with roll, pitch, thottle info every few fractions of a second and the drone acts accordingly. I've just connected to it's wifi network used a very simple UDP packet sender from my phone and sent the hex digits "66 80 80 80 80 01 01 99" and it went into launch mode (I was hanging onto it).

So my current thoughts are I've ordered a wifi module to make an arduino that generates the UDP packets based on PPM input. Although I have come across a hackaday project who came up with a proof of concept library that can make an NRF2410+ generate UDP. But I don't know enough about that architecture or the way the Deviation communicates with the chip. But I would assume that the start of the packet is pretty much fixed IP from and to so to simulate the UDP packet would be about how the binary data was written. And certainly I think it would open up tens of these WiFi controlled drones if it could be achieved. I am uncertain if actually joining the wifi network is necessary.

I also intent to set up a wifi hotspot on my PC with the same name and see as I suspect that the remote is just sending out these packets.

Nice no idea if you can do "Wifi" compatability with the current deviated chipsets, possibly need and ESP module?

"Silverware" custom firmware for the Eachine H8 / Bayang drones with NRF chip, has also a nice bluetooth app, while you can control the drone using the original TX controller and at the same time receive telemetry on a Bluetooth app on the phone.

I think my assumption that the TX also joins the Wifi network is wrong as I get no traffic on the wifi network from the transmitter. It may well still use the same packet structure just missing some of the SSID header info and the receiver looks out for both. I have opened them up tonight and managed to get chip ID's for the TX and Drone. The TX has the NXS1040V which doesn't appear currently anywhere but the Drone seems to be based around the PAN159CY which is listed as "Panchip PAN159CY Soc2.4ghz High speed Wireless transceiver single chip microcomputer QFN40" which I think is running a skinny version of linux. I can connect to a Telnet on the drone but haven't got the login details as yet. This chip has flagged up at least one deviation thread with the DM002 Protocol which seems to have the same chip and seems to have had success with the nrf24l01 module. But I haven't read all through this yet. Also found a github using the nrf24l01 module in the multiprotocol TX project to control the Global Drone GW008 which apparently has the same chip. But I guess a lot depends on the firmware. Also noted that there are Data pins on the PCB so serial connection may be possible but I don't think silverware is compatible.

Hello
I want to link my T8SG with Eachine E58. Does anyone know the protocol?
Thank you

Right I've begin playing with using the PPM output of my Devo 7E controller and using a simple and very cheap ESP8266 module the ESP-01S. You'd need a good 3V regulator as well.

www.ebay.co.uk/p/Esp8266-Esp-01-Serial-W...=292736904806&chn=ps

which can be programmed through Arduino-IDE and using a FTDI serial adaptor or there are cheap usb programming devices designed for these modules. It is no where near the true practice of deviation as it is leveraging the WiFi aspect of this and potentially applicable to many other wifi drones. I've not actually tested in the flesh as yet but I've compared the UDP packets that I can get this to produce and that the Phone UFO-WIFI app produces and they seem to be comparable. I'll need to do some work with timings and as I say its using the PPM output although these modules essentially have an SPI interface as I understand it so they could be programmed I believe to be modded into the controller. My E58 is currently in pieces but I'll try to get it back together and test soon. I've attached the ardiono-ide sketch as a text file. My code is sloppy and leveraged a ppm receiver code from the following instructable. I've also included my Devo7E model file with how my mixer channels are set up for the PPM. The code takes values for HOLD0 to trigger the unlock motors state of the drone which should then make stick movements active. It could also be switched for one click launch I guess and other switches could be used for rate modes etc. The number of PPM channels in theory could scale up a lot.

Further to this I've hooked the boards up enough to test. I'd got the wifi wrong with _ instead of - and I think the frequency of the UDP packets is too high and possibly causing a backlog. But I got it to fire up and able to hear throttle changes on moving sticks. But it'll be a bit of testing yet before I put the probs back on. There is no bind procedure other than joining the wifi and the light sequence on the quad changes as soon as packets are being sent.

The limits of going over wifi will always be less reliable than propitiatory 2.4GHz RF signals and if wifi disconnects there would be an inherent delay to reconnect and I haven't added a reconnect function yet. I've managed to mod an external antenna onto one of these PCB antenna traces before which would improve range. I'm sure ESP modules with SMB connectors could be purchased.

First test with props off and things seem to be working well. ESP-01 chip still being USB powered while I refine the sketch. But it seems to have potential. In the future the ESP-01 could be powered by a battery with a 3V regulator and just 1pin for the PPM signal so would be quite a small addon.

Currently the switch unlocks the motors but the Flight controller doesn't really go into launch mode until the throttle passes into positive zone. Think I wish to do a bit more testing and checking the channels before I launch test it.

Well it works as is. Other than a few trim errors the first tethered flight seems really responsive. Unfortunately a little accident and seem to have burned out a motor before I could record it properly. I should try and wildcard the WiFi SSID as I think the last part will be drone specific. In theory other drones that use the numerous branded WiFi apps could also leverage this and possibly the WiFi SSID might be usable to have the ESP8266 programmed to auto recognize which variation of protocol to use. As I think some use different start and stop bits and possibly different command bytes. But as far as basics go it works. I'll have to try and replace the motor before I can test it.

As a side not there are better ESP chips which have an analogue pin. I've seen proof of concept that this could be programmed to output an AV signal. I think that the video stream is broadcast encoded with FFMPEG. I think it is well beyond me but feasibly the chip could take the broadcast video packets and have a line output for video to goggles. Which would still have all its existing latency problems and artifacts. Although I suspect it would put too much processing load on a single chip already using interrupts for the PPM.

I seem to have lost Rudder after the nightly builds for some reason and trim is a bit out which seems to make it a bit skittish. But a kind of proof of concept that the ESP module can work. Yet to do any sort of range tests.

Got rudder control back. Strangely the last couple of nightly builds once I calibrate my Devo 7E I loose all yaw resolution. Copied my backed up TX.ini and have full range again. Tried watching this video back at quarter speed and there doesn't seem to be much latency on stick movements. Getting a couple of right hand roll glitches which may be the way the ESP is translating the PPM. But they are minimal and even out over the next couple of pulses. Think I may need to add some Expo on the sticks but until I'm in a wider space and can test the full bank. My hope is to cycle through different byte options on the command byte with the small hope there is a hidden command that will switch it to acro. Really not likely. But yeah having proper stick control seems to make it so much more responsive but I'm not getting much of its attempting to hover character which may just mean I need a bit of a dead zone on the input and the gyro calibrating.

Nice job!

Maybe you could use the serial prototocls like sbus or pxx instead ppm?
Or maybe you could even connect via usb port HID device?
or even connect devo to a laptop via HID and have laptop transmitter?