- Cloudynights qhy polemaster for mac how to#
- Cloudynights qhy polemaster for mac serial#
- Cloudynights qhy polemaster for mac driver#
Wat jij kunt doen met je 9.25 is een reducer aanschaffen, dan wordt je gezichtsveld ook breder en hoef je niet meteen heel precies de sterren te volgen om goede foto’s te krijgen. Daarom adviseer ik vaak om te beginnen met een kleinere telescoop, dan kun je iets meer “volgfouten” hebben omdat je gezichtsveld dan ook wijder is. Als je net begint dan is het – denk ik – als eerste van belang om een hele goede montering (EQ mount) te kopen met genoeg draagkracht zodat je met de 9.25 XLT heel precies de sterren kunt volgen, heb je dat al? Daarnaast heb je ook een “volgtelescoopje” + “volgcamera” nodig. However when I unplugged the PoleMaster, all the rest can be connected back on to Ekos/ INDI server.Dag Ruut, De 9.25 is mooi, maar ook een grote telescoop.
Ekos/ INDI server has a pop up message of "No QHY cameras detected. 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. Firstly, let put aside the QHY5L-ii-m get frames problem in PHD2. Today I have some new findings, at least I have replicate the problem. 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. 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.
To avoid the potential 2.4G interference problem, I've disabled it and only connect the pi to the 5G wifi. usb 2-1: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd usb 1-1.3-port1: unable to enumerate USB device usb 1-1.3.1: device not accepting address 9, error -71
Cloudynights qhy polemaster for mac driver#
usbcore: registered new interface driver brcmfmac brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6 usb 1-1.1: USB disconnect, device number 3 usb 1-1.3.1: new low-speed USB device number 9 using xhci_hcd usb 1-1.3.1: device not accepting address 8, error -71 bcm2835_audio soc:audio: card created with 8 channels usb 1-1.3.1: Device not responding to setup address. systemd-journald: Received request to flush runtime journal from PID 1 usb 1-1.3.1: new low-speed USB device number 7 using xhci_hcd usb 1-1.3.1: device descriptor read/64, error -32
am I really run into the trouble of the USB 3.0 + wifi 2.4 G interference? It seems "brcmfmac" is involved, I'm no expert on what it is but it seems it is a drive for wifi. 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? Thanks dmsummers amd Hans for the replies above. There may be other / better ways to do this. Now I chose to maintain these rules by myself. SUBSYSTEMS="usb", ATTRS ="0507", MODE="0666", SYMLINK+="sx_lodestar"Those rules get activated on boot, or manually with 'udevadm control -reload-rules'.
Cloudynights qhy polemaster for mac serial#
Just read up on the serial port naming and such (and search youtube for the video).
Cloudynights qhy polemaster for mac how to#
Jasem has a youtube video on how to name your device ports to avoid this confusion. The post describes that further.įinally, 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. 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. In the end, it was RF interference between USB3 and wireless at 2.4GHz. In my case, lots of folks advised me about power, but my Pi4 was acting really flaky (like you describe). 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. 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.
You should try to only use 1 of the PI's USB ports (ONLY for the USB hub data connection back to the PI). Is your Astroberry a Pi4? If so, you need to be sure it's getting enough amps. You're running with a powered USB3 hub, so that's likely good. I'll start the advice chain by recommending you rule out a couple of first magnitude likely culprits.
0 kommentar(er)
