Esky Protocol

Hi,

I happened to find this project while looking for some info on DSM2 and ran into the Protocol Stack topic. Really cool what you guys are doing! Anyway, I noticed this post: deviationtx.com/forum/7-development/64-p...-stacks&start=40#623 and I may be able to offer some help.

Esky uses the nRF2401AG in their TX/RX equipment, but the nRF24L01(+) is compatible with it. I've got a couple of $3 nRF24L01+ boards and an Arduino to talk to both the Esky TX and RX and got the entire protocol (save 2 magic bytes in the binding) figured out. Channels, frequency hopping, address and message size, payload, etc. All Esky TX/RX's use the same hardware and protocol and are compatible with each other.

Various models of Esky TXs only differ in physical layout (knobs/switches), the PCBs are identical. Some older TXs have some dipswitches inside which allow you to turn CCPM mixing off, the newer ones are hardwired using zero ohm resistors but the PCB layout remains the same. All TXs are six channel, even the "4CH" which can be modified to support a fifth channel using a potentiometer and a few wires.

Interesting thing to note is that their main PCB outputs PPM to a separate RF board which contains the nRF2401AG. This RF board decodes the PPM and transmits it digitally to the receiver. I guess they didn't want to update their main PCB when they joined the 2.4GHz club.

All receivers are identical as well, save a few pin headers on the 4CH models. The Esky 4-in-1s actually consist of a separate receiver board and BEC/ESC/Gyro board. The receiver board is identical to their 6 CH RX for CP helis, only the throttle and rudder pins are mounted on the back and poke directly into the BEC/ESC/Gyro board.

Long story short: if your project works with one Esky tx/rx, it works with all Esky tx/rx.

If anyone is interested in the technical bits of the protocol, let me know. I can put it here or send a PM, whichever you prefer.

Interfacing the nRF24L01 is easy, there are loads of example code for that floating around on the internet. I'm still working on my own implementation so I'm not posting that until it's done.

But anyways, here's the technical details of the protocol:

For all packets use the following settings:
Data rate: 1 Mbit/sec
CRC: On, 2 bytes
Payload size: 13 bytes
Follow the datasheet on compatibility with the nRF2401:
TX and RX: No Auto Ack (EN_AA = 0)
TX: No Automatic retransmission (SETUP_RETR = 0)

For binding packets:
Channel: 50 (2450 MHz)
Address width: 3 bytes (SETUP_AW = 1)
Address: 0x00, 0x00, 0x00

For data packets:
Channel: two active channels spaced 37 MHz apart, more on this later
Address width: 4 bytes (SETUP_AW = 2)
Address: three bytes from binding packet, last byte always 0xBB

When turning the transmitter on it will send binding packets for a few seconds. The payload looks like this:
Byte 0-2: first 3 bytes of TX address in reverse order
Byte 3: information on which channels the TX will transmit on
Byte 4-5: Magic bytes, seem to be identical for all TXs (0x18, 0x29)
Byte 6-12: Always 0

to get the complete TX address:
addr[0] = binding[2]
addr[1] = binding[1]
addr[2] = binding[0]
addr[3] = 0xBB

This is because addresses need to be send to the chip in reverse order; LSB first.

The TX seems to transmit at least one garbage package when transitioning between binding and data transmission. That packet has 13 identical bytes (all 0xCC in all my tests).

