Esky 150X, which protocol ?

Actually the log from the LA is really at the top of page 2, together with a complete explanation from me, how the binding process works...

As said above the source still has the big problem of not doing the correct tx_address handling. As I edit a lot of my posts, maybe you need to refresh, to see my comment there...

Saw your edits now. You're right, I mixed up TX and RX addr. Please find attached an updated build for devo10.

OK it works now. But I would go back to the random channel selection that victzh implemented and not the fixed channels.
BTW the rudder channel is inverted. I already knew this, that the stock tx sends the value inverted. Should we invert it in the protocol, or shall all the people invert it on their devo manually?

What I don't get:
To me it seems, that the current code does not initialize the rx_addr if you don't bind. But strangely it still works.
As said, I would put the rx_addr init into the general nrf24l01 init procedure, as IMHO i doesn't belong into the bind proc.

BTW: Where in the source is indicated at which rate these bind&data packets get sent?
As they have to be sent every 20ms (my stock TX does it even every 21ms). Otherwise I'm not sure what the rx will be doing...

And I personally would definitely increase the binding time from 2s to 5s (or even more), as it makes the binding process much easier...
2 seconds is already quite short, as you have to get the correct time window on the rx...

I didn't yet do a full function check, just a short try. If I get the time, I will make a full check tomorrow.

Käseknigger wrote: OK it works now. But I would go back to the random channel selection that victzh implemented and not the fixed channels.

I will post a build with victzh's channel selection, it was just to reduce possible reasons for fails in binding.

Käseknigger wrote: BTW the rudder channel is inverted. I already knew this, that the stock tx sends the value inverted. Should we invert it in the protocol, or shall all the people invert it on their devo manually?

Does this only affect your ESky150X or also the original ESky150? If it inconsistent throughout different models using one protocol, it should be kept in the model file, otherwise we can change it in the protocol.

Käseknigger wrote: To me it seems, that the current code does not initialize the rx_addr if you don't bind. But strangely it still works.
As said, I would put the rx_addr init into the general nrf24l01 init procedure, as IMHO i doesn't belong into the bind proc.

You're right, this just proves it isn't really needed. I'll move it anyways .

Käseknigger wrote: BTW: Where in the source is indicated at which rate these bind&data packets get sent?
As they have to be sent every 20ms (my stock TX does it even every 21ms). Otherwise I'm not sure what the rx will be doing...

This is why I wanted to see more of the LA-captures, to see at which intervals how many packets are sent (on which channel). Right now we're sending every 4.8 ms on alternating channels, which is what ESky150 did and I guess victzh saw in the original SPI captures. The bind packet gets send every ms, I guess it cannot hurt to send it "too much". I doubled it to two ms in the build coming up and increased the total number sent - that should give you enough time to have your RX ready.

Here is the build for devo10



If anyone needs a 7e test build please pm me, the zip is to big for forum uploads (silly 1 MB limit...)

Had a look again at my logs.
The bind packets get sent about every 21ms
And the data packets get sent every about 4.4ms

So the 4.8ms in the source seems OK.

This is all on my stock tx.

So with the new protocol you can now start flying 19 ms earlier

Seriously, I wouldn't worry about the amount of bind packets and their timing in a one way protocol.

Let me know if bind time is long enough now and if the random channels work.

@Moeder & Kaseknigger:
Thank you, you did a great job.
I would like to test on devo 6s, can you post a build or is it too large for the forum ?

@Moeder:
LOL...

Does this only affect your ESky150X or also the original ESky150?

Just from theory, as the stock TX's also work for other helis (e.g. 150 and 300), pure logic tells, that the channel also would have to be inverted for them. But surely dado099 and SeBy could test that, to be sure

You're right, this just proves it isn't really needed.

Lol, when I think about it, as we only send TX->RX the rx address init is really not needed at all...

But I have one problem. The throttle seems to spool up too fast IMHO. I will have to check that.
Fortunately I can connect the RX by USB to my PC (CC3D) and then exactly see the RX inputs.
I will test it soon...


EDIT:
BTW, as I just had a look at the nrf24l01 datasheet:
There is indicated that the tx_addr should have more than one bitchange overall, otherwise it could be problematic. Maybe one could implement something into the ID scrambler to be absolutely sure, that this is the case...
Otherwise, if there is one unfortunate guy with an id just like that, he will have problems, that others don't have...
BTW: IMHO one could also put this ID bit scrambling in some other source file, as it is needed a lot, over all the protocols...

But anyways. First things first. First this protocol has to be in a state to commit. then I could maybe go over the source and have a look at it.

Edit2:
Ah BTW, in the nrf24l01 datasheet I also saw, that one should only use every second channel in 2Mbps mode, as otherwise you get a channel collision. Maybe one should adapt the random channel selection to only even channel numbers...

OK tested it now. It had some kind of strange behavior now, when binding, so that I first had to power rx off and on again until I could control it after binding.
Also sometimes it just lost connection, and only started to work again when I switched the TX off and on again. I'm wondering if this is a channel hopping problem.

CH2, Ch3 Ch4 and Ch6 work with no flaws...
Ch7 I cannot test, as CC3D with PWM only has 6 channels.
Ch5 doesn't work and ch1 is erratic. as it makes jumps forth and back.
Ch5 and CH1 problems could be related as they are within the same data byte.
I used the diagram from lawrence at the beginning of this thread as source. Will make another SPI log, to see if it is correct or not, and then have a look at the source.

