After updating to the latest stable release I had difficulty with the ASI cameras.
After two weeks both cameras are connecting at the moment, but I need to find more consistency.

Simplifying can help, I ran with an Ekos profile using just the telescope simulator and a single camera.

Many of my failure runs seem to have been due to prior errors. I connect through hubs and have to
remove and reconnect power to them between Ekos/driver sessions. I have not gone back to without hubs
to see if it really the disconnecting of the camera that is impacting results.

Running the /usr/bin/asi_camera_test can provide a clue where to look for the problem. I think it is provided
by the install and uses the same library code.

There was a period where the camera was connecting but not fully and I mistook those as failures to connect.
Presently it takes a minute or so for the connection to become apparent. Then after another minute or
two the indi screen finally puts up the Control tab.

It might be worth examining the ~/.indi/'ZWO CCD ASI294mc_config.xml' file to see if all the name and settings
appear correct. A new guide camera was introduced and the xml file contained a mix of camera types. Probably
something I caused unknowingly.

The last time of trying to use the imaging camera an exposure would count down to 0 and then restart the exposure again without producing an image. This is an old problem, seems like a year or so since last seen. I note the ASI rules.d file has been replaced.

Hi All,

I tried two set ups a couple of days ago in the field using ASI cameras (ASI1600 MM pro with ASI120MM guiding on Astro-Physics mount and another using a different RPi with NEQpro EQMOd ASI294MCpro and ASI120MM guider) both were using a locked in nightly build from about 2-3 weeks ago and both set ups performed perfectly. I will try to find out the details of the nightly that I am using. I have not updated since.
I will try to find the details of that build and post it.

Mike

How do you lock in a nightly? Do you just remove the PPA, or just don't upgrade?

Hi,

Write this into a terminal as per my post above

sudo apt-get install ppa-purge
sudo ppa-purge ppa:mutlaqja/indinightly

and it will remove the ppa for any nightly build. When you then update and upgrade using software updater you will revert to the stable build.
If it is all working OK go into the software updates gui and remove the ppa for the stable builds by unticking the boxes that contain the mutlaqja ppa then you can still update your other software using apt-get or the software updater but KStars will not update.
However if there are some issues with the stable build as per the above posts you may have to wait until these are resolved in the nightlies and then update to the one that works and lock it in by removing the nightly and stable ppas.
These driver issues that crop up in the nightlies are usually fixed fairly quickly so if you are still getting problems keep an eye on the forum and try another nightly as that is where any fix will be pushed through.

My working build is Version 3.5.3. beta
Build- 2021-03-12 T01:13:57Z

Hope that this helps

Mike

Cool, reverted back to stable 3.5.2
Build: 2021-03-01T11:47:36Z

All devices are found and run!

This version still has Celestron driver 3.5, but I need 3.6 to fix the pulse guiding rate but at least I can guide ST4 and know how to get back, and do testing now.

Thanks so much everyone!

With today's nightly (March 16)  both my ZWO cameras are working again...but my ZWO EAF still is not recognized.  

I don't think nightly is the problem. More likely a driver readiness issue. As I described, I had similar problems a couple of nights ago with my ZWO-EFW and my ZWO imaging camera.
Can you mount the EAF from the device manager after starting EKOS and after your cameras have been found? If not, try unplugging the EAF, plug it in again, then retry mounting it from the Device Manager (found under Tools) with EKOS running.

It could also be a timing issue. Perhaps some, but not all, of the nighlty package builds have finished and a mix of old and new packages gets downloaded leading to inconsistencies.

I was also thinking of a timing issue, but a different one. I had 4 independent copies of Kstars on my Pi, one install from nightly 2 days ago and 3 independently compiled versions with different dates that had all worked fine previously. The only common factor was that I had updated the drivers which would be used by all the Kstars versions. Each of them had the same problem finding my ZWO peripherals. Only the ASI120MM-S was found every time, along with the CEM25 and the Moonlite focuser module.

What I was wondering is whether the updated drivers might have taken too long to find the peripherals and timed out? The interesting part is that only ZWO peripherals were affected and the one that uses the lowest amount of resources, i.e. the camera with the smallest sensor, had no problem with connecting.

Does this make sense?

Jo

Thanks for that Jo but the ZWO EAF won't come up from the device manager in Kstars.  I know it is not a focuser problem, it works fine with the Kstars stable version.

Again, I am running the stable release using an Intel machine, ubuntu 20.04.
Have problems with both imaging and guide camera, no problem with ZWO filter wheel.

Perhaps relevant to the thoughts about it being driver readiness/timing releated.
I have always run a local setup with Ekos and drivers on the same machine with
Ekos auto starting the drivers. However since updating to the recent release
the only way I found to coax the Astrophysics Experimental driver through its
initialization was to use indiserver to start the drivers. Then use Ekos remote
to the same machine without auto start. That allows the connect and cold start
buttons to be functional for the mount.

So it finally dawned on me to revert back to the original method of startup and have
Ekos start and connect to the drivers. Now both cameras connect and operate okay.
I have only gone back and forth two or three times but the results seem consistent.
No longer have cameras failing to connect, or connecting but taking 2 minutes to fill
in the indi panel controls. Also can image without it looping and restarting the image
attempt several times.

In case it is of use to anyone, local vs distributed startup playing a role?

For the moment for me it is camera or mount, pick one. I think next will try
stringing a USB2 cable to the mount instead of ethernet see if that changes the
timing.

Edit:
Correction I get the same beneficial effect by not using auto connect in Ekos, that is I do not have to use indiserver to
prestart the drivers. Uncheck the auto connect box in the Ekos profile. That still allows access to the cold start button
after connect for the mount. It seems (for me) I need to allow Ekos to auto start the ASI drivers for the cameras to work.
Then can manually connect to the other drivers.  Will see if this holds up when able to do an imaging session.

 

Unfortunately, last night my Pi executed unattended updates before I could stop them and now my ASI-EFW is also no longer recognized. 

Arghhh!!!  I need to roll back the drivers to an earlier version.  It can't be Kstars, since I have multiple independently compiled versions dating back to December on my Pi4, so it must have something to do with the specific driver for the ASI-EFW.  I now cannot even get it to be recognized manually anymore.  Cameras are now being recognized just fine.  But the ASI-EAF is not anymore.

Has anyone found an easy solution for this?