Here is my list of USB devices from a couple of days ago. After a sudo apt update and sudo apt upgrade yesterday intended to freshen up my image with KStars 3.4.3, all the devices located on the RPi USB2.0 bus are missing. If I revert back to an earlier image all is well again. I’m guessing that the upgrade to Raspian OS caused the issue rather than KStars.

Another day another update/upgrade. Raspberry Pi have issued a further change to the Linux Kernel which I upgraded to yesterday. This did not immediately sort out my USB issue however, although by process of elimination it seems that disconnecting the Pegasus Astro Pocket Power Box from the powered USB 3.0 hub and connecting it directly to one of the RPi4’s USB2.0 ports got things all working again. Jasem refers to a Raspberry Pi Kernel issue in his responses on a Stellarmate thread today. www.indilib.org/forum/stellarmate/7374-n...ct-port-mapping.html

Astroberry has always been built with Raspbian, but there may well have been a kernel update within the latest upgrade....

Hello,

I went out last night as my son and his family wanted to see NEOWISE. My rig includes 2 USB 3.0 hubs because they have the right form factor. As I review my equipment, all devices are USB 2.0.

Problem: the difference in operation is distinct as night and day. The Hubs are 2.0 compatible. The Raspberry PI has two 3.0 ports.

When I plug my equipment in, the first item in the hub chain works. The ancillary devices partially work, enumerate but complain vociferously in syslog and INDI. Udevadm rules partially work if they are universal. Button line, rules for SYMLINK do not get created. This almost suggests RPI4B is rigidly USB 3.0 compliant or my Hub are loosely 2.0 compatible.

When I plug my Hubs into the RPI4B 2.0 ports, every 2.0 device is happy and INDI is also. What happens is GPSD is the canary. My UBlox-7 is second in the hub. GPSD works and locks on. Time works. SET to Now works. KSTARS knows where it is.

Under USB 3.0, UT time cannot be set by GPSD. Location is unknown. Setting Geographical Location to my preloaded configuration feels good, but GPSD issues breaks KSTARS. KSTARS does not know its location. It defaults to Warsaw, PL. KSTARS collapses to a shutdown and pack up.

Now that a distinction between USB 2.0 and USB 3.0 has been established, I surmise that this update trued up USB 3.0. A rigid 3.0 spec is restricted to USB 3.0 devices. The use of chained USB 2.0 devices need not apply. The first USB 2.0 device in the chain gets serviced.

Hence, I have involved myself in several discussions not knowing the USB 3.0 issue. Now, I can ask, “what USB version is the device and which port is plugged into?” Pick a USB 2.0 port. Don’t mix 3.0 and 2.0 devices together on USB 3.0. Priority will be given to USB 3.0.

@AradoSKYindi: "Now that a distinction between USB 2.0 and USB 3.0 has been established, I surmise that this update trued up USB 3.0".

While it's possible you're right, I think it's important to post your full communication setup before making too many assertions. There are at least 3 known / documented issues with PI4's USB3 on the forum (all with solutions or workarounds). Here are the 3 Pi4 USB3 issue threads I know about:
www.indilib.org/forum/general/6576-pi4-u...erference.html#56911
www.indilib.org/forum/stellarmate/7382-f...rp3-or-pc.html#57229
www.indilib.org/forum/stellarmate/7374-n...t-mapping.html#57258
The first post deals with USB3 RF interference for wifi, bluetooth, HDMI, and some screen resolutions. The second one deals with an extension of the same interference issue to GPS. The third one is related to a Raspian kernel issue triggered in this latest release. So, to know which issue you're tripping up against, you should indicate your communications setup. Then you'll have a better idea of whether you're facing something new or not. For example, it sounds like you have GPS, but are you using Ethernet or wireless? Are you just using the USB2 ports on Pi4, or a mix/multiple 2/3 ports (etc.). Cheers, Doug

Hello,
This was my opening communication path. I separate Video from Controls into two different ports. The hub pipe is stout and all hubs are powered.

“My rig includes 2 USB 3.0 hubs because they have the right form factor. As I review my equipment, all devices are USB 2.0.”

As such, my assessment was performance based. My AstroEQ worked on the right 3.0 hub. The UBlox-7 and 32G USB stick partially load. GPSD throws many errors about UT not being set. GPSD shows it is running. But cgps and INDI cannot talk with the device. INDI throws many errors about unknown site. Clocks are off even though an RTC is installed, daytime at nighttime. The default site is Warsaw, Poland. KSTARS cannot operate. Setting Geographical Site does not change clocks, location or time zone. The end is to quit.

My QHYCCD PoleMaster worked on the left hub. The QHY5LII and the ZWO ASI 120 mini sort of worked on the same left hub. They don’t cause KSTARS to become inoperable. Getting video maybe a bad experience. Crippling KSTARS is not the problem.


With both hubs under USB 2.0, all systems are good. No faults are presented. UT is not right time zone. KSTARS knows where it is. GOTO is working fine. I imagine if all devices were USB 3.0, then nothing would be said.