Edit:
Just had a look at the source again...

Stupid me!!! I mistakenly made logic ands instead of bitwise...

E.g. the lineshould obviously be:
Can you correct that and make a new dfu?
Sorry for the much work you have to do...And BTW also Thanks a lot for it...

Edit2:
Now compared stock TX to Devo output. (BTW this time the binding worked flawless???)
It seems both stick left right movements are reversed. If that is consistent, we should invert them by default.

Edit3:
Now there is only one strange thing. Now the heli doesn't do anything anymore. No servo movement at all, although it still received the values correctly, as shown on the CC3D...

Edit4:
Ah was just the case when I enabled ch6 reception in CC3D. Don't know, why it did then go into failsafe. Anybody an idea?
When I disabled it again, it worked...

This build goes back to fixed channels for now and has packet[2] corrected. And also for devo6 so we enlarge our testbed




PLEASE BE AWARE THESE ARE TEST BUILDS - I'M NOT RESPONSIBLE FOR ANY DAMAGE TO YOUR MODEL. I SUGGEST FIXING THE MODEL TO A TABLE OR THE FLOOR WHENEVER TESTING A NEW PROTOCOL BUILD DURING DEVELOPMENT.

Lol, when I think about it, as we only send TX->RX the rx address init is really not needed at all...

I see, you get my point

Otherwise, if there is one unfortunate guy with an id just like that, he will have problems, that others don't have...
BTW: IMHO one could also put this ID bit scrambling in some other source file, as it is needed a lot, over all the protocols...

Since this affects so many protocols, I would actually wait and see if it is more of a theoretical problem.

Ah BTW, in the nrf24l01 datasheet I also saw, that one should only use every second channel in 2Mbps mode, as otherwise you get a channel collision. Maybe one should adapt the random channel selection to only even channel numbers...

Of course increasing datarate means increased bandwidth, but we are swapping between two channels separated by 39 others for every packet we send, that is definitely enough separation...

Now compared stock TX to Devo output. (BTW this time the binding worked flawless???)
It seems both stick left right movements are reversed. If that is consistent, we should invert them by default.

Just tell me which channels to invert whenever you have finished your analysis, right now I'm more confused than anything else

Hi Moeder,
I just uploaded your 6s build.
It binds at first time, ail and ele channels works OK, but I had no throttle at all so cannot fly.
I have throttle on CH 1 is this correct or is it on another channel ?
Anyway I'm investigating.....
@Kaseknigger: can you share your ini file ?
Thanks again.

Try this build for your devo6s. It uses the "old" channel 1 code from ESky150

@dado099:
Is your ail also inverted? What model do you have?
BTW: I would not try to fly in the current state, as long as we are not sure all the channels work properly. Otherwise you risk quite a crash...

Since this affects so many protocols, I would actually wait and see if it is more of a theoretical problem.

That's the problem. Yes, it is unlikely, but as always, someone in the world might be just the ONE unlucky guy. An he will probably just be discontent with deviation and try something else...
And basically it isn't such a big code change. Maybe I can get at it tomorrow...

but we are swapping between two channels separated by 39 others for every packet we send, that is definitely enough separation...

Lol, I don't mean collision of the same TX/RX, but collisions with other people flying their helicopters in the same place. E.g. If I fly channel 10 and 50 and he flies coincidentally 11 and 51, or 9 and 49, we have a problem.
But again this scenario is unlikely, but also possible.
But I have to think again about it, if collisions are less likely if we have only half the channels, but these do not collide, or if we have all the channels but neighboring channels collide...
But then again other might more possibly fly other protocols...so...let's forget it...

I'm wondering if in the end it wouldn't be better to do it similar like victzh did it for SeBy to test. Just use the last digits of the id. Then one could easily change channels deliberately to a specific one, with a fixed ID. Currently due to scrambling you have no idea on what channel you will send.
I actually anyways do not get why we scramble the id at all. I don't see any advantage in this, honestly. The ID isn't more unique and the channel selection not really more random..
At the end we modulo it by 37. I don't see any less collisions happening with scrambling.

Will test the new dfu tomorrow. Now going to sleep, midnight now here...

Edit:
Did now some extensive binding tests, still with the "old" FW with random channels. And it always worked flawless...
I have no idea why it didn't worked, when I tried it the first time. But At the first time I was also at the same time setting up the model in my devo...Maybe there's some strange path in the SW so that one then goes in a state, where it doesn't work anymore???

@Moeder:
Thank you I will try the new dfu this evening (CET)
@Kaseknigger:
My model is (old) F150, the one with airwolf body.
I cannot see if ail is inverted until I have throttle working....
Thanks

Well cannot you see in which direction your swash is tilting, even without throttling up?
I would bet my left hand and right foot, that it is inverted...

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...

Ok, anyway cannot check until this evemimg...

One could try implementing the following, before packet assertion:
Then we could see if dado still has the throttle problems or not.

edit:
Another maybe nicer option would be to pack it into esky2_convert_2bit_channel proc

Had last night in the train again a thought about the 4 remaining data bytes, of what could they be for...failsafe?...no...and suddenly it made click: Are these trim values?
Now I tested this by SPI logging, and yes these are trim values.
They go from 0x9C (-100) to 0x64 (100) in steps of 4. So a signed 8bit int value. That makes 25 trim steps possible in both directions.
And the 4 bytes are also arranged in TAER format.
As devo includes the trims in the normal channel outputs these 4 bytes have to be 0, as they are now. But good to know what they are for.