Date   

Re: APPM with ASI6200 and TSX Imagelink - bogus image data

Ray Gralak
 

Ø  But… why the rather unusual, 32 bit format?

 

ASCOM Camera drivers return a two-dimensional array of 32-bit integer values. Although I don’t think any cameras exceed 16-bit values, that doesn’t mean no future camera ever will.

 

So, I hope this leads you to conclude that APPM’s ASCOM camera client works and does not set all the values in your images to 32767?

 

-Ray

 

From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of ap@...
Sent: Monday, August 2, 2021 12:56 PM
To: main@ap-gto.groups.io; Bratton, Ray (ray@...)
Subject: Re: [ap-gto] APPM with ASI6200 and TSX Imagelink - bogus image data

 

@Ray Gralak:

 

  • I think your analysis is bad. If I load the image into CCDStack the image obviously is not all one level.
  • Here’s a screenshot:

 

The screen shot resolution got munged by Google, I assume it shows SolveNow-2021-08-02-140042.fit.  I don’t have access to that program, but I think I now understand some things better. Thanks.

 

The file from APPM has some differences in FITS headers that are confusing, for example it shows the data as BITPIX 32 and oddly has flipped orientation (landscape to portrait).  The latter should not be an issue, but the former and BZERO set to 0 may be, since the same ASCOM camera on TSX shows BITPIX 16, BZERO 32768.

 

Now those settings may be proper for whatever was done to the data, but I think something in there confuses pixinsight.  Fits Liberator does show statistics (see below). So the interpretation may be a Pixinsight issue.

 

Though it does beg the question: Is there a reason you choose to store 16 bit DN’s in 32 bit format?   (That’s obviously not a driver thing since it’s the same driver).  Is that contributing to the file size issues?

 

I did go back to a file that to me looks wrong, but should have been a real image of some part of the sky as I closed down the first night.  To me in Pixinsight it is not visible, but I tried a all sky, no-scale, plate solve in TSX and it worked.  It did not work that night from APPM, but maybe I had something wrong in the plate solve page. Regardless, whatever format difference is present, Imagelink seems to accept it, so my failure to solve may originate from settings I had wrong.  So I need to try again with real nighttime.  If anyone is curious I attached it (but at 15mb not sure it will make it through).

 

I’ll inquire at Pixinsight why it can’t preview stretch that image.  Or solve it – I tried the same plate solve there and it said “no stars found”.  So it really isn’t reading it correctly.

 

But… why the rather unusual, 32 bit format?

 

Linwood

 

 


Re: APPM with ASI6200 and TSX Imagelink - bogus image data

ap@CaptivePhotons.com
 

@Ray Gralak:

 

  • I think your analysis is bad. If I load the image into CCDStack the image obviously is not all one level.
  • Here’s a screenshot:

 

The screen shot resolution got munged by Google, I assume it shows SolveNow-2021-08-02-140042.fit.  I don’t have access to that program, but I think I now understand some things better. Thanks.

 

The file from APPM has some differences in FITS headers that are confusing, for example it shows the data as BITPIX 32 and oddly has flipped orientation (landscape to portrait).  The latter should not be an issue, but the former and BZERO set to 0 may be, since the same ASCOM camera on TSX shows BITPIX 16, BZERO 32768.

 

Now those settings may be proper for whatever was done to the data, but I think something in there confuses pixinsight.  Fits Liberator does show statistics (see below). So the interpretation may be a Pixinsight issue.

 

Though it does beg the question: Is there a reason you choose to store 16 bit DN’s in 32 bit format?   (That’s obviously not a driver thing since it’s the same driver).  Is that contributing to the file size issues?

 

I did go back to a file that to me looks wrong, but should have been a real image of some part of the sky as I closed down the first night.  To me in Pixinsight it is not visible, but I tried a all sky, no-scale, plate solve in TSX and it worked.  It did not work that night from APPM, but maybe I had something wrong in the plate solve page. Regardless, whatever format difference is present, Imagelink seems to accept it, so my failure to solve may originate from settings I had wrong.  So I need to try again with real nighttime.  If anyone is curious I attached it (but at 15mb not sure it will make it through).

 

I’ll inquire at Pixinsight why it can’t preview stretch that image.  Or solve it – I tried the same plate solve there and it said “no stars found”.  So it really isn’t reading it correctly.

 

But… why the rather unusual, 32 bit format?

 

Linwood

 

 


Re: APPM with ASI6200 and TSX Imagelink - bogus image data

Ray Gralak
 

Hi Linwood,

 

I think your analysis is bad. If I load the image into CCDStack the image obviously is not all one level.

 

-Ray

 

Here’s a screenshot:

 

 

 

 

From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of ap@...
Sent: Monday, August 2, 2021 11:21 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with ASI6200 and TSX Imagelink - bogus image data

 

@Ray said:

 

  • I have no idea how you are taking your images but even a short duration image in daylight can max out the pixels.

 

Well, the lens cover was on.  But I'll do it at a wall in a fairly dark room at 0.01 seconds, so it will not be clipped.

 

  • The next step is for you to use the APCC Log Zipper and zip all of the APPM logs and a few of the "bad" FITS images. Then provide a dropbox, google drive, or other link to download it.

 

Sure.  I did these steps:

 

  • Started TSX, connected to ASCOM driver for ASI174MM Mini, took a 0.01s image (attached starting with TSX).
  • Closed TSX entirely
  • Opened APCC, APPM, verified I was connected to the same driver (I was, no change), set the exposure to 0.01s, took an image (attached named SolveNow-2021-08-02-140042.fit)
  • Below are the statistics from Pixinsight of what should be basically the same image:

 

I ran the log zipper, selected the files from just this run, then added the images to the zip file.  It is here:

 

https://drive.google.com/file/d/1lshJoo9CWKDThRwqgmabyaPFavAcxJsG/view?usp=sharing

 

Also, in case it is not in the files, I am using:

 

