How fast is IR transmission?

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.

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.

Thanks for the clarifications but you totally dodged the question :slight_smile:
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);

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:

  1. 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.
  2. 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.
  3. 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:

1 Like

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

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.

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

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. :slight_smile:

1 Like