Inspired by this I tried a reordering of the connections to the USB2.0 and USB3.0 ports of the RPi4. I moved the USB3.0 cable which feeds the 7-port USB3.0 powered hub to one of the RPi4 USB2.0 ports. I connected the two USB3.0 devices, the SSD and the ASI camera, directly to the RPi4 USB3.0 ports, and the other devices to the USB powered hub, presumably now operating as USB2.0. This was not helpful, in this arrangement lsusb didn’t list any Bus 001 (USB2.0) devices, only three Bus 002 devices, the SSD, ASI camera and the RPi4 USB3.0 hub.
Still, for the moment I have a working arrangement, so have gone back to ‘leaving well alone’!

Hello,

A working state is a better state. I use 4 port hubs. I split video devices from controller devices.

Port 1: AstroEQ, UBlox-7, 32G Drive
Port 2: PoleMaster, QHY5LII, ZWO ASI120mm, Joystick

I tried 7 ports and had similar issues. 7 ports are plentiful. The power looks impressive. 4 seem to have better results. I make sure total amps and amps per channel match the hardware.

I tested 2x RPi4 with 4 Gb memory with full OS and KStars updates installed with a Canon camera, 2 ZWO cameras, ZWO filter wheel, ZWO focuser and an iOptron mount and no problems whatsoever.


Wouter

My present feeling is that the upgrade to the RPi kernel 5.4 from 4.19 has changed something in the behaviour of the USB ports. However it is quite possible that my device installation was marginal before due to the several potential ‘earth loops’ and possible WLAN interference. Incoming 12V power is split by the Pegasus Astro PPB, from there drives the mount, the focuser, the camera cooling and the powered USB hub. The hub powers the RPi from one of its charging ports, and the RPi USB ports link to the SSD, the USB hub, and the PPB. The camera, mount and focuser have USB cables from the hub, except the guide camera which is fed from the main camera’s internal USB hub. I guess cable lengths, pathways, and ultimately, screening quality may all have influences here. I should probably start searching out clip on cable ferrites.

Hello,

Without evidence in logs, it is possible for anecdotal evidence. When all logging systems go silent, that is evidence also.

My evidence is quite lengthy. The number of days committed to fixing GPSD, INDI, ZWO, and QHYCCD because rules stopped working are many. I have come to the conclusion that these USB 3.0 are compliant to the spec. One to one works well. One to many does not. The RPI4B does not rate what we add to the device via these 2 sets of USB ports.

With my gear, I think like must link with like. My HUBs are USB 3.0. All my devices are USB 2.0. The number of hubs I have tried are 4. Always the same problem existed. I selected
1. Telescope = EQMOUNT
2. CCD = QHYCCD
3. GUIDER = QHYCCD
4. ACCESSORY 1 = GPSD
5. ACCESSORY 2 = SkySafari
6. ACCESSORY 3 = Joystick
7. ACCESSORY 4 = ZWO.
I should have 7 devices. I am seeking to establish which CCD I am satisfied with. The test comes when this profile is run. When stuff goes missing or a feature doesn’t work in INDI, that is when research begins.

The number of rules edited specific to this list are many. Udevadm became my friend. GPSD became my focus. Powered hubs became a need. 7 ports at 35W were tried and rejected.

The RPI paradigm is not Windows. Each port is designed to give one device power. Under RPI3B+, a specific model and splitting the load to two powered USB 3.0 HUBS with 4 ports brought better results. The 7 devices are connecting, INDI is working, and the site is physically identified with the correct time zone and time.

Then, the memory and power complaint of the OS became to appear. RPI4B has a heftier Amp rating and memory. I went with RPI4B. The solution had been vetted out. Will it work? It should.

Rules in Ubuntu are different in Raspbian. No custom rules worked. They were in the wrong directory.

After normalizing Rules and individually testing, all devices were fixed. Remember, USB 2.0. All tests were conducted under USB 2.0.

In the field, the night is dark. USB 3.0 ports are used. GPSD stops working. Time is yesterday last week. Everything with time is back to Warsaw Poland. The GPSPANEL shows the locating as Warsaw, Poland. Syslog stops logging. INDIWEBMANAGER stops logging. GOTO goes to a location somewhere in the world with a different time zone. It is pack up time.

Only recently did I think to go to the USB 2.0. There, everything works, sort of. My two RS232 devices bounce between ttyACM0 and ttyACM1. Under RPI3B+, they are consistently at their assigned ports.

After research, Raspbian rules are different. I settle with a workable solution such that consistent ttyACM ports are assigned. Now, normalcy is back. I just have to wait for clear skies.

So, the USB 3.0 issue with the USB 3.0 hubs chaining USB 2.0 looks more about hardware and not the OS. My USB 3.0 hubs have thick USB cables stacked. They work fine under USB 2.0 ports. I like splitting device use to two channels. Priority is always given to port 1.

Manual setting Geographical location in KSTARS does not overcome a dead GPSD service. In my conclusion, GPSD is a critical component which can impact KSTARS by crippling its ability to GOTO any place. Going nowhere in space is not very satisfying.