Windows Pro vs 21H1 build 19043.1110

Ascom Platform 6.5 SP1

APCC V1.8.8.17

ZWO ASCOM Driver 6.5.1.8 (just downloaded 2 days ago)

Intel NUC (genuine not knockoff) i5-8259U, 32gb memory, 500gb M.2 (half full or less)

 

Linwood

 

 

APPM:

 

 

Notice in particular the min/max/median are fractions.  They should not be if it’s downloading the raw data.

 

TSX:

 


Re: APPM with ASI6200 and TSX Imagelink - bogus image data

ap@CaptivePhotons.com
 

@Ray said:

 

  • I have no idea how you are taking your images but even a short duration image in daylight can max out the pixels.

 

Well, the lens cover was on.  But I'll do it at a wall in a fairly dark room at 0.01 seconds, so it will not be clipped.

 

  • The next step is for you to use the APCC Log Zipper and zip all of the APPM logs and a few of the "bad" FITS images. Then provide a dropbox, google drive, or other link to download it.

 

Sure.  I did these steps:

 

  • Started TSX, connected to ASCOM driver for ASI174MM Mini, took a 0.01s image (attached starting with TSX).
  • Closed TSX entirely
  • Opened APCC, APPM, verified I was connected to the same driver (I was, no change), set the exposure to 0.01s, took an image (attached named SolveNow-2021-08-02-140042.fit)
  • Below are the statistics from Pixinsight of what should be basically the same image:

 

I ran the log zipper, selected the files from just this run, then added the images to the zip file.  It is here:

 

https://drive.google.com/file/d/1lshJoo9CWKDThRwqgmabyaPFavAcxJsG/view?usp=sharing

 

Also, in case it is not in the files, I am using:

 

Windows Pro vs 21H1 build 19043.1110

Ascom Platform 6.5 SP1

APCC V1.8.8.17

ZWO ASCOM Driver 6.5.1.8 (just downloaded 2 days ago)

Intel NUC (genuine not knockoff) i5-8259U, 32gb memory, 500gb M.2 (half full or less)

 

Linwood

 

 

APPM:

 

 

Notice in particular the min/max/median are fractions.  They should not be if it’s downloading the raw data.

 

TSX:

 


Re: 1100GTO AE PHD2 Settings #Guiding #Absolute_Encoders

Pete Mumbower
 

Thanks for the links for the docs Brian. I will go thru those to see if anything has changed in recent years. I have used PHD for the last 10yrs (I think) but I am always learning new things. More just trying to undo how I use to think with my Celestron mount and trust that the A-P can handle longer guide exposures to smooth our seeing noise. Heck I just love the next non-existent backlash in the DEC!

Sorry to the OP, not trying to hijack the thread. I will start a new post if I feel the need for one.


Re: 1100GTO AE PHD2 Settings #Guiding #Absolute_Encoders

 

Hi Pete

there is a doc PHD offers on best practices:

One other thing I'd suggest is doing a baseline guiding setup, which can be done by following this doc (this is what we use in the PHD support forums) - this is a more recent best practice we recommend in addition to the above doc:


This starts with entering appropriate equipment settings and using default algorithms, and then using the built-in guiding assistant will get you a solid starting point and avoid common mistakes that can happen when transitioning between mounts. 

better behaved mounts can perform better (i.e., reduce seeing related noise) with longer exposures, but of course ymmv

ae vs non ae mounts are very different in terms of guiding, so they really are two different approaches. 


hth

Brian


On Mon, Aug 2, 2021 at 10:58 AM Pete Mumbower <pmumbower@...> wrote:
I agree lots to learn for the for the newer mount owners coming from "non-premium" mounts. I know there is tons of nuggets of info on best practices for both AE and non-AE 1100/1600 mounts with PHD around. But does anyone have a best practices collection? For myself coming from a CGE-Pro, I was so use to 2s PHD exposures. Last night I switched to 4s for the heck of it and the RMS improved noticeably. I need to remember my non-AE 1100GTO behaves totally different. I also need to go out and balance both axis as Rolando suggested a couple days ago.



--
Brian 



Brian Valente


Re: 1100GTO AE PHD2 Settings #Guiding #Absolute_Encoders

Roland Christen
 

Refocusing does not require re-balancing. I would not worry about it.

Seeing can be judged easily by turning tracking corrections off and watching the star excursions on the tracking graph in Dec. If the star jumps around +- 1.5 arc seconds, then your seeing is 3 arc sec P-P and you can then set your Min Move to that level. Seeing will vary somewhat with altitude, so if you image an object near the zenith, the seeing might be twice as good as it would be if the object is at 30 to 45 degrees above the horizon.

Rolando

-----Original Message-----
From: Andrew Jones via groups.io <andrew.jones@...>
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Sent: Mon, Aug 2, 2021 12:35 pm
Subject: Re: [ap-gto] 1100GTO AE PHD2 Settings

Hi Roland.
 
I really appreciate these detailed After Action Reports. 😊  These reports provide useful insight for those of us still learning the art/science of astrophotography and how to get the best experience from our AP Mounts. I recently upgraded my Mach1 to a 1100 AEL. I am still in the process of getting it setup in my observatory (waiting for some cooler weather here in Texas), but once setup these reports will be useful references to help ensure I am able to get everything setup and calibrated correctly.
 
The info you provided about DEC balance is very interesting. I never really paid that much attention to the DEC balance. I would balance my TEC 140 close to its imaging configuration when putting the scope on the mount in my observatory, but then I really didn’t mess with again. I just weighed my camera/FW combo and it is almost 5lbs. Combined with 85mm of back focus for the TEC 140, I would guess this creates a fairly substantial moment arm on the DEC axis (similar to the recommendation to avoid putting counter weights as the end of the counter weight bar vs. adding more weights). This moment arm could help explain why I always struggled with guiding with my Mach1, particularly on the DEC axis. PEMPro indicated my polar alignment was within 1-2 arc min on both axis, so I don’t think it is an issue with alignment. Your worse RMS of 0.6 arc sec would be a dream for me. On a typical night, I am lucky if I could keep the RMS below 1 arc sec using PHD2. Based on your observation, I will be pay more attention to the DEC balance and balance more frequently for different temperature ranges and see if that helps with my guiding.
 
