Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Data packet size incorrect
#1
Is anyone else getting this error?

ERROR - serial_driver - 1: Data packet size incorrect.
Exception in thread Thread-57:
Traceback (most recent call last):
 File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
   self.run()
 File "/usr/local/lib/python2.7/dist-packages/bibliopixel/animation.py", line 24, in run
   self._anim._run(**self._args)
 File "/usr/local/lib/python2.7/dist-packages/bibliopixel/animation.py", line 124, in _run
   self._led.update()
 File "/usr/local/lib/python2.7/dist-packages/bibliopixel/led.py", line 136, in update
   d._update(self.buffer[pos:d.bufByteCount + pos])
 File "/usr/local/lib/python2.7/dist-packages/bibliopixel/drivers/driver_base.py", line 51, in _update
   self.update(data)
 File "/usr/local/lib/python2.7/dist-packages/bibliopixel/drivers/serial_driver.py", line 329, in update
   DriverSerial._printError(ord(resp))
 File "/usr/local/lib/python2.7/dist-packages/bibliopixel/drivers/serial_driver.py", line 159, in _printError
   raise BiblioSerialError(msg)
BiblioSerialError: Data packet size incorrect.

Best wishes,

ks
#2
Please send the following details:

OS and OS Version
Controlling hardware (laptop, RasPi, BBB, etc)
Has the AllPixel worked for you before?
results of "pip freeze"
#3
(04-12-2016, 08:05 AM)Adam Wrote: Please send the following details:

OS and OS Version
Controlling hardware (laptop, RasPi, BBB, etc)
Has the AllPixel worked for you before?
results of "pip freeze"

Raspberry Pi 3
Raspbian Jessie
Linux santa 4.1.19-v7
AllPixel works great until I tried starting / stopping a series of animations.  I need the animation to be threaded and obviously don't have a handle on how to gracefully handle the start / stop of threaded animations.  I tried using the animation queue class first, but could not get it to stay synchronized with the mp3 (great at first, but gradually drifted off).  So I have taken an alternate approach which requires the starting and stopping.

Here is the basic code:
# START AN ANIMATION RUNNING
anim.run(fps=45, threaded=True)

# POLL FOR AN EVENT THAT TRIGGERS THE NEXT ANIMATION
anim.stopThread(wait=True)

# START THE NEXT ANIMATION RUNNING
nextAnim.run(fps=45, threaded=True)

This causes the data error most times.  After experimenting with stopThread / waitForUpdate, etc, with no luck.  I eventually found that if I add a time.sleep(0.05) between the stopThread and the nextAnim, no data error.

Thanks in advance for any help you can give me,

ks
#4
Ahh... Just a misunderstanding of what the threaded animations are for. I assume you are trying to basically super-impose multiple animations on top of one another. This is not possible unless those super-impositions run *in the same* animation thread, *before* pushing the update. In general, BiblioPixel doesn't have a great way of doing this because when you set the color on a pixel that already has a color, it overwrites, instead of blending. It's possible to do the blending yourself, but it's slow.

What's happening when you get that error is that you have two animations calling update on one driver. The AllPixel is still accepting data from the first animation when you try to send data for the second, but because the AllPixel is busy, it doesn't respond correctly. Hence the error.

Animation threads are intended so that you can do something else, non-animation related, while the animation runs. For example... poll a twitter feed and when you get a new matching tweet, run the ScrollText animation and thread it, so you can go back to searching for a new tweet to show. When you get it, stop the first animation, and start a new one.
#5
(04-13-2016, 08:04 AM)Adam Wrote: Ahh... Just a misunderstanding of what the threaded animations are for. I assume you are trying to basically super-impose multiple animations on top of one another. This is not possible unless those super-impositions run *in the same* animation thread, *before* pushing the update. In general, BiblioPixel doesn't have a great way of doing this because when you set the color on a pixel that already has a color, it overwrites, instead of blending. It's possible to do the blending yourself, but it's slow.

What's happening when you get that error is that you have two animations calling update on one driver. The AllPixel is still accepting data from the first animation when you try to send data for the second, but because the AllPixel is busy, it doesn't respond correctly. Hence the error.

Animation threads are intended so that you can do something else, non-animation related, while the animation runs. For example... poll a twitter feed and when you get a new matching tweet, run the ScrollText animation and thread it, so you can go back to searching for a new tweet to show. When you get it, stop the first animation, and start a new one.

First off, I want to thank you for what you have built.  I'm having a blast and look forward to using your tools in the future.  Secondly, I should have done a better job of explaining what I am trying to accomplish.

