Controlling LightBuddy- output not updating until the next command is sent
I am using Node/SerialPort to talk to Light Buddy. This appears to work.. BUT, it looks like Light Buddy doesn't actually send the commands out to the LEDs until the NEXT time I send data after the FF.
so, if I send something like 0x01, 0x02,0x03, 0xff I would expect it to light up LED 1 immediately. But actually, nothing happens.
but if I send that, then 0x00,0x00,0x00,0x05,0x06,0x07,0xff
LED 1 lights up, and nothing for LED 2.
I know I am looking at the right LEDs because I can step through them and see each light up (and the boot up pattern lights them all).
Any ideas on what is going on?
Comments
Interesting.. even when I try creating basically the same task in Processing, I see the same problem. I send triplets to set all the leds in the string, and nothing happens until I start sending the NEXT command.
It isn't a timing problem, because I have a 10 second delay between the sets of triplets.
I have attached the Processing code that demonstrates the problem.
I seem to have dug the hole even deeper. I tried a few different variations of delays after the 0xff, two 0xff's in a row (with and without a delay between).
Now the tiles all just blink once when I send the 0xff (all on dim), but the actual pattern I am trying to display doesn't show up until about 12 times?
I have tried it on two different computers (both Windows 10).
I hope this doesn't mean I have to reload the Light Buddy code.. I took a look at that path and it looked dark and long.
Hmm, thanks for pointing that out. I see the same issue on OS X with the sample code you posted, and also in Pattern Paint- apologies for not noticing the issue earlier (we're usually streaming data to it, so it's not as obvious). Here's the code that is handling serial input on the lightbuddy: https://github.com/Blinkinlabs/BlinkyTile/tree/5085cf6da9b42f881f1cfdee0e9f51a05b5b31d4/firmware
(edited to point to the actual version used in production)
Thanks Matt,
I can't see in the code where it should buffer anything.
I did get it to work 'sort of'.
See the attached file. By sending out another triplet after what I really want to display, I force what I want to show up, and the odd triplet displays the next time I go to send real data (you can see pixel 1 flicker).
It's sort of an uggly hack. I think I can add some code to remember the color of pixel one, so it won't flicker.. but it will be a pain.
Ug, that is a pain. One thing that might help is to buffer larger sets of bytes and send them out together, in case the operating system is sending a USB transaction per byte and overwhelming the LightBuddy. Something around 60-250 bytes per serial write seems to work best in OS X, but I still see that one frame delay when I implement it.
I'll try to do some more tests to see if it can be improved. The good news is that the controller has a USB bootloader, so it's possible to update the firmware.
Matt,
I only have 12 lights attached, so that's 43 bytes of data (including the 0xff). I am not sure how Processing handles the s.write... but I am issuing that for each byte.
When I first started this on Node on the Edison, I was doing a write of all 43 in one statement. But the symptoms were the same.
I did try writing just an extra 0xff (with and without a 10 ms delay between), and that didn't help. I did not try sending just one 'non-0xff' and then the 0xff.
But, at least I have a work around. And it might not be a bad as I thought. I think I can just resend the 1st LED colors again. When they do get pushed to the lights during the next cycle, it will just set the first LED to what it was. So nobody should notice.
We should proably change the title on this thread to make it easier to find. Or update the docs for when you have a pattern you want to stop at a particular place.
Good idea, I just updated the title- let me know if you have a better suggestion :-). Ok, that amount of data isn't big enough to swamp it (if you're sending 100's of LEDs worth it will probably become an issue).