Distributed learning/reprogramming

I’ve been thinking about your distributed learning model via IR, and had a few questions:

  1. Blink Program Layout: What is the physical layout when doing the IR distributed reprogram?

Star pattern with central Blink as the program sender and the surrounding Blinks as receivers of the new program?

  1. Blink Depth: Can they be more than 1 deep off of the program sender?? (e.g. a row of Blinks, or 2+ deep in star pattern?)

  2. Data Validation: How are you ensuring the receiving blinks are receiving all of the correct data? And when is the validation performed? (per data packet, per bunch, at program end??)

  3. Message Queue/Buffering: Is there a message queue (bufferign), or only last received (depth=1; overwrite)?

  4. Transmission rate: (directly tied to (3) and (4)) - what kind of data transmission speeds are you reaching reliably?

  5. IR Timeout: Given that Blinks are continuously broadcasting and an IR timeout is only when there is no neighbor (or neighbors off); how are you distinguishing valid repeated data from old stale data? E.g. if the receiving BlinkOS in a “read loop” sees 0x11, 0x22, 0x22, 0x22, 0x33 - how can you tell if the 2nd or 3rd 0x22 is a rebroadcast of previous (stale) data or is a purposeful send of the same data?

Thank you,

  1. This is up to the user, the most efficient transmission of a game will be the most dense packing (i.e. star pattern with central Blink as the program sender), This is not enforced though

  2. Yes, each Blink will first receive, verify reception, then immediately try to share it with its adjacent neighbors.

  3. This is in active development, definitely share thoughts on this with @bigjosh, an important part of game transmission for sure.

  4. If I understand this correctly, the designed architecture is to have a buffer such that the game being played will only be overwritten once a successful transmission of the new game arrives into the buffer.

  5. With our Dev Kit Blinks, our data rate is ~ 666 bits/s. Games should be < 4K

  6. Gonna let @bigjosh weigh in on this one as well :slight_smile:


The State model paradigm could work but seemed sub-optimal for this purpose [sharing Blink program data]. This relates back to the discussion (dropbox API) on IR constant broadcasting and the expire flag only means “no neighbor detected”.

If blinks can be more than two plus layers deep than message queues could make faster transmission rates but it requires a more complicated protocol. Or, a queue depth of one for a simpler model and “fixed” transmission rates. Either way, the ability to detect new vs old (stale) data was a prerequisite, and the data validation (for obvious reasons).

Look forward to hearing more. Thank you.

When is the IR method of programming going to be completed and distributed?