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
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 in realtime 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.
Because ist 2014 and we can.
And there are numerous reasons to bring the messages to the streets (with a blinky twist).
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
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 :)
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.
(in case there is no embedded video look here http://www.youtube.com/watch?v=VX14pmky07Q)