Aside from the relatively straight-forward color data, each Adalight frame is preceded by a small six-byte header. Since this header data is mixed in with a lot of RGB color data, I got to thinking… if this data was pushed to the LEDs, what would it look like?
Now that I’ve calculated the theoretical framerate limits, it’s time to measure the actual framerates my Adalight device is putting out.
Using a logic analyzer and an Arduino Nano, I’m going to measure the framerate at varying Prismatik “Grab Intervals” and baud rates, and compare those numbers to what my calculations predict will happen.
Since I’m experimenting with increasing Adalight framerate, the first step was to try driving the Arduino Nano with a faster serial baud rate.
Unfortunately, Prismatik only supports three baud rates: 9600, 57600, and 115200. But after talking with Patrick Siegler, he pointed out a way to use your own custom baud rate for Adalight or Ardulight devices.
As cool as I think ambilights are, using Adalight with my DIY setup has one major limitation: framerate.
Video technology works on a principle caused persistence of vision, which means that our brains still “see” an image briefly after it’s taken away. If you replace the images quickly enough, our brains interpolate the differences between them and we get an illusion of motion.
Project complete! The LEDs are in place, the code is done, the PCB is built, and everything is installed and running. So what is there left to do? Shoot some videos of everything in action!
In all of these videos, the ambilight is generating colors in real time based on the monitor’s image. The monitor image is as-filmed and is not superimposed.
I’ve previously mentioned that I was initially using this code by James Bruce to drive the ambilight. While I was waiting for the circuit board components to arrive, I thought I would take some time to expand on his work, fix some bugs, and add a few features I thought Read more…