Esky 150X, which protocol ?

More
20 Dec 2016 19:06 - 20 Dec 2016 19:07 #57059 by Käseknigger
Replied by Käseknigger on topic 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...
Last edit: 20 Dec 2016 19:07 by Käseknigger.

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

More
20 Dec 2016 19:14 - 20 Dec 2016 21:31 #57060 by Moeder
Replied by Moeder on topic Esky 150X, which protocol ?
Saw your edits now. You're right, I mixed up TX and RX addr. Please find attached an updated build for devo10.
Attachments:
Last edit: 20 Dec 2016 21:31 by Moeder. Reason: Updated Attachment

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

More
20 Dec 2016 21:33 - 20 Dec 2016 21:35 #57064 by Käseknigger
Replied by Käseknigger on topic Esky 150X, which protocol ?
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.
Last edit: 20 Dec 2016 21:35 by Käseknigger.

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

More
20 Dec 2016 21:54 - 20 Dec 2016 22:00 #57066 by Moeder
Replied by Moeder on topic Esky 150X, which protocol ?
:woohoo:

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

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.
Last edit: 20 Dec 2016 22:00 by Moeder.

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

More
20 Dec 2016 22:05 - 20 Dec 2016 22:10 #57067 by Moeder
Replied by Moeder on topic Esky 150X, which protocol ?
Here is the build for devo10

File Attachment:

File Name: deviation-...5640.zip
File Size:616 KB



If anyone needs a 7e test build please pm me, the zip is to big for forum uploads (silly 1 MB limit...)
Attachments:
Last edit: 20 Dec 2016 22:10 by Moeder. Reason: Attachment coming from virtualization...

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

More
20 Dec 2016 22:20 #57068 by Käseknigger
Replied by Käseknigger on topic Esky 150X, which protocol ?
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.

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

More
20 Dec 2016 22:28 #57070 by Moeder
Replied by Moeder on topic Esky 150X, which protocol ?
So with the new protocol you can now start flying 19 ms earlier :woohoo:

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.

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

More
21 Dec 2016 08:19 #57085 by dado099
Replied by dado099 on topic Esky 150X, which protocol ?
@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 ?

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

More
21 Dec 2016 10:18 - 21 Dec 2016 11:36 #57090 by Käseknigger
Replied by Käseknigger on topic Esky 150X, which protocol ?
@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...
Last edit: 21 Dec 2016 11:36 by Käseknigger.

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

More
21 Dec 2016 12:09 - 21 Dec 2016 13:53 #57093 by Käseknigger
Replied by Käseknigger on topic Esky 150X, which protocol ?
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 line
packet[2]  = ((flight_mode << 6) && 0xC0) | ((aux_ch7 << 4) && 0x30) | ((throttle >> 8) & 0xFF);
should obviously be:
packet[2]  = ((flight_mode << 6) & 0xC0) | ((aux_ch7 << 4) & 0x30) | ((throttle >> 8) & 0xFF);

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...
Last edit: 21 Dec 2016 13:53 by Käseknigger.

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

More
21 Dec 2016 14:36 - 21 Dec 2016 14:55 #57097 by Moeder
Replied by Moeder on topic Esky 150X, which protocol ?
This build goes back to fixed channels for now and has packet[2] corrected. And also for devo6 so we enlarge our testbed ;)

File Attachment:

File Name: deviation-...17af.zip
File Size:835 KB

File Attachment:

File Name: deviation-...17af.zip
File Size:616 KB



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.
Attachments:
Last edit: 21 Dec 2016 14:55 by Moeder. Reason: Added warning.

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

More
21 Dec 2016 14:51 - 21 Dec 2016 14:53 #57099 by Moeder
Replied by Moeder on topic Esky 150X, which protocol ?

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 :blink:
Last edit: 21 Dec 2016 14:53 by Moeder.

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

More
21 Dec 2016 19:25 #57108 by dado099
Replied by dado099 on topic Esky 150X, which protocol ?
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.

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

More
21 Dec 2016 21:16 #57111 by Moeder
Replied by Moeder on topic Esky 150X, which protocol ?

File Attachment:

File Name: deviation-...2-21.zip
File Size:834 KB


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

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

More
21 Dec 2016 22:58 - 22 Dec 2016 09:38 #57112 by Käseknigger
Replied by Käseknigger on topic Esky 150X, which protocol ?
@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???
Last edit: 22 Dec 2016 09:38 by Käseknigger.

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

More
22 Dec 2016 08:44 #57115 by dado099
Replied by dado099 on topic Esky 150X, which protocol ?
@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

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

More
22 Dec 2016 08:47 - 22 Dec 2016 09:35 #57116 by Käseknigger
Replied by Käseknigger on topic Esky 150X, which protocol ?
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...
Last edit: 22 Dec 2016 09:35 by Käseknigger.

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

More
22 Dec 2016 09:05 #57117 by dado099
Replied by dado099 on topic Esky 150X, which protocol ?
Ok, anyway cannot check until this evemimg...

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

More
22 Dec 2016 09:24 - 22 Dec 2016 09:45 #57118 by Käseknigger
Replied by Käseknigger on topic Esky 150X, which protocol ?
One could try implementing the following, before packet assertion:
if (Model.num_channels < 7) aux_ch7 = 0;
if (Model.num_channels < 5) flight_mode = 0;

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
if (Model.num_channels <= num) ch_out = 0; //set unused channels to zero, for compatibility with older 4 channel models
else
{
...
}
Last edit: 22 Dec 2016 09:45 by Käseknigger.

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

More
22 Dec 2016 10:53 - 22 Dec 2016 10:59 #57120 by Käseknigger
Replied by Käseknigger on topic Esky 150X, which protocol ?
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.
Last edit: 22 Dec 2016 10:59 by Käseknigger.

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

Time to create page: 0.065 seconds
Powered by Kunena Forum