How fast is IR transmission?

bearclaw · December 6, 2020, 7:35pm

How long does it take between a setValueSentOnFace() on one blink and the value being available in the GetLastValueReceivedOnFace() of a connected blink (assuming the second blink has nothing else in the “loop” function)?

I ask because I’m working on a game that does a lot of broadcasting, and I need more than 6 bits (10 actually) of state and I’d rather avoid the datagram api. So I’m thinking of rapidly cycling between my two pieces of data.

BGA · December 6, 2020, 7:50pm

The face value API transfers a single byte so it is relatively fast, the main issue here is that the transfer speed can be estimated but not relied upon as there is no guarantee that a face value sent in a loop iteration will be received by the other end in that same iteration. The API itself is designed in a way this does not matter (it will eventually get to the other side) but trying to rely on any timings is a sure way to have very subtle bugs in your code.

bearclaw · December 7, 2020, 5:49am

Thanks for the clarifications but you totally dodged the question
I don’t need to send synchronously, nor even having consistency between the two bytes.
If I take a 10x margin compared to the theoretical transmission time I’m pretty sure I can reach something reliable.
I’ll experiment with something like
if (millis()/something%2) setValueSentOnFace(data1); else setValueSentOnFace(32 | data2);

BGA · December 7, 2020, 2:21pm

Well, I did not try to dodge the question. Giving a specific value for the time it takes for a face value to “show up” in the other blink is both difficult and irrelevant. Some of the factors that will completelly screw the timing:

Number of connected faces. The value is sent serially to each connected face and if everything goes right, a Blink connected to face 0 will receive it first (in wall-clock time) than a blink connected in face 5.
It is possible that you send a value and it takes more than one loop iteration to get to the other side due to a collision. In this case not only the loop time of the “destination” Blink would be relevant but the time the local Blink takes to run its loop will too.
IR interference, which might make everything take longer and make values be incorrectly transmitted and dropped because they are invalid (might even happen without any obvious IR interference source).

You might try that, yes, I suspect you might get frustrated. If you want to approach anything close to reliability, you would need to design it through signaling. Something like this:

github.com

scartier/commtest/blob/master/commtest.ino

// TILE COMMUNICATIONS
// by Scott Cartier
//
// Tiles use the value on their faces to communicate to their neighbors.
// They can send six bits of data (0-63).
//
// The protocol here uses one of the six bits as a TOGGLE bit that changes
// with every new piece of data. Additionally, one bit is an ACK bit that
// tells the neighbor when the current value has been received.
//
// Because one bit toggles with every new value sent, the receiver can
// always tell when there is new data to read.
//
// Bit 5: ACK BIT - Equals the last received TOGGLE BIT from the neighbor.
// Bit 4: TOGGLE BIT - Toggles between 1 and 0 (command and data).
// Bit 3-0: COMMAND or DATA - The payload value.
//
// When the neighbor's ACK BIT equals our TOGGLE BIT we know the neighbor 
// processed our current value and is ready for the next one.

This file has been truncated. show original

ScarPixel · December 9, 2020, 3:18am

I was just going to point to my comm algorithm aaaaand @BGA beat me to it

I’ve improved it a bit since that first release as I used it in both Terrarium and Blackout, but it is largely the same.

Before I start on my next game I want to come up with something a bit more robust to send arbitrary length packets. Right now it can send a 4-bit command coupled with a 4-bit data payload. If your payload is longer than that it will take multiple commands to send.

BGA · December 9, 2020, 5:14am

Sorry… You need to be really fast to beat me here.

You can both use face values for signaling and datagrams for actual data transfer or do straight datagrams for both (basically implementing guaranteed delivery of datagrams) I experimented with both and got them to work. The straight datagrams version was cheaper but was still a lot more costly and with more corner cases than simply doing it in blinklib. This is how my custom blinklib started.