QHY 174 GPS Calibration LED issue // USB Traffic weirdness

procyon12
Posts: 255
Joined: Tue Jan 14, 2020 11:32 am

Re: QHY 174 GPS Calibration LED issue // USB Traffic weirdness

#91

Post by procyon12 »

Hi,

Regarding SWRI/NASA:
As far as I know they did not use the Slave Mode. This mode is only known from the Chinese QHY sites - I've never seen any use. The SWRI people, led by Marc Buie, were the first to use the camera for stellar occultations. They work with SharpCap and have made decisive contributions to its use with the camera.
Also the RECON teams use this cam http://tnorecon.net/first-2020-21-full-recon-campaign/

Cheers, Christian
Kai Getrost
Posts: 21
Joined: Sun Jun 07, 2020 2:36 pm
Location: US

Re: QHY 174 GPS Calibration LED issue // USB Traffic weirdness

#92

Post by Kai Getrost »

As far as I know they did not use the Slave Mode.
Correct; all of the QHY cameras were (and are) run independently.
Jean-Francois
Posts: 384
Joined: Sun Oct 13, 2019 10:52 am
Location: Germany

Re: QHY 174 GPS Calibration LED issue // USB Traffic weirdness

#93

Post by Jean-Francois »

Hello Christian, Robin and Kai,

Concerning the master/slave mode of the camera:
Yes, I read some information on the QHY website. I was sure that the "NASA" team perform some measurement with synchronized cameras.
Robin, is it possible from SharpCap to access/modify the master/slave mode of the QHY-174-GPS camera ?

OK, the RECON team seems to be very active ... and with a lot of QHY camera (24 + 20) ... but they not mentions if it is the 174-GPS.

Concerning my script and the SC menu:
I do it !
I mean, I take this afternoon time for modifying and debugging the "menu-script".

LED_calibration_menu.png
LED_calibration_menu.png (953.34 KiB) Viewed 2678 times

Here the script: (note that the ".py" file is not accepted. Also here as ".txt", but delete ".txt" from the name before use!)
Calibration_LED_menu.py.txt
(13.38 KiB) Downloaded 93 times

How to insert in the SharpCap menu ?
#
# - Copy the script somewhere on the computer
# - Start SharpCap
# - In "File" - "SharpCap Settings" - "Startup Scripts" - select this script
# - Close SharpCap (the script will be loaded at the next start)
# - Start SharpCap
# - Connect QHY-174-GPS camera (no idea what happen if it is only the QHY-174 camera)
# - Switch-on the LED illumination (the camera must be covered)
# - Move the USB traffic or change the exposure time (so that SC fill the Start/End Pos values)
# - Activate/Show "The Image Histogram" window (see example image above)
# - Activate the "FX Selection Area" (for showing the red selection rectangle)
# - Move and scale the selection rectangle above the most intense region of the LED illumination
# - Click on the "Cal_LED" button on the SharpCap menu
# - Start the calibration by clicking the "Start Calibration LED" button
# - Close the script by clicking "Exit" button.

Please note the following: with the script starting from the menu, the camera image seems to be frozen.
Wait some time until the active image is back.
With my script from the Python console, I have not this ... the image is all the time active.
Robin, can you have a look, why the camera freeze during the "menu-script" is running ?

In addition, I note the following ... if the image dimension is not changed and if you have already placed the "red-box" at the correct position, then it is not necessary to activate the Histogram view or the red-box ... and it is not necessary to switch-on the LED (the script does it before running if the LED is off and switch-off at the end of the script).

Concerning my script and the SC automatic value: my script ignores the SC automatic values (sorry Robin).
But more important ... it works only with the camera connected to the USB 3 connector !
Also ... how many people are using the camera with USB 2 ?


Best regards,
Jean-Francois
User avatar
admin
Site Admin
Posts: 13280
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: QHY 174 GPS Calibration LED issue // USB Traffic weirdness

#94

Post by admin »

Hi folks,

I still need to spend some time reviewing the calibration data (probably a lot of time!), but I am going to wait until I can get the USB module replaced and test on USB2 and 3 before investing time in that.

I can provide some more info on the GPS slave mode - I added support in scripting for that some time back. There were bugs in the SDK when I did that which stopped it from working properly, and I'm not sure if they got fixed. If you want to try it.

Code: Select all

control = SharpCap.SelectedCamera.Controls.FindById(CommonPropertyIDs.GPSFrameControl)
control.RawControl.EnterGPSControl(DateTime.UtcNow + TimeSpan.FromSeconds(30), TimeSpan.FromSeconds(1))
... later
control.RawControl.ExitGPSControl()
As long as your camera is set up and running with GPS locked before you run that code, it should take a one second exposure at the point in time when the GPS clock hits the specified point.

