Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

One frame behind

I've been playing with BlinkyTape for two nights now, and I first noticed it with the PatternPaint demo application.
The LED state is one frame behind the last one sent and "rendered" with the 0xFF byte.
In my test app, I can also send 60 red tuplets followed by the FF, at which point, the current animation stops.
I then send 60 green tuplets with their FF and the strip will change to red.
The next full frame I send causes it to render green, etc.

Sending two FF bytes does not help, nor do delays between each tuplet/byte.
Only sending another full frame causes it to render.
So far, I've worked around this by sending each full frame twice if it's only being rendered temporarily.

When running an animation this is less obvious, but still exists.

Has anyone else noticed this or is it known or already fixed?

Thanks

--
Deanna

Comments

  • edited July 2014
    Oh, hmm. In the python library, we're actually sending two 0x00's and then a 0xFF, and that causes it to output the frame. Can you try that and see if it works for your library?

    If so, I'll update the docs to recommend that sequence instead. It's very likely a bug in the BlinkyTape firmware.

    Edit: To be a little clearer, try sending 0x00 0x00 0xFF instead of 0xFF at the end of the frame.
  • Thanks, I've just checked the production sketch and it doesn't detect the FF until there are at least 3 bytes to read:
    https://github.com/Blinkinlabs/BlinkyTape/blob/master/ProductionSketch/SerialLoop.cpp#L11
    Sending FF FF FF or any other combination of 3 bytes with an FF in works. (but 00 00 FF has the best result of just "rendering" once.
Sign In or Register to comment.