Esky 150X, which protocol ?

More
22 Dec 2016 14:05 - 22 Dec 2016 14:09 #57123 by Moeder
Replied by Moeder on topic Esky 150X, which protocol ?
Yes, trim values sounded very likely to me as well, but as you said we won't need them. I will update the sources with the check for number of input channels used and will then compile a version for you two to test which also has a protocol option to select random or fixed values for RF channels so you can make some more and longer tests with both options. Unfortunately due to a 24h shift you will have to wait until tomorrow. (and, yes I also share timezone and umlauts with Käseknigger ;) )

Edit: Concerning random IDs, the idea is to not know which is the final RF ID used, because naturally the number entered into the ID field is far from random. I even believe that many still run on 123456.
Last edit: 22 Dec 2016 14:09 by Moeder.

Please Log in or Create an account to join the conversation.

More
22 Dec 2016 14:17 #57124 by dado099
Replied by dado099 on topic Esky 150X, which protocol ?

Käseknigger wrote:
Edit:
Tested the channels now. Now all channels work flawless on my 150x.
If dado has throttle problems, then it is most likely because he only has 4 channels and that the unused channels (5 to 7) need to be 0. (or as it seems at least ch5 and ch7)
So we need to implement a bit source which reads how many channels are used on the model, and zeros the remaining channels...

Yes I have 4 channels. Can I set 7 channels on protocol, then fix 5,6,7 to zero as a workaround ?

Please Log in or Create an account to join the conversation.

More
22 Dec 2016 14:38 #57125 by Moeder
Replied by Moeder on topic Esky 150X, which protocol ?
Dado, did you try the special build I made for you? It should work on 4ch

Please Log in or Create an account to join the conversation.

More
22 Dec 2016 15:10 #57126 by dado099
Replied by dado099 on topic Esky 150X, which protocol ?
Not yet, I'm at work now.....
Thank you

Please Log in or Create an account to join the conversation.

More
22 Dec 2016 15:23 - 22 Dec 2016 15:30 #57129 by Käseknigger
Replied by Käseknigger on topic Esky 150X, which protocol ?
@Moeder:

