|
Re: APPM with ASI6200 and TSX Imagelink - bogus image data
ap@CaptivePhotons.com
@Geoffrey Collins wrote:
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 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.
|
|
|
|
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?
HH
|
|
|
|
Re: Heads-up on possible abrupt parking problem
#Absolute_Encoders
#Mach2GTO
#APCC
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?
HH
|
|
|
|
Re: Heads-up on possible abrupt parking problem
#Absolute_Encoders
#Mach2GTO
#APCC
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:
-- Roland Christen Astro-Physics
|
|
|
|
Re: Possible CP5 Wi-Fi module failure
#WiFi
Roland,
toggle quoted messageShow quoted text
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:
|
|
|
|
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.
 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
Ø 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:
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:
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
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:
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.
Sure. I did these steps:
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:
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.
Sure. I did these steps:
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. --
|
|
|