Cheers, Robin
Filipe Dias
Posts: 10
Joined: Sun Nov 15, 2020 3:11 pm
Location: Portugal

Re: QHY 174 GPS Calibration LED issue // USB Traffic weirdness

#95

Post by Filipe Dias »

Robin, :!: Sorry, but I must warn against my numbers :!: :!:

:arrow: I found out that my USB 3 cable, and how well it is fixed on the camera, may have influence in them.

the following situations refer to (MONO16, 1920x1200, bin 1x1, same USB3 port on the computer, exposures shorter than 20 ms)
A: camera #1 could not do more than 6 frames per second, camera horizontal showing up-right image
B: camera #2 could not do more than 20 frames per second, camera horizontal showing up-right image
C: last night camera #2 was put on a telescope (Moon) in a diagonal, camera pointing down (cables were coming out upwards so making good connection) and the camera was doing 50 fps !!

I noticed differences in the calibration numbers between situation A and B. I could not measure in situation C, but this weekend I can try to explore this... I suspect there is influence of the "quality of the USB connection" (be it because the plug is in a USB2 port, or because the cable is not providing "good-enough something", or precariously attached physically to the camera)..

If SharpCap can detect what speed the USB port is working in, maybe the calibration times can become more deterministic, or we can try reconnecting the camera at a better speed mode. (assuming this cannot change during an established connection, and that there may be a limited number of possible speed modes for the USB to connect at (only these: 1.5 12 480 and 4800 Mbps ?) (I'm throwing ideas into the air)

Every connector attaches to the camera with a thread, except the USB cable! :(
Jean-Francois
Posts: 384
Joined: Sun Oct 13, 2019 10:52 am
Location: Germany

Re: QHY 174 GPS Calibration LED issue // USB Traffic weirdness

#96

Post by Jean-Francois »

Hello Filipe,

One way for better stability is to fix the cable at the camera housing ...
Img_2315.jpg
Img_2315.jpg (92.93 KiB) Viewed 2645 times

Here with the short cable for the direct connection to my EAGLE2 mini computer. For inside test, I use a 2 m cable.

For the slow readout of the camera ... sometimes the "Force Still Mode" is On at the start of SharpCap, change it to Off and the full fps can be achieved. If the USB cable is deteriorated, then test the connection with different cable(s) and/or with a different computer.

Do you perform the firmware update of the camera ? (means do you open it ?)

Yes, the USB 2 or 3 selection has a big impact. On my desktop computer with the same camera settings. USB 3 => 130 fps and USB 2 => 8.5 fps.
Also more than 15x slower with USB 2. Note that is important for short exposure time ... it is different if you have 1 s exposure time.


Regards,
Jean-Francois
Jean-Francois
Posts: 384
Joined: Sun Oct 13, 2019 10:52 am
Location: Germany

Re: QHY 174 GPS Calibration LED issue // USB Traffic weirdness

#97

Post by Jean-Francois »

Hello Robin,

I try something for the GPS master/slave mode.

First ... you write each time so much that I'm interested, but not sufficient that I can do something ;)

I remark some confusing things ... In IronPython, I can import "datetime" or "System". Both have an UTC function ...
- datetime.utcnow() with result 2020-11-21 11:15:19.0000
- DateTime.UtcNow with result 21.11.2020 11:15:19
other point the function TimeSpan.FromSeconds() can be added only to the DateTime.UtcNow.

Also "DateTime.UtcNow + TimeSpan.FromSeconds(30)" works only with the correct "import" ... means with "System", but not with "datetime".

Other point ... in the documentation from QHY about the 174-GPS ...
=> set_GPS_SlaveMode_Parameter(target_sec,target_us,deltaT_sec,deltaT_us,expTime)

The time is not in UTC but in JS format (I prefer the UTC format ... it is not necessary to calculate the JS (modified Julian date) before the command.
Is it a change in the SDK or do you perform this calculation intern ?

Now the big question is ... what to do between "EnterGPSControl" and "ExitGPSControl" ?

In the QHY documentation, I understand that the camera will take images synchronized with the "deltaT" time between the images.
Also starts at target time "target" with exposure time "expTime" and a waiting time between the exposure "deltaT".
The camera starts in this mode to take images continuously until the camera is set back to master mode.

Now ... how to show or save the "synchronized images ?

Robin, do you test my "Calibration_LED_menu.py" script from the SharpCap menu ?
Is it possible to avoid that the image freezes during the LED calibration ?
I think that it is better to have an active view on the LED changes (the user can see that something is working).

Regards,
Jean-Francois
procyon12
Posts: 255
Joined: Tue Jan 14, 2020 11:32 am

Re: QHY 174 GPS Calibration LED issue // USB Traffic weirdness

#98

Post by procyon12 »

Hello,

Jean-Francois, the so called Slave Mode (the QHY description is here https://www.qhyccd.com/index.php?m=cont ... =30&id=190) sounds interesting - e.g. 1µs (?) precision.
There is a new driver, 2020.11.12 https://www.qhyccd.com/index.php?m=cont ... =141&id=62 related to Slave Mode: "QHY174:Increase stability in 16 bits SLAVE mode". I didn't install it.
However, du you see a sensible (astronomical) application? I think what is described can be done without this mode, maybe with SC's new sequencer (and GPS on).

Cheers, Christian
Jean-Francois
Posts: 384
Joined: Sun Oct 13, 2019 10:52 am
Location: Germany

Re: QHY 174 GPS Calibration LED issue // USB Traffic weirdness

#99

Post by Jean-Francois »

Hello Christian and Robin,

I see the last version of the driver. I install it on my old laptop (because it was the first installation on the laptop for the tests with the USB 2 connection). Now, I do not remember, if I install it on my other computers. Before solving the "stability" problems, I have to solve other problems ...

Here the status of my different tries:

Code: Select all

import clr
import time
from System import *

from SharpCap.UI import CaptureLimitType
SharpCap.SelectedCamera.CaptureConfig.CaptureLimitType = CaptureLimitType.TimeLimited
SharpCap.SelectedCamera.CaptureConfig.CaptureLimitTime = TimeSpan.FromSeconds(10)
SharpCap.Settings.CaptureFolder = "D:\Scripts\GPS_control"
SharpCap.SelectedCamera.PrepareToCapture()


delta_utc = TimeSpan.FromSeconds(5)     # start of the exposure after delta_utc from UTC-now
delta_time = TimeSpan.FromSeconds(1)    # individual delta time in [s] between each image, shall be larger than exposure time

print "FindById(CommonPropertyIDs.GPSFrameControl)"
control = SharpCap.SelectedCamera.Controls.FindById(CommonPropertyIDs.GPSFrameControl)

print "EnterGPSControl"
print("DateTime.UtcNow :"),
print DateTime.UtcNow
control.RawControl.EnterGPSControl(DateTime.UtcNow + delta_utc, delta_time)

#print("Sleep 20s")
#time.sleep(20)

#SharpCap.SelectedCamera.CaptureSingleFrameTo("D:\Scripts\GPS_control\capture.fits")

print("Run capture: 10 s")
SharpCap.SelectedCamera.RunCapture()

print "ExitGPSControl"
control.RawControl.ExitGPSControl()

I first do simple test with the "time.sleep(20)" function. (comment out the "SharpCap.SelectedCamera.RunCapture()" before).
The camera image freezes and wait until the time UTC + 5 s, then it starts to show 1 image per second (second parameter of "EnterGPSControl" (Robin, this parameter is not the exposure time, but the time between 2 images). After 20 s (time.sleep), the camera comes back in normal mode (ExitGPSControl).
I try to save images ... direct with CaptureSingleFrameTo ... but it captures only 1 time.
I try with RunCapture ... but not the wanted result. The EnterGPSControl does nothing and the images are saved indepently.

Also ... I do some small steps, but I think that the good direction is missing.

Christian, the GPS in the camera can be used to set the computer time at the correct time. I think that all the other script date/time functions use the computer time (+local settings) for calculating the UTC time. One possible use of the master/slave function is to be sure that images are taken at the correct time (coming from the camera GPS time). I do not check this ... what happen if the computer time is away from the GPS time.
For the multi cameras synchronization .. I have no idea if it is a wanted advantage. (Meteor trajectory ... only if all the cameras are the 174-GPS).


Regards,
Jean-Francois
Jean-Francois
Posts: 384
Joined: Sun Oct 13, 2019 10:52 am
Location: Germany

Re: QHY 174 GPS Calibration LED issue // USB Traffic weirdness

#100

Post by Jean-Francois »

Hello Robin and Christian,

I do some analysis of the camera connection to the USB 2.0 ...
I do first a manual search, than a quick analysis with my Excel/Mathcad sheets, than an automatic search of more "points" and a new (full) analysis.

Here the result for the camera with USB 2.0 connection:

Code: Select all

    if (Colour_Space == "MONO16"):
        Time_limit = (usb + 70.58) * (0.002133 * H + 0.0853)
        if (Time_limit > expos_ms):
            StartPos = int(((0.0000369961*H - 0.0630984)*H - 74975.3897)*expos_ms + ((-0.0072202354*H + 172.951051)*H + 3347.7079)*usb + (-0.502798606*H + 12201.4370891)*H + 228427.0061)
            EndPos = int(((-0.007110743*H + 172.7993684)*H + 2720.27087)*usb + (-0.50207155*H + 12199.72619)*H + 191991.38230)
        if (Time_limit <= expos_ms):
            StartPos = int(2240 * usb + 158142)
            EndPos = int(((-0.00003682*H + 0.056556)*H + 74972.1494)*expos_ms +((0.00052719*H - 0.85945)*H + 1759.0895)*usb + (0.007671744*H - 11.132414)*H + 114582.3757)

    if (Colour_Space == "MONO8"):
        Time_limit = (usb + 45.76) * (0.002132 * H + 0.087)
        if (Time_limit > expos_ms):
            StartPos = int(((0.00013005*H - 0.2440064)*H - 74881.948669)*expos_ms + ((-0.0069995*H + 172.589349)*H + 3405.9198)*usb + (-0.33087063*H + 7919.72377)*H + 144481.9839)
            EndPos = int(((-0.007112382*H + 172.80228872)*H + 2719.082882)*usb + (-0.325502697*H + 7909.9047582)*H + 124488.17441)
        if (Time_limit <= expos_ms):
            StartPos = int(2240 * usb + 102539)
            EndPos = int(((-0.0000291363*H + 0.0627396763)*H + 74974.60048)*expos_ms +((0.0000661856*H - 0.1459149162)*H + 1527.998352)*usb + (0.0055215121*H - 12.1137656248)*H + 75014.4810344)

Here again the result for the USB 3.0 connection:

Code: Select all

    if (Colour_Space == "MONO16"):
        Time_limit = (usb + 9.76) * (0.001067 * H + 0.0435)
        if (Time_limit > expos_ms):
            StartPos = int(((0.0000390615*H - 0.0707123)*H - 74967.6652)*expos_ms + ((-0.0035966154*H + 86.4884205)*H + 1635.68176)*usb + (-0.0344038914*H + 842.6668063)*H + 16080.628624)
            EndPos = int(((-0.0035558392*H + 86.4002017)*H + 1360.09956)*usb + (-0.0347116673*H + 843.4836578)*H + 13250.53035)
        if (Time_limit <= expos_ms):
            StartPos = int(1120 * usb + 10939)
            EndPos = int(((0.0000163613*H - 0.01334320)*H + 74999.19033)*expos_ms +((0.0000067656*H - 0.01705296)*H + 735.04566)*usb + (-0.0007104888*H + 0.710555)*H + 7515.87826)

    if (Colour_Space == "MONO8"):
        Time_limit = (usb + 5.60) * (0.001067 * H + 0.0421)
        if (Time_limit > expos_ms):
            StartPos = int(((0.0000637116*H - 0.1436327)*H - 74917.10660)*expos_ms + ((-0.00358619*H+86.459717)*H + 1607.70533)*usb + (-0.019717898*H+483.579932)*H + 9199.23345)
            EndPos = int(((-0.0035558*H + 86.4002344)*H + 1360.007826)*usb + (-0.0199132*H + 483.84284)*H + 7591.707861)
        if (Time_limit <= expos_ms):
            StartPos = int(1120 * usb + 6276)
            EndPos = int(((-0.0000118685*H + 0.0201366)*H + 74992.7219)*expos_ms +((0.0000136924*H - 0.022276)*H + 773.9233)*usb + (0.0003354606*H - 0.5725338)*H + 4421.8013)

With expos_ms = the exposure time in ms, H = the image height and usb = the USB traffic.

In addition, I create a new script for the menu and I update the preceding one for USB 3.0.
Note: the file ending ".txt" has to be deleted before use.

For use with the USB 3.0 connection:
Calibration_LED_menu.py.txt
(13.41 KiB) Downloaded 96 times

For use with the USB 2.0 connection:
Calibration_USB2_LED_menu.py.txt
(13.69 KiB) Downloaded 103 times

Wenn I test both menu script at the same time ... It was a surprise to see that SharpCap and Python take all the script in one batch.
The problem was that at the beginning both scripts have the functions with the same name, but with different calculation.
I rename in the "USB2" script version the necessary functions ... I hope it will work properly.
For the people using only USB 2.0 or only USB 3.0, it is not necessary to install both script.

Robin ... the "menu" script starts the calibration of the LED without image refresh.
Is it possible to "reactivate" the live view of the camera image ?


Regards,
Jean-Francois
Post Reply