I made a beginning comment section for the source. You can just paste it there. This should make future work on the protocol, if ever needed, easier
//****************************************************************************
//  ESky protocol for models since 2014 (150, 300, 150X, ...)
//****************************************************************************
// 
//  Relating threads (in order of relevance):
//
//    https://www.deviationtx.com/forum/6-general-discussions/6446-esky-150x-which-protocol
//    https://www.deviationtx.com/forum/builds/2458-devo10-esky-protocol-draft
//    https://www.deviationtx.com/forum/3-feedback-questions/4007-esky150-protocol-and-devo-6-8s
//
//  Comment:
//
//    Analysis based on SPI captures from SeByDocky on his 150 (TX_ADDR = 
//    710A31F4) and Käseknigger on his 150X (TX_ADDR = C6F3D602). Data format 
//    by a picture from Iamlawrence3c3c, which he got from the manufacturer, 
//    and further SPI analysis.
//    (https://static.rcgroups.net/forums/attachments/5/3/3/5/5/1/a9467524-85-esky%20mini%20transceiver%20protocol.JPG)
//
//****************************************************************************
//  General protocol features:
//****************************************************************************
//
//  Chip used        : nRF24L01 (stock uses compatible Beken clone BK242x)
//  Data rate        : 2Mbps
//  Payload size     : 15Bytes
//  Address size     : 4 Bytes
//  Data direction   : Always TX->RX (NO ACK)
//  No Data Channels : 7
//  Resolution of Data Channels: 
//    CH1-4 & CH6    : 12 bits (where only 10 bits are effectively used)
//    CH5            : 1 bit (implemented in this protocol as 2bits)
//    CH7            : 2 bits
//  Channel assignment :
//    CH1            : Throttle
//    CH2            : Aileron
//    CH3            : Elevator
//    CH4            : Rudder
//    CH5            : Flight Mode
//    CH6            : Aux 1
//    CH7            : Aux 2 (switch)
//
//****************************************************************************
// Binding protocol
//****************************************************************************
//
//  Comment:
//
//    After chip initialization, the TX sends its unique TX_ADDRESS continuously 
//    in a special data packet on RF channel 1. For sending this packet it uses a 
//    special binding TX_ADDRESS. The receiver will store the unique TX_ADDRESS 
//    permanently, so binding is only necessary once per model.
//
//  Binding RF Channel: 1
//  Binding TX address: 0x73, 0x73, 0x74, 0x63  ("sstc")
//  Binding packet send rate: every 21ms (stock), 2ms (in this implementation)
//
//  Binding data packet format (15 Bytes):
//    Unique TX_Address (4 Bytes)
//    Binding TX_Address (4 Bytes)
//    Unique TX_Address (4 Bytes)
//    Filler 0 Bytes (3 Bytes)
//
//****************************************************************************
// Data protocol
//****************************************************************************
//
//  Comment:
//
//    The RX seems to go through all channels to find one, where it receives 
//    a valid data packet from the bound TX_Address. Then it seems to use the 
//    two indicated channels in this packet for reception.
//    The data packets always hop between these 2 different frequencies. 
//    These are seemingly fixed to 0x22 and 0x4A on the stock implementation. 
//    But any other frequencies also seem to work, as long as the 2nd channel 
//    is the first+40. Therefore this implementation uses channels derived 
//    from the TX_Address.
//
//  Data TX address: The TX_Address which the model has been bound to.
//  Data packet send rate : every 4.8ms (stock 150), 4.4ms (stock 150X), 4.8ms implemented
//  No of frequency channels : 2 (stock seems to use always channels 0x22 and 0x4A)
//
//  Data packet format (15Bytes):
//    First RF sending channel (1 Byte)
//    Second RF sending channel (1 Byte)
//    CH1-7 information (see above linked picture for format) (8 Bytes)
//    Throttle Trim value (1 Byte)
//    Aileron Trim value (1 Byte)
//    Elevator Trim value (1 Byte)
//    Rudder Trim value (1 Byte)
//    Checksum (all other values summed up) (1 byte)
//
//  Data channel value range (12 bit channels CH1-4 & CH6):
//    From 1000 to 2000 with midpoint at 1500.
//    Channel values are servo time in ms of common PWM servo signal.
//    Data channels CH2 and CH4 are reversed.
//
//  Data channel value range (1 and 2 bit channels CH5 & CH7):
//    These are channels for switches, so they just have the values possible.
//    If older 4 channel models are used, these channels have to be 0 for
//    compatibility reasons.
//
//  Trim value range:
//    From 0x9C (-100) to 0x64 (100) (signed 8bit int value)
//    Stock makes step of 4, which yields 25 trim steps in both directions.
//    As devo includes the trims in the normal channel outputs, trim values 
//    have to be 0 in this implementation.
//
//****************************************************************************
.
Last edit: 22 Dec 2016 15:30 by Käseknigger.

Please Log in or Create an account to join the conversation.

More
22 Dec 2016 15:33 #57130 by victzh
Replied by victzh on topic Esky 150X, which protocol ?
For this kind of texts we have a separate place - doc directory. Make a plain text out of your comment, name it appropriately - say esky_after_2014.txt - and place it there. As a comment it is a bit long.

Please Log in or Create an account to join the conversation.

More
22 Dec 2016 15:36 - 22 Dec 2016 15:37 #57131 by Käseknigger
Replied by Käseknigger on topic Esky 150X, which protocol ?
@dado:

Yes I have 4 channels. Can I set 7 channels on protocol, then fix 5,6,7 to zero as a workaround ?

Yes, this should actually work. If you set these channels fixed to -100.

@Moeder:
Again thanks a lot. And no hurry...
Last edit: 22 Dec 2016 15:37 by Käseknigger.

Please Log in or Create an account to join the conversation.