I am, like many others, attempting to synchronize LEDs with music.  After reviewing a lot of Youtube videos and Instructables, I took the plunge and bought 5 meters of APA-102, a Raspberry Pi 3, and an AllPixel.  These, combined with my Arduino's and a bunch of sensors, will become (in my dreams) an interactive display.  The base of the system is the Raspberry Pi, which is responsible for communicating with the Arduino's sensors, playing music, and triggering animations via the AllPixel.  The sensors can trigger music, sound effects, LED animations, and anything else I can dream up.

That said, my main problem has been keeping the animations synchronized with the mp3 music.  I tried using animation queue's where I set very specific timings for each animation but the queue's lose time as the song plays.  I built a timing system that works within .1 seconds for the duration of the mp3.  When an "animation event" occurs, I stop the animation that is currently playing and start the next animation.  This is working great and is accurate within .1 seconds for the full duration of the mp3.

So, I'm not trying to play animations simultaneously.  Quite the contrary.  I want to seamlessly transition from one animation to the next.  Pseudo-code follows:

Sensor trigger
Load timing file
Start song
While song is playing:
- if timing in file < timing in song:
    - stop current animation thread
    - start next animation as a thread
    - do other stuff

The problem occurs in the stop / start.  If I put a time.sleep() in there, no problem.  If I take it out, data packet error.  It would be great to understand the proper way of starting and stopping the animations.  Not a big deal, but I'm a little OCD about this project :-)

Best Wishes and Thanks Again!

ks
#6
Ohhh... gotcha. Believe it's basically the same problem though...

You calling anim.stopThread() ?
call anim.stopThread(wait=True) instead.

Here's the thing... calling stopThread only *requests* that the thread stops and then moves on with life. The thread won't actually stop until it's done doing whatever it was doing (which is dependent on your animation code) and when you then start the next thread, it's entirely possible that it tries to update the AllPixel when the last thread (that you thought you stopped) is also trying to update. That's why the sleep fixes it... gives it enough time for the first thread to finish. using wait=True will do the same, but the time isn't arbitrary. It will be whatever it needs to finish and no more.

That being said... in your animation code, DO NOT use sleep! Make it run as fast as possible and control framerate with the fps parameter. If the animation is waiting to run the next frame because of the set framerate, the stopThread() function *will* get the thread to stop as soon as possible. But if you used a sleep wait inside your step() animation function then stopThread() has no control over it. You probably don't... just wanted to mention it.

Hope that helps!
Absolutely want to see this when you've got it up and working... sounds awesome!
#7
Thanks for the help.  I will try it out and get back to you.

I will absolutely share this if I can get it done.  I already have 10 touch sensors that basically act as an mp3 player (start, stop, next track, louder, softer, sound effect, stop anim, etc) and should be able to scale to 100's without an issue as the arduino's are doing all of the sensor polling and just sending signals back to the Pi.  Now if I can just figure out how to update your anims to dynamically change the colors / brightness / hue so that the running animations are interactive as well.

Best Wishes,

Ks
#8
Ok... I think I have an idea for you. Now, note that this is entirely untested, but I think the logic is sound:

https://gist.github.com/adammhaile/d54f19fff1b82e8543da9208e455369d

Here's the 1000 foot view...

I felt that your threaded method was too complicated and could be simplified. Totally get why you are doing it that way, but having to start and stop threads is a pain and inefficient. So... the class at the link above is based on AnimationQueue but is meant to allow dynamic choice of which animation is running, on the fly, instead of just playing them in a particular order.

So, do this:

Code:
main = AnimationChooser(led)
a0 = bibliopixel.animation.OffAnim() # so you have an option to turn them off
a1 = Anim1()
a2 = Anim2()
a3 = Anim3()

main.addAnim("Off", a0, fps=5) # can run slow because it's just off
main.addAnim("A1", a1, fps=30)
main.addAnim("A2", a2, fps=30)
main.addAnim("A3", a3, fps=30)

main.run(threaded=True)


while True:
    i = get_input() #whatever this is
    if i==0:
        main.choose_anim('Off')
    elif i=1:
        main.choose_anim('A1')
    etc...

I think you get the idea...

So here's the thing. You only ever have to start the thread once! When you call choose_anim() it stops the last animation and when it stops, it will load up the animation you just chose.

Granted, previous comment about the timing of how long it takes for that animation to stop still stands, but this will be MUCH more efficient than starting and stopping threads... which is horrible in Python.

Hopefully this should solve a lot of your timing issues. If all your main animations are running at around 30fps, that means that at most you will have to wait 0.033s for the next animation to startup (plus however long that new animation takes to render the frame).

Again, this was a 10 minute hack with no testing, but it should be on the right path. Let me know how it goes and we can tweak as need be.
#9
Adam,

This looks perfect.  I will work on it this weekend and revert.

Best Wishes,

ks
#10
You have given me more to think about than I anticipated.  The hardware has been soaking up all my time but I want to make this piece work!

ks


Forum Jump:


Users browsing this thread: 1 Guest(s)