Hi all,
I think I may have found a bug in the native ToupTek driver when using my ToupTek GPM462M in 8-bit mode on Windows.
I first noticed intermittent “Star lost - low HFD” errors. I used ChatGPT to help analyze the PHD2 debug log and trace the relevant code path.
Log shows the guide star alternating between abnormal and normal values:
22:07:36.699 Star::Find(...) frame 125
22:07:36.700 Star::Find returns 0 (4), X=811.00, Y=676.00, Mass=66348, SNR=182.1, Peak=65413 HFD=0.0
22:07:38.998 Star::Find(...) frame 126
22:07:38.999 Star::Find returns 1 (0), X=810.91, Y=676.48, Mass=1077, SNR=23.2, Peak=123 HFD=2.4
22:07:41.303 Star::Find(...) frame 127
22:07:41.304 Star::Find returns 1 (0), X=811.89, Y=676.73, Mass=1103, SNR=23.5, Peak=119 HFD=2.6
22:07:43.600 Star::Find(...) frame 128
22:07:43.601 Star::Find returns 0 (4), X=812.00, Y=677.00, Mass=66372, SNR=182.2, Peak=65409 HFD=0.0
22:07:45.900 Star::Find(...) frame 129
22:07:45.902 Star::Find returns 1 (0), X=812.82, Y=677.43, Mass=1066, SNR=23.1, Peak=101 HFD=3.2
22:07:48.594 Star::Find(...) frame 130
22:07:48.595 Star::Find returns 0 (4), X=811.00, Y=676.00, Mass=66386, SNR=182.2, Peak=65412 HFD=0.0
The relevant code in src/cam_touptek.cpp appears to be:
const char *src = static_cast<char *>(m_cam.m_buffer);
for (unsigned int i = 0; i < img.NPixels; i++)
img.ImageData[i] = *src++;
`img.ImageData` is an `unsigned short *`.
On Windows/MSVC, plain `char` is signed by default. Therefore an 8-bit source value >= 128 is first interpreted as a negative signed `char`, and is then converted to `unsigned short` when assigned to `img.ImageData[i]`.
For example:
source byte 0x80 = 128
signed char = -128
unsigned short = 65408
65536 - 128 = 65408
This seems consistent with the observed Peak values around 65409-65413, while unaffected frames show normal 8-bit Peak values around 100-123.
I will attach the original PHD2 debug log as well.
Thanks,
Lingjing