SharpCap Forums

Hello Jean-Francois,

... do you know if people connect the camera with an USB 2.0 connector ?

I think that the majority of QHY174GPS owners use USB3 (with USB2 you cannot take full advantage of the cam, especially for stellar occultation observing).

Cheers, Christian

Hi folks,

has anyone encountered the QHY 'GPS BOX'? - it can apparently give GPS data to various models of QHY camera including the 600M, 4040M, 42Pro and 163M.

I was investigating a crash report from a 163M that seemed to be setting the GPS calibration - my initial thought was 'that's ridiculous', but then I discovered the GPS BOX existed.

I presume that the work we have done to calculate the calibration parameters from USB speed, exposure, etc, is very much tied to the 174 camera and will probably give the wrong results for other cameras with GPS functionality, but it would be good if someone could confirm this.

cheers,

Robin

Hello Robin,

I have seen that it exists, and I have think to have it, but it was not compatible with all the cameras or it is necessary to modify the camera (change the back plate).

So I have no other information about the GPS Box.

Jean-Francois

Hi,

I've seen it too, but that's about it. Maybe, Robin, you can get a test model from QHY?

Cheers, Christian

Hi Jean-Francois, Christian,

thanks, I will contact QHY to see what they have to say about it If I get my hands on one I will write a report on it!

cheers,

Robin

Hello Robin,

OK.

Jean-Francois

Note: I do not investigate the question about the LED-time in other topic ... I do today mountain-bike and sun-heliography (spectroscopy).

Does binning no longer play a role in the new formula(s)?

That's right. The calibration depends only on the exposure time and the USB traffic.

Christian

I have observed that BadData could also mean that the time that comes out of the GPS could be just a few SECONDS different from the computer's clock.

On several occasions in the past, e.g., last night, SharpCap showed "BadData" when the Windows clock differed by just 5 or 6 seconds from UTC. When I synchronized the Windows clock with "internet time" - a Windows feature to adjust time & date when there is an internet connection - then voila! "BadData" instantaneously changed to "PartialData", followed a few minutes later by "Locked."

Why does the camera's received GPS time have to agree with the computer's clock? If the camera has built-in GPS, why is the computer's clock even needed?

Andy Howell
Gainesville, FL

Kai Getrost wrote: ↑Sat Jul 18, 2020 6:48 pm

admin wrote: ↑Fri Apr 24, 2020 6:32 pm ... After a lot of investigation we discovered that if you don't have accurate calibration of the end and begin points then the output of the GPS system can be badly off (much more than you would think if you had the idea that the calibration was just fine tuning mechanism). ... The 'bad data' status means that the time that came out of the GPS reading is more than 24 hours different from the PCs system clock.

Cheers, Robin

Following up on this statement from back in April. How bad is "badly off"? I've noticed two consequences to bad calibration, depending on how severely off it is:

1. Completely frozen (unchanging) GPS time and BadCalibrationReduceEndPos (or sometimes BadData) error, or
2. GPS window reported exposure (`Exp. (us)') differing greatly from the GUI-set Exposure -- like by a factor of 1.5x, 2x, even 0x different from what was set

Are there other known consequences, especially ones that might not be easily noticed? Thanks.

-Kai

Hi Andy,

the code only sets the 'BadData' flag if the shutter start time stamp differs from the PC clock by more than 86400 seconds (1 day). I suspect that in the initial phase before the signal locks completely there are some frames that have reasonable timestamps and others that are wildly wrong and get the bad data flag.

cheers,

Robin