×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

No ASI Camera after Update - Suspect port mapping

  • Posts: 421
  • Thank you received: 102
I believe I have traced it down to a permissions issue on the USB bus itself, in the /sys hierarchy.
$ ls -l /sys/bus/usb/devices/usb*
lrwxrwxrwx 1 root root 0 Jul 30 02:41 /sys/bus/usb/devices/usb1 -> ../../../devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1
lrwxrwxrwx 1 root root 0 Jul 30 02:41 /sys/bus/usb/devices/usb2 -> ../../../devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb2

Following the symlinks:
$ ls -ld /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb*
drw-rw---- 6 root root 0 Jul 30 02:41 /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1
drwxr-xr-x 6 root root 0 Jul 30 02:41 /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb2

Notice anything wrong with the permissions on one of them?

These aren't individual USB devices, but rather USB buses.
$ lsusb
Bus 002 Device 004: ID 03c3:1604  
Bus 002 Device 003: ID 174c:3074 ASMedia Technology Inc. ASM1074 SuperSpeed hub
Bus 002 Device 002: ID 174c:3074 ASMedia Technology Inc. ASM1074 SuperSpeed hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

As you can see, it only shows Bus 2, which matches the permissions listed above.

Now for the magic.
$ sudo chmod +rx /sys/bus/usb/devices/usb*
$ lsusb
Bus 002 Device 004: ID 03c3:1604  
Bus 002 Device 003: ID 174c:3074 ASMedia Technology Inc. ASM1074 SuperSpeed hub
Bus 002 Device 002: ID 174c:3074 ASMedia Technology Inc. ASM1074 SuperSpeed hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 009: ID 03c3:1f01  
Bus 001 Device 007: ID 04b4:6572 Cypress Semiconductor Corp. 
Bus 001 Device 005: ID 0bda:b812 Realtek Semiconductor Corp. 
Bus 001 Device 008: ID 1618:0921  
Bus 001 Device 006: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
Bus 001 Device 004: ID 174c:2074 ASMedia Technology Inc. ASM1074 High-Speed hub
Bus 001 Device 003: ID 174c:2074 ASMedia Technology Inc. ASM1074 High-Speed hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

And I confirmed INDI is now happy, running as a regular user, not root.

So, my short-term fix is to add this one line to /etc/rc.local:
chmod +rx /sys/bus/usb/devices/usb*

sudo isn't necessary because it already runs as root.
The following user(s) said Thank You: Avocette, Bernd Limburg
3 years 7 months ago #57510

Please Log in or Create an account to join the conversation.

  • Posts: 421
  • Thank you received: 102

Not yet. I posted last night, but it hasn't been released from moderation yet. Once it is released, I'll add this information to the Raspbian forum post (and share the link here of course).
3 years 7 months ago #57512

Please Log in or Create an account to join the conversation.

So that doesn't work in my case. So I tried changing what they're pointed to:
chmod -R +rx /sys/devices/platform/scb/fd500000.pcie

So while that makes lsusb works, when you try to use drivers they cannot access libusb still (e.g. QHY). So it's still broken.
3 years 7 months ago #57513

Please Log in or Create an account to join the conversation.

  • Posts: 421
  • Thank you received: 102

Curious, because it works for me. Even after a reboot. Everything is plugged into the powered hub. My ASI1600, QHY guide camera, EFW, etc. all work, running as the "pi" user, after doing the chmod.

Regardless, I think this points to a definitive kernel bug, since the permissions in the /sys tree are managed by the kernel (not udev or systemd), I believe. I was hoping to let the Raspbian people responsible for taking it up with the kernel people, but they still haven't even approved my post. I was even polite. :)
3 years 7 months ago #57515

Please Log in or Create an account to join the conversation.

  • Posts: 421
  • Thank you received: 102
Just for fun (because the alternative is to actually do some real work) I'm updating my Linux laptop to a 5.4 kernel, to see if the problem also exists there.
3 years 7 months ago #57519

Please Log in or Create an account to join the conversation.

  • Posts: 421
  • Thank you received: 102
The following user(s) said Thank You: Avocette
3 years 7 months ago #57522

Please Log in or Create an account to join the conversation.

  • Posts: 421
  • Thank you received: 102
So an interesting development. I tried a lot of different things, but I narrowed it down to the USB-to-Serial adapter (EQDirect cable). If I leave it unplugged, or plugged directly into the Pi, everything works perfectly fine. But, as soon as I plug it into the USB3 hub, that's when things get wonky.

