I’ve been trying to teach myself a little Python, and here’s what I came up with for my first small project. Using their respective APIs, I’ve built a plugin for the Prismatik ambilight software that maps live data from the iRacing simulator. A video demonstrates the end result far better than I can explain it:
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?
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.
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.
I recently posted a few ideas about how to improve the framerate of an ambilight driven using the Adalight protocol. Before trying to implement some of those options, I thought it would be worthwhile to actually calculate the theoretical framerate limitations.
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.