thanks for your reply. There is no ZWO EAF in drivers.xml, but I tried and moved the lines from indi_asi.xml to drivers.xml. But it's the same behavior then, changes always go into ~/.indi/ASI EAF_config.xml.
I have to revive this old thread again, because the solutions doesn't work for me anymore.
I have Astroberry on RPi4 with 2 ZWO EAF focusers in 2 setups with differing maxpositions. In /usr/share/indi/indi_asi.xml I created 2 devices:
<device label="ASI EAF APO" manufacturer="ZWO">
<driver name="ASI EAF APO">indi_asi_focuser</driver>
<device label="ASI EAF Newton" manufacturer="ZWO">
<driver name="ASI EAF Newton">indi_asi_focuser</driver>
I even changed the driver name, not only the device label, but that made no difference. Every time I change the maxposition and save the configuration, only the file ~/.indi/ASI EAF_config.xml is updated. The 2 files ~/.indi/ASI EAF APO_config.xml and ~/.indi/ASI EAF Newton_config.xml remain unchanged (although they exist).
It worked before, but I didn't use Astroberry for several weeks. Yesterday, I updated all and had to modify /usr/share/indi/indi_asi.xml again, as described, because my previous change was gone.
Do I miss something, or am I doing something wrong?
You mean the “Park mount at HH:MM every day” function in the mount tab?
this might be a stupid question (sorry if so), but is there a possibility to stop mount tracking after an image sequence? After finishing an (unattended) image sequence, I want the mount motion to stop to avoid possible collisions.
I tried setting a min Alt limit in the Ekos mount tab, but that only seems to prevent the mount to slew below that min altitude. When tracking an object and the object gets below the limit, tracking continues.
I'm using a HEQ-5 with the EQMod driver on a RPi 4 (Astroberry image).
Thanks for any help and CS
I did the changes in /lib/udev/rules.d/60-rpi.gpio-common.rules as Jasem described (for me the directory was „rules.d“ and not just „rules“). In fact I added the obviously missing slashes „/“ in line 3 between /sys and %p.
Then I connected all devices again to my USB3 hub as before. After reboot, my ASI290 was recognized, so issue seems to be fixed!
I‘m an Astroberry user, not SM, btw.
Changing the EQMod Direct cable from my external powered USB 3 hub directly to one of the Raspi’s USB 2 ports did the trick for me as well. Now my ASI290MM is recognized by Indy again, finally. The ASI290 is connected to the USB 2 hub of the ASI294 which in turn is connected to the USB 3 hub.
Same for me, 4.19 vs. 5.4.
Of course new features are worth an update. What I mean is I won't do updates just because there is an update and it has nothing to do with Kstars or PHD2 or something Astroberry-related. And having a proper backup of the whole system is mandatory. I have to figure out what's the best approach here.
In the mean time, I got an answer from the wifi stick's support (the driver was not running) and they told me I have to update to the latest kernel etc... after that my wifi stick will work, but my ASI290 will be gone again. So I have to hope that there will be a solution to have the latest Raspbian updates and the USB issue solved.
But nevertheless it's a good time for solving problems now since we have bright moon weeks...
I reflashed my SD card with a clean Astroberry 2.0.2 image and my ASI290 is back again...! As expected. I restored my backup copy of the Astroberry home folder and almost all settings are back. Still have to implement boot from SSD and my wifi stick isn’t working yet (have to compile the driver), but I will get this sorted out as well.
Then I will stop making updates unless it’s absolutely necessary. The RPi is a tool for my hobby, not my hobby itself. It cost me 1 valuable, perfect night for M16, the last possibility this year. If the moon is gone again, M16 is too deep in the west for a senseful session. A pity. Thanks to an update I never needed. If it ain’t broke, don’t fix (or update) it.
thanks for the reply. The ASI294MC is working correctly. This is a USB3.0 cam. The ASI290MM is not working (is not recognized). The 290 is a USB2.0 cam. I tried to plug it directly into one of the Pi's USB2.0 ports, no success. All profiles have CCD = ZWO, I didn't change anything there.
You are right, in the log is no ZWO related error. In fact it is missing the "[ org.kde.kstars.ekos] - Ekos received a new device: "ZWO CCD ASI290MM Mini" line... it is as if the cam is not connected at all.
Maybe/probably I have the same problem that is discussed here: No ASI Camera after Update - Suspect port mapping
I already tried this
sudo rpi-update e1050e94821a70b2e4c72b318d6c6c968552e9a2