Does SGP talk to Planewave's PWI AutoFocus?

If you bin2x2 the measured HFD values will be about half compared with unbinned vakues. At small HFD values (<=2) the HFD value will increase due to lower sampling and rounding, so I would expect that the binned HFD values be a little higher then half of the original values.

Processing the images should be the same for the command line and in the program itself. In the latest versions for HFD measurment ASTAP ignores saturated stars. If you find a significant difference between the command line results and in the program result tell me where so I can have a look.

Hyperbolic curve fitting will improve the result. The linear V-wings will fit perfectly with the hyperbolic curve, making is less susceptible to outliers.

Han

@jared cc @han

I’ve rechecked the SGP log for the period covering the capture and analysis of AF Pack 2-9, as loaded into the ASTAP screen-shot pictured above at post 141.

I am certain that the #stars and HFD values listed in the log do not correspond to those shown in the screen-shot.

I can currently think of two possible reasons for this:

  1. On the Auto-Focus Options screen I have Crop AF frames by 5%. Maybe SGP is cropping the frame before passing it to ASTAP, rather than the full-frame as loaded in the screen-shot.

  2. Maybe as a result of the AF parameter Min Star Size at 1x1, SGP is discarding some of the star detections I assume would be reported by ASTAP. In the SGP log it shows: Calculating HFR with sample size: 3. I have previously wondered about the relevance of this parameter with the ASTAP option.

It would be nice if Jared could provide the Devs assessment on this.

Mike

Hello Mike,

The ASTAP inspector tab was detecting all stars with an SNR>10. This is now adapted to the viewer CCD inspector and command line setting SNR>30. Stars with an SNR between 10 and 30 are less reliable for HFD measurement. The results should be now the same. The SNR minimum value can be set in the command line but is default 30. Could be used within SGP.

ASTAP version 0.9.459b:
http://www.hnsky.org/astap_setup.exe

The SGP screen HFR values are from the internal routine. The csv file output containing all HFD measurements from ASTAP is not used by SGP version 3.651

Han

Hi Han,

Thanks for identifying the probable cause of the #stars discrepancy. According to the current forecast I may get a short period of clear sky this evening to do some more testing with .651 release. I am perhaps lucky but I have managed to download, install and connect to all my gear using both 32- and 64-bit versions. And I have downloaded your latest 0.9.459b release.

FWIW I have seen a couple of favourable comments (and none negative) wrt AF improvements using ASTAP as metrics provider so hopefully many other users will see improvement in the longer term.

As you say, current SGP release is still showing old SGP AF star detections and HFRs even when ASTAP is selected as the AF metrics provider. As this is a Beta release (and being aware of the issue) I don’t have a problem with this BUT longer term I think it would be better to have SGP correctly display ASTAP HFD detections when ASTAP is selected and SGP HFR detections otherwise.

Would ASTAP need to have capability to output an annotated image file (or star detection coordinates) for SGP to display when called from the command line, to facilitate this display?

Mike

1 Like

SGP has

SGP has just to execute ASTAP with -extract option and the CSV output file contains the HFD X, Y for each detected star. You can also specify the minumum SNR value. So

ASTAP -f image.fits -extract

or to decrease the detection sensitivity from SNR>30 to SNR>10

ASTAP -f image.fits -extract 10

The output file will be image.csv. Can be read by any text editor or spreadsheet program. The median HFD is in the exit code but that is already implemented.

Han

1 Like

Hi folks,

Here’s a new test file with PWI3 results…

https://spaces.hightail.com/receive/yE2rsMPzn5/dXMtMmZjMDc5NTgtYzY5Zi00YWFhLTkxY2YtZTAyOGI0MzllMGM1

KG

FocusSampleGraph.JPG

…and the PWI3 graph…

FocusSampleGraph

Hello KG,

Nice test images. ASTAP calculates focus at 5925 compared with 5958.7 for plateSolve2.
There is a discrepancy between image 5039 and 5389.

Han


spreadsheet. Pink is the Hyperbola curvefit

This looks good. If we can get this working in SGP I can run more rigorous tests possibly this month and in January.

I take it the curve fit used in Excel is the same calculation as used in ASTAP but with the added ability to show the HFD and HFD Hyperbola curves?

Thinking about possible incorpration in SGP, the present parabolic fit method provides a quality measure for the curve fit that seems to me to be a useful feature. Is there something equivalent that can be provided with hyperbolic fit?

Mike

It is already available in the beta version of SGP. You only have to get SGP working with your setup. Note the individual screen values displayed are still SGP detection based.

Yes, I take the three hyperbola parameters calculated in the ASTAP inspector tab and put them in the spreadsheet to produce the pink curve. The dark blue line is the smoothed curve drawn by the spreadsheet using the measured values.

The error for curve fitting is calculated by the differences between the measured points and the curve points. For ASTAP, I use a linear error so the curve is kind of average fit and outliers don’t get too much influence as with sqr(errors) . Furthermore you could limit the extreme outliers but don’t remove them because they could be correct. Applying statics and removing outliers doesn’t work in my opinion for these curve fitting but others have a different opinion.
But the existing parabolic fit will also work using the individual measured HFD values.

Han