More
22 Dec 2016 15:57 - 22 Dec 2016 16:04 #57132 by Moeder
Replied by Moeder on topic Esky 150X, which protocol ?
I'm not in a hurry, I just wish I had not forgotten to take my notebook to work :lol:

One more thing I thought of: Could you check on your SPI captures if the stock TX really only transmits each packet once, or if it always transmits the same packet on rf channel one and two before updating packet data?

I will put the protocol info in the doc directory of my repository. When you are done testing the final protocol and we are convinced it is good to the doc will be part of the pull request. Which reminds me, for that we should agree on the naming scheme. I prefer ESky2 and would remove ESky150.

@victzh: BTW, what do you think of sorting the protocols by alphabet (maybe grouped by rf module)? I personally hate the chaos when scrolling through the options...
Last edit: 22 Dec 2016 16:04 by Moeder.

Please Log in or Create an account to join the conversation.

More
22 Dec 2016 16:13 - 22 Dec 2016 17:25 #57134 by Käseknigger
Replied by Käseknigger on topic Esky 150X, which protocol ?
@Moeder:
As one can see on the capture on the first page of this thread, each packet is updated separately. So the code, like it is now, is OK in this relation.
But better to have asked an checked this...

About the naming:
Honestly, I don't really care. There are good points for both variants...

Edit: Concerning random IDs, the idea is to not know which is the final RF ID used, because naturally the number entered into the ID field is far from random. I even believe that many still run on 123456.


But that wouldn't make any difference. As If you use the same scramble algo on 123456, they all still are on the same channels.
And as said, scrambling the MCU_ID with a pseudo random algorithm, doesn't give you an iota more randomness. You could just as well just take the MCU_ID and calculate it down into the needed size, using all of the info (e.g. by XORing or summing).
Last edit: 22 Dec 2016 17:25 by Käseknigger.

Please Log in or Create an account to join the conversation.

More
22 Dec 2016 19:26 #57137 by dado099
Replied by dado099 on topic Esky 150X, which protocol ?
@Moeder:
Yes your last patch version make the throttle works with 4 channels, nice job !
@Kaseknigger:
Yes, ail is reversed together with rudder ch.
The workaround to set 7 ch. and fix at -100 ch 5,6,7 works very well too !

I made a short fly with both FW version and I think it is correctly flying.

If you need other tests just let me know.

Thank you very much for your effort.

I think we are very near to make a definitive protocol version.

Please Log in or Create an account to join the conversation.

More
22 Dec 2016 20:00 #57138 by Käseknigger
Replied by Käseknigger on topic Esky 150X, which protocol ?
Good to hear. I also think we are almost there.
I think in the next version, again with tx_id channel selection (not fixed 22 and 4A), and with the fix for the 2 bit values (set to zero, if not needed).
And with channels reversed for CH2 and CH4.

If this version then works for both of us, I think we can commit it...

Please Log in or Create an account to join the conversation.

More
23 Dec 2016 06:12 #57145 by Käseknigger
Replied by Käseknigger on topic Esky 150X, which protocol ?
Just had 3 additional thoughts:

About ch6:
It seems ch6 doesn't need to be zero for it to work on the 4channel models. But I'm pretty convinced, that it needs a valid value for newer models not using it by default, like my 150X. As my stock TX does send a valid value for it, although it isn't usable. So the handling of ch6 should remain as is and not be especially zeroed.

About the naming:
I just realized that the manufacturer itself calls the protocol "esky mini transceiver protocol". So from the name it sounds like it is the protocol intended for their small models. Then we could name it ESky_mini. As if they publish another big model, it could be very likely that it isn't using this protocol, but again the original esky one.

Again ch6:
I didn't realize that I didn't check if ch6 is also reversed. Will check that, and report back.
BTW: Easiest way to reverse a channel is just to calculate 3000-old_value. I would do it in the esky2_read_controls.

I already apologize that I will not have much (any?) time these next 3 days. And today I'm on the road, so...I already wish you all a nice christmas.

Please Log in or Create an account to join the conversation.

