Possible 8-bit signed-char bug in native ToupTek driver

73 views
Skip to first unread message

LJ Y

unread,
Aug 22, 2026, 7:22:06 PMAug 22
to Open PHD Guiding
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
PHD2_DebugLog_2026-08-09_210659.txt

Bruce Waddington

unread,
Aug 22, 2026, 10:11:42 PMAug 22
to Open PHD Guiding
This debug log from 08/09 is using a version of PHD2 that is over 2.5 years old and the camera was running in 8-bit mode.  Since that time, there have been 6 updates to the ToupTek SDK.  The later logs we have from you are running the current 2.6.14 release and show the camera running in 16-bit mode.  Looking at the 2.6.14 logs, I see only one batch of lost-star events and those don't exhibit the behavior you're talking about.  Do you actually have a problem on the current release and if so, can you reproduce it?  Going forward, we need to see both your guide and debug log files, uploaded to our server using the PHD2 log upload feature:
Regards,
Bruce

Bruce Waddington

unread,
Aug 22, 2026, 11:46:37 PMAug 22
to Open PHD Guiding
Update: we happen to have one of these cameras and can see the problem in 2.6.14.  It will be fixed in the next dev release - thanks for reporting it!

Bruce
Reply all
Reply to author
Forward
0 new messages