Issue of Target m51 in planning tools showing the incorrect date/time.
On SGP 4.1.0.753 beta version 32bit
The galaxy m51 in planning tools was showing that it was setting when the sun was coming up and that’s the opposite of the day yesterday when the object was above the horizon all night. It caused issues with plate solving and slewing to the object from SGP saying the object was below the horizon and would not slew. the mount separately could slew to the object m51, its an iopton cem 60 using ioptron commander on my PC or the handcontroller. I was able to force the sgp to get to M51 for the beginning of the imaging session, but it then failed to meridian flip and plate solve in the middle of the night I believe due to SGP having the wrong info.
I tried to get the program to adopt local location data and time and date from the mount, in the user profile area after experiencing the issue during setup in the beginning of the imaging run.
The time that the issue was in effect was starting around 7pm when I setup throughout the night and culminating in the failure at the meridian flip, maybe around 21:00
Now when I look at the planning tools this am, the graphic looks correct showing m51 rising and being above the horizon, unlike last night where is was the opposite and showed two nights worth of arcs on the graphic incorrectly.
here is a photo of what it looks like now: more correct
Here is the log file.
Here Is what i imported from the scope at the beginning of the session to try and correct the incorrect planning tools info i was seeing.
Thanks so much, i would like to avoid this issue in the future as it cost me imaging time after the meridian.
I am having a lot of difficulty following this. In terms of meridian flips, there is only one attempt in the logs and that is at 0149. In terms of the safety mechanism built in to disallow rogue slews to targets below the horizon, SGPro logs very specific details about that rejected request and I don’t see that in the log files at all. Is it possible that the events you are describing happened the night before last and not last night? In any case, the primary issue in these logs seem to be that the camera times out during download for almost all exposures.
Hey Ken,
sorry for the confusing explanation.
For me, the issue i think I was battling in the beginning during setup is that the SGP thinks its either the wrong time/date/location. So yes I was up against the safety mechanism of not letting it slew below the horizon, but in reality, M51 was above the horizon in the sky and IOPTRON commander or hand controller could slew to it no problem. I was trying to set the date/time,location data and i found Under the User profile manager and import from scope button, I did this and i was able to then slew and platesolve on m51. But the Planning tools of M51 was still showing incorrect info, and only showed updated to be correct the next morning so i assumed it was still struggling with that issue and caused the failed meridian flip, but maybe “import from scope” fixed the SGP issue and the downloading timeout was causing the failed meridian flip and plate solve.
This would make sense as it had the same failed meridian flip last night as well. see attached log:
Do you have any suggestions for trying to remedy the downloading timeout issue, I’m using a mirrorless sony a7s, with USB micro cable from the camera into the laptop, how should i set my download settings? thanks so much Patrick
I am pretty sure this was a bug and not a timeout. It has been corrected in beta 754.
In terms of the planning tools, I am not 100% certain, but I think the issue here is that calculating a target’s ephemeris can be computationally expensive and so SGPro runs these tasks in the background so the data is available when you need it. Before you changes your geographical location, the target’s transit data had already been calculated and I think changing the user location failed to properly mark it as needing refresh.
Hey Ken,
As for the planning tools, I did pull the location data from the scope then save user profile and I believe I restarted SGP to give it a chance for it to set. It still showed the old graph but maybe that just updated when it went to platesove next at the meridian flip and that showed in the next morning.
I don’t think the downloading timeout and failure to save is fixed as last night I already ran Beta 754 and it still had the issue and failed to platesolve after the meridian flip and looked like it struggles to save a lot of the imaging LIGHTS also.
Image showing the warnings for the failure on beta 754: Dropbox - dowloading error on the beta 754.jpg - Simplify your life
showing more errors: Dropbox - more saving errors.jpg - Simplify your life
I had space available on both the camera memory card and the computer hd to save/download the photos, so I’m not sure why they are timing out on some and saving others
Sorry, I don’t really have any advice or experience with the Sony ASCOM driver, but I know that driver must have been a nightmare to write… Sony’s camera SDK is all network driven I think and it seems like the probability of timeout may be higher with that kind of framework. I could be wrong here… but the driver’s author would likely be the best troubleshooting resource here.
In terms of the target transit data, I will try to recreate that issue here in a bit.
