Very Variable Framerate

simonrowesimonrowe
edited December 2013 in BlinkyTape Troubleshooting
I've got a program which is continuously squirting a new set of 60 RGB values to the blinky tape and then sending the "update" code (255). My problem is that this runs at about 30Hz for a while and then after a few minutes of doing this drops down to about 1Hz. After this has happened I generally need to power-cycle the binkytape to get it back to the 30Hz performance. Occasionally it will fix itself after a few minutes of the slow performance. Having instrumented my code with some timers, its definately the serial write which is slowing things down.

This is using the default firmware and happens if I drive the tape from either a linux box or a Mac.

Comments

  • simonrowesimonrowe
    Looks like this was probably my mistake - hadn't realised the Blinky sends back a byte each time you send a "show" command, and so this was probably caused by some serial buffer filling up . I've fixed my code and so far all is well.
  • ThreeethanThreeethan
    OK awesome - we need to document the tape's acknowledgement byte, so I wouldn't say this is your fault. We skipped it because it doesn't seem to be an issue with Processing, but other languages do get weird if you ignore that.
  • XanXan
    Yup, same garden rake I stepped on.
    My pull-request for the Python library is still pending, have you guys missed it or just don't have time to merge?
  • ThreeethanThreeethan
    Hmm, I thought Matt had merged it, I'll bug him about it.
  • Matt MetsMatt Mets
    Sorry about that, Xan- it's on my list, I'll try to get to it this evening.
  • XanXan
    Thanks Matt, as long as it wasn't simply forgotten (I understand you devote most of the time to PatternPaint now) it's fine. I was just checking.
  • XanXan
    I also want to have a method to read the state from the diagnostic byte, but I'll do it on another branch so you can merge this "stable" version first.
Sign In or Register to comment.