I am rewriting parts of blinklib and I added some checksum code for packets. I let a ping-pong among a cluster of 7 Blinks for several hours and not even once I got an invalid checksum. I am wondering if BlinkBIOS does its own checksum and if, in practice, it is possible that I would get a corrupt packet inside blinklib if I did not use a checksum. If BlinkBIOS already does it, maybe I can get hid of blinklib checksums altogether? That would reduce code size and simplify code in a non-negligible way (also free some more memory for user programs).
Yes. I was poking through blinklib recently and noticed that it does a parity check on the IR interface. That’s partly why the user-accessible part of the IR interface is only six bits. One of the extra bits is used for odd parity. The other is to handle keep-awake signaling when you click a button.
1 Like
Yep. There is also a checksum byte for datagrams, but my theory is that none of this is strictly needed as it does look like BlinkBIOS itself already does checksum checks when transmitting data (which makes perfect sense at its level but I can not say for sure as there is no source available for BlinkBIOS).
In any case, my partial rewrite should have some interesting perks:
- Built-in guaranteed delivery datagrams.
- All 256 possible values available for face values.
- Datagrams will not be able to cause starvation of face values.
- Removal of brute force approach to send special packets (force sleep/wake up).
- Reliable and high performance sending of big datagrams even when sending on all faces.
- The above is made possible by a huge minimization on possible collisions obtained mostly by better setup of send deadlines. Technically one can still have collisions but they are VERY unlikely).
This all with using LESS memory than the current version (although not much less) and striving to use less or the same amount of storage (it is not complete yet, so I am not sure).
Also, Only very small API changes (notably the face values mentioned above and the fact that sendDatagramOnFace will return a bool to indicate success or failure to send.
Also relevant is a slightly change on semantics (that I might revert) where if you send multiple datagrams and the other side do not mark them as read, datagrams will be overwritten in the destination (currently they are not overwritten and new datagrams are lost). Also when sending, if there is a pending datagram it will not be overwritten (currently it is) and sendDatagramOnFace will return false as mentioned above.
4 Likes
Whoa sounds like you’ve done a ton of work! Looking forward to it.
1 Like
Yeah, I am kinda hooked on this Blinks thing. 
I should have something usable by next week. I am happy enough that this should save enough space for my game that I will be able to implemnte at least some of the animations I want. 
3 Likes
BlinkBIOS does not do any checksums - it just sends the raw bytes with special pulses at the start and end of a packet.
That said, on the RX side it does do a lot of error checking and silently ignores any packet that fails because, say, the timing between two pulses is outside the permissible window or the number of bits in a packet is not an even multiple of 8.
Yes, it is possible and it does actually happen in the wild, you just might need to wait a while. I aimed for on the order of about 1 bit error in 1,000,000 bits although this is dependent on lots of factors like environment and manufacturing tolerances on each individual TX and RX unit. This is the purpose of the parity bit and the checksums - to reduce the number of these corrupted bits that make it up to the user layer (but know that you can never totally eliminate these as per Shannon-it is always a trade off between fidelity and throughput).
2 Likes