feature tracking calibration works one one computer, not on an other

[julien.t]

Hi,

I encountered some strange issues while configuring SharpCap on a second PC. The feature tracking calibration doesn't work on the second one. I imported the settings I exported on the first computer.
Dec calibration seems to work correctly but on RA, the calibration fails every time. Most of the time, it tries to calibrate way over the set calibration distance (50 px) and doesn't do the other way and fails.
On the first computer, it succeeds every time. The issue is not due to a difference in observation conditions, mount alignment, ... I have done tests with both computers in the same condition (a few minutes apart) and behaviour is constant: on computer 1 it succeeds and on the 2nd it fails.

I attached logs of an attempt on each of the computers.

Regards,

Julien

[admin]

Hi Julien,

in the log for computer 2, I can see in the log that an experimental mount movement tracking algorithm is being used instead of the default algorithm. This shows as log lines reading 'using new mount guiding...' in the computer 2 log and equivalent lines reading 'using classic mount guiding' in the computer 1 log. This is most likely the cause of the difference in behaviour.

The new experimental mount movement tracking only gets enabled if the '/prerelease' command line option is used when launching SharpCap to enable pre-release features (at least, I can't see any other way it could get used), so my conclusion is that you must have that option set up on the second PC and in this case it is causing an issue.

So, the immediate fix would be to remove that parameter to go back to the old way of doing the mount movement tracking. Interestingly, from the log, it looks like the ASCOM driver for your Pegasus mount is perhaps not reporting the movements made by pulse guiding tweaks as position changes - certainly the data for the measured mount offset (current position distance to start of calibration position) always comes out as 0 or 60 arc seconds

Code: Select all

// first value is calculated mount movement in arc sec, second is observed image offset in pixels
0,2.543254		
0,6.4640474		
0,11.016618		
0,15.121029		
0,19.09428		
60,23.157974	
60,27.515696	
60,32.36587		
60,34.94981		
60,38.706196	
60,43.278873	
60,47.34856		
60,51.485558	

Also, looking in the new machine log, you can see that all the reads of RA/Dec from the ASCOM mount driver are an exact number of degrees and minutes (Dec) or hours and minutes (RA) - there seem to be no seconds readout in the mount co-ordinates. For example...

Code: Select all

Verbose	10:32:16.611822	#27	Mount : SharpCap.MountProxy.ASCOM.IMountInterceptionProxy.get_RightAscension :: Starting get_RightAscension()
Verbose	10:32:16.643308	#27	Mount : SharpCap.MountProxy.ASCOM.IMountInterceptionProxy.get_RightAscension :: Completed (returned 5.983333333333333) get_RightAscension()
Verbose	10:32:16.653857	#27	Mount : SharpCap.MountProxy.ASCOM.IMountInterceptionProxy.get_Declination :: Starting get_Declination()
Verbose	10:32:16.675262	#27	Mount : SharpCap.MountProxy.ASCOM.IMountInterceptionProxy.get_Declination :: Completed (returned 22.116666666666667) get_Declination()

Effectively this limitation in the ASCOM driver is stopping the new calibration scheme from working properly. Maybe there is an ASCOM driver update to resolve this - it's certainly a weird thing for an ASCOM driver to do...

cheers,

Robin

[julien.t]

Hi Robin,

That's strange, I never heard about the /prerelease option. Could it be possible it is automatically enabled with beta version ? I had a beta version on this computer. I reallized that I had a beta version and uninstalled it and installed the latest stable version. Would it be possible that by doing that some parameter have been left over and the stable version use them ?

I will look at the Pegasus driver and contact them as this could be a bug.

Regards,

Julien

[admin]

Hi Julien,

OK, then this is weird - both of your logs came from SharpCap 4.1, so the beta version can't have anything to do with it (anyway, the beta doesn't enable that feature - I have just checked).

Do you use any command line arguments? I wonder if somehow the command line handling code is mistaking something else for that option? Unfortunately SharpCap doesn't currently log the command line arguments (I will fix that), so I can't check from the logs.

cheers,

Robin

[julien.t]

Hello,

No, no command line argument.

Julien

[admin]

Ok, please try the next update of SharpCap 4.2 beta that comes out - I have added some extra logging to that to record command line parameters (if any) and if the pre-release features get enabled. Hopefully that extra logging will give a better picture of what is going on, as currently it seems that the rules of logic are not working!

cheers,

Robin

[julien.t]

I found the origine of the issue. The calibration doesn't work correctly when the decimal symbol is set (in Windows date, time, number settings) with . and not ,

Julien

[admin]

Hi,

ah, that's interesting - do you also get proper position readings from the mount when you set the decimal separator to a '.'?

I will try to test this with another brand of mount and the ',' for decimal separator. I'd give a 70-80% chance that this is happening inside the Pegasus mount ASCOM driver/control code and is also responsible for the rounded off position readings from the mount. I don't think that the code inside SharpCap that supports the feature tracking does any conversions of floating point numbers to/from strings (except for logging).

cheers,

Robin

[julien.t]

do you also get proper position readings from the mount when you set the decimal separator to a '.'?

I quickly developed a console app that log the current RA and Dec and executed it with both settings ',' and '.' and in both cases I got coherent values.

But if, in my first computer settings, I configured the decimal separator with ',' this must be for a reason. I'm in Switzerland and usual decimal symbol and configured by default in Windows, is '.' . I try to remember why I changed it to ',' This is probably because I already had an issue with some astronomic software.

Let me know if you want me to do other tests.

I don't think that the code inside SharpCap that supports the feature tracking does any conversions of floating point numbers to/from strings (except for logging).

Yes, that make sense. I don't see any reason why you would convert the RA/Dec float result to string.


Regards,

Julien