SafeParse Double - What is going on? What does this mean in the Log?

This is now the 4th time on the bounce that I am getting issues with SGP. I have to say that it is sadly sapping my confidence in what I have until now found to be an excellent piece of software.

I previously posted a thread where my SGP log basically stopped recording anything and it was thought to be a one off and had never been seen. Now it’s happening every time, so much so that I can’t leave the scope unattended as it just doesn’t seem to do the recovery or park or indeed anything it should when this happens.

I’ve attached my past 3 SGP logs and I really hope that someone has some idea from here what’s wrong.

On one of them I lowered the sub exposure to 10s so that I could see that the camera would capture and download - It was fine. Yet up it again to 30m and this is the result in the log. I’m hoping that someone can give me some idea of where to even start looking.

I have also added the PHD debug log from last night incase that assists.

Hi Sara.

Sorry to read about your problems. Whilst I can’t help on the specific SGP software analysis, other items to check and ideas are (you may well have checked/thought of this already and have it in hand): possible effects from any MS Windows updates, anti-virus software updates, other programs installed, driver updates etc, ie all other PC-related matters that might affect the smooth running of SGP.

Good luck and I’m sure Jared and/or Ken will respond.


And it’s here again…

Today I have done the following.

Updated PHD2 to beta
Changed camera cable

The log shows everything as normal, then after the first long sub the safeparsecdouble comes up again, the meridian flip info disappears and that’s it… everything continues until SGP needs to actually do something…

I’m struggling to reproduce any behavior like this. It might be some combination of settings I have not seen or it may be environmental. We have lots of QSI users with no issues like this. A couple questions:

  • In your first post you mentioned that this is the fourth time you have seen this issue. Anything change four times ago?
  • Another variable is region. What region are you in (what is your decimal separator?)?

Thanks Barry and Ken for looking and answering.

Ken I can confirm that NOTHING has changed since this has started to happen.
Region - I am reliably informed that the region is Spain and the decimal separator is a full stop. I have no idea what I am looking at there, so Trevor has kindly done it for me.

Will chip in here, I have looked at the system just after this happened, one thing that is odd is that SGP loses the time to flip when this happens.

Aborting the sequence did stop the messages but did not reinstate the time to flip.

We restarted SGP, PHD2 and CdC and restarted and the time to flip was shown after the slew, what I am not sure of is if just a slew would have worked.

Sara uses EQAscom and this is setup correctly and can see no obvious issue.

Its got me dumbfounded currently as this system has been working for a fair while in this configuration.


By decimal separator, I mean do you express the number one and a half as 1.5 or 1,5? That’s just FYI, I can deduce the rest from Spain (assuming your computer’s region is set to Spain (ES).

Forgive me - only trying to help & happy to be corrected - I thought Sara’s Avalon had been changed to use Avalon’s StarGo system and this mount control software was used rather than Eqmod?

I also recall that on initial installation the StarGo couldn’t carry out an auto meridian flip although this may well have been corrected in subsequent driver updates. If StarGo is used as the mount control, has anything changed (or become faulty) with this driver?

I replaced the motherboard back to the SynScan one once I realised that the StarGO wouldn’t flip. So I’ve been using EQMOD again since about June time with no hitches until a continuous headache about 4 outings ago… when it all started to go oddly wrong!

@swag72 , Can you send a SGF file that produces the condition where safeparsedouble is called hundreds of times?

Ah. Understood.

It displays as 1.5

I have the SGP logs that I have attached via drop box, as well as the original thread I started when the issue first happened. Not sure if there’s anything else I have that will be useful?

Here’s a link to the SGP file that I was using at the time.

And an update to tonight…

… The first 30m sub rolled in fine, the log looked spot on …the guider settled after the dither, and then when the camera went to start the Log has suddenly started returning lines of ‘SafeParseDouble: Input string was not in a correct format’

In my experience this has meant that the camera will continue to capture and everything APPEARS to work fine until SGP comes to do something (like AF or flip) …

This evening the EQMOD cable has been changed, this afternoon Ascom and EQMOD was uninstalled and reinstalled…

I have been looking at this in a daze for hours today. I think I have it narrowed down to something to do with image history (it seems like you have this on), I can’t figure out exactly what, but you may want to disable it to see if it makes a difference.

So… I still cannot locate the source of the double conversion error. I cannot reproduce it in your region with your sequence so I’m not sure how to help at this point.

Here is one thing I noticed though. The two things you are reporting… SafeParseDouble errors followed by errors involving movement (centering / flipping) may actually not be related at all. When inspecting the sequence you sent, you have asked SGPro to try 50 times to get your centering within 2 pixels of the requested position. This is near impossible so I suspect you meant to ask SGPro to try 2 times to get you within 50 pixels (entries are transposed). This is why your meridian flips are failing. Still investigating the weird conversion errors, but I think they should be fairly innocuous.

I can confirm Ken that I do indeed have the accuracy of the pointing set to 2 pixels in 50 runs and this is correct. It always gets there and has never failed! Very often it solves within 2 plate solve iterations and sometimes it takes a little longer - but has never failed me yet! I certainly don’t want to change this to 50 pixels… I am not wiling to accept an error of 50 pixels!!!

It’s certainly nowhere near impossible I am pleased to report.

I am truly shocked that you were able to get reliable plate solves with an error of only 2 pixels in the past. It must be an incredible mount that you have. As Ken says, a 2 pixel error is nearly impossible and at that level you are chasing mechanical issues in the mount or even possibly seeing conditions. I’m not doubting your statement that you were able to get accurrate solves with a 2 pixel error, but it really can’t hurt to bump that pixel error up to about 10-15 and see what happens.

If you do have an Avalon mount…I need to get one!!! :grinning:

I can’t believe that anyone works with less than 2 pixels accuracy and neither can I believe that anyone finds it shocking that I can get reliable plate solves… I assumed that this is perfectly normal. Don’t you all do it?

I do indeed have an Avalon Joel - It’s a great mount!