More
23 Dec 2016 09:46 #57146 by Moeder
Replied by Moeder on topic Esky 150X, which protocol ?
Merry christmas to all!

File Attachment:

File Name: deviation-...bff5.zip
File Size:835 KB

File Attachment:

File Name: deviation-...bff5.zip
File Size:616 KB
Attachments:

Please Log in or Create an account to join the conversation.

More
23 Dec 2016 09:53 #57147 by Moeder
Replied by Moeder on topic Esky 150X, which protocol ?

So from the name it sounds like it is the protocol intended for their small models. Then we could name it ESky_mini. As if they publish another big model, it could be very likely that it isn't using this protocol, but again the original esky one.

I guess those who can approve the pull request should decide on this matter.

BTW: Easiest way to reverse a channel is just to calculate 3000-old_value. I would do it in the esky2_read_controls.

I'm really glad didn't need your advice on this one :P

I already apologize that I will not have much (any?) time these next 3 days. And today I'm on the road, so...I already wish you all a nice christmas.

So am I. You can find the promised builds in the post above, including the protocol option for fixed RF channels just in case somebody encounters problems - I guess it doesn't hurt.

Thanks for the excellent team work on this protocol!

Please Log in or Create an account to join the conversation.

More
24 Dec 2016 08:26 - 24 Dec 2016 08:28 #57190 by dado099
Replied by dado099 on topic Esky 150X, which protocol ?
Tried last build from Moeder.
For me it's all OK, if it is also from Kaseknigger, we can proceed to a pull request.

Merry christmas to everybody.

Dado
Last edit: 24 Dec 2016 08:28 by dado099.

Please Log in or Create an account to join the conversation.

More
24 Dec 2016 09:06 #57192 by Käseknigger
Replied by Käseknigger on topic Esky 150X, which protocol ?
Did you try it in 4 ch mode? Just to be sure...

Please Log in or Create an account to join the conversation.

More
24 Dec 2016 09:09 #57193 by dado099
Replied by dado099 on topic Esky 150X, which protocol ?
Yes I tried with 4ch and 7ch, both works.

Please Log in or Create an account to join the conversation.

More
24 Dec 2016 09:36 #57194 by Käseknigger
Replied by Käseknigger on topic Esky 150X, which protocol ?
Perfect. Unfortunately, I'm not in the place today, to test my 150X.
But I had again a thought, why I could have had a problem with my RX, where I had to repower it, to work again.
That was the FW, where the Throttle Upper Byte was calculated wrongly. So the RX got wrong throttle values (outside of 1000-2000). Maybe some value then got the RX to crash...

As since then I never had the problem again.

Again enjoy christmas!

Please Log in or Create an account to join the conversation.

More
28 Dec 2016 18:47 - 28 Dec 2016 19:01 #57306 by Käseknigger
Replied by Käseknigger on topic Esky 150X, which protocol ?
Sorry for the late reply, but just got ill after christmas...
Yes, I know...some people can't stand partying...

Everything works for me. Ch6 is not reversed, so perfect as it is now.
Just as an indication if it ever gets needed anywhere in the future. My stock TX sends as value for ch6 always 1000.

For me it looks like we can merge your changes into the main trunk.
BTW: I added a few comments in your file (mainly in the beginning and about the trim values). Attached the new version
I also saw, that you now again disabled the fixed channel selection.

Edit:
Added a changed protocol doc, for the new protocol
Attachments:
Last edit: 28 Dec 2016 19:01 by Käseknigger.

Please Log in or Create an account to join the conversation.

More
02 Jan 2017 15:56 #57473 by Moeder
Replied by Moeder on topic Esky 150X, which protocol ?
Sorry, haven't been up to reading the forum for a couple of days. Thanks for your work, I already put up a pull request a couple of days ago which is waiting for merge. I updated the code and documentation from your files and hope that someone with write access to the repository will close the pull request soon so you'll have it future nightlies.

Please Log in or Create an account to join the conversation.

Time to create page: 0.067 seconds
Powered by Kunena Forum