ESKY150 Protocol and DEVO 6/8S

Hi,
I have installed nRF24L01 module inside my Devo 6S and it's correctly working.
I have also installed las nightly build 2015 02 21.
Now I have active the ESKY150 protocol (withouth the asterisk).
I try to bind with an E-SKY F150, but without success.
When I press re-init button nothing happens at all.

I searched the forum and I found that only a success with this protocol is reported with a Devo 10.

So I was asking:
is ESKY150 really implemented also for Devo 6/8 or am I loosing my time ?

It would be interesting to implement this protocol beacause it seems that E-SKY will only use this from now on.

Thank you very much.

Sorry, I have neither E-Sky F150 nor Devo 6S. I reversed the protocol "by ear" - SeByDocKy's SPI dumps and try outs of my code.

In theory, there should not be any difference between transmitter's handling of the protocol.

How do you know that the module is working correctly?

Thank you victzh for the reply.
I suppose the module is working because I have no more asterisk in front of it.
Is that enough ?

You'd better check that it works with some other nRF24-based protocol, not only E-Sky 150.

No star means the module is configured in hardware.ini file, that's it.

victzh wrote: No star means the module is configured in hardware.ini file, that's it.

If the 2015-02-21 build is from the deviationtx repo it includes the code that checks communication with the nRF chip. No guarantee it's working as a radio, but writing/reading to it is working if no "Missing Module" screen is displayed. I think that's in the PB nightly as well.

Anyways, the best test is another protocol working with the module.

Wanna start a survey:

Anybody success with protocol ESKY150 ?

If yes, please specify which Devo TX radio and wich nightly build version.

Thank you very much for any feedback.

Dado

What I learnt, there is a "binding" procedure with the radio... I will try to capture some new SPI data one day

Survey input.
Devo 7e, nRF and A7 modules, TX working fine with, V911, V966, V977, Orange RX 100/V-bar, Cheerson CX-30, so all modules working as expected.
Deviation FW version devo7e-v4.01-9022e68.

No response/reaction from TX trying bind Esky 150.

I'd be happy to flash and try any build suggested.

Hi All,
is there any update on f150 protocol ?
If it is still dead (as I believe) why don't remove it from possible protocol choiche ?
If you leave it you will make loose a lot of time to whom trying to make it work.
Thank you

SeBy, is this binding for F150 only, or for 150 as well? Can you shake the dust from your model and check?

I agree !
The Esky150 protocol is not binding no matter how ~
I have tried many version of Deviation and many kind of binding ,it still doesn't work~
There is not too much people have this helicopter in China,so I came here to look for answers.
hope victzh can solve it~thanks!
I'm not very good at English~: )

Nice !
second person in the world who has esky 150 !

The stock tx is rubbish, please help us !
Thanks

How? I don't have it. Can you solder to TX and capture SPI traces?

Doesn't SeBy has one as you told ?
I don't know how to capture SPI traces

The problem is it's SeBy's model I did my reverse engineering on - remotely, over the ocean So it's probably still working for him - they must have changed protocol since I did this.
There are instructions published at www.deviationtx.com/forum/protocol-devel...95-spi-capture-guide .

Just as an update as I recently recorded the binding process for my 150X here:
www.deviationtx.com/forum/6-general-disc...ch-protocol?start=20

The current implementation of the esky 150 protocol doesn't have the binding part included. Therefore it probably only worked for Seby's model, as he was the one contributing his SPI data. So only his model is bound to this TX_ID.

@victzh:
Did you program the esky 150 protocol?
As I would like to update it, but there are a few things I don't get.
E.g. How did you get to this channel selection code out of the TX_ID, with even a random scrambled devo id, not using his original TX_ID???
E.g. SeBy's TX uses the channels 22 and 4A (at least that's what it seems from the code). My TX has a completely different TX_ID but still uses the channels 22 and 4A. So I'm wondering...

Hi Kaseknigger,
great discovery !
If you see my old posts it's about one year that I insist that ESKY150 protocol only works on SeBy heli all over world !
But nobody took care of this, I also proposed to delete the protocol to save memory......
Hope someone will implement a working one for ALL !

Yes, I'm looking forward to update it, also adding the additional channels.
Probably we should then rename it into something like ESKY_NEW, and not 150, as the TXs seem to work for all new ESKY stuff.

I'm still just puzzled, how the channel selection works.
Strangely, the first 2 bytes in every data packet declare on which channels the data gets sent. But why including this in every data packet?
Or does the RX scan just all possible channels until it finds one and then uses these channels???
For me that's kinda the only reasonable explanation...
For if the channels would be TX_ID specific, then why declare them in every data packet?
That would also explain why my TX sends on the same channels as SeBy's. So it would seem stock TXs all send on the same channels, independent of the TX_ID.
But for Devo one could make it send on any channel one wants independent of the TX_ID.