Blinkenschild
What
The Blinkenschild project
- is aportable sign
- consists of:
- 15 pcs RGB-123
- counts a total of 960 pixels (40x24)
- a teensy 3.1 for control
- a microsdcard reader interface
- a bluetooth module
- 15 pcs 400 mAh LiPo
How
960 individually addressable RGB pixels run DIRECTLY at 15 pcs 3.7-4.2V LiPo s in parallell (each 400mAh)
I had lots of those thats why.
Animations are generated with Glediator and saaved in the native glediator protocol
A frame starts with 0x01 and is followed by 960x3 bytes RGB data.
These information is saved in a single file via a nice hack involving socat to capture the serial data.
Glediator2 is GREAT software but unfortuneatly it is NOT open source, just free to use :((
The animations are on a microsdcard on a FAT16 filesystem read by the teensy 3.
There is an android app that lets you pick the animations over bluetooth and set a text and text colour for overlay and brightness for both animations and text.
This is done in realtime and pixelvalues are recalculated before display.
This is still too fast so i had to add 30 ms delay between the frames or we would not perceive it as a fluid animation but rather just blinking bright light.
Teensy 3.1 is a GREAT MCU, OctoWS2811 is incredible fast.
Why?
Because ist 2014 and we can.
And there are numerous reasons to bring the messages to the streets (with a blinky twist).
Lessons learned
Hardware
The RGB-123 panels can be powered DIRECTLY from a LiPo cell between 3.7 and 4.2 volts.
The WS2812 dtasheet says you need 5V signal levels, but the WS2811 datasheet states that the signal levels must be at least 70% of the VCC.
As VCC is between 3.7 and 4.2V the 3.3V signal levels are well within that range.
When changing from teensy 3.0 to teensy 3.1 i experienced some weird flickering.
After hours of debugging i found out that it is a software issue with teensy 3.1 and the OctoWS2811 libraries.
Upgrading to the latest -rc1 teensyduino environment worked fine.
Also there is a thread on the internet about this erratic behaviour:
And this is the difference int he OctoWS2811 lib that does the trick.
> #ifdef __MK20DX256__ > MCM_CR = MCM_CR_SRAMLAP(1) | MCM_CR_SRAMUAP(0); > AXBS_PRS0 = 0x1032; > #endif
Software
general knowledge
Animations are generated with Glediator.
Glediator support GIF files, nad thats great for pixel animations .. protip: you can search on google for animated gifs at a certain size.
To display the gifs correctly each frame needs to have the "dispose" flag set, you can do this in photoshop, i am sure there is a way to do this automatically with image magick, but i really like photoshop for image editiing.
The Glediator output structure looks like this:
0x01 marks the head of frame
It is followed by (<no of pixels> * 3) bytes of data. These bytes describe RGB values but how they are ordered (RGB,RBG,BGR,GRB,GRB,GBR) can be selected in the glediator output configuration.
In OctoWS2811 you can use setPixel(int <no>, int R, int G, int B) to set a pixel.
I output the animations using GRB color encoding and horizontal linewise starting bottom right (HL_BR) order of strips.
I have a lookup table for the 960 leds that show what pixel is at what position.
hacks
Glediator is GREAT. It can do 12324 things, runs on all the platforms and performs really well.
Unfortuneatly it is not open source.
There are options to send data out over serial but not over IP and not directly into a file.
But we are hackers around here so we can fix this in software. right? right.
socat is the tool of choice. Lets create a virtual serial port and dump its output to a file :)
The magic:
socat -d -d -lf socat.out pty,raw,echo=0 - > $file
java -Dgnu.io.rxtx.SerialPorts=$pty -jar Glediator.jar -d32
Might not work depending on your librxtx.. you might want to symlink /dev/ttyACM0 to /dev/pty/? and start java as root.
Who
Files
https://github.com/hackerspaceshop/Blinkenschild
Media
(in case there is no embedded video look here)
