Nano blink sticks ON


#1

2nd thread on this as the first seems to have been forgotten.

Using the python scripts the Nano blink stick randomly sticks ON after a blink command.

This is the same with sending on, off. When stuck on there is no way to turn it off other than pulling it out of the port or sending another blink. Which then still has the chance of sticking on.

I have looked through the code and can’t see anything untoward, it has to be a conflict with the stick and the USB port. I am using these on the Raspberry pi.

Can someone please give this some priority, if this cannot be resolved I have 130 nanos to return.

Many thanks.


#2

Any update on this or do I need to send them all back to you?


#3

Hi Tull,

Can you please provide me a bit more info about this:

  • What RPi version are you using?
  • What OS do you have installed on RPi?
  • Which of the USB ports do you connect the BlinkStick to?
  • Can you please send me your code sample you use?

I need the info above to reproduce your issue.


#4

Pi, version 3, 3b, 3b+, same issue.
OS is raspbian. Fully up to date.
Any usb port, no difference.
Any python code, any on/off, any blink. :

#!/usr/bin/python

from blinkstick import blinkstick as bstick
import time

while True:
	for b in bstick.find_all():
		b.blink(red=100,green=100,blue=100,index=0,name=None, repeats=1,delay=250)
		b.blink(red=100,green=100,blue=100,index=1,name=None, repeats=1,delay=250)

	time.sleep(1)

Changing any value makes no difference. Blinking only 0 or 1 makes no odds. repeats makes no odds, name, anything. I have tried over the last couple of months absolutely everything.

I have just run this very simple code on a block of 8 pis, within 10 seconds 1 of them has stuck on and now will not turn off.


#5

Thanks for giving me the info. I’m trying to reproduce this now.


#6

I’m still looking into this, but I think I know what may be going on. You need to add sleep between two blinks.

#!/usr/bin/python

from blinkstick import blinkstick as bstick
import time

while True:
	for b in bstick.find_all():
		b.blink(red=100,green=100,blue=100,index=0,name=None, repeats=1,delay=250)
                time.sleep(20) #Add sleep here
		b.blink(red=100,green=100,blue=100,index=1,name=None, repeats=1,delay=250)

	time.sleep(1)

Just before first blink exits, the library sets black color for the LED, but then immediatelly after that it sets the RGB color you specified in the second blink command. There needs to be a small delay before BlinkStick can accept new commands.


#7

But as explained it does the same if I’m only using one or other index.
With the test I did earlier I was only using index 1.


#8

Because this is a very important part of the entire system, I have been through absolutely everything, I very much doubt you could ask me to try something I haven’t already. I’ve even gone to the trouble of totally bug testing your python library, as posted before, I can’t find anything wrong in there, but it is a bit past my knowledge of USB port coding.


#9

@tull a quick update on this. I managed to reproduce this issue and it seems to be related to PyUSB module BlinkStick is using to communicate. I’m still working on this and will update you with the progress.


#10

@tull I’ve been runing a test similar to yours, however I am blinking LEDs a lot faster with 20ms intervals to be able to reproduce this issue more quickly.

#!/usr/bin/python

from blinkstick import blinkstick as bstick
import time

#Search for BlinkStick only once
sticks = bstick.find_all()

while True:
    for b in sticks:
        b.blink(red=100,green=100,blue=100,index=0,name=None, repeats=1,delay=20)
        time.sleep(0.02); #Add 20ms delay after blink command
        b.blink(red=100,green=100,blue=100,index=1,name=None, repeats=1,delay=20)
        time.sleep(0.02); #There needs to be a 20ms delay here too

I’ve been running the code above for the last hour and it has not crashed with pipe error. This means that it has been blinking for almost 100000 times. I’ll leave it running for the rest of today.

I am still investigating this issue, but I suspect that once RPi sends the information too fast to the BlinkStick, USB controller gets into a broken state which causes more random pipe errors until RPi is rebooted.

The is updated equivalent of your code below.

#!/usr/bin/python

from blinkstick import blinkstick as bstick
import time

#Search for BlinkStick only once
sticks = bstick.find_all()

while True:
    for b in sticks:
        b.blink(red=100,green=100,blue=100,index=0,name=None, repeats=1,delay=250)
        time.sleep(0.02); #Add 20ms delay after blink command
        b.blink(red=100,green=100,blue=100,index=1,name=None, repeats=1,delay=250)
        time.sleep(0.02); #There needs to be a 20ms delay here too

A few notes:

  • Make sure that the Pi is rebooted when running this code: shut down, unplug power and plug it back in
  • I have modified the code to search for BlinkStick only once. This is a good optimization unless you will be running this code to constantly enumerate BlinkStick devices connected to Pi, because you will be plugging BlinkSticks in and out when running this script.

#11

All the cables are out of the cluster at the moment, I should have 32 of them back up this evening so I will give this a go. My fingers are very crossed. :o)

The pi shares the USB with the network, I’m not sure how, do you think this could have anything to do with it?


#12

Aaarrgghh! I was so hopeful!

  1. I’m so glad you’ve been able to reproduce the problem, there’s always that worry when you escalate a bug report you’ve missed something yourself.
  2. Still have the problem with your changes in place.
  3. Problem still exists if I’m only blinking one index.
  4. You don’t have to reboot the pi after a ‘crash’, just kill and restart the process, that will clear the fault until it happens again.

Is your pi network connected via the ethernet port or wifi?

I’m not convinced there isn’t a clash between the ethernet and usb, as mentioned above they share the same bus, or memory or something. I don’t remember having this problem when I was doing my first testing with wifi only. I cannot test the cluster this way, my router becomes unreliable with so many connections.


#13

Some further testing.

With the above changes in place, only checking for the sticks once, this error randomly stops the app:

Traceback (most recent call last):
File “/g/blinktest”, line 11, in
b.blink(red=100,green=100,blue=100,index=0,name=None, repeats=1,delay=250)
File “/usr/local/lib/python2.7/dist-packages/blinkstick/blinkstick.py”, line 689, in blink
self.set_color(channel=channel, index=index)
File “/usr/local/lib/python2.7/dist-packages/blinkstick/blinkstick.py”, line 341, in set_color
self._usb_ctrl_transfer(0x20, 0x9, report_id, 0, control_string)
File “/usr/local/lib/python2.7/dist-packages/blinkstick/blinkstick.py”, line 244, in _usb_ctrl_transfer
return self.device.ctrl_transfer(bmRequestType, bRequest, wValue, wIndex, data_or_wLength)
File “/usr/local/lib/python2.7/dist-packages/usb/core.py”, line 711, in ctrl_transfer
self.__get_timeout(timeout)
File “/usr/local/lib/python2.7/dist-packages/usb/backend/libusb1.py”, line 836, in ctrl_transfer
timeout))
File “/usr/local/lib/python2.7/dist-packages/usb/backend/libusb1.py”, line 571, in _check
raise USBError(_str_error[ret], ret, _libusb_errno[ret])
usb.core.USBError: [Errno 32] Pipe error

This is beyond my python knowledge.
The main app that first brought this problem to my attention is well error trapped, so it’s very possible this particular error has been hiding, I just wouldn’t have noticed it.


#14

I have noticed other pipe errors on posts for other blink products, but as they weren’t related to the nano I haven’t taken much notice of them. Could this be related?