If you are using Blind solving in PointCraft, please update to APT 3.81 to avoid possible problems. There are also few improvements for native ZWO connection and bit more.
We have released a small update in order to address some stability issues, to fix the blind solving of color CCD/CMOS images, to add support for new ZWO and Nikon cameras. Take few minutes to update your APT!
It is not a deviation This topic is for questions and news about APT.
The latest camera should be supported without need to change APT. Possibly there will be need to update the ZWO drivers. Of course if changes are needed in APT will make them shortly.
It was not planned to make new site, but the hosting options for the old one were getting too few. Rewriting it, opened new options in long term Also it was a fun to learn new platform
APT was updated to version 3.84. It comes with support for a new great solving application named ASTAP, handy USB monitor to keep track what is going on with the devices in the setup as well as more new features and many fixes.
Appreciate your thoughts on a challenge I am having running two ZWO cameras in parallel - a ZWO ASI071MC-c Pro and a ZWO ASI1600MM-c + filter wheel. One gets controlled by APT and the second by SGP. I intermittently get download fails somewhere in my -3 hour long imaging runs (taking 2 -5 minute subs, each camera driver told to use no more than 40% of available 5Gpbs USB3 hub bandwidth).
It most often affects the 71MC-c Pro controlled by APT - even when doing darks I get image has waited more than 30 seconds to download (for over an hour). When this occurs and I notice it I have to simply disconnect and reconnect the camera than it all works until the next timeout - 30 - 240 minutes later.
Both cameras run off one of two powered USB3 hubs over separate 3m USB cables to my astrolabs PC's USB3 ports. Each camera has the latest driver and is powered by a large, high quality Lab power supply.
I have just upgraded to the latest APT version today and SGP is also the latest version.
I suppose that you have tried to switch between the ASCOM and native driver?
Other idea is to try to make a USB2.0 connection at higher speed. From all the feedback I have with ZWO, QHY and Altair Astro cameras this is common problem with the CMOS models. Quite random and hard to reproduce. My opinion it is caused hiccup of the USB connection that can caused by ambient temperature and/or humidity and/or cooling. I don't remember to see such behavior with un-cooled camera.
Sometimes changing the USB cable/hub works in other doesn't
I'm sorry that am quite fuzzy, but this is the information I have...
I have tried adding a new port and swapping ports around. I updated from v3.54 to the latest version of your software and find the USB monitor very helpful - it showed me the ZWO ASI120MM-s guide camera switching on and off ever few minutes for a few seconds - which made me wonder is the MBeat powered USB3/2 hub - with individual on / off buttons per port - possibly got a bit of a troublesome on/off button!
I switched the 120MM-s around once to a different port on my second MBeat hub and I saw no more switching on and off for almost an hour before the behavior started again with just that camera. So I simply switched it off then.
I got no USB errors to indicate any problems with the ASI071MC-c controlled by APT - but it did failed downloading an image twice causing the run to totally hang in the first 3-4 minutes of a 4 hour dark run. After these two failures I switched the order of dark frames to take short images first and it has been rock solid for over two hours now. SGP I have noticed seems to have had 2-3 hangs, but I guess it has a timeout function that if an image isn't received in minute it aborts the shot, tells the camera to clear its buffer and tries again. Wonder if that is something APT could adopt too?
So my thinking before I switch to USB2 is to try a high quality powered USB3 hub whose ports are always on; would you recommend any brand?
By the way yes I have switched to the ZWO native driver - I think your software is very impressive!
One last strange behaviour - if an imaging running had to be stopped when the camera download timed out - once or twice the cooling aid would say cooling - to a target temperature of -5 - but whilst the camera had risen in this time back up to -2 or -3 - it would raise the temperature all the way to 15 degrees, before cooling it back down to -5! Any idea how this behaviour switched on - it was like it was trying to enforce a non selected warming aid before it would give precedence back to the cooling aid!
I have used a few different packages (APT, SGP, Voyager) and I have seen that cooling behavior occasionally with all of them using my ASI294. When I see it happening I disconnect and reconnect the camera and it short cuts it back to normal cooling.
The control over the cooling is kind of limited. It is possible to turn it on/off and to defined target temperature. The rest is made by the camera electronics.
Matthew, good news that the connection is stable with the USB2 hub as it is a solution. The bad news is that this is one more evidence that the USB3 cameras have a weak point in the communication
I switched to a different powered hub and now it is back stable again as a USB3 camera. I agree with your summation - I wish ZWO would acknowledge that point and either provide diagnostics tools, warnings or a list of gear they certify their cameras will work with.
That was a lot of avoidable worry and angst to try and track down the root cause of the problem.
Your USB diagnostics module made all the difference. But I still absolutely don't see how an issue with one device on one hub can manifest as a problem with one or more separate devices on other hubs - that is really concerning!
APT was updated to version 3.87. It comes with better support for ZWO and Altair Astro cameras, support for new Canon and Nikon models, settings profiles as well as more new features and many fixes.
Thanks for your great work Ivo.
I have just started in astrophotography and use APT with my EOSM6.
I am now at a stage where I am tipping my toes in the scripts to start at a defined time. This because the moon is still up when I am awake. :-)
I got it working yesterday but that was with a very simple script sequence as I had done the plate solving before I started the sequence.
Now I want to do the GoTo++ automatically as well by using the image from the previous night.
Not sure how that will translate in a script.
How does this work?
There are two ways to script the goal The first and more precise is to load the image and solve it in PointCraft, click Store and save the target as Custom Object. After that use the ScriptEditor when you are editing the plan and select the target when you are adding #GoTo++ command.
The second way is to use the #LoadImage command and after that #SolveGoTo command but it will make regular GoTo, not GoTo++
I tested it yesterday on M83 and did some test runs prior. Glad I did as I forgot to connect PHD2.
When I woke up this morning everything worked with the exception of restarting after the meridian flip.
It was working fine the previous few nights, not sure what the difference is.
Another test session yesterday night and everything was working this time, including restart after the meridian flip.
No idea why it didn't do it the night before.