New ideas never stop lighting up my brain. In an attempt to come up with some way to still have a functional POV Poi system when there is no SD card present, I thought why not program them in. There are several poi systems that already do that: you get the ability to select different patterns, set different modes on each, and then run them as a sequence. So, I came up with the following which I may still do on the current v1.0 release – after figuring out how or where I’m going to add the additional button:
- single chase along the stick; option to set color, speed, and direction
- multiple chase along the stick; option to set color, speed, direction, and how many pixels
- single fading tail chase; option to set color, speed, and direction
- flashing pixels; option to set color, and flash rate
- simple shapes like squares, circles, star, triangles; option to set color, flash rate, filled or transparent
- “Knight Rider” chase; option to set color and speed (this would create a wave pattern when spun)
As I keep thinking about it and once I start writing code, I may come up with additional patterns. The idea is that if a unit does not have an SD card in it, it will automatically default to the build-in patterns. When there is an SD card present, the unit will also allow the end-user to use the build-in patterns, either exclusively, or mixed in with the patterns on the SD card.
The build-in pattern sequences that the end-user create will be stored in EEPROM when the unit is running without an SD card, or the user can set the various options in the same control file that the SD card would use if present. One example would be to do something similar to the following:
<img name>|<refresh rate>|<timeout>|<delay between images> <pattern#>|<color>|<speed>|<direction>|<optional>
- color can be one of the seven defaults, or an r,g,b decimal value from 0 to 255 for each
- speed will be a value between 0 and 5 and will map to 0=25ms, followed by 50ms, 75ms, 100ms, and 150ms for refresh values
- direction is simply -1 for backwards, 0 for stand still, and 1 for forward
- the optional value will be used for those patterns that have a fourth value
- The running code will have to determine whether what it’s going to display is a build-in pattern, or an image from the SD card.
Something else I ran into this past weekend as I was testing and demonstrating the prototype was data corruption after running for a while. I’m not entirely sure it actually is data corruption, or whether the voltages are just too low for the drivers to latch the data. So I’m going to push the voltage to 5V instead of running at 3.3V. The MCU will still remain at 8MHz though. And I am seriously considering keeping the output down to 1/8 power, or at the very least use a button to adjust the output. Running at full brightness is just way too much. Anyone attempting to take a picture will get it all washed out. So I’m thinking the settings will be 32, 64, and 128. Right now I’m running with a brightness of 32 and it’s plenty bright, even with moderate stage lights. The only issue with lowering brightness is that you also lose the full color fidelity. Meh!