Now my question for the group is, is it just me, or is it the same for you guys as well? If you're having the same problems, are you using a USB-to-Serial cable (for example, an EQDirect cable)? Even if you have a mount with a USB port on it, those are often USB-to-Serial internally. And if you do have one of those, does unplugging it (and rebooting) make things work again?
3 years 7 months ago #57550

Please Log in or Create an account to join the conversation.

  • Posts: 32
  • Thank you received: 6
I’m using an EQDirect cable, but mine has always been plugged directly into the RPi. My camera s plugged into the hub, and the focuser into the camera. The focuser is my only other serial device.
3 years 7 months ago #57553

Please Log in or Create an account to join the conversation.

  • Posts: 421
  • Thank you received: 102

That means your focuser is making its way through the external hub, just with one extra hop. So this doesn't rule out my findings. :)
3 years 7 months ago #57554

Please Log in or Create an account to join the conversation.

  • Posts: 326
  • Thank you received: 50
I do have an EQdirect cable, but it’s not causing the problems. However, I’ve made some more observations and would be keen to see if there is any other pattern emerging:
I started with a clean Astroberry 2.0.2 image installation on a new microSD card. I set up the localisation parameters, and then carried out a sudo apt update followed by sudo apt upgrade on an RPi4 4GB v1.1 and as expected the new kernel was installed. I removed the house WLAN entry before shutting down, and then moved the card to my astronomy set up (also RPi4 4GB v1.1). lsusb showed that Bus 001 was not present in the list, and hence most of my USB devices were also unlisted. I shutdown and disconnected the USB3.0 tp-link powered hub and booted again. lsusb had the three internal RPi entries. I plugged in the USB hub, and the four hub Realtek devices (two Bus 001 and two Bus 002) were there. Then I plugged in the EQdirect mount cable, lsusb listed it as well as the others, then the ASI camera - there it was, and then the focuser - yes also, then finally the Pegasus Astro PPB - NO the lsusb list was back to the short Bus 002 only list.
I unplugged the PPB again. the lsusb list was still truncated. I reboot, and the list is back to ‘correct length’ again.

As it happens, the PPB had been plugged into the first USB3.0 output on the hub. I connected it again, but this time into output 6 which is one of the three ports marked as charging ‘1.5A max.’ This time lsusb is full and includes the PPB. I unplug the focuser from its present USB port, and into the first port in which the PPB had caused problems - no problem with the focuser - all list entries are there!!
So my clutching at straws theory is that the USB cable from the PPB is possibly trying to ‘back feed’ power to the USB hub. The PPB is already the source of 12V to power the hub, and the hub is powering the RPi itself through a simple USB type A to USB-C cable using hub output 7, one of the three charging ports.
So I seem to have stumbled upon a work around. Anyone got any further light to shed on why?
Thanks!
Last edit: 3 years 7 months ago by Avocette. Reason: clarification
3 years 7 months ago #57573

Please Log in or Create an account to join the conversation.

  • Posts: 398
  • Thank you received: 117
@Avocette, regarding " the hub is powering the RPi itself through....one of the three charging ports":

A bit OT, but this is definitely a marginal power setup for Pi4 that could easily get you to odd instabilities. The Pi4 power spec is 3 amps. The actual power delivery to the Pi4 from your hub is dependent on the total power draw on the hub (all ports). Recommend you reconsider and power the Pi4 either direct from a separate 5v, 3amp PS, or from a 12v-5v (3 amp) buck converter connected between PPB and Pi4. Powering the PI4 from a hub charging port will be flaky (sooner or later). USB and wireless are the first to go on Pi4 when power is insufficient (my own experience with Pi4). Cheers, Doug
3 years 7 months ago #57582

Please Log in or Create an account to join the conversation.

  • Posts: 326
  • Thank you received: 50
Hi Doug. The power spec of the recommended power supply for the RPi4 is 3A at 5.1V, and I have one spare that I have substituted in place of the 1.5A charger USB port from the hub from time to time. I also measured the voltage and current draw of the RPi4 in this actual configuration with a Sandisk Extreme SSD and the tp-link 7-port powered USB 3.0 hub being the only directly USB connected devices. The input voltage never dropped below 5.07V and with KStars running, mount slewing and camera imaging away the RPi4 current drawn peaked at around 550mA. I'm not discounting possible power issues, but they don't seem to be of infleunce here.
3 years 7 months ago #57589

Please Log in or Create an account to join the conversation.

Time to create page: 1.111 seconds