SharpCap Forums

I'm not sure if this is a bug or not. Recently we switched from Daylight Savings Time back to Standard Time. Not sure if they have this stupidity in the UK, but in they US they change the clocks by 1 hour twice a year, forward in the spring, back in the fall. In any event, after the switch back to standard time, the laptop clock was correct, the time on the mount was correct and the mount knew it was Standard Time. But when SharpCap connected to the mount, it claimed the time on the mount was off by 59 minutes and change (I assure you it was not). Plate solving would not work. It wasn't like it was off by too much, either (I have it set to search 90 degrees). It wasn't even trying to plate solve. Only after I entered the wrong time on the mount, ahead by an hour, would SharpCap not complain about being an hour off and plate solving proceed. So I had to tell the mount it was 7:20pm instead of the correct 8:20pm on the laptop for SharpCap to work properly. This seems like a bug on SharpCap's part, but I guess it could somehow be the mount? I'm not sure how though.

Cheers,

Mike

Hi Mike,

SharpCap is comparing the UTC time/date as reported by the mount ASCOM driver with the UTC time/date reported by the PC. If you look in the log you will see both of the times are recorded there, so you can track down which one is incorrect.

We do have summer time here and I haven't seen this particular problem with any of my hardware, so I think its not a SharpCap bug (we would have heard a lot more about it if it was...)

My suspicion is that it will be something between the mount handset and the mount ASCOM driver - perhaps that the mount handset is set up for standard time but the ASCOM driver knows it is summer time, so is making the incorrect compensation when it converts the time from the mount into UTC to give to SharpCap. Anyway, the log will give both times and that will point to where to continue investigations.

cheers,

Robin