I always pay close attention to your experiences with PHD2. As mentioned, I have struggled with guiding. It is helpful to read your(and others) observations and experience with PHD2 and what settings they were using. I wish there was one universal combination of settings in PHD2 that would work in all conditions, but that probably unlikely. It helpful thou to read what settings are working for other AP mount owners that I can try with my own setup, at least as a starting point. I just saved a note with the settings Brian Valente posted earlier and intend to give those a try once I get everything setup.
 
 
I have a couple of questions if you don’t mind.
 
  1. I can balance the scope at the begging of the night close to my last focus position, but as soon as I run auto focus obviously the moment arm will change somewhat. Where I image, it is not uncommon to see a 10°F change in temperature during a given imaging session. I refocus ever 1.5° change in temperature.  To avoid the static friction issue on the DEC axis, is it necessary to rebalance during an imaging session or are the changes to the moment arm due to refocusing insufficient to cause the static friction issue you discussed? In other words, how much out of balance can be tolerated due to refocusing before we should be concerned about static friction?
 
  1. Kind of unrelated question, but how do you determine what your Seeing is during an imaging session? Are you just using the FWHM as reported by your imaging software or do you have another method of determine what the seeing is on a giving night? Based on what your report regarding the impact Seeing has on guiding, it would be good to have a easy way to determine what the Seeing conditions are for a given night so we can adjust our guiding expectations accordingly. I know there are Sky Quality Meters as well as Clear Sky Charts online. I was just curious if you use one of these tools to determine your seeing or if you have another method. Probably a stupid question, but hey I am still learning…
 
Clear Skies,
Andrew J

--
Roland Christen
Astro-Physics


Re: 1100GTO AE PHD2 Settings #Guiding #Absolute_Encoders

Pete Mumbower
 

I agree lots to learn for the for the newer mount owners coming from "non-premium" mounts. I know there is tons of nuggets of info on best practices for both AE and non-AE 1100/1600 mounts with PHD around. But does anyone have a best practices collection? For myself coming from a CGE-Pro, I was so use to 2s PHD exposures. Last night I switched to 4s for the heck of it and the RMS improved noticeably. I need to remember my non-AE 1100GTO behaves totally different. I also need to go out and balance both axis as Rolando suggested a couple days ago.


Re: APPM with ASI6200 and TSX Imagelink - bogus image data

Ray Gralak
 

I have no idea how you are taking your images but even a short duration image in daylight can max out the pixels.

The next step is for you to use the APCC Log Zipper and zip all of the APPM logs and a few of the "bad" FITS images. Then provide a dropbox, google drive, or other link to download it.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of ap@CaptivePhotons.com
Sent: Monday, August 2, 2021 10:40 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with ASI6200 and TSX Imagelink - bogus image data

@Ray wrote:



* First, this morning I tried the image Ray sent. I still get the weird “Expose failed(1): StartExposureNumX Set
– ‘1024’” – where 1024 was the image width. It (something) is picking up the coded X width and misusing it, I think.



* APPM reads values from the ASCOM camera driver when it connects. It sounds like you may have
reconfigured the width of the CCD in the simulator without reconnecting APPM. Thus APPM tried to create a sub-
frame at out of bounds coordinates.



Just tried again, started everything up fresh, it was set before I connected (I viewed but did not change). Same
error.



* I understand the argument that “simulator works, real driver doesn’t, must be the real driver”.



* Except, I’ve already stated that I have successfully taken ASCOM camera images from my ASI294MM
(binned 2x or sub-framed) and FLI ProLine 16803 cameras. Luca posted he has taken ASCOM Camera images too.



* I even posted a screen shot this morning of an image taken indoors this morning with the latest FLI ASCOM
driver. I am willing to make a walk-through video this evening to prove it if you don’t believe me! J



Never in any of this did I mean to imply I don’t believe you. But we are seeing different results, which means we are
either running different software environments, or doing something differently.



Can we step away briefly from the simulator issue. I went back to and tried the ASCOM driver for an ASI174MM
camera I use for guiding. It’s a much smaller frame (1936x1216). I set it up in the simplest state, bin 1, connected
via ASCOM and took an image – the image is all 32767. I loaded in Pixinsight and looked at statistics, the minimum
and maximum are 32767 and 32768 (and some fractions, which is odd for integer data, implying a transformation
somewhere).



I then disconnected from APPM, opened TSX, connected that same ascom driver in TSX with no changes in
settings, took an image and got expected noise patterns (the cover is on the scope so no real image). This is the 32
bit TSX by the way, not 64 bit, and definitely ascom not native driver.



So a smaller frame, same manufacturer (all I have) works in TSX and not in APPM. I guess it’s possible TSX has
done some special coding to work around ASI issues? Except the same driver and same camera work in NINA
(now that’s 64 bit and I have no idea how that works, maybe it’s the same driver name but different code?).



* The problem with the large-pixel count ASI cameras is that full-frame images from that camera exhaust all of
the available memory of APPM, which is a Win32 WinForms application. The question is why does the ASI ASCOM
driver need 1GB of memory for a single 46MPixel monochrome image?!!



Ok, that’s a fair question, but clearly not one I can answer. And lamenting how I wish ASCOM and vendors would
join the 64 bit world won’t help either. 😊



But unless it’s being corrupted silently I do not see how that is causing such weird errors as the errant error
message above, or the all grey returned image. It’s not failing – it is getting an image, saving it on disk, the image is
just garbage.



Out of curiosity I downloaded the latest ASCOM compliance checker, and ran it on the 6200 driver with camera
connected:



