Protocol Stacks

PhracturedBlue wrote: I spent some time double checking my code against the sample logs I got from renatopub. I don't see anything else wrong, so if it still doesn't work with the last build and fixed-id, I'm stumped. In that case, I guess I'll dump my logs and make sure what I see on the emulator is what I see from the Tx.

Sorry, I couldn't check the latest build yet, because I'm at work now!
I will check it later, when I get home...

FDR wrote:

PhracturedBlue wrote: I spent some time double checking my code against the sample logs I got from renatopub. I don't see anything else wrong, so if it still doesn't work with the last build and fixed-id, I'm stumped. In that case, I guess I'll dump my logs and make sure what I see on the emulator is what I see from the Tx.

Sorry, I couldn't check the latest build yet, because I'm at work now!
I will check it later, when I get home...

That is fine. I checked the tx spi logs and they match what renatopub sent, so if it still doesn't work, I am at a loss.

Note that to change the fixed_id, you need to edit the ini file on the tx through your PC. Because the max-value is limited to 99999, you can't enter the id I listed above. But it works ok if you enter it through the ini file.

Yep, it binds now with the new build and fixed id!
Without the fixed id it didn't bind...

However, the servo extends and the throttle value is too low!
It might use different output range, I guess...

EDIT: I've used: fixed_id=487193

FDR wrote: Yep, it binds now with the new build and fixed id!
Without the fixed id it didn't bind...

However, the servo extends and the throttle value is too low!
It might use different output range, I guess...

EDIT: I've used: fixed_id=487193

Glad to hear it.
Can you try different values? 487192, 487194, 487182, ...

I'm not surprised about the servo throw. I see the same thing for all other protocols. I need to measure the throw with the real tx to try to figure out why the range is wrong.

...and looks like aileron is reversed, but I have to double check that...

We need to figure out how you can compile the code yourself.
Since there are things you could do (like playing with the range) which would be easier to do if you could compile the code.

It has bound with 680913, so I guess any value will do...
I don't remember that I could set fixed id with the 2401 protocoll in my WK2801Pro thow...
Probably it is just the fw has to have a value, even a random one...

PhracturedBlue wrote: We need to figure out how you can compile the code yourself.
Since there are things you could do (like playing with the range) which would be easier to do if you could compile the code.

Yep!

Or we should ask renatopub to dump some more spi with the maximum channel throws (with and without maxed servo extends)...

yes, WK2401 and WK2601 do not have 'fixed' id. They just internally generate one.
Since I already have an interface for fixed_id, I see no reason not to allow the user to use it (It won't reduce bind time though). I am somewhat surprised though, since the previous build had a hard-coded id (non zero) and it still didn't work.

As for building, I'm currently trying this:
www.microbuilder.eu/Tutorials/SoftwareDe...ingGCCToolchain.aspx

That should provide the same toolchain that we use on linux/mac

FDR wrote: ...and looks like aileron is reversed, but I have to double check that...

I can confirm, that the aileron channel is reversed!

Is it correct for the other protocols?
Is the right horizontal stick input is corrected? Because while my rudder (left horizontal stick in mode 2) goes negative in the left, the aileron goes positive in that direction!

PhracturedBlue wrote: Since I already have an interface for fixed_id, I see no reason not to allow the user to use it (It won't reduce bind time though).

Agree, but if there is no fixed id defined, then we should generate a random one!

FDR wrote:

PhracturedBlue wrote: Since I already have an interface for fixed_id, I see no reason not to allow the user to use it (It won't reduce bind time though).

Agree, but if there is no fixed id defined, then we should generate a random one!

That is what I'm saying. I did that and it didn't work for you.

FDR wrote:

FDR wrote: ...and looks like aileron is reversed, but I have to double check that...

I can confirm, that the aileron channel is reversed!

Is it correct for the other protocols?
Is the right horizontal stick input is corrected? Because while my rudder (left horizontal stick in mode 2) goes negative in the left, the aileron goes positive in that direction!

I think they use the same gimbal setup in both left and right sticks, just rotated 180-degrees. this would explain why the throttle was reversed (I have code that fixes that). Probably need the same thing for the rudder. (or maybe it is the right-stick that is reverse). In either case, fixing it is easy.
Since I' haven't used the deviation firmware on an actual model, I haven't noticed whether the channels all move in the right direction or not

wuselfuzz wrote: I got the rx binding without the fixed_id string.

I know the wk2801 has a special case for when the id is '0' (which is not allowed). I expected that any value other than 0 would work.
I'm not sure about an RNG (seems wasteful to include a prng just for this one function), but I thought the crc of the model file would make a good id when none is specified.