Maximum "frame rate"?

Hi, I want to use Blinkytape in combination with monitors to present motion. The idea is to present an elongation of road markings (lines) in an experiment in perceptual psychology, using only visual feedback, in a car simulator. The task for the participant will be to drive at certain speeds, and the steering wheel will be disengaged, so the Blinkytape can be mounted as an elongation of the road markings (intermittent lines) that are presented on the monitors ahead.

The motivation for using Blinkytape as an elongation of the lines is primarily that use of LEDs should theoretically allow much faster presentation rate than a monitor can acheive, which would mean much smoother and more realistic motion, especially when simulating driving at high speed. The monitors we use work at 144 Hz. Our measurements of Blinkytape reveal that the response rate is 3–4 ms, meaning a theoretical upper limit of 250 Hz.

However, when trying out the Blinkytape by running the simulation at high velocity and video-recording at 240 frames per second, we see that the presentation rate achieved by Blinkytape is about 100 Hz (the Blinkytape updates the position of the road line/marking once every two to three frames recorded). This is also fairly consistent with the fact that Blinkytape is limited to 115200 baud (or bits/s): the Blinkytape should be able to receive and process the 1440 bits necessary (60 LEDs, 3 colours each, 8 bits/colour) 80 times per second, since 115200 / 1440 = 80.

So, my question is if anyone has ideas on how to solve my problem, that is, to increase the presentation rate. For example, is there perhaps a way to boost performance by programming, or by replacing a component (e.g., upgrade the Atmega processor)? Or, can perhaps presentation rate be helped by programming only part of the Blinkytape to be active, such as only the first 30 LEDs?

Comments

  • Hi Bjorn,

    Cool project! There are a couple things to consider here. For these numbers, I'm referencing the WS2812s datasheet:
    http://www.world-semi.com/uploads/soft/150522/1-150522091P5.pdf

    With no communications constraints, the maximum speed that the LEDs can be changed at is equal to their PWM refresh rate. The BlinkyTape is using WS2812s digital LEDs, which have a PWM refresh rate of 400Hz. During this cycle, the LEDs turn on for a short time corresponding to how bright they are programmed to be, then turn off for the remainder of the time.

    The second thing to consider is the communication speed between the BlinkyTape controller (Arduino) and the WS2812s LEDs. The communication speed is 800Kbps, or 1.25uS per bit. Since each LED has three colors (R,G,B), and each color is represented by 8 bits, it takes 30uS to transmit the data for each LED, or 1800uS to transmit 60 LEDs worth of data. Additionally, there is a minimum delay of 50uS between frames, so for 60 LEDs the required time is 1850 uS or 540hZ. Remember that even if we send data this fast, though, the maximum LED refresh rate is 400Hz, so this doesn't affect the theoretical maximum.

    The third thing to consider is that the microcontroller used on the BlinkyTape can't do anything else while refreshing the LEDs, so the time per cycle is actually a combination of the above 1850uS and however much time it takes to process the incoming data. This is a little hard to calculate (since it involves how the processor handles the USB data, etc), so I measured it using an unmodified BlinkyTape. On my computer (a macbook running OS X 10.10) it comes out to 3.22mS, using the BlinkyTape_Python library with no delays between sending frames of 60 LEDs. Also, after measuring the output, it's actually a little slower than predicted, due to some practical limitations on the processor speed, so it actually takes 2ms to output the data for a frame. This puts us at 5.24ms/frame, or 190 frames per second maximum (and that's assuming that the computer program is outputting data continuously, and not doing anything else that might get in the way- this could be achieved by making it threaded, for example).

    Keeping in mind that the processing time is much longer than the data output time, a good thing to try is what you suggested- cut down the number of LEDs. I re-configured the Python program to only control 30 LEDs, and the cycle time cut down to 3.74mS, or 267frames/second.

    In conclusion, the BlinkyTape as-is should be capable of ~190FPS when configured for 60 LEDs, or ~260FPS when controlling 30 LEDs. It's technically possible to cut this down a little by replacing the Arduino firmware with something custom, but that would come at the expense of compatibility.

    Finally a note about the 'baud rate' setting for the BlinkyTape- it's actually completely disregarded, since the BlinkyTape is a USB device pretending to be a serial device, not an actual serial device. It always communicates at the USB bus speed, regardless of what this is set to.

    Cheers,
    Matt
Sign In or Register to comment.