Oh no it’s fine, Quads need comm protocols too.
I’d like to 3D print a superstructure and go from there. 3D printers are expensive tho.
Updates:
I’ve revisited C4 and finally added the needed packet number reset system command that allows two desynchronized devices to resync automatically.
Basically let’s say device A was about to send packet #5 when device B loses power. Device B comes back on moments later but it’s state is gone, and it now expects packet #1 (the default stating packet number).
Well problem is device A is trying to resend packet #5 over and over again because that’s the last un-ACK’d packet, and device A has no idea that device B reset and is now expecting packet #1.
So instead of just sending back the un-ACK’d packets, device A now sends a message telling device B what packet it’s on before every resend batch. Device B can decide (based on a number of rejected packets) to change it’s expected packet number to match that of device A, thus resyncing the two devices.
I’ve also written code that forces a new connection to wait for one of these sync events before it starts accepting packets. This prevents a device that goes offline and back online from accidentally processing one of the wrapped around packets that is being resent from the other device out of sequence.
TBD:
What needs to be done next is a little clearnup, followed by ports to ROBOTC / PROS / ConVEX / Windows, one by one with more advanced testing under some more real-world conditions.
I’ll also be creating some example commands, for testing and documentation.
I think I’ve covered most of the nasty edge cases, but I’m sure there’s something I’ve missed. The more this gets tested the more confidence I’ll have in it.