Hello guys, I've been setting up my Astroberry Pi, I'm able to connect my equipment most of the time, including my main camera (QHY CCD), guide camera (QHY CCD), Pegasus Pocket Power Box, and PoleMaster to it, however it is not always working as the main camera (some times the guide camera or the Pegasus PPB) cannot be connected.

In the screen dump, most except the main camera cannot be detected by EKOS.

Is the problem related to the USB devices/ connection?

PS: All of them are connected via a USB3.0 powered hub. The PoleMaster is installed manually, and somehow it can always connected and works (execute using sudo PoleMaster).

I'd like to make sure my system always work in valuable clear sky night, appreciate for any advice!

Here is my original post in cloudynight, I'm advised to ask around in this forum: www.cloudynights.com/topic/702220-astrob...problems/?p=10115855

I'll start the advice chain by recommending you rule out a couple of first magnitude likely culprits. First, there's power. You're running with a powered USB3 hub, so that's likely good. Is your Astroberry a Pi4? If so, you need to be sure it's getting enough amps. You should try to only use 1 of the PI's USB ports (ONLY for the USB hub data connection back to the PI). If you have monitored via PPB the amp draw and you're confident this isn't a power issue, then you should next rule out any possible Radio Frequency (RF) interference of the USB3 ports. If you move your USB3 Hub connection to a USB2 port on the PI, does everything work (albeit more slowly)? If so, then are you using a wireless connection at 2.4 Ghz? If so, USB3 RF interference may be the cause. See this post:
www.indilib.org/forum/general/6576-pi4-u...erference.html#51297

In my case, lots of folks advised me about power, but my Pi4 was acting really flaky (like you describe). In the end, it was RF interference between USB3 and wireless at 2.4GHz. I used a ethernet cable to isolate and verify that, and then things started to become clear as to what options were available to mitigate. The post describes that further.

Finally, I have noticed times when not having "named" devices/ports (especially when moving USB cables around during debugging) can cause the next startup to be confused. Jasem has a youtube video on how to name your device ports to avoid this confusion. Just read up on the serial port naming and such (and search youtube for the video).

Good luck.....

dmsummers gave good advice already. I want to add a bit on the named devices as you mentioned ttyUSB0 and ttyUSB1. When you have disconnect/reconnect problems the old entry that was made for the device may not be gone yet, and then you get a new one with a higher number. This is annoying as you have configged INDI to look for ttyUSB0, but now the device new name may be ttyUSB1 and ttyUSB0 is unresponsive. The fix for this in Linux is to set up rules to name your devices yourself. Once done this makes the INDI configuration a lot easier too. For instance I use in /dev :
You can use 'tail -F /var/log/syslog' to see what happens when you plug in a USB device. And tools like udevadm to search for identifiers, for instance for my sx-ao-lf serial to USB adapter it lists :
I maintain the naming in /lib/udev/rules.d/99-observatory.rules :
Those rules get activated on boot, or manually with 'udevadm control --reload-rules'.

Now I chose to maintain these rules by myself. There may be other / better ways to do this. I hope others can fill in that.

-- Hans

Thanks dmsummers amd Hans for the replies above.
I have reinstalled the astroberry server 2.0.1 entirely, updated & upgraded using the usual commands, then this time, I have plugged in the mouse, keyboard and QHY5L-ii-m (guide cam, via an unpowered USB 2.0 hub) to the pi USB 2.0 ports and a QHY168C (main cam) directly to pi 3.0 port, and I get the follow error (dmesg), any clue what they are about?

It seems "brcmfmac" is involved, I'm no expert on what it is but it seems it is a drive for wifi... am I really run into the trouble of the USB 3.0 + wifi 2.4 G interference?

[ 2.328320] usb 1-1.3.1: device descriptor read/64, error -32
[ 2.547987] usb 1-1.3.1: new low-speed USB device number 7 using xhci_hcd
[ 2.648231] usb 1-1.3.1: device descriptor read/64, error -32
[ 2.779746] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[ 2.862433] systemd-journald[100]: Received request to flush runtime journal from PID 1
[ 2.868394] usb 1-1.3.1: device descriptor read/64, error -32
[ 2.988320] usb 1-1.3-port1: attempt power cycle

---

[ 3.868590] usb 1-1.3.1: Device not responding to setup address.
[ 3.968083] bcm2835_audio soc:audio: card created with 8 channels
[ 4.088029] usb 1-1.3.1: device not accepting address 8, error -71
[ 4.197974] usb 1-1.3.1: new low-speed USB device number 9 using xhci_hcd
[ 4.198638] usb 1-1.3.1: Device not responding to setup address.
[ 4.292437] usb 1-1.1: USB disconnect, device number 3

---

[ 4.547770] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[ 4.549617] usbcore: registered new interface driver brcmfmac
[ 4.638037] usb 1-1.3.1: device not accepting address 9, error -71
[ 4.639372] usb 1-1.3-port1: unable to enumerate USB device
[ 4.788305] usb 2-1: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[ 4.793034] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[ 4.808876] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Mar 2 2020 23:30:41 version 7.45.202 (r724630 CY) FWID 01-72f6ece2

There's some ambiguity in your description, but it sounds like you've got all the Pi4's USB ports engaged. I spent quite a bit of time myself trying to just use the Pi4's ports and avoid a separately powered USB hub. Seems like it should work, but it was never stable for me. For a "robust" solution, I do recommend using a separately powered USB3 hub (for all devices except Pi4), and a 15W (3amp) power supply dedicated to the Pi4. In my case, I used a buck module (12v-5v converter) to avoid a separate 5V power line on the OTA. That works very well (but requires soldering).

You haven't indicated whether your wireless is 2.4Ghz. RF interference would only be a factor for 2.4Ghz and USB3. If both are in use, you are most certainly going to have odd/diverse issues. My best guess in that case is that you might experience BOTH power and wireless problems. So, how much time do you want to spend debugging HW vs imaging?

Thanks for the reply. To avoid the potential 2.4G interference problem, I've disabled it and only connect the pi to the 5G wifi. You are right that no one like debugging but imaging, but in this unusual period of time where most of us need to stay at home, also the place where I leave with heavy light pollution, I don't have a backyard, current weather is no good... so I do have a bit extra time I can spend on debugging! I do have a new powered USB 3.0 hub, all equipment of mine are powered by the same 12v battery source, I also use a 12v-5v converter to powered the pi, I soldered the wire myself.

Today I have some new findings, at least I have replicate the problem. Firstly, let put aside the QHY5L-ii-m get frames problem in PHD2.

Whenever I plug in my PoleMaster, no matter to the 2.0 or 3.0 port or via any 2.0 or 3.0 USB hubs, Ekos/ INDI server is unable to establish connection to the main (QHY168C) or guide cameras (QHY5L-ii-m), but the Pegasus PPB can be connected. Ekos/ INDI server has a pop up message of "No QHY cameras detected. Power on?".
However when I unplugged the PoleMaster, all the rest can be connected back on to Ekos/ INDI server.

dmesg shows the below when I plugged in polemaster to any of the USB ports:
"config 1 interface 0 altsetting 0 bulk endpoint 0x81 has invalid maxpacket 64"
"config 1 interface 0 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64"

Any ideas?

I have no experience with Polemaster. However, when I did a search on the forum (right top search panel) for "Polemaster", there were several posts that came up that I would think you would want to review (if for no other reason to be aware). Sounds like there have been problems (at least in the past) with Polemaster. Not sure if those are fully resolved or not. Good luck....Doug