The data packets are really straightforward, 6 channel values in microseconds, MSB first. Channel layout is Futaba style: AIL, ELE, THR, RUD, GYRO, PIT. The last byte is an indicator for the amount of packets to be send and on which channel.
Each data packet is sent three times on two channels, six times total, 50 times per second (so 300 packets per second in total).
For the first packet the last byte is 6 (0x06). I believe this may indicate the amount of times the packet will be send, or perhaps divided by two the amount of times the packet will be send on this channel.
For the second packet the last byte can be divided by two to get the first channel the TX is transmitting on (so it's 48 when transmitting on ch 24).
For the third packet the last byte can be divided by two to get the second channel the TX is transmitting on (so it's 122 when transmitting on ch 61), always 74 larger or smaller than in the previous packet (the two channels are always 37 channels apart).
These three packets are also transmitted on the other channel in the same order.
This is easy to realize with the nRF24L01+, just put the three packets in the TX FIFO (which is three levels in size) and put CE high, wait until the FIFO is empty, put CE low, change channel and repeat.

A bit more info about the channel selection algorithm and the special byte in the binding packet. This byte is incremented every time the transmitter powers on. It starts at 10 (0x0A) and goes up to 83 (0x53) after which it wraps around to 10. Use the following code to get all combinations:
int channel2 = 10;
int channel1 = channel2 + 37;
for (int i = 10; i < 84; ++i)
{
printf("%2d: ch1: %2d ch2: %2d\n", channel1, channel2);
channel1 += 5;
channel2 += 5;
if (channel1 > 83) channel1 = channel2 - 37;
if (channel2 > 83) channel2 = channel1 - 37;
}

Eery time the TX powers on, both channels move 5 MHz up. If one channel goes above 83, it moves down 74 MHz.

The receiver simply scans channels 7 to 83 to find a valid data packet, once it has one, it knows the two channels the TX is actually transmitting on, so it may switch channels when it loses signal.

I've got the same info available here: sourceforge.net/p/arduinorclib/wiki/Esky%20Radio/ my own implementation of the nRF24L01+ driver and Esky compatibility code can be found there as well (once it's done)

Hi PB

Now that we have the nRF module added for the V202 protocol, any change to add the Esky support. I know it is probably a short term requirement with Esky having closed down, but there are probably 1000s of Esky co-axials and CPs out there.

victzh, maybe you can give it a go?


Regards

I would if I had a receiver/transmitter. PhracturedBlue is absolutely right, my experience also shows that you can't just type in some code, cleanly compile it and hope that it works even in you HAVE the receiver, transmitter, all connected to logic analyzers and you think you understand everything. There is always something more that you overlooked. Even in V202 there are unclear details, though it works and feels much better than the original crappy TX.

No eBay APP ID défined in Kunena configurationI have a spare receiver board from a busted 4-in-1 which I'm willing to send by mail if it's of any use to you. Esky uses the same board in all of their 2.4 GHz receivers, except the headers for ch3 and 4 are on the back side of the board in this case (where it plugs into the 3-in-1).

It's also available on eBay:


I'm not sure what kind of unclear details the V202 has that you are referring to, but I doubt Esky has any of those. The protocol is really straightforward and all 2.4 GHz models (Coax/FP/CP) all use the same TX/RX hardware.

dvdouden wrote: I have a spare receiver board from a busted 4-in-1 which I'm willing to send by mail if it's of any use to you. Esky uses the same board in all of their 2.4 GHz receivers, except the headers for ch3 and 4 are on the back side of the board in this case (where it plugs into the 3-in-1).

It's also available on eBay: skipped

I'm not sure what kind of unclear details the V202 has that you are referring to, but I doubt Esky has any of those. The protocol is really straightforward and all 2.4 GHz models (Coax/FP/CP) all use the same TX/RX hardware.

It will be useful, definitely. I can not guarantee I can return it intact - I will for sure solder some wires to it and in the process can damage it. Also, I rely on the fact that Esky protocol relatively well explored and I could try to program a transmitter without another, working transmitter at hand, only receiver. It can be problematic but I can try. Also, as it seems you are an expert in this protocol, I will ask you many stupid questions, which I could not figure by myself without working transmitter. If it suits you, please send the module.

PM me an address and I'll put it in the mail somewhere this week. Doesn't really matter if it gets damaged, I don't use it for flying anyway.

I have some working Arduino examples for creating a compatible TX and RX, I'll clean them up a bit and send them as well or post them here. That should contain pretty much all the info you'll need.

Feel free to ask any questions you have, I can't guarantee I can answer everything but I'll do my best I have access to a Coax/FP transmitter and I can borrow a CP transmitter from a colleague if needed.

OK, it seems I'm taking the effort due to generous donations of hardware. Stay tuned.

victzh, the RX is on its way It should take about a week, maybe two, to cross the pond.

I also found an old TX board in my parts bin that I got from a fellow Esky pilot. It doesn't seem to be working and he asked me to have a look at it, but I could never pin-point what was wrong with it; I'm more of a software guy really... Perhaps it's of use to you, so I've put it in the envelope as well.
It has a three pin connector; Gnd, V+ and signal. It has its own 3.3V regulator so V+ should be about 5V or more. It expects a PPM signal on the signal pin, 6 channel, 20ms. Maybe you can get it to work, if not then just throw it away

Thanks, you never know what will help, so the more hardware the better. WRT to TX, another person kindly sent it to me, but anyway, for V202 it was important to have more than one transmitter just to be able to compare the packets, so I expect it to be useful here as well. Plus your existing expertise and code.

I doubt there will be any differences between TX's, but you never know of course

The following Esky models all seem to be using the same RX board:
A300
Belt CPX
Big Lama
Comanche
Dauphin
CP3
CT
FP V2
Hunter
King V3
King V4
KOB
Lama V3
Lama V4

Which is basically their entire 2.4GHz line. I've compared transmitters of the Hunter, Big Lama, FPV2, King V3 and Belt CPX and they're all identical. The only difference between a CP and FP/Coax TX is the presence of a few extra knobs and switches, the PCB inside the TX's are identical, the FP/Coax's just have some empty pads where the CP switches/knobs connect. There's some dipswitches on the PCB to switch between CP and FP/Coax mode.

On the receiver side things are just as identical, the only difference being the layout of the pin headers. The larger CP's use angled pin headers, the CP3 straight headers and the FP/Coax have channels 3 and 4 on the back to plug into the 3-in-1. A King3 RX will happily bind with a Big Lama TX and vice versa.

I have compared packets sent by my FP V2 transmitter and a King 3 transmitter, they seem to be entirely identical, only the address was different of course.

All in all I'm fairly confident that if you manage to get it working with one RX, you've got it working for all of them.

Hi @dvdouden. As promised, I need your help in clarifying some details. In your description of protocol I see that you define so called band - 7 frequencies (actually, two groups of 7 freqs). You have an example of first packet sent 6 times, 3 on the first frequency, 3 on the second. But I am more interested in second packet - does the protocol use the same frequency, or implements frequency hopping?

I soldered to the receiver (piece of cake compared to V202) but figured it uses older nRF2401 chip which has 3 wire SPI for which I don't have decoder, so it's a bit easier to ask than to figure out.

Thanks,

Victor.

Hi victzh. It turns out it aren't really bands, It's just that the nrf detects carrier signals on three channels above and below the channel that is being used. The transmitter selects 2 channels when it's powered and it will keep using those two channels until the power is cycled. So there's no hopping done after the TX has been turned on, it'll only "hop" when you power down and up again.

So the first time you power the transmitter it will send this binding packet for a few seconds:
<adr1>,<adr2>,0x0A,0x18,0x29, and 7* 0x00

Then it will start transmitting data packets in blocks of 6
ch47: ch1, ch2, ch3, ch4, ch5, ch6, 0x06
ch47: ch1, ch2, ch3, ch4, ch5, ch6, 0x5E (94)
ch47: ch1, ch2, ch3, ch4, ch5, ch6, 0x14 (20)
ch10: ch1, ch2, ch3, ch4, ch5, ch6, 0x06
ch10: ch1, ch2, ch3, ch4, ch5, ch6, 0x5E (94)
ch10: ch1, ch2, ch3, ch4, ch5, ch6, 0x14 (20)
Where channel data is 2 byte, high byte first, all channel data is the same for each of the six packets. Then it will send a new block of data packets with new channel data.

When restarting the transmitter, the following binding packet will be send:
<adr1>,<adr2>,0x0B,0x18,0x29, and 7* 0x00
Only byte 3 changed, it will increment with each power cycle until it has reached 83 (0x53), then it will jump back to 10 (0x0A).
The channels will have moved up by 5 and the last byte of the data packets will be different
ch52: ch1, ch2, ch3, ch4, ch5, ch6, 0x06
ch52: ch1, ch2, ch3, ch4, ch5, ch6, 0x68 (104)
ch52: ch1, ch2, ch3, ch4, ch5, ch6, 0x1E (30)
ch15: ch1, ch2, ch3, ch4, ch5, ch6, 0x06
ch15: ch1, ch2, ch3, ch4, ch5, ch6, 0x68 (104)
ch15: ch1, ch2, ch3, ch4, ch5, ch6, 0x1E (30)

My guess is that the last byte in the data packets are actually left aligned 7 bit numbers, so their actual values are: 3, first channel, second channel.

A complete list of possible channel combinations has been placed on the Wiki of my sourceforge project: sourceforge.net/p/arduinorclib/wiki/Esky%20Radio/

The RX most likely just scans all channels for packets, once it has some it'll know which channels are being transmitted on.

I've attached two example Arduino sketches, one for a transmitter and one for a receiver, but I don't have access to the required nrf24 library I used at the moment. I'll add that tonight when I get home.

And here's a small video of the RX board in action to demonstrate the binding procedure and possible states the board can be in:

Thanks, I suspected so. Even though nRF2401 does not use SPI you can see some pattern of communication even not resorting to deciphering the whole protocol. It has a peculiar way of reusing DATA wire for transmission both ways - when master wants to transmit something to RF chip it asserts CS, when chip wants to communicate back it asserts DR - Data Ready. So I've seen CS asserted at the very beginning of the session - the chip is initialized, the bands are searched - then it goes another way - only DR is asserted when the packets are received. No frequency hopping is possible without RF channel adjustment, which can not be seen there.

So it simplifies things, but makes the protocol less noise-prone. Which is interesting considering it is used for controlling real pieces of metal, not only cheap micro helis.

The hell? I thought I added some attachments to my previous posts... Trying again.

edit, doesn't work. Dropbox to the rescue!

www.dropbox.com/s/d9xb4arp9kkcqkx/Mirf.rar
www.dropbox.com/s/h1sysfdbgb9ukk2/receiver.pde
www.dropbox.com/s/t2seuzy1ym92fmt/transmitter.pde
www.dropbox.com/s/kgvyq2uordike0k/NRF24L01pBase.h
www.dropbox.com/s/0kc02ona06apxgr/NRF24L01pBase.cpp

Finally, after summer trip and move to a new place I got a chance to pay my debt to ESky.

Yesterday and today I ported the code, gracefully donated by @dvdouden to Devo.

It is still not complete - it does not switch to a new pair of radio channels at each turn off, but all 6 channels work. In a day or two I'll beat it into shape and if anybody has time and ability to test it, I'd gladly build it for you.

Thanks for all who donated hardware, it would not be possible without live system to check against despite of thorough and detailed explanations of @dvdouden.

Hi,
I have a 2.4G 6ch receiver somewhere from a King2... the tx is busted (does not bind, just blink forever) so I have not used it for ages. I'll be glad to help with testing. I have a devo10.
cheers

OK, I will build Devo 10 with ESky for you later and put it in the builds.

Cool, I'll will go and find the little guy somewhere