Conformance test complete



No errors, warnings or issues found: your driver passes ASCOM validation!!



Again, I’ve been there, written drivers which were loaded with bugs, but could still pass compliance checks. So this
is not definitive by any means. And the compliance check doesn’t give you a copy of the image.



Again, I have a workaround. If you want to just let it go, please do with my thanks for your help. I feel like I’m
annoying you and that is not my intention. If on the other hand you want more debugging info, let me know what I
can provide. It’s cloudy and daylight so I have time, and lots of programming tools lying around.



Linwood


Re: 1100GTO AE PHD2 Settings #Guiding #Absolute_Encoders

Andrew Jones
 

Hi Roland.

 

FYI. I think the manual needs to be updated. The manual indicates that a balance offset is recommend on both axis

 

 

From Page 27 of the 1100 GTO Manual:

 

Precision Balancing Remember that dangling cables will dramatically change balance and create guiding problems, so you’ll want to be sure that all cables are carefully secured and not dragging before you proceed with balancing. Ensure that your focuser is in its focused position, the dew shield extended and the dust cap removed. The following three recommendations will increase guiding performance.

  1. Slightly offset balance to the counterweight side of the R.A. axis. When the axis is perfectly balanced horizontally, then offset the weight just enough to start motion slightly downward on the counterweight side.
  2. Slightly offset balance to the camera side of the Dec. axis. When the axis is perfectly balanced horizontally, then offset the scope just enough to start motion slightly do
  3. The counterweights should ride high on the counterweight shaft. It is best to add counterweights and slide them to the top of the shaft with the heaviest at the top and then use the smallest weight to perform the precision balancing. The reason for this is called “Inertial Moment Arm”. Sliding less weight down the shaft will balance the scope, but will greatly increase the moment arm force; that is to say, it will require a much greater torque to start the axis rotating. (Think of a tightrope walker using a long rod to stabilize his balance.) This is a very important consideration when you are trying to do precise guiding

 

AJ


Re: 1100GTO AE PHD2 Settings #Guiding #Absolute_Encoders

ap@CaptivePhotons.com
 

@Andrew Jones wrote:

 

  1. Kind of unrelated question, but how do you determine what your Seeing is during an imaging session? Are you just using the FWHM as reported by your imaging software or do you have another method of determine what the seeing is on a giving night?

 

I’m also interested, and in particular if there’s an expected relationship to something like total RMS error in PHD2.

 

I’ve had all of two nights with the AP1100 and am just delighted with its guiding performance.  I’m seeing around 0.25 to 0.30” total RMS consistently and nice round stars, and low FWHM in the images. 

 

So a large part of me says ‘take it and be happy’, but there’s that nagging section that says “is it seeing limited, or can I do better”.  How do you know?

 

But even that nagging part of me is really happy… I looked at my eccentricity from the luminance shots, 120s each, and they were not only almost perfect, but almost a straight line – very consistent shot after shot (I have some backfocus issues in the corners I suspect is why they are not better still).

 

But to his larger point – yes please, those who know what you are doing, keep the examples and suggestions coming.  Lots to learn!

 

 


Re: APPM with ASI6200 and TSX Imagelink - bogus image data

ap@CaptivePhotons.com
 

@Ray wrote:

 

  • First, this morning I tried the image Ray sent.  I still get the weird “Expose failed(1): StartExposureNumX Set – ‘1024’” – where 1024 was the image width.  It (something) is picking up the coded X width and misusing it, I think.

 

  • APPM reads values from the ASCOM camera driver when it connects. It sounds like you may have reconfigured the width of the CCD in the simulator without reconnecting APPM. Thus APPM tried to create a sub-frame at out of bounds coordinates.

 

Just tried again, started everything up fresh, it was set before I connected (I viewed but did not change). Same error.

 

    • I understand the argument that “simulator works, real driver doesn’t, must be the real driver”. 

 

  • Except, I’ve already stated that I have successfully taken ASCOM camera images from my ASI294MM (binned 2x or sub-framed) and FLI ProLine 16803 cameras. Luca posted he has taken ASCOM Camera images too.

 

  • I even posted a screen shot this morning of an image taken indoors this morning with the latest FLI ASCOM driver. I am willing to make a walk-through video this evening to prove it if you don’t believe me! J

 

Never in any of this did I mean to imply I don’t believe you.  But we are seeing different results, which means we are either running different software environments, or doing something differently.

 

Can we step away briefly from the simulator issue.  I went back to and tried the ASCOM driver for an ASI174MM camera I use for guiding.  It’s a much smaller frame (1936x1216).  I set it up in the simplest state, bin 1, connected via ASCOM and took an image – the image is all 32767. I loaded in Pixinsight and looked at statistics, the minimum and maximum are 32767 and 32768 (and some fractions, which is odd for integer data, implying a transformation somewhere).

 

I then disconnected from APPM, opened TSX, connected that same ascom driver in TSX with no changes in settings, took an image and got expected noise patterns (the cover is on the scope so no real image). This is the 32 bit TSX by the way, not 64 bit, and definitely ascom not native driver.

 

So a smaller frame, same manufacturer (all I have) works in TSX and not in APPM. I guess it’s possible TSX has done some special coding to work around ASI issues?   Except the same driver and same camera work in NINA (now that’s 64 bit and I have no idea how that works, maybe it’s the same driver name but different code?).

 

  • The problem with the large-pixel count ASI cameras is that full-frame images from that camera exhaust all of the available memory of APPM, which is a Win32 WinForms application. The question is why does the ASI ASCOM driver need 1GB of memory for a single 46MPixel monochrome image?!!

 

Ok, that’s a fair question, but clearly not one I can answer.  And lamenting how I wish ASCOM and vendors would join the 64 bit world won’t help either.  😊

 

But unless it’s being corrupted silently I do not see how that is causing such weird errors as the errant error message above, or the all grey returned image.  It’s not failing – it is getting an image, saving it on disk, the image is just garbage.

 

