BlinkyTape development -- where to start?

baat

I'm looking for software specs/API info for controlling BlinkyTape. This is such a cool device I'm thinking I might have the skills to develop a Linux (and maybe Mac OS X) command line tool in C.

The Device::BlinkyTape perl module here http://search.cpan.org/~okko/Device-Blinkytape-0.001-TRIAL/lib/Device/BlinkyTape.pm has this near the bottom of the page:

AUTHOR

Oskari Okko Ojala

Based on exampls/Blinkyboard.py in Blinkiverse's BlinkyTape repository at https://github.com/blinkiverse/BlinkyTape/ by Max Henstell (mhenstell) and Marty McGuire (martymcguire).

I'm not finding Blinkyboard.py. I was expecting it to be in https://github.com/Blinkinlabs/BlinkyTape_Python

I realize stuff may have moved around since Device::BlinkyTape was first developed.

Matt Mets

Hi Batt,

Things have indeed moved around a bit since then! The python example is here now:
https://github.com/Blinkinlabs/BlinkyTape_Python/blob/master/BlinkyTape.py

BlinkyBoard was the working name for the project before it became BlinkyTape.

The protocol is hopefully pretty basic. Basically, you send one byte each for the red, green, and blue values of the first LED, then repeat for each LED up to 60, for a total of 180 bytes. The color values range from 0 (off) to 254 (full brightness). Then, you send a 255 a couple of times (0xFF), which signals the strip to display the colors. An example that updates the first three LEDs with the colors R, G, and B would be like this:
[254][0][0][0][254][0][0][0][254][255][255]

The first set: [254][0][0] make the first LED red
The second set: [0][254][0] make the second LED green
The third set: [0][0][254] makes the third LED blue
Finally, the [255][255] instructs the strip to display the new colors.

Note that because the LEDs are wired in series, it isn't possible to update them one at a time- the whole strip needs to be refreshed every time.

Cheers,
Matt

baat

Matt, thank you VERY much! This will get me started.

1. In BlinkyTape.py under show() it says, "discards any accumulated responses from BlinkyTape". What kind of responses does a BlinkyTape send, and how would I read them?

2. Also in BlinkyTape.py, I see resetToBootloader -- what exactly does it reset and what state is the BlinkyTape left in?

3. Are there any other firmware features that I might be able to, or might want to, take advantage of that are not currently present in BlinkyTape.py?

4. Lastly, the feature that I'm most interested in is a way to send a static pattern to the BlinkyTape, say via a Perl script, have the Perl script end and have the BlinkyTape keep the static pattern and not resume the rainbow pattern. How could I do this? I'm wondering if https://github.com/Blinkinlabs/BlinkyTape_Arduino/blob/master/examples/ColorSwirl/ColorSwirl.ino in the serialLoop() code would be related to this. Specifically, the comment "If we haven't received data in 4 seconds, return to playing back our animation"? If I had a way from Perl to disable the resumption of the rainbow animation, and then another way to enable it again, I think that would work for me. But I don't see any methods In BlinkyTape.py or in Device::BlinkyTape that allow this.

Threeethan

Hey baat,

Great questions - I'm not too familiar with the Python methods but I'll take a stab at them - on 1 I believe it just sends back some acknowledgements bits etc; nothing too useful. On 2, I believe that resetToBootloader puts the tape in the state where it can receive a firmware update. And 3 - I don't believe so.

4 is a very interesting question - are you looking to put patterns onto the tape permanently, or do you plan to have the tape hooked up to the computer? If it's the latter, it should be easy enough to keep feeding the images to the tape (even if they're not changing.) Alternatively you'd have to change the firmware on the tape to add new features.

Also, if you want to permanently change the pattern, that should be possible - in PatternPaint we actually flash new firmware onto the tape using some command-line programs - and you should be able to do this pretty easily in Perl as well.

Matt Mets

Couple small notes-

#1, it is some diagnostic flags that were used during production of the BlinkyTape. There should be 1 byte of data returned, with bits set corresponding to each of the inputs on the BlinkyTape (the button, and the three tiny I/O pads on the bottom of the BlinkyTape controller). A little confusingly, though, if you load any of the Arduino examples or use Pattern Paint to write a new pattern, then the new program won't send these bits.

#4, there are two options to prevent the strip from going back into rainbow mode. First, you could upload a new Arduino sketch to it, with the delay lines commented out (thus disabling the feature). Otherwise, If you set up your python program to send a new image (it can be the same one, just repeated) every few seconds, then it will reset the counter, which will also prevent the rainbow sketch from showing up.

baat

Thanks for getting back to me, Threeethan and Matt.

do you plan to have the tape hooked up to the computer

Yes. The pattern will not be permanent and will change on the fly. For example, a progress meter representing 10 steps would turn six LEDs on at a time. Each step might be part of a shell script copying files, say 10 files to make it simple. I'd have a script that would accept a number and trigger that many groups of six LEDs.

cp source/file1 destin/file1 btape 1 cp source/file2 destin/file2 btape 2 cp source/file3 destin/file3 btape 3 ...

you could upload a new Arduino sketch to it, with the delay lines commented out (thus disabling the feature).

Looks like I'll be creating a new Arduino sketch, something I've not done but it'll be fun to try. Since all data sent to the BlinkyTape is either going to be new firmware or a new pattern, is it practical for me to create a new firmware function similar to resetToBootloader such that a baud rate of say 2400 disables the delay? I'd like some flexibility in switching between the two modes without having to reload the firmware all the time.

Threeethan

If you plan to have the tape hooked up to the computer for this, then there's not really much functional reason to change anything low-level (as far as I can see.) The only benefit to doing the Arduino approach is so the tape will retain patterns even after it's unplugged.

If you're going to be doing everything from a central shell script, I think I'd make several simple python scripts that run in the background and send a single pattern to the tape (effectively sending it over and over again so the rainbow pattern doesn't return.) Then when you get to the next step, end the previous python process and start a new one with a different image.

That said - I think you'd really enjoy hacking on the Arduino side of things, so give that a go by all means! It's fairly clear what does what in there but we're here for questions.