No the other serial devices aren’t currently plugged in.
It’s definitely talking to the right device for the all pixel.
This is the path that shows up in dmesg with the right Vendor & Product IDs.
My suspicion is something weird is happening between the os driver & the APM during setting up the connection that leaves the APM in the wrong state.
My client has decided to go with other hardware (decision mostly unrelated to this issue!)
I’ll let you know if these other serial devices are causing this issue though.
···
On Wed, May 16, 2018 at 12:21 PM, Adam Haile adammhaile@gmail.com wrote:
Random thought… there aren’t any other USB Serial devices connected are there? What’s the output of ls /dev/tty* ?
I’m assuming not… I just was wondering if somehow the code was timing out trying to get the device ID out of a device that isn’t the AllPixel. I’ll admit, I don’t really ever test with serial devices connected that aren’t the AllPixel… at least I haven’t in a while.
It’s possible that the AllPixel is somehow getting stuck but I stand by the firmware. We haven’t changed it in nearly 4 years because it’s been rock solid. Every issue we’ve found has been the OS doing something silly or BiblioPixel. But there’s always a first time.
I’ll try to do some more testing tonight… and I found an unrelated bug that needs to be fixed. So I’ll see what I can dig up.
On Wed, May 16, 2018 at 5:16 AM James M Southern jms301@gmail.com wrote:
An update:
The problem is definitely caused by some thing in pyserial & my Ubuntu 16.04 (Desktop) machines usb serial software.
The exact same hardware works under Windows 10 & the exact same software works on a different linux machine with the same AllPixelMini.
The output from dmesg is identical between the working & non-working Ubuntu machines.
Running in a virtualenv and adding some debug to the bibliopixel code I can see that the com.write() believes it’s written 3 bytes & com.out_waiting is 0 afterwards but the read still times out.
Increasing the read timeout a bunch makes no difference.
Possibly relevant, I’ve previously used an RS232 cable and a USB Serial barcode scanner on the two ubuntu machines that don’t work.
Neither are currently connected though.
The write timeouts aren’t caused by switching pixel protocol but due to too many successive attempts without re-setting the board.
After 2 lots of writing: b’\x04\x00\x00’ the writes lock up (as no write-timeout is set). At this point print(com.out_waiting) still outputs 0.
Possible that the AllPixelMini is stuck in some state where it doesn’t read the data for some reason???
I’ll try plugging the other usb serial devices into the working ubuntu machine this evening and see if it breaks there too.
On Tue, May 15, 2018 at 12:21 AM, Adam Haile adammhaile@gmail.com wrote:
Mine’s exactly the same on Fedora.
I’m honestly stumped.
Silly thing to try….
sudo ionice -c 2 -n 0 nice -n -20 $(which bp) all_pixel_test APA102
That should run with max IO priority. The which thing is just so it picks up your bp path in case you are in a venv or something.
On Mon, May 14, 2018 at 7:08 PM James M Southern jms301@gmail.com wrote:
It works in Windows so it’s not a hardware issue.
$ stty -F /dev/ttyACM0 -a
speed 921600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^; erase = ^?; kill = ^U; eof = ^D; eol = ;
eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; discard = ^O; min = 0; time = 0;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
could that be my problem?
On Mon, May 14, 2018 at 10:07 PM, Adam Haile adammhaile@gmail.com wrote:
James,
Did you order it from Tindie? I couldn’t find an order with your name.
I’ll send you a new one and make a label for you to mail yours back to me. If it is somehow a hardware problem I want it for testing 
Try with a different brand cable and Windows first though if you don’t mind.
Cheers,
Adam
On Mon, May 14, 2018 at 5:03 PM James M Southern jms301@gmail.com wrote:
Adam,
Thank you very much for looking into this, I had already, tried sudo, 3 USB cables, different ports and a different computer!
Although they’re all the same brand of USB cable so that’s something else to try. The 2nd computer was linux too so I’ll give windows a shot.
We’re going to order a 2nd AllPixelMini so that should clear up if I’ve messed something up or if it’s a hardware fault.
Your very prompt support has certainly reassured us it’s worth another try!
All the best,
James S
On Mon, May 14, 2018 at 9:51 PM, Adam Haile adammhaile@gmail.com wrote:
Just tried things out on my end, on Linux and Windows and it all is working.
As Tom noted, we haven’t made any changes to anything related to the hardware, so it’s very unlikely it’s something we did recently.
We see this from time to time, especially on linux and it’s usually permissions related, though I see you noted you are already in the dialout group, but maybe try it as root once just to check.
It seems like Serial is having trouble connecting at all…
Running the test should just look like this:
$ bp all_pixel_test WS2812
INFO - devices - Using COM Port: /dev/ttyACM0, Device ID: 0, Device Ver: 0
INFO - driver - Reconfigure and reboot needed!
Waiting for controller to restart…
INFO - devices - Using COM Port: /dev/ttyACM0, Device ID: 0, Device Ver: 0
INFO - driver - Reconfigure success!
DEBUG - animation_threading - Animation starts on main thread
The reboot of course would only happen once.
Main things I can suggest now are the usual troubleshooting ones:
- Try a different USB port.
- Try a different USB cable (this is a problem more often then you’d expect).
- Verify that your barrel jack power supply is correctly at 5V and has enough current capacity.
- Try a different computer entirely.
I hate to be so pedantic as you clearly know your stuff, but the USB serial connection pretty much just always works, except for when it doesn’t and then it’s incredibly mysterious and rarely ever the same. But the above usually point you in the right direction.
On the incredibly rare chance it’s somehow a hardware problem with the AllPixelMini (this has literally never happened) we will of course replace it ASAP.
On Mon, May 14, 2018 at 12:40 PM Tom Swirly tom@swirly.com wrote:
Very peculiar!
We believe we haven’t made any hardware-oriented changes in several releases - we have been concentrating on other things, and deliberately not perturbing that area, as our automatic testing can’t cover serial interactions.
Adam will give this a try at home and be able to test in parallel with you to either reproduce it, or hopefully, come up with the issue.
–
You received this message because you are subscribed to the Google Groups “Maniacal Labs Users” group.
To unsubscribe from this group and stop receiving emails from it, send an email to maniacal-labs-users+unsubscribe@googlegroups.com.
To post to this group, send email to maniacal-labs-users@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/maniacal-labs-users/CAOuQWfW2fOZFuvfsM2aMDQRc%3DaTz1V9i9itN%2B95%3DMjUn%3DEdcbA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
On Mon, May 14, 2018 at 4:04 PM, James M Southern jms301@gmail.com wrote:
I was wondering if the get was failing because the ID had never been set.
But arduino EEPROM.read() in the GETID command returns 255 if it’s unset so that can’t be it.
running
bp all_pixel_test WS2812
doesn’t produce any output.
ctrl-c gives me:
^CDEBUG - devices - Error getting device_id for /dev/ttyACM0, 921600
Traceback (most recent call last):
File “/usr/local/bin/bp”, line 15, in
main.main()
File “/usr/local/lib/python3.5/dist-packages/bibliopixel/main/main.py”, line 78, in main
result = run(args) or 0
File “/usr/local/lib/python3.5/dist-packages/bibliopixel/main/all_pixel_test.py”, line 41, in run
driver = Serial(ledtype=ledtype.make(args.ledtype), num=10)
File “/usr/local/lib/python3.5/dist-packages/bibliopixel/drivers/serial/driver.py”, line 61, in init
resp = self._connect()
File “/usr/local/lib/python3.5/dist-packages/bibliopixel/drivers/serial/driver.py”, line 87, in _connect
self.devices.find_serial_devices()
File “/usr/local/lib/python3.5/dist-packages/bibliopixel/drivers/serial/devices.py”, line 31, in find_serial_devices
id = self.get_device_id(port, self.baudrate)
File “/usr/local/lib/python3.5/dist-packages/bibliopixel/drivers/serial/devices.py”, line 115, in get_device_id
com.write(packet)
File “/usr/local/lib/python3.5/dist-packages/serial/serialposix.py”, line 556, in write
abort, ready, _ = select.select([self.pipe_abort_write_r], [self.fd], [], None)
KeyboardInterrupt
After this bp all_pixel_test APA102 has the same behaviour until the board is re-set at which point back to the same 5second timeout behaviour of:
DEBUG - devices - Error getting device_id for /dev/ttyACM0, 921600
ERROR: ord() expected a character, but string of length 0 found
–
/t
https://tom.ritchford.com
https://tom.swirly.com
On Mon, May 14, 2018 at 2:45 PM, Adam Haile adammhaile@gmail.com wrote:
There’s no setting of the ID going on at all in all_pixel_test.
As noted, I’ll give this a test at home tonight. Maybe we did something stupid recently…
On Mon, May 14, 2018 at 9:43 AM James M Southern jms301@gmail.com wrote:
Same error with no strip connected.
Is it possible to set the id without first requesting it?
On Mon, May 14, 2018 at 2:40 PM, James M Southern jms301@gmail.com wrote:
I only have 6 LEDs connected with a 5v barrel jack supply on too.
I’ll try disconnecting the strip & re-running. I guess it doesn’t matter what LED chip type I input then?
On Mon, May 14, 2018 at 2:32 PM, Adam Haile adammhaile@gmail.com wrote:
Tom’s right most likely. At this point I was mostly gathering information so I could run a quick test when I got home to confirm, but his assessment is where I was likely going anyways.
Me being home to test this won’t be until tonight, but in the meantime a way to test is to disconnect the LEDs and try again. If it still works without them connected it’s definitely a power issue.
Which brings up the important question… how are the LEDs being powered? Only USB or did you connect a bigger supply to the barrel jack?
Even if you are only lighting, for example, 10 LEDs and USB should be OK for that you have to remember that “off” LEDs still draw power too. So when we say that USB supports ~60 LEDs we mean TOTAL… not LEDs that are lit. 60 LEDs physically connected in any way.
On Mon, May 14, 2018 at 9:27 AM Tom Swirly tom@swirly.com wrote:
All Adam’s questions are good but I should add this:
- Your guess as to what triggered this error is quite right.
- I see some places in that code where we handle that problem better and others were we don’t. We should always handle this “0 length response” problem better.
- But there really is no great way to handle that problem. It almost certainly means there’s some sort of communication issue beyond our control - it’s not clearly how to continue.
In my experience, this is nearly always called by inadequate power somewhere in your setup. For example, in an early setup I had, it would work fine until the total brightness of the pixels on my LED became too great, and then I’d get an error much like this (but elsewhere in the code) - turned out I just didn’t have enough power.
On Mon, May 14, 2018 at 2:57 PM, Adam Haile adammhaile@gmail.com wrote:
Can you give the details below?
- What version of bibiopixel (bp --version)
- What python version (python --version)
On Mon, May 14, 2018 at 8:52 AM James S jms301@gmail.com wrote:
I have a strip of SJ 10060 102 LEDs there are 6 LEDs
This is connected to an AllPixelMini which is connected to a linux pc via USB.
python serial & bp are upto date via pip3.5 install.
I can see the device on /dev/ttyAMA0 my user is in the dialout group.
if I run:
test code or command:
bp all_pixel_test APA102
I get an error thrown:
DEBUG - devices - Error getting device_id for /dev/ttyACM0, 921600
ERROR: ord() expected a character, but string of length 0 found
This appears to be caused by:
bibliopixel/drivers/serial/devices.py#L116
–
You received this message because you are subscribed to the Google Groups “Maniacal Labs Users” group.
To unsubscribe from this group and stop receiving emails from it, send an email to maniacal-labs-users+unsubscribe@googlegroups.com.
To post to this group, send email to maniacal-labs-users@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/maniacal-labs-users/ca31bb64-bf4e-45ba-b956-66fcfb1997f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
You received this message because you are subscribed to the Google Groups “Maniacal Labs Users” group.
To unsubscribe from this group and stop receiving emails from it, send an email to maniacal-labs-users+unsubscribe@googlegroups.com.
To post to this group, send email to maniacal-labs-users@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/maniacal-labs-users/CAG8g-TaAexk%2Bm%3Dr48cy4hzVM5yjYgxb%3DzC%2BnTt65hoqDfz%2BnUw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
–
/t
https://tom.ritchford.com
https://tom.swirly.com