Out of curiosity I downloaded the latest ASCOM compliance checker, and ran it on the 6200 driver with camera connected:

 

Conformance test complete

 

No errors, warnings or issues found: your driver passes ASCOM validation!!

 

Again, I’ve been there, written drivers which were loaded with bugs, but could still pass compliance checks.  So this is not definitive by any means.  And the compliance check doesn’t give you a copy of the image.

 

Again, I have a workaround.  If you want to just let it go, please do with my thanks for your help.  I feel like I’m annoying you and that is not my intention.  If on the other hand you want more debugging info, let me know what I can provide. It’s cloudy and daylight so I have time, and lots of programming tools lying around.

 

Linwood


Re: 1100GTO AE PHD2 Settings #Guiding #Absolute_Encoders

Andrew Jones
 

Hi Roland.

 

I really appreciate these detailed After Action Reports. 😊  These reports provide useful insight for those of us still learning the art/science of astrophotography and how to get the best experience from our AP Mounts. I recently upgraded my Mach1 to a 1100 AEL. I am still in the process of getting it setup in my observatory (waiting for some cooler weather here in Texas), but once setup these reports will be useful references to help ensure I am able to get everything setup and calibrated correctly.

 

The info you provided about DEC balance is very interesting. I never really paid that much attention to the DEC balance. I would balance my TEC 140 close to its imaging configuration when putting the scope on the mount in my observatory, but then I really didn’t mess with again. I just weighed my camera/FW combo and it is almost 5lbs. Combined with 85mm of back focus for the TEC 140, I would guess this creates a fairly substantial moment arm on the DEC axis (similar to the recommendation to avoid putting counter weights as the end of the counter weight bar vs. adding more weights). This moment arm could help explain why I always struggled with guiding with my Mach1, particularly on the DEC axis. PEMPro indicated my polar alignment was within 1-2 arc min on both axis, so I don’t think it is an issue with alignment. Your worse RMS of 0.6 arc sec would be a dream for me. On a typical night, I am lucky if I could keep the RMS below 1 arc sec using PHD2. Based on your observation, I will be pay more attention to the DEC balance and balance more frequently for different temperature ranges and see if that helps with my guiding.

 

I always pay close attention to your experiences with PHD2. As mentioned, I have struggled with guiding. It is helpful to read your(and others) observations and experience with PHD2 and what settings they were using. I wish there was one universal combination of settings in PHD2 that would work in all conditions, but that probably unlikely. It helpful thou to read what settings are working for other AP mount owners that I can try with my own setup, at least as a starting point. I just saved a note with the settings Brian Valente posted earlier and intend to give those a try once I get everything setup.

 

 

I have a couple of questions if you don’t mind.

 

  1. I can balance the scope at the begging of the night close to my last focus position, but as soon as I run auto focus obviously the moment arm will change somewhat. Where I image, it is not uncommon to see a 10°F change in temperature during a given imaging session. I refocus ever 1.5° change in temperature.  To avoid the static friction issue on the DEC axis, is it necessary to rebalance during an imaging session or are the changes to the moment arm due to refocusing insufficient to cause the static friction issue you discussed? In other words, how much out of balance can be tolerated due to refocusing before we should be concerned about static friction?

 

  1. Kind of unrelated question, but how do you determine what your Seeing is during an imaging session? Are you just using the FWHM as reported by your imaging software or do you have another method of determine what the seeing is on a giving night? Based on what your report regarding the impact Seeing has on guiding, it would be good to have a easy way to determine what the Seeing conditions are for a given night so we can adjust our guiding expectations accordingly. I know there are Sky Quality Meters as well as Clear Sky Charts online. I was just curious if you use one of these tools to determine your seeing or if you have another method. Probably a stupid question, but hey I am still learning…

 

Clear Skies,

Andrew J


Re: APPM with ASI6200 and TSX Imagelink - bogus image data

Ray Gralak
 

Ø  First, this morning I tried the image Ray sent.  I still get the weird “Expose failed(1): StartExposureNumX Set – ‘1024’” – where 1024 was the image width.  It (something) is picking up the coded X width and misusing it, I think.

 

APPM reads values from the ASCOM camera driver when it connects. It sounds like you may have reconfigured the width of the CCD in the simulator without reconnecting APPM. Thus APPM tried to create a sub-frame at out of bounds coordinates.

 

Ø  I understand the argument that “simulator works, real driver doesn’t, must be the real driver”. 

Except, I’ve already stated that I have successfully taken ASCOM camera images from my ASI294MM (binned 2x or sub-framed) and FLI ProLine 16803 cameras. Luca posted he has taken ASCOM Camera images too.

 

I even posted a screen shot this morning of an image taken indoors this morning with the latest FLI ASCOM driver. I am willing to make a walk-through video this evening to prove it if you don’t believe me! J

 

The problem with the large-pixel count ASI cameras is that full-frame images from that camera exhaust all of the available memory of APPM, which is a Win32 WinForms application. The question is why does the ASI ASCOM driver need 1GB of memory for a single 46MPixel monochrome image?!!

 

-Ray

 

 

 

 

From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of ap@...
Sent: Monday, August 2, 2021 8:10 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM with ASI6200 and TSX Imagelink - bogus image data

 

Wow, go to bed and lots to catch up on…

 

@Bill Long: Thanks for the pointers on the Model Properties.  I checked the exclude boxes.  Mine is actually showing 120, you said 10 or 20?  Also, should Correct for Refraction be checked, I would have thought so?  And thanks for the follow through on the camera stuff.

 

@Ray Grakak and @Bill Long re cameras:

 

First, this morning I tried the image Ray sent.  I still get the weird “Expose failed(1): StartExposureNumX Set – ‘1024’” – where 1024 was the image width.  It (something) is picking up the coded X width and misusing it, I think.

 

