Deviating a JoySway

Doesn't build - undefined reference to `JOYSWAY_Cmds'.

hg doesn't report any new files between the default branch and the joysway branch. Did you forget to add the joysway protocol source before committing?

It's an easy mistake to make. Thanks!

That builds. Unfortunately, I've got multiple Dr's appointments to get me or my mother to over the next three days, most of them over an hours drive away. I'm not sure when I'll be able to actually test it.

Does not bind. If I bind to the Tx I tested with first, it connects. I have two Rx's, and both work that way.

One Rx works fine on channels 1-3, but channel 4 does nothing,. The other Rx is a two-channel and both channels (1 & 3) work fine.

Is there some other capture that would help with this? Binding or connecting with the other Tx, maybe?

Capturing stuff from the Devo is liable to be hard. I would rather avoid it if at all possible.

Channel 4 is indeed the rudder output from the devo. I have four channels defined in the model setup. I just took an empty model & changed the protocol to Joysway.

The rudder channel now works in both the EVEN_ODD 00 and EVEN_ODD 01 builds. However, neither binds when I press the Rx bind button. Hitting re-init while the Rx is flashing doesn't seem to make any difference. Neither does whether or not an ID is set (though I didn't expect that to work based on what you said).

The connect capture is turning on the Rx. The bind capture is hitting the bind button on the Rx, which causes it to disconnect and then bind. If I turn on an Rx that is not bound to the Tx, it doesn't connect.

Could the difference in the pattern be whether or not the Tx thinks it's connected? In the init (tx-poweron?) capture, there is no Rx turned on, so it's never connected. In the connect capture, it starts out disconnected and then connects, and in the bind capture it starts connected, disconnects when the Rx starts a bind, then reconnects. For the other four, it's connected the entire time.

You want a 10-20 second capture. What should be happening then? And which captures would you like to rerun if that fails? And finally, do I need to do anything to make a bind happen? On the Joysway tx, that's not required - it sees the Rx binding, and just does so.

Ok, done.

drive.google.com/file/d/0B72nhihrc01MLXB...RVk/view?usp=sharing

This starts with the Tx on and the Rx off. I turn on the Rx, hit the bind button on it, wait until it binds, then hit it again and let it bind again. I suspect that the missing transition was going from not bound to bound, as I think the other "bind" version started with the Tx bound.

The trims capture is all the trims button. What should have been the second aileron button press didn't happen, so I went back and added it at the end.

Ok, the current build binds, and all four channels work.

If the bind ID could do something useful, it'd be nice if that worked. Other than that, I'd say this was ready.

The fixed ID version no longer binds.

Just changing initialize to use a fixed id doesn't fix the bind issue.

I actually have 3 Joysway Tx/Rx pairs (that's pretty much the way they sell them). The most interesting two interoperate, but the third does not.

So, which is more useful? Going back to the working version and trying that set of ids, or captures from a second Tx? If the latter, will just the disconnnected->bind->connected state do, or do you need the full power on/bind/bind again?

Ok, here's what I got. I tested them in order:

0xf82dcabf -- binds
0xf82dcaa1 -- binds
0xf82dc9a0 -- binds
0xf82dcba0 -- connects without binding
0xf82ccaa0 -- binds
0xf82ecaa0 -- connects without binding
0xf72dcaa0 -- doesn't bind
0xf92dcaa0 -- doesn't bind

I tested the two ends of the range: 0xf8000000 & 0xf8ffffff. Those both bound.

I then added BSD's random ( svnweb.freebsd.org/base/stable/10/lib/li...n=256281&view=markup ) to the source, and had initialize add the low order 24 bits (all the bits are random) a new random number to 0xf8000000. Loaded that, hit bind on the Rx. Hit re-init, the Tx disconnected. Hit bind on the Rx again. It rebound. Did the reinit/bind thing a hundred times, and every time it disconnected as expected, and then rebound. The rebind times varied between instantaneous and taking most of a second.

Also tested 0xf7ffffff and 0xf9000000. Neither bound.

"connect without binding" means that after changing the value, building and installing the DFU, power cycling the Tx and turning on the Rx resulted in a connection. Other times, it needed to bind beforehand. I did the two that are reported as connecting without a bind twice, to make sure I hadn't skipped a step that might have left the old version on my Tx. I actually just reran them again to check again.

I could recreate this - but on a hit or miss basis - by tweaking one bit in the value after binding. Tweaking two seemed to fail regularly, even if I connected with the intermediate value.