Date   

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

ap@CaptivePhotons.com
 

@Geoffrey Collins wrote:

 

  • So Linwood, in APPM you are using the SkyX driver for the camera rather than the ASCOM camera driver. If I switch to the SkyX driver, I should be able to use Pinpoint for plate solving.  I probably will still not be able to use a full frame image though.  

Ok, so caveat first: where that long thread ended though was that it might not be necessary, that the APPM camera interface to the ASCOM drive may well work fine.  I won’t be able to try again until a clear night.  The format of the file it produces is different than other programs using it, but I think it may solve (it did not for me, but I probably had a setting wrong).

What I did that worked was to use the TSX camera and plate solver.  It’s important to note that it isn’t really a camera driver exactly, so much as an automation call – APPM asks TSX to take an image, it uses all the camera program features in TSX, and whatever driver TSX has connected.

I don’t see any point in using TSX camera and then trying to go to a different environment (Pinpoint) to solve.  I’m not saying you cannot, just don’t see the point.  If you have TSX, let it use Imagelink, it will be simpler.

Also, as I mentioned elsewhere, I connected the mount to TSX also; I do not know if that’s needed for it to get coordinates or not.  It doesn’t hurt, as TSX won’t DO anything to it (unless you tell it to).

  • I wonder if there is a 2 or 3 star alignment process with the AP hand controller.  I haven’t seen that concept in APCC, and my hand controller has not arrived yet.  

I didn’t even order one.  😊

Just polar align with something else – Pempro, Sharpcap, NINA, etc.  Pempro is recommended and may be the most accurate, Sharpcap is very quick, NINA is quick also but the feature really new and you have to be on the nightlies. 

Linwood

 


Re: Current manuals electronically?

 

Linwood,

 

The 1100 and CP4 manuals on the website are now up to date. I apologize that we did not catch this earlier. I also realized that the manuals that were copied onto the USB drives sent with the mounts were also not current. So, new mount owners may wish to substitute the current versions on their USB drives. Thanks again for bringing this to our attention.

 

Clear Skies,

Marj Christen

Astro-Physics

11250 Forest Hills Road

Machesney Park, IL 61115

Phone: 815-282-1513

www.astro-physics.com

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of ap@...
Sent: Friday, July 30, 2021 9:10 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] Current manuals electronically?

 

Now that I got the AP1100 I realize the manuals I have are out of date.  I almost never use paper, I vastly prefer electronic, I can read it on my phone, my kindle, my computer, etc.

Is there anywhere to get the current manuals? 

Example: the CP4 manual shipped is Feb 2020, but the one online is Nov 2018.  Or the 1100GTO says "Mounts shipped starting in March 2021" but online it says "Mounts shipped starting in Nov 2018". 

Obviously not an earth shaking issue, I still remember how to use paper (I think), but am I just looking in the wrong place?   I'm looking here: 

https://astro-physics.info/index.htm?tech_support/tech_support

Thanks, 
Linwood


Re: AP1100, Berlebach Planet, mounting CP4

 

Hello Linwood,

 

I just uploaded the current RAPAS instructions to the website. Thank you for bringing this to my attention.

 

Clear Skies,

Marj Christen

Astro-Physics

11250 Forest Hills Road

Machesney Park, IL 61115

Phone: 815-282-1513

www.astro-physics.com

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of ap@...
Sent: Thursday, July 29, 2021 9:07 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] AP1100, Berlebach Planet, mounting CP4

 

Wow, I sure missed an obvious solution.

 

@Peter Nagy “Never leave RAPAS into the mount after finishing polar alignment. I guarantee you at least one of the cables will get caught.”

 

@Woody Schlom “I just remove the RAPAS after PA.  Cables want to hang up on it anyway.“

 

@fernandorivera3 “There is absolutely no reason to keep the RAPAS permanently attached to the mount. It is only used for initial polar alignment & once done with the fine tuning/tweaking it is put away until the next session.“

@M Hambrick “I agree with all of the comments about the RAPAS. Do not leave it attached.”

 

OK… I admit to a brain failure of some sort, it just never occurred to me that this was intended as an in-and-out device. I also read two lines in the manual badly, and they left me with the impression it was left in:

 

even if the polar scope is removed at the end of a session and replaced at the next session.” (note “end of session), and then I MIS-read:

 

Important Reminder: The RAPAS Adapter must always remain attached to the scope.”  As saying the RAPAS must remain attached, but it goes on to say “Only the RAPAS itself, is removed”.  Clearly it is referring to a change to other mount types and placement of a special adapter that should not be removed.  Forgot high school test taking 101 –read the whole question.

 