I understand the argument that “simulator works, real driver doesn’t, must be the real driver”.  I do, but there’s a lot more going on – one thing is the parameters I put into the simulator setup – maybe I screwed them up.  Not sure.  I CAN use your image in TSX with the simulator, just not APPM.

 

But here’s another side that seems to come out from last night’s discussion as well as my successful run:  The same ASCOM driver for the real camera works fine in TSX (and other programs, I tried NINA).  Add to that Bill tried several unrelated ASCOM camera drivers (Thank you!) and none worked in APPM (if I understood).

 

Note I’m not trying to pick on APPM. I now have a workaround using TSX.  I hope for a permanent workaround using NINA soon. So while the software developer in me thinks the issue is APPM, it may not be and I have a workaround.  So…

 

If it is useful to you (Ray) to pursue further, I’m more than happy to help, experiment, etc., try to figure out why you can run the simulator and I can’t (I have used it before, in NINA).  I’m also more than happy to provide traces or whatever might be useful from the ASCOM driver.  I can dig up the ASCOM validation routine as well, though in drivers I’ve written LOTS of bugs can still be in them and pass. 😊  Just let me know if there’s anything I can do to help.

 

But if you are sure the problem lies in ZWO or otherwise not worth pursuing, that’s fine also. I’m delighted to get a decent model now, and have a workaround for the time being.

 

Thanks again to both, sorry I went to bed early, but I already trust the AP1100 to just do its thing – and it did, flip and all.

 

@Geoffrey Collins and use of TSX:  It took me a few tries and a bit of trial and error but here is what I found that works:

 

  • Set up TSX with the camera, and connect
  • Connect the mount from TSX (no need to do anything with it, but this lets it get coordinates)
  • Take an image from TSX and plate solve (to be sure you can).  Note binning and also image scale from imagelink
  • Fire up APPM, and set up the camera in as TSX Camera Pro, and this is where I went wrong at first: in APPM on the Plate Solve settings, be sure to put the right image scale there.  I thought it would use my setting in Imagelink, but the scale is pushed in from APPM, and note it is the UNBINNED scale (says right on it, but didn’t keep me from putting binned in there the first time)
  • Do the immediate plate solve from APPM, see if it works.  If not, it should bring up the image in the viewer in TSX even if it fails, go there, plate solve, compare settings.  If TSX works and APPM doesn’t get a valid answer, it’s probably a settings difference on the camera or plate solving tabs.

 

I’m not sure if the mount has to be connected to TSX to plate solve through APPM, but I left it connected.  I figured this would give the camera software in TSX access to the coordinates which non-blind plate solving would need.

 

Note that also the bin and exposure setting comes from the camera tab in APPM and NOT from the camera setup in TSX.  APPM pushes the camera tab settings into TSX even though APPM is not driving the camera.  Convenient.  Wasn’t obvious to me, but it’s a nice setup.

 

Once I had all that, each plate solve took only a couple seconds, very fast, primary limiting factor in building the model was slew time, and a bit of exposure (I used 4 seconds with a 4” refractor, maybe less would have worked, but that worked on all but one frame and that was from clouds).

 

Linwood


Re: Mach 2 + 12.5" AGO iDK?

Roland Christen
 


Not sure if it was the idea to move to neutral balance, or the seeing here is better.
Probably both.

Rolando


-----Original Message-----
From: Bill Long <bill@...>
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Sent: Mon, Aug 2, 2021 2:09 am
Subject: Re: [ap-gto] Mach 2 + 12.5" AGO iDK?

Not sure if it was the idea to move to neutral balance, or the seeing here is better. The guided performance is much better in this configuration. 


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Bill Long <bill@...>
Sent: Sunday, August 1, 2021 11:31 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Mach 2 + 12.5" AGO iDK?
 
Well then.... 20 mins here:




From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Bill Long <bill@...>
Sent: Sunday, August 1, 2021 9:08 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Mach 2 + 12.5" AGO iDK?
 
Had to take a break but should be back in the swing tonight with this combo. I took Rolands advice and neutral balanced both axis on the Mach 2. Here is a photo of the beast in route to a fun night.

Counterweights are 1x30, 3x18, 2x10, aka all the weights I own. 😂

She's perfectly balanced though. We'll see how the night goes. 

image/jpeg 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Bill Long <bill@...>
Sent: Friday, July 30, 2021 12:14 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Mach 2 + 12.5" AGO iDK?
 
Night 5, still the same story. Excellent performance with a massive load on the Mach 2 mount. I have still done nothing at all in terms of the model, PA, or anything else.

I should probably add in for new people that this rig sits 2 stories in the air, on a wooden deck that is over 15 years old. If that doesn't show the power of this mount, nothing will. This is the ULTIMATE torture test. The mount is at its limits, and its environment is well past its limits. Yet -- with good equipment even you can image on a tightrope. 

😄 




From: Bill Long <bill@...>
Sent: Thursday, July 29, 2021 12:19 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Mach 2 + 12.5" AGO iDK?
 
Yep. Absolutely no problem at all.


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Roland Christen via groups.io <chris1011@...>
Sent: Thursday, July 29, 2021 12:08 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Mach 2 + 12.5" AGO iDK?
 
Great! So, this combination mount and scope is a winner. Good to know.

Thanks,

Rolando



-----Original Message-----
From: Bill Long <bill@...>
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Sent: Wed, Jul 28, 2021 10:57 am
Subject: Re: [ap-gto] Mach 2 + 12.5" AGO iDK?

A total of 4 all night imaging runs with this combo and still not a single sub thrown out. Excellent tracking and guiding performance. I haven't touched PA, PHD2 settings, or the model since night one when I set the mount up outside. It just works. Tonight will be night 5.


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Bill Long <bill@...>
Sent: Monday, July 26, 2021 2:49 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Mach 2 + 12.5" AGO iDK?
 
We had mild wind here about 5-6MPH and so I wanted to show that as well. No impact at all to subs, and the Mach 2 handled it fine. 






