Danny HavenithNo LED identification without LEDs, so the first step in this project has been to order an LED string. After a ~20 day wait (shipping to Europe seems to take the longest), they arrived. Time to start coding.
First: let's see if my ws28811 driver still works for these strings...
Aaaand: no. Weird colors. But wait a minute, when I send pure red, green or blue, it quickly becomes clear that these strings don't accept their RGB values in G, R, B order as I'm used to with WS2811s, but in R, G, B order instead. So that's an easy fix and before the evening is over, we've got lights:
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
I've considered using the three channels in parallel, but first I'd like to get this to work on single channel and secondly, in a moving video, I'd like to keep all LEDs switched on to allow feature tracking over several frames.
Are you sure? yes | no
RBG order is the "normal" order but GRB is a hack in the design of the WS2812 integrated LED.
What kind of pattern do you intend to send ? I have examined similar situations and I'm curious to see what you have come up with :-)
Are you sure? yes | no
I'm working on uploading the video for my first pattern. I'm still experimenting, but in essence it's a simple binary code, where all leds are turned on and off at the same time (for time reference), but LED colors alternate between blue and red (say, reds are zeros and blues are ones). This allows 2^n unique led patterns with n flashes of the LED string.
Are you sure? yes | no
It can be simpler and more efficient :-)
The binary code is indeed a good start, send 01010101010101010101
then 001100110011001100110011
then 000011110000111100001111
etc.
Now if you use R, G and B as different channels, you can reduce the number of steps to identifiy the position of each LED.
It will depend on the quality of the camera and its AGC to prevent saturation and color bleeding...
Are you sure? yes | no