Improve telemetry communications

[MatzElectronics]

Implement xon-xoff in FTDI chip, GS, and FC. This is a breaking change.

[JasonDorie]

XOn / Off is software only, so the FTDI shouldn't need to be involved. Not
sure what the benefit would be though. At some point, packets will get
lost. I'd rather they were the old packets, not the new ones. Reduce the
XBee retry counts, and possibly switch to using API mode with the XBee
instead of pass-through (if it can be done without requiring additional
pins).

J

On Friday, September 16, 2016, Matthew Matz [email protected]
wrote:

Implement xon-xoff in FTDI chip, GS, and FC. This is a breaking change.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#23, or mute the
thread
https://github.com/notifications/unsubscribe-auth/ANak_nbLo8ghIDhfQphw0LicSbZbI3dXks5qq3iUgaJpZM4J_gwa
.

[MatzElectronics]

Open to suggestions, or even calling where it's at good enough...

[JasonDorie]

I just want to know what you expect to get from enabling flow control. It
would mean not corrupting packets on slow delivery, but the packet loss
itself is from the XBee failing transmission. If loss happens, flow
control will make new data wait for old data to finish going through, but
for realtime display, it's more relevant to have new data prioritized over
old data. It's never going to be a lossless connection.

I was thinking it would be worthwhile breaking the comms and making new
packet types that were packed. I'm using 16 bits to transmit each radio
value, even though they're only 11 bits each. Ditto for motor values, and
others could be reduced similarly. It would cost a bit of code time to
pack them, but there'd be less to send, so more room for retries.

J

On Saturday, September 17, 2016, Matthew Matz [email protected]
wrote:

Open to suggestions, or even calling where it's at good enough...

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#23 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANak_gyu9xAnekh4PBDJ3hKcQIDgm_Vbks5qq6Q0gaJpZM4J_gwa
.

[JasonDorie]

Telemetry comm is now using less data per packet, and packet transmit rate has been reduced by 20% (coinciding with 20% reduction in update rate), giving more time for retries. In theory, this should improve reliability - can one of you check this?

[MatzElectronics]

I might be able to tomorrow, I'll let you know either way

On Oct 4, 2016 9:00 PM, "Jason Dorie" [email protected] wrote:

Telemetry comm is now using less data per packet, and packet transmit rate
has been reduced by 20% (coinciding with 20% reduction in update rate),
giving more time for retries. In theory, this should improve reliability -
can one of you check this?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#23 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AS0quClYUvbcLtXVGbqcg0p_6Z6nUq5mks5qwyDlgaJpZM4J_gwa
.

[MatzElectronics]

Closing - addressed in #40.