From: Bill Long <bill@...>
Sent: Sunday, July 25, 2021 8:47 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Mach 2 + 12.5" AGO iDK?
 
Here are some sample subs:


I took the highest and lowest FWHM from the data set and shared them. 


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Bill Long <bill@...>
Sent: Sunday, July 25, 2021 10:12 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Mach 2 + 12.5" AGO iDK?
 
Circling back on this as I finally got to test this out. I put my 12.5" AGO iDK, Moonlight Nitecrawler, FLI Proline 16803, CFW 5-7, Sagitta OAG, and Ultrastar guide camera on the Mach 2. Balancing the load was pretty easy to do, and I had just enough weights on hand for the job. This is pretty much at capacity for the mount based on the specifications. Might even be a tad over. 😁

Performance was stellar. I made a 98pt model in APPM, and used 5 second guide exposures. I took 5 hours worth of 20 minute HA subs and not a single one had any trailing at all. Very nice tight round stars in all of the images. Guiding was about 0.2-0.35" range throughout the night. Graph picture below.

I'll be getting some more data over the next few nights. I'll share some subs later this evening when I'm back on the Astro PC.

Conclusion: Mach 2 is a beastly mount that easily handled this challenge and passed with flying colors. Well done AP!

image/png


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Roland Christen via groups.io <chris1011@...>
Sent: Friday, April 23, 2021 5:44 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Mach 2 + 12.5" AGO iDK?
 
Well, I've never tried that scope, but I have loaded my Mach2 to the limit and imaged/guided just fine. Balance is critical and is easy to do.

Weight makes for larger moment, which makes the mount slower to respond to external disturbance, like wind. If your scope is open tube with no shroud, wind will not be a problem.

I will be loading my Mach2 with a 12" F8 carbon fiber Maksutov astrograph in the next couple days. Weight is about the same as your system. I expect that it will handle it fine and will post some guiding results. Will be getting ready for galaxy season.

Rolando



-----Original Message-----
From: Bill Long <bill@...>
To: AP-GTO Groups. io <ap-gto@groups.io>
Sent: Fri, Apr 23, 2021 7:07 pm
Subject: [ap-gto] Mach 2 + 12.5" AGO iDK?

What say ye?


46lbs, but would need to add focuser (8lbs), TCS System (1lb), and camera/accessories (call these 5 lbs). The OTA is about 18" tall (maybe 17.5" but lets call it 18") so this puts me at 18" and 60 lbs.  This puts me right on the yellow on the Mach 2 graph AP has. Length of everything, in focus with camera gear on would be about 45". 

Seems right at the limits, but likely safe. Any ideas on this from AP or others?

-Bill 

--
Roland Christen
Astro-Physics

--
Roland Christen
Astro-Physics

--
Roland Christen
Astro-Physics


Re: Possible CP5 Wi-Fi module failure #WiFi

Roland Christen
 

From your description it does not sound like the WiFi is toast.
Call George or Howard at AP and they can assist you in connecting to your WiFi.

Rolando


-----Original Message-----
From: Eric Weiner <weinere@...>
To: main@ap-gto.groups.io
Sent: Sun, Aug 1, 2021 2:45 pm
Subject: [ap-gto] Possible CP5 Wi-Fi module failure #WiFi

I've been using the CP5 Wi-Fi successfully for several months now.  My primary method of connectivity to my PC is serial over USB, but I always connect the CP5 to my home Wi-Fi network so I can simply control it via my iPhone using SkySafari Pro when I want.

Recently I was having issues connecting to my home network from my observing site which is less than 100 feet from the router.  I brought my Mach2 inside today to troubleshoot and was unsuccessful.  The CP5 Wi-Fi will not connect in station mode, or allow a connection as an access point.

With the mount 10 feet from the router it won't connect to my home Wi-Fi network (which is working); no IP or hostname shows up in APCC for Wi-Fi.  I've tired several antenna orientations.
I made a direct LAN connection to check the settings
The CP5 did connect to my home LAN network and populated the IP in APCC (still not Wi-Fi IP shown in APCC)
The CP5 would not connect to my home Wi-Fi network from the setting page (I confirmed the password is correct)
I started up the built in access point, connected, but could not join the access point network; all access point settings started out as OEM including the password
I tried several passwords, several power cycles, turning the Wi-Fi off and on, but even when the access point was created (sometimes it failed to even transmit the host name) I would get "Unable to join the network "GTOCP5_NET_102".

It sure seems like this Wi-Fi modules is toast.  Any ideas from users or A-P?

Thanks,
Eric

--
Roland Christen
Astro-Physics


Re: 1100GTO, slight free play in RA axis only. Is a backstop adjustment needed?

Roland Christen
 

The backstop won't adjust the free play. DON'T jam the back stop hard into position!
What does affect the free play is the retaining nut on the end of the worm. If this is loose or has backed off slightly, it will allow the worm to move back and forth. Call George at AP and he will assist you.

Rolando



-----Original Message-----
From: skester@...
To: main@ap-gto.groups.io
Sent: Sun, Aug 1, 2021 12:36 pm
Subject: [ap-gto] 1100GTO, slight free play in RA axis only. Is a backstop adjustment needed?

I've had my 1100 for a few months and it has performed well.  However I noticed from day 1 a small amount of free movement in the RA axis while the Dec axis has none.  The amount of play in the RA axis is between 1 and 2 mm of movement at the tip of the counterweight shaft.  

Is this amount of play normal/correct, or should I adjust the RA gearbox backstop as described on page 34 fo the owners manual?

Thanks,
Scott

--
Roland Christen
Astro-Physics


Re: Possible CP5 Wi-Fi module failure #WiFi

Eric Weiner
 

Rebooting the router was the first troubleshooting step I took.
 
I'm using three Orbi AC3000 which provides excellent coverage throughout my house and across my property.
 
These new router settings did the trick. The Wi-Fi connections to the CP5 are consistent, immediate, and solid now regardless of how I initialize the mount. 
 
