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.

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!

@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

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.

@Avocette: The danger is peak draw during startup. If you're monitoring amps from PPB, you probably can't be sure what the true peak is (I think it's more of an time sampled/avg peak). FWIW, I also see mild amp draw once the whole config is up & running, which the charging port might be ok to handle. Just wouldn't trust the 1.5 during startup, especially if anything is connected to the Pi4 USB3 ports.

I removed the EQMod cable and same results, so that's not it.

Hmm, well I guess it isn't as simple as I had hoped. It seems each of us has "that one device" that breaks things, but it isn't the same device for all of us.

Did a little research, and it seems the Pegasus PPB is controlled via USB-to-Serial internally (you plug a USB cable into it, but internally it has a USB-to-Serial adapter, and it shows up on the host computer as a serial device). So it seems USB-to-serial adapters aren't off the hook yet!

You are quite correct - nothing is yet off the hook. Attached is my lsusb list from the original working version, pre-kernel-upgrade. The PPB is Bus 001 Device 004. The EQdirect cable has a Proflific brand serial adapter which I recall caused a number of problems in the past - we were all advised to avoid Prolific and choose FTDI instead. I guess I have to get used to running lsusb before starting up KStars and counting the entries before resorting to replugging everything!

Interesting. Your Prolific USB-to-serial doesn't cause problems, but your FTDI one does. My EQDirect cable is based on FTDI.

I might be barking up the wrong rabbit hole, but then again....

I filed a bug report here: github.com/raspberrypi/linux/issues/3779

Hopefully we get some feedback on it.

I learned a new command (sudo lsusb) from your bug report, so I thought I would try it out. Before that I did a sudo apt update && sudo apt upgrade. I subsequently found that all my USB devices were listed both by lsusb and sudo lsusb. Has kernel 5.4 perhaps been fixed? My SSD installation seems to be working including the KStars 3.5.0 beta.