|
|
|
|
|
|
|
"Might as well send current stick position" makes a whole lot of sense. Why it would wait for a reply would only makes sense if it intended to do something about it if it did not get a reply. Which if it did Jim would be all over these threads. Which he isn't.
So since a laymen such as myself can only make use of information at hand would decide XPS just is not the way to go 2.4.
I have no intention to bash anyone but the proof is in the pudding. He would settle this matter quickly if it was possible.
Since for me XPS is a dead horse I am WAY more interested in how they all stack up to interferance before "lockout".
Very patiently waiting on those results should the testing get that far.
Thanks KIWI  |
|
|
|
|
It's a module based system with PPM signal as the input.
PPM frames are 20ms long. XPS can not send updated stick positions until the next
PPM frame comes along. However, if it fails to receive an ACK for the first packet it sends
(which could mean the Rx can't hear the Tx, or the Tx can't hear the Rx), it has 3 more
opportunities to re-transmit that same packet (can see it all in my screencaps posted above),
before the next PPM frame comes along with updated stick positions.
There's nothing illogical about how it works, and it can't really work any other way.
Packets are occasionally lost, and need to be retransmitted to avoid loss of responsiveness.
If it were tied directly to the Tx CPU then it could send updated stick positions much more frequently.
ian