A key indicator that I didn't pick up on these past few months is the signal strength meter on the CP5 settings page.  Before I made these changes the CP5 setting page showed my home Wi-Fi network listed, but the signal strength as "??."  I just assumed this was a function of having a mesh network, and not just a single router.  After making these changes it now shows a signal strength of -47dB at 50% Tx pwr (it was at -52dBm at 25% for reference).  
 
I can only hypothesize, but it sure seems like it was a matter of RF interference across the Wi-Fi channels I had selected for the CP5 and my router (both are set to Channel 1 now), too much throughput allowed on the mesh network (CTS/RTS at 500 vs 2346), and perhaps too much power out at my mesh transmitters (50% vs 100% now).  


Re: APPM with ASI6200 and TSX Imagelink - bogus image data

ap@CaptivePhotons.com
 

Wow, go to bed and lots to catch up on…

 

@Bill Long: Thanks for the pointers on the Model Properties.  I checked the exclude boxes.  Mine is actually showing 120, you said 10 or 20?  Also, should Correct for Refraction be checked, I would have thought so?  And thanks for the follow through on the camera stuff.

 

@Ray Grakak and @Bill Long re cameras:

 

First, this morning I tried the image Ray sent.  I still get the weird “Expose failed(1): StartExposureNumX Set – ‘1024’” – where 1024 was the image width.  It (something) is picking up the coded X width and misusing it, I think.

 

I understand the argument that “simulator works, real driver doesn’t, must be the real driver”.  I do, but there’s a lot more going on – one thing is the parameters I put into the simulator setup – maybe I screwed them up.  Not sure.  I CAN use your image in TSX with the simulator, just not APPM.

 

But here’s another side that seems to come out from last night’s discussion as well as my successful run:  The same ASCOM driver for the real camera works fine in TSX (and other programs, I tried NINA).  Add to that Bill tried several unrelated ASCOM camera drivers (Thank you!) and none worked in APPM (if I understood).

 

Note I’m not trying to pick on APPM. I now have a workaround using TSX.  I hope for a permanent workaround using NINA soon. So while the software developer in me thinks the issue is APPM, it may not be and I have a workaround.  So…

 

If it is useful to you (Ray) to pursue further, I’m more than happy to help, experiment, etc., try to figure out why you can run the simulator and I can’t (I have used it before, in NINA).  I’m also more than happy to provide traces or whatever might be useful from the ASCOM driver.  I can dig up the ASCOM validation routine as well, though in drivers I’ve written LOTS of bugs can still be in them and pass. 😊  Just let me know if there’s anything I can do to help.

 

But if you are sure the problem lies in ZWO or otherwise not worth pursuing, that’s fine also. I’m delighted to get a decent model now, and have a workaround for the time being.

 

Thanks again to both, sorry I went to bed early, but I already trust the AP1100 to just do its thing – and it did, flip and all.

 

@Geoffrey Collins and use of TSX:  It took me a few tries and a bit of trial and error but here is what I found that works:

 

  • Set up TSX with the camera, and connect
  • Connect the mount from TSX (no need to do anything with it, but this lets it get coordinates)
  • Take an image from TSX and plate solve (to be sure you can).  Note binning and also image scale from imagelink
  • Fire up APPM, and set up the camera in as TSX Camera Pro, and this is where I went wrong at first: in APPM on the Plate Solve settings, be sure to put the right image scale there.  I thought it would use my setting in Imagelink, but the scale is pushed in from APPM, and note it is the UNBINNED scale (says right on it, but didn’t keep me from putting binned in there the first time)
  • Do the immediate plate solve from APPM, see if it works.  If not, it should bring up the image in the viewer in TSX even if it fails, go there, plate solve, compare settings.  If TSX works and APPM doesn’t get a valid answer, it’s probably a settings difference on the camera or plate solving tabs.

 

I’m not sure if the mount has to be connected to TSX to plate solve through APPM, but I left it connected.  I figured this would give the camera software in TSX access to the coordinates which non-blind plate solving would need.

 

Note that also the bin and exposure setting comes from the camera tab in APPM and NOT from the camera setup in TSX.  APPM pushes the camera tab settings into TSX even though APPM is not driving the camera.  Convenient.  Wasn’t obvious to me, but it’s a nice setup.

 

Once I had all that, each plate solve took only a couple seconds, very fast, primary limiting factor in building the model was slew time, and a bit of exposure (I used 4 seconds with a 4” refractor, maybe less would have worked, but that worked on all but one frame and that was from clouds).

 

Linwood


Re: APPM with ASI6200 and TSX Imagelink - bogus image data

 

>>> I run the 64bit SGP version, which plays nice with the large format ASI cameras through the ASI ASCOM driver.

I think this is a big part of it. I used my 6200mc with APPM via SGP version 4 64 bit and it worked great. SGP 32 bit didn't work at all. They are monster file sizes

On Mon, Aug 2, 2021 at 7:39 AM Luca Marinelli <photo@...> wrote:
I don't have any of the large format sensor ASI cameras connected at the moment, but I remember having similar difficulties using the ASCOM driver directly from APPM. I also remember not having trouble using the ASI6200MM Pro camera through SGP but I also plate solve with SGP, which requires the camera to be connected to that application, so the issue may be related to multiple applications poking the ASI ASCOM driver. Also, I run the 64bit SGP version, which plays nice with the large format ASI cameras through the ASI ASCOM driver.

I did try to collect daytime images with the QHY ASCOM driver connected to a QHY 268M camera, as well as with the ASI ASCOM driver connected to the ASI290MM Mini guide camera. In both cases, the images display full bit depth grayscale and not a single value, similarly to what Ray reported with the FLI ASCOM driver. To avoid the double-polling of the driver, I selected ASCOM in the camera interface and SkyX for plate solving.

Luca



--
Brian 



Brian Valente

3461 - 3480 of 83231