Mike, at the moment there is no curve fit error output. Only an indicator of the number stars detected.

Charles asked for a curve fit output. I made something experimental:

ASTAP version 0.9.465:

Commandline:
c:\astap.fpc\astap -focus1 D:\temp\FocusSample\FOCUS04689.fit -focus2 D:\temp\FocusSample\FOCUS05039.fit -focus3 D:\temp\FocusSample\FOCUS05389.fit -focus4 D:\temp\FocusSample\FOCUS05739.fit -focus5 D:\temp\FocusSample\FOCUS06089.fit -focus6 D:\temp\FocusSample\FOCUS06439.fit -focus7 D:\temp\FocusSample\FOCUS06789.fit -focus8 D:\temp\FocusSample\FOCUS07139.fit
echo Exit Code is %errorlevel%
pause

or with -debug option showing the GUI

astap.exe -debug -focus1 D:\temp\FocusSample\FOCUS04689.fit -focus2 D:\temp\FocusSample\FOCUS05039.fit -focus3 D:\temp\FocusSample\FOCUS05389.fit -focus4 D:\temp\FocusSample\FOCUS05739.fit -focus5 D:\temp\FocusSample\FOCUS06089.fit -focus6 D:\temp\FocusSample\FOCUS06439.fit -focus7 D:\temp\FocusSample\FOCUS06789.fit -focus8 D:\temp\FocusSample\FOCUS07139.fit

or using the command line version. See screenshot below:

No wildcards and spaces are allowed in the file names!!

Clear skies, Han

update:
Added also the remaining curve-fit error in the exitcode by:
Errorlevel/Exitcode is focuspos x 1E4 + remaining_error x 1E3

Special ASTAP commandline version

Hi Han,

Assuming I have used your hyperbola8.xls correctly, I will be very happy if I can get AF curve fits as per this one! The slight discontinuity is from the Validation frame, which has yield a marginally better measurement than the earlier data point at 5553.

What’s not to like?

Just need some clear nights now!

Mike

Hello support,

I am having the same issue with autofocus where the reported position differs 1-2 steps from the goto position. That this stops the sequence is frustrating.

Can we have a fix for this? Either by ignoring this or by being able to have a retry.

Best regards
Matthias

1 Like

This is very annoying problem indeed. When your SGP focusing run is hanging on that 1 micron difference, you can press the “goto” -button in PWI focuser-tab and it moves the focuser to correct position, then focusing routine will continue.

The worst thing in this focuser bug is, that focusing run might work just fine for a week and then next week there is always this 1 micron mismatch in every focusing move.

Exactly the same here. I’ve commented elsewhere on the problem. I lose about 1 in 5 imaging sessions to the focus issue.

Voyager has an option to specify the number of steps away from target that are considered ‘on target’ for the focus motor. Either an explicit option or a tolerance built into the autofocus routine would be welcome.

Andy

Another one here, I cannot use automatic focusing routines because of PWI focuser.

You can correct focus based on temperature change and, even if it fails sometimes, SGP will simply give up on focuser not reporting correct position and will continue imaging. You lose some time but not the whole night.

I’m pretty happy to say that I think I’ve solved the problem with the PWI focuser. It is a fork (I think I’m being precise) of this virtual focuser project GitHub - jlecomte/ascom-virtual-focuser: Virtual Focuser ASCOM Driver

My good friend Rafa Barberá kindly programmed a variantion that included a position tolerance so, as long as PWI focuser is inside tolerance, it reports to SGP (or whatever) that the focuser is on the requested position.

Ascom Virtual Focuser

If you are running 64 bits software versions I think you need the DeviceHub as an envelope for the 32bit PWI driver. In my case it is SGP->VirtualFocuserAscomDriver->Ascom DeviceHub->PWI Ascom driver.

This is the DLL Dropbox - ASCOM.DarkSkyGeek.VirtualFocuser.dll - Simplify your life

And these are the installation instructions:

Step 1: Get the file from this messge and put ASCOM.DarkSkyGeek.VirtualFocuser.dll somewhere on your system (example: C:\Users\julien\ascom-virtual-focuser).

Step 2: Open a command prompt, but make sure you run it as an administrator!

Step 3: Then, proceed with the installation of the driver using RegAsm.exe, a utility that should already be present on your system (it comes with the .NET framework). Just don’t forget to use the 64 bit version, and to pass the /tlb /codebase flags. Here is what it looked like on my imaging mini computer:

cd C:\Users\julien\ascom-virtual-focuser
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\RegAsm.exe /tlb /codebase ASCOM.DarkSkyGeek.VirtualFocuser.dll
Microsoft .NET Framework Assembly Registration Utility version 4.8.4161.0
for Microsoft .NET Framework version 4.8.4161.0
Copyright (C) Microsoft Corporation. All rights reserved.

Types registered successfully
Note: The output may be more verbose than the above. As long as it says Types registered successfully, you are good to go!

Note: Once the driver has been installed, make sure you do not delete or move the ASCOM.DarkSkyGeek.VirtualFocuser.dll file, or things will not work! (if you do move it, you will need to register it again in its new location)

Step 4: Start whatever application you use to control your equipment.

I hope this helps you all

1 Like