In my case I'm getting this error all the time now, and I'm not missing any index files, I downloaded even the largest ones.
About the possibility it simply means that it can't find enough stars - I don't remember ever getting this error before when the solver could not find enough stars. Are you sure it means that?
The error is precise and appears in the solver log: "solution file doesn't exist"
Isn't that enough to track it through the code ?
have you tried nighly channel ?
Same exact problem here using last nightly build. Reported the error to Stellarmate with a ticket this morning.
Once again, the power of AZ-GTI in Alt-Az mode. I just walked out around 11PM in Poitiers, France (urban area, clean sky though), installed the mount on a Gitzmo lightweight photo tripod, launched the Synscan Pro app, did one star alignment to Rigel, connected Stellarmate with Synscan driver, did one Sync with astrometry, then goto M42. Then 100x10sec frames at 800ISO with my D5100 hacked DSLR through a 127" sky-watcher MAK, plus some dark and bias, then stack, boom.
Having a driver that can do this without having to bother about connection issues in the background to the Synscan app would be tremendous!
Here's a picture I did yesterday using Stellarmate with my AZ-GTI working in ALT-AZ, Nikon D5100, and SkyWatcher 127 MAK, just one exposure of 30 seconds:
@geehalel thank you SO MUCH for your work. Indeed, having a driver available to track correctly to be able to plate solve as a quick sync technique would be amazing. Let me know whenever there is something to test. All my very best and again, thank you. Federico
"I don't know when does field rotation appear in altaz mode, but plate solving may also fail in altaz mode for that reason, even with a perfect smooth tracking. Or am I wrong ?"
Field rotation would not disturb pictures with an exposure so short as I was describing above (10-15 seconds)
And to the why not use the wedge, I have it, but if I bring it I also have to bring the counterweight, which adds about 4kg to the package and also requires a more serious tripod and kind of overweights the AZ-GTI at least theoretically. In AltAz you can use AZ-GTI with minimum weight and becomes perfect for traveling. Additionally, Alt-Az doesn't require polar alignment so it can be snappier to set up.
Dear Jean-Luc, I will read and respond more thoroughly later today but I wanted to mention that the situation where AZ-GTI (and others) in AltAz can excel is in EAA (Electronic Assisted Astronomy). With my Nikon D5100 you can capture deep sky pics of short exposure (10-15 secs) at 1000 ISO and live-stack them and have a wonderful experience of almost-real-time seeing of objects you can't see with your eyes. As you mentioned, doing this requires somewhat precise tracking (sufficiently precise to avoid blurry images during the 10-15 secs of the exposure), although movement / rotation between pics is unimportant since the live stacking can correct it.
Jasem mentioned EAA was in the roadmap of Stellarmate. More later, thank you for your response!
Dear Jasem, sorry to be communicating about the same subject on many fronts (Stellarmate support ticket HAYB-000932, Github enhancement demand
, and now here).
As I mentioned in both other places, the version of the indi_skywatcherAltAzMount driver you are using with the alias AZ-GTI AltAz is the one that still contains the bug that doesn't allow UDP connection with Az-GTI, as explained -and then solved- in this GitHub bug github.com/indilib/indi/issues/1158 ).
So that's the first problem. The second problem for is that when using AZ-GTI in AltAz with indi_skywatcherAltAzMount driver (not your version), it does not track. The driver connects through WiFi (UDP), and then it is parked. If I unpark, it goes somewhere, but when it gets there it doesn't track. I can slew somewhere else (sometimes, sometimes it stops) but again when it gets to destination it does not track.
As the original post demanded, I also think the best would be to have an AltAz "translation layer" between Ekos and AZ-GTI eqmod-based driver, translating from AltAz to EQ and back in every interaction with said driver, would that be possible? Since that driver works seamlessly with AZ-GTI whereas the indi_skywatcherAltAzMount driver does not.
Dear Jean-Luc, as I mentioned in my recent exchange with Jasem, both skywatcherAltAzSimple and indi_Skywatcher_AltAzMount drivers are buggy on many front; particularly, with the AZ-GTI mount, the mount keeps slewing randomly for no reason, these are small slews but enough to slip from your target. When you try to do platesolve-alignment, alignment is continuously stopped by an error that says "slewing detected, aborting solving". Also, it's difficult to provide any stable piture of stars for plate solving because tracking is significantly bad. These two drivers, at least when connected through UDP with the AZ-GTI mount, give very bad results in my experience. Compare that with your driver, based on eqmod: I've been using it (in EQ) for months, never a bug, tracking is perfect, etc etc. So I believe strongly that the best would be to have an option in your driver for alt-az mounts. That would also alt-az users to profit from all future features added to your driver. For instance, recently a version of your driver added a feature to use the SNAP port of the AZ-GTI mount to take pictures longer than 30s with DSLRs (
) - although pictures longer than 30s are not probably a good idea for altaz operation, it would be nice to have the feature to try. Thank you so much for your work on this driver!!!
Can you invite Jean-Luc into this conversation?