Enough excuses: It’s obvious in retrospect it can just come off.  Though I do worry about daily use and the relatively small threads on the holes, but I’ll cross that bridge if it becomes an issue.

 

One small suggestion – if Astro-Physics is reading: – I had read and in some cases printed these manuals ahead of time, and did not until now look at the instruction sheets in the box.  The one online is from 2017.  The one in the box is from 2019, and in big bold print at the top it says “USE IT AND REMOVE IT” that is not on the online copy.  Please consider updating the online manual with the new text for those who try to get a head start.  (Link is mid-page on “tech_support” page under Mount Accessories, Instructions”).

 

Anyway…. Back to:

 

@M Hambrick said: “Back to the topic of whether you should orient the tripod with the 3rd leg pointed south, I would caution you not to do this.”

 

Sorry, I thought I was clear, I tried, it will clearly be a tip over risk with the AP1100.  I agree completely.  What I was trying to convey is the REASON it is a tip over risk is that the mount extends further out (than the MyT) and that also is the reason that there is no need to reverse – the additional extension away from the center of gravity also provides plenty of leg clearance (in either orientation).  Net good thing.  I guess I would say a bad thing on the MyT that its design exacerbates leg crashes in the conventional CW-over-one-leg orientation.  No issue, was just a (convoluted) comment.

 

As to play in the mount holes, I will keep an eye out for movement there, but it seems reasonably snug so far but indeed the thru holes are quite a bit larger than the screws. Thanks for the photos and pointer.  That shift would occur regardless of leg placement.

 

Anyway… mostly wanted to provide a followup, and a head’s up to anyone mounting on Berlebach’s base – it’s a great, well made, heavy duty base – but the added wall thickness needs to be accommodated with some different hardware.

 

Linwood

 


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

Geoffrey Collins
 

So Linwood, in APPM you are using the SkyX driver for the camera rather than the ASCOM camera driver. If I switch to the SkyX driver, I should be able to use Pinpoint for plate solving.  I probably will still not be able to use a full frame image though.  

It’s cloudy tonight so I will have to wait until tomorrow night to try.  

I wonder if there is a 2 or 3 star alignment process with the AP hand controller.  I haven’t seen that concept in APCC, and my hand controller has not arrived yet.  


Re: Heads-up on possible abrupt parking problem #Absolute_Encoders #Mach2GTO #APCC

David Johnson
 

Maybe an extended timeout is possible, but I can't believe it's rebooting.  If I were to reboot or it were to reboot on it's own, it would have to restart SGP and reconnect the focuser, the camera, the filter wheel, and the mount driver in SGP.  It would also have to reset the camera to be at the same temperature it was at previously through SGP.  SGP definitely does not do this automatically. Even APCC does not start automatically, and I don't have it set up to connect to the mount automatically.  All of these I have to do manually when I restart the computer.

I'll try to set it to five minutes for the Safety Park tonight and see what happens.


Re: Heads-up on possible abrupt parking problem #Absolute_Encoders #Mach2GTO #APCC

Bill Long
 

How is the mount being connected to the PC? USB or Ethernet? If it's USB make sure the hub in device manager has the power savings feature turned off. You can do this for all of the connected hubs down in device manager. This is especially important for users of the ultimate powerbox or similar devices. I've seen all kinds of communication errors happen with that option enabled.

Likewise, you can try using Ethernet and seeing if the issue will reproduce.

Bill


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Howard Hedlund <howard@...>
Sent: Monday, August 2, 2021 4:29 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Heads-up on possible abrupt parking problem #Mach2GTO #APCC #Absolute_Encoders
 
Dave's theory was a good theory, but I'm afraid it wasn't correct.   Here was my response to him sent well after his post, so I repeat:  At the time it was a god theory.   The short-term quick-fix is to simply set the park timer to a larger value.  I suggested 5 minutes.  
Response:

I still think something is causing a restart or an extended timeout of your computer.  Have automatic Windows updates been either turned off or else set to a time when you are not imaging?

  • The timekeeper for the park timer is in the GTOCP5 control box, not the computer or APCC.  APCC simply tells the park timer to start its specified countdown.  After that, the mount counts down its time like an egg timer.  If the timer goes off, the mount parks.  It is APCC’s job to keep resetting the timer before it goes off.  The default timer is set for 1 minute, but APCC generally resets it every 8 or 9 seconds, so the countdown never even gets close to going off.
  • The MGBox ‘s GPS times are consistently off by a couple seconds compared to the PC time throughout the log.  Polling occurs every second.  I never found a discrepancy anywhere close to 2 minutes 48 seconds.
  • After initially setting the time in the GTOCP5, there were no corrections to the mount time sent until AFTER the event, and that was a 1 second correction.  If the PC had corrected its time, an equivalent change would have been sent to the mount within a few seconds.  There was no correction sent to the mount. 
  • Computer time was about 2.9 seconds ahead of the MGBox’s GPS time before the glitch (fancy technical term).  It was about 3.4 seconds ahead after the glitch.  That certainly wasn’t a correction to the time.
