Esky 150X, which protocol ?

Ok, now did an analysis for the binding process.
As it seems the binding process is quite forward: The TX just sends a special packet on channel 1, with the base tx_addr 0x73,0x73,0x74,0x63, over and over again, as long as you hold the trim button.
If the RX is powered on or off doesn't make any difference.

The init remains the same. Just the last two packets from the init procedure above are not executed, the ones which change the channel to 22 and set a new TX_addr.

The packet is as following:


As you can see, the package contains first the TX_ID of my transmitter (C6, F3, D6, 02), then the default TX_addr(73, 73, 74, 63) and then again the TX_addr of my transmitter (C6, F3, D6, 02) and the remaining 3 bytes are unused (00). there's no additional checksum. But as the TX-ID will be transmitted two times in one package that should be enough error detection.

That's all.
Anybody keen to implement this binding process?
I could implement the additional channel handling (add channels 5,6 and 7), but I would first have to analyze other protocols to see how to implement the binding procedure in deviation.

Edit:
There's only one thing that puzzles me. Although I have a completely different TX_ID than the one in the current implementation, mine also uses the channels 22 and 4A. I get the impression that onlky these channels are used independent of the TX_IDs. Otherwise that would be quite a coincidence.

Has been a while for tweaking a protocol, but this should actually be a quick fix to this truly incomplete module.
Fixed channels 22 and 4A could very likely be possible, so all we have to do is transmit the "unique" TXID in a bind packet...
I'll try to get my docker images back up and running (am I the only one having trouble with this?)...unless victzh beats me to modifying the protocol

I'm also currently at it... Lol...

But I don't have the proper environment for compilation.

BTW. As I looked back, on another thread, it seems what victzh did with the channel selection does work, as the protocol works seemingly with any channels, if only the 2nd channel is the first+40.

So one really just has to integrate the bind process, and add the additional channels (CH5 Ch6 and CH7), whereas CH5 is only 1 bit, But I would implement it as 2 bits and CH6 is 12 bits and CH7 again 2bits.

Edit: Attached, what I have so far. But I just started...

Docker is up and running again, I forked the master branch, but the main code changes I haven't pushed into the repo yet. I'll use your stuff and send you some compiled Zip as soon as it's ready. What transmitter do you need?

as attachment now the more progressed code. The channel handling should now be complete.
The binding still needs some handling code.
The tx_adress of the nrf24l01 has to be set to the same as the rx address for binding. And then set back to the tx_id.
I have a devo 10.

Edit:
Unfortunately I dont' have more time for today... So either someone else is finishing the binding code stuff, or I will continue tomorrow.

BTW:
I renamed the esk150 protocol into esky_new, as the protocol works for all newer esky models. So the makefile and protocol.h need to be updated accordingly.

Edit2:
Just saw an obvious error I made in the static u16 convert_2bit_channel(u8 num) routine
It should obviously be return ch_out; not return ch;

BTW:
Why do all the nrf24l01 protocols do have the code for the special Beken Chip init in it (lol)?
Did really anyone install such a Beken module into his devo???
And even if they did, then one could add the beken init procedure into the nrf24l01 code (probably 3 different variants for the 3 different speeds)

That would save quite some memory! As like it is done now, it seems like a unnecessary waste of memory to me...

Sometimes an existing cheap TX is a reasonable source of nRF24 compatible module. We don't want to close this possibility if it costs nothing.

And it's not that terrible waste, but I'll think about moving it into separate procedure in nRF24 module.

To not duplicate the whole protocol we have options. You can introduce a new option into esky150, say 'Esky 150X'.

I actually disagree in this case. Since the old Esky150 protocol ONLY works for SeBy, it does make no real sense to keep it in future nightlies, once the new Esky2 (I don't like "new" and "old") protocol is merged we should remove "esky150".

@victzh:

Actually options are not needed. As it seems, they all use exactly the same protocol. So no options needed.

OK, then just fix existing esky150 - why introduce any new protocols? It's very common situation - bugs being fixed, protocols amended. If we change names every time it happens we'll be out of names soon

I just thought since nobody actually uses ESky150 (except perhaps SeBy), we could replace it with something more universal. But I can live with ESky150 as well...

Anyhow, please find attached my first test build for devo10. Please select protocol "ESky2". Not sure it works though, I don't have an Esky150 myself for testing.

WRT "nobody uses", pay attention to the numbers at the bottom of main forum page. Right now there are 19 registered users and 305 guests. These guests, a.k.a. lurkers, can use various things, and you never know until you try to turn something off.

@Moeder:
Thank you I will test it as soon as I got time, which will probably be in the evening, so it will take some time.
Would it also be possible to post your new source file. If anything isn't working I could check it accordingly.

@victzh:
Well actually, we can be pretty sure that the current ESKY150 protocol is not used by anyone except SeBy as it isn't possible to bind to any model. So it will not work for anyone except SeBY.
But IMHO it was just a question of naming. E.g. if one should rename the esky150 protocol into esky2 protocol, as the protocol itself hasn't really anything special to do with the 150, but is just the protocol for all new esky models. But in the end, as it is just a naming issue, it doesn't really matter at all...

Well in theory the fixed Esky150 should bind some other Esky Helis (300 for example)..... after if both 150 & 150x are implemented I don't care about the name of the protocol

Please find attached the devo10 zip for my rewrite of ESky2. I actually mixed the KN protocol up with part of your ESky150 writeup, since I liked the transmitter state setting and some other things more structured in the former one. You can find the sources in my repository . I wish you and me luck it works.

P.S.: I removed the old test version in the post above, since I missed out on the correct entry in protocol.h...it would've never worked ;P

Just a short notice:
The bind doesn't work. It is also waaaaayyy to short. It should be on for a few seconds, or until a key is pressed, if you bind, but it only tries to bind for like half a second.
Nevertheless didn't get it to bind. The stock tx still works without new binding it, so the binding definitely hasn't worked.
When I find the time, I will have a look at the source, if I can find the problem.

Edit:
Ahh I already found a big problem in the source:
The RX address (NRF24L01_WriteRegisterMulti(NRF24L01_0A_RX_ADDR_P0, ...) is fixed and is always needed and should therefore IMHO be initialized in the nrf24l01 init, as it has been done in the esk150 source
Exactly this RX address has also to bet set as TX_addr (NRF24L01_WriteRegisterMulti(NRF24L01_10_TX_ADDR, ...) for binding!!!
For normal data sending the tx address then can be the specific devo unique one.

Could you send me (a link to) the LA capture of the bind signal?

What do you mean by "LA"? EDIT: ah Logic Analyzer
Actually all info for the binding proc is just on the top of this page.

Edit: Just saw another problem in the source: Why do you set the Bitrate to 1MB for bind???

I meant the raw capture from your logic analyzer (LA), is it a permanent signal? Is there small breaks between pulses? Things like that.

I just saw that I accidentally set the wrong bitrate for binding. Please find attached an updated version, which also sets channels fixed to 0x22 and 0x4A and significantly extends the bind period.

Edit: Seems we both found my error at the same time