I am not an expert using Windows Event Viewer, but I would like to see whether it confirms my suspicions.
HH


Re: Heads-up on possible abrupt parking problem #Absolute_Encoders #Mach2GTO #APCC

Howard Hedlund
 

Dave's theory was a good theory, but I'm afraid it wasn't correct.   Here was my response to him sent well after his post, so I repeat:  At the time it was a god theory.   The short-term quick-fix is to simply set the park timer to a larger value.  I suggested 5 minutes.  
Response:

I still think something is causing a restart or an extended timeout of your computer.  Have automatic Windows updates been either turned off or else set to a time when you are not imaging?

  • The timekeeper for the park timer is in the GTOCP5 control box, not the computer or APCC.  APCC simply tells the park timer to start its specified countdown.  After that, the mount counts down its time like an egg timer.  If the timer goes off, the mount parks.  It is APCC’s job to keep resetting the timer before it goes off.  The default timer is set for 1 minute, but APCC generally resets it every 8 or 9 seconds, so the countdown never even gets close to going off.
  • The MGBox ‘s GPS times are consistently off by a couple seconds compared to the PC time throughout the log.  Polling occurs every second.  I never found a discrepancy anywhere close to 2 minutes 48 seconds.
  • After initially setting the time in the GTOCP5, there were no corrections to the mount time sent until AFTER the event, and that was a 1 second correction.  If the PC had corrected its time, an equivalent change would have been sent to the mount within a few seconds.  There was no correction sent to the mount. 
  • Computer time was about 2.9 seconds ahead of the MGBox’s GPS time before the glitch (fancy technical term).  It was about 3.4 seconds ahead after the glitch.  That certainly wasn’t a correction to the time.
I am not an expert using Windows Event Viewer, but I would like to see whether it confirms my suspicions.
HH


Re: Heads-up on possible abrupt parking problem #Absolute_Encoders #Mach2GTO #APCC

Eric Weiner
 

Very subtle problem. Nice troubleshooting. Thanks for sharing. 


Re: Heads-up on possible abrupt parking problem #Absolute_Encoders #Mach2GTO #APCC

Roland Christen
 

Just to clarify the role that clock time plays: The clock time is only used at the beginning of the session to find a sky object on the RA axis. Once the session has begun, the clock plays no role in pointing or tracking. On the Mach2, the clock time plays no role in the park positions either. So, updating the clock during a session has no benefit whatsoever, and should not be done by external software.

Roland

-----Original Message-----
From: David Johnson <dajohns37@...>
To: main@ap-gto.groups.io
Sent: Mon, Aug 2, 2021 4:20 pm
Subject: [ap-gto] Heads-up on possible abrupt parking problem #Mach2GTO #APCC #Absolute_Encoders

I want to describe an issue I’ve had with my Mach2 so that others who might run into it can avoid the frustrations I’ve had.  I want to emphasize that, as with many intermittent issues, it was hard to diagnose and also hard to be sure it’s solved, but, thanks to help from Howard at A-P, I think we have an answer.

I’ll skip some details, but what was happening was that sometimes (and I’d say it was about half the evenings I imaged and randomly occurring), during data acquisition using SGPro and APCC (with tracking correction from an APPM model, although I don’t think that matters), APCC would suddenly just park the mount.  Fortunately, I usually caught this and avoided wasting an entire clear night.  However, you can imagine it was very frustrating because I never knew when it was going to happen, although once it was fixed it never happened again during that night’s work.  This is an important point.

What Howard’s investigation showed was that there was the same amount of time missing (almost three minutes last night, for example) in both the APPC log and the SGPro log.  Once again skipping some details, what I think may have happened is that my MGBox was queried, the system clock for the computer was incorrect and then corrected based on the GPS time from the MGBox, and then APCC thought it had lost communication with the mount for that period of time, which was greater than the default one-minute period,  and did a safety park.  Therefore, once it happens and the clock is correct, it wouldn’t happen again.  An obvious solution is for me to make sure the system clock is correct and/or increase the amount of time before a safety park (although I realize this can increase risk).

I’ll follow-up if the problem persists.  Thanks to Howard and the A-P team for their help with a frustrating problem.

--
Roland Christen
Astro-Physics


Heads-up on possible abrupt parking problem #Absolute_Encoders #Mach2GTO #APCC

David Johnson
 

I want to describe an issue I’ve had with my Mach2 so that others who might run into it can avoid the frustrations I’ve had.  I want to emphasize that, as with many intermittent issues, it was hard to diagnose and also hard to be sure it’s solved, but, thanks to help from Howard at A-P, I think we have an answer.

I’ll skip some details, but what was happening was that sometimes (and I’d say it was about half the evenings I imaged and randomly occurring), during data acquisition using SGPro and APCC (with tracking correction from an APPM model, although I don’t think that matters), APCC would suddenly just park the mount.  Fortunately, I usually caught this and avoided wasting an entire clear night.  However, you can imagine it was very frustrating because I never knew when it was going to happen, although once it was fixed it never happened again during that night’s work.  This is an important point.

What Howard’s investigation showed was that there was the same amount of time missing (almost three minutes last night, for example) in both the APPC log and the SGPro log.  Once again skipping some details, what I think may have happened is that my MGBox was queried, the system clock for the computer was incorrect and then corrected based on the GPS time from the MGBox, and then APCC thought it had lost communication with the mount for that period of time, which was greater than the default one-minute period,  and did a safety park.  Therefore, once it happens and the clock is correct, it wouldn’t happen again.  An obvious solution is for me to make sure the system clock is correct and/or increase the amount of time before a safety park (although I realize this can increase risk).

I’ll follow-up if the problem persists.  Thanks to Howard and the A-P team for their help with a frustrating problem.


Re: Possible CP5 Wi-Fi module failure #WiFi

Roland Christen
 

No problem. I ran into a similar issue at my recent Hawaii outing. My WiFi would not connect. I knew it wasn't the WiFi that was not working, i knew instead that my brain wasn't. After configuring my laptop properly everything worked.

Rolando

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

Roland,

After sending that first group.io call for help I spent several hours of testing and tweaking the CP5 and my home Wi-Fi network settings.  I found what seems to be a very stable solution. 

No offense was meant by the “toast” comment. It was simply that it had been working fine for several months, then starting 2 nights ago I couldn’t connect to either my home network or the CP5 access point no matter what I tried. There have been no changes to my home network, so it sure did manifest like it was Wi-Fi module failure. It wasn’t, and everything works great now. 

I shared my experience and settings with everyone since I’ve read on the boards about others who had similar, if not identical Wi-Fi connections issues with the Mach2 which A-P stated they were unable to recreate in the lab. 

Cheers,
Eric 


On Aug 2, 2021, at 10:36, Roland Christen via groups.io <chris1011@...> wrote:


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

--
Roland Christen
Astro-Physics


Re: Possible CP5 Wi-Fi module failure #WiFi

Eric Weiner
 

Roland,

After sending that first group.io call for help I spent several hours of testing and tweaking the CP5 and my home Wi-Fi network settings.  I found what seems to be a very stable solution. 

No offense was meant by the “toast” comment. It was simply that it had been working fine for several months, then starting 2 nights ago I couldn’t connect to either my home network or the CP5 access point no matter what I tried. There have been no changes to my home network, so it sure did manifest like it was Wi-Fi module failure. It wasn’t, and everything works great now. 

I shared my experience and settings with everyone since I’ve read on the boards about others who had similar, if not identical Wi-Fi connections issues with the Mach2 which A-P stated they were unable to recreate in the lab. 

Cheers,
Eric 


On Aug 2, 2021, at 10:36, Roland Christen via groups.io <chris1011@...> wrote:


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
 

If it's good, don't fix what works. Wink

Rolando



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

Roland,

Last night I adjusted the back stop using the lightest pressure I could, barely touching the backstop with one finger, and gently tightening the two screws.  After doing this, all the free play in the RA axis was gone.  I then did a few slow (12x) test slews and then a couple of 600x slews and all seemed fine.

After reading your reply today I loosened the RA backstop screws again and with only gravity holding the backstop down and no finger pressure at all tightened them.  The free play in RA is still gone.  

Do I still need to contact George, or should the mount be good to go?

Thanks,
Scott

--
Roland Christen
Astro-Physics


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

skester@...
 

Roland,

Last night I adjusted the back stop using the lightest pressure I could, barely touching the backstop with one finger, and gently tightening the two screws.  After doing this, all the free play in the RA axis was gone.  I then did a few slow (12x) test slews and then a couple of 600x slews and all seemed fine.

After reading your reply today I loosened the RA backstop screws again and with only gravity holding the backstop down and no finger pressure at all tightened them.  The free play in RA is still gone.  

Do I still need to contact George, or should the mount be good to go?

Thanks,
Scott


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

8301 - 8320 of 88085