Date   

Re: APCC feature request - Get time from mount

Howard Hedlund
 

The MGBOX2 has its own software app.  I am not positive of this, but I believe that this software cannot run simultaneously with a program like APCC.  However, The MGBOX2 could be used at the start of a session to calibrate the computer system clock.  Then, shut down the MGBOX2 software and start APCC.  APCC will then be getting the same time source that was used for the PC.


Re: Final Verdict: Mach 2 Torture Test

Bill Long
 

AG Optical 12.5" Truss iDK. Camera was a FLI PL16803, CFW5-7, NiteCrawler, etc.

All in all about 70lbs fully loaded OTA. 17" tall, 45" in length at critical focus.


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Ram <ramviswanathan@...>
Sent: Tuesday, October 5, 2021 11:34 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Final Verdict: Mach 2 Torture Test
 
Bill, what scope did you put on the mount?
Thanks for your report. 
-Ram


On Oct 5, 2021, at 10:43 PM, Bill Long <bill@...> wrote:


Hello again friends,

Quick update -- 10 Micron said no go on this load on the 1000 mount of theirs. While I will not copy and paste their entire response here (as some people seem to think that is poor form) they cited the mount would not be able to perform well under that load, would be beyond its limit, and would overall suffer - especially unguided. 

So, there you have it folks. AP not only stood by me in the load I wanted to try out -- but they are also one upping me with the 12" Mak system on the Mach 2. 

Make of that, what you wish.

-Bill 


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Bill Long <bill@...>
Sent: Saturday, October 2, 2021 8:50 PM
To: AP-GTO Groups.io <ap-gto@groups.io>
Subject: [ap-gto] Final Verdict: Mach 2 Torture Test
 

[Edited Message Follows]

Hello friends,
 
It was finally time to bring the mount and telescope inside. The weather has been very poor. Rainy and very high humidity as of late. I finally pulled in the gear. It sat outside from July 25 - October 2, with 104 pounds of counterweights, 70 pounds of scope and accessories, with an OTA 17" in height, and 45" in length at critical focus. On the AP Mach 2 graph this is 5 pounds into the RED. 
 
The rig operated at seeing limited tracking and guiding at all times during the 60 day onslaught. Not once was there ever a problem with the mount in terms of the load, or in terms of its inability to meet the demands I placed on it. I want everyone reading this to be mindful that the mount sat for 2 months on a set of 2x4 piece of wood suspended 2 stories in the air (aka my deck).  The deck is old, the wood is worn, and in some places there are holes in the deck. (I do plan to get it replaced next week with some better material). I would not be wrong if I assumed other people are imaging in much better environments than I. Still, even in this environment the mount did exactly what it was asked to do. Be invisible. 
 
I did get some series of mild winds, roughly 4-5MPH sustained, with some 10MPH gusts. The guide graph did show some response to those conditions, but the images were just as good as those without the wind. So, in mild conditions, 2 stories in the air, the system seems to work fine, even under the incredible load I put it under and some, mild winds trying to encroach. 
 
So, in the end I think this mount punches significantly higher than its class would dictate. I have no intentions of posting this same review on CN, as I think it would get drowned out by people fan-boying 10 Micron mounts. That is not really a discussion I want to have, nor want to see unfold. Rather, I would prefer this to be a tale to my friends here, of how I took AP's new hot mount and put it up against the odds I did not think were possible for it.  I would also prefer this to be the time where people sat back saying, wow -- that is a remarkable achievement for AP. Especially considering the big bet they put on selling every mount with encoders. I think that was a wise decision, and I hope others with the mount agree.
 
In closing, I am more than happy with my purchase. But more importantly, I am happy that the mount Roland really wanted to be the next big thing -- is the next big thing. There is no other mount in its class that comes close to it. I believe it to be the shining jewel of A-P engineering, and while the wait list might be long -- trust me -- it is well worth the wait.
 
-Bill
 
PS: I sent 10 micron a sales request asking if they would support the scope and stuff I used on the Mach 2, on their 1000 class mount (the Mach 2 competitor) once I hear back from them I will share it with you. I asked Roland the same question before I tested this out, and he was confident the Mach 2 could do it. And, to no surprise, he was right! 🙂


Re: Final Verdict: Mach 2 Torture Test

Ram
 

Bill, what scope did you put on the mount?
Thanks for your report. 
-Ram


On Oct 5, 2021, at 10:43 PM, Bill Long <bill@...> wrote:


Hello again friends,

Quick update -- 10 Micron said no go on this load on the 1000 mount of theirs. While I will not copy and paste their entire response here (as some people seem to think that is poor form) they cited the mount would not be able to perform well under that load, would be beyond its limit, and would overall suffer - especially unguided. 

So, there you have it folks. AP not only stood by me in the load I wanted to try out -- but they are also one upping me with the 12" Mak system on the Mach 2. 

Make of that, what you wish.

-Bill 


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Bill Long <bill@...>
Sent: Saturday, October 2, 2021 8:50 PM
To: AP-GTO Groups.io <ap-gto@groups.io>
Subject: [ap-gto] Final Verdict: Mach 2 Torture Test
 

[Edited Message Follows]

Hello friends,
 
It was finally time to bring the mount and telescope inside. The weather has been very poor. Rainy and very high humidity as of late. I finally pulled in the gear. It sat outside from July 25 - October 2, with 104 pounds of counterweights, 70 pounds of scope and accessories, with an OTA 17" in height, and 45" in length at critical focus. On the AP Mach 2 graph this is 5 pounds into the RED. 
 
The rig operated at seeing limited tracking and guiding at all times during the 60 day onslaught. Not once was there ever a problem with the mount in terms of the load, or in terms of its inability to meet the demands I placed on it. I want everyone reading this to be mindful that the mount sat for 2 months on a set of 2x4 piece of wood suspended 2 stories in the air (aka my deck).  The deck is old, the wood is worn, and in some places there are holes in the deck. (I do plan to get it replaced next week with some better material). I would not be wrong if I assumed other people are imaging in much better environments than I. Still, even in this environment the mount did exactly what it was asked to do. Be invisible. 
 
I did get some series of mild winds, roughly 4-5MPH sustained, with some 10MPH gusts. The guide graph did show some response to those conditions, but the images were just as good as those without the wind. So, in mild conditions, 2 stories in the air, the system seems to work fine, even under the incredible load I put it under and some, mild winds trying to encroach. 
 
So, in the end I think this mount punches significantly higher than its class would dictate. I have no intentions of posting this same review on CN, as I think it would get drowned out by people fan-boying 10 Micron mounts. That is not really a discussion I want to have, nor want to see unfold. Rather, I would prefer this to be a tale to my friends here, of how I took AP's new hot mount and put it up against the odds I did not think were possible for it.  I would also prefer this to be the time where people sat back saying, wow -- that is a remarkable achievement for AP. Especially considering the big bet they put on selling every mount with encoders. I think that was a wise decision, and I hope others with the mount agree.
 
In closing, I am more than happy with my purchase. But more importantly, I am happy that the mount Roland really wanted to be the next big thing -- is the next big thing. There is no other mount in its class that comes close to it. I believe it to be the shining jewel of A-P engineering, and while the wait list might be long -- trust me -- it is well worth the wait.
 
-Bill
 
PS: I sent 10 micron a sales request asking if they would support the scope and stuff I used on the Mach 2, on their 1000 class mount (the Mach 2 competitor) once I hear back from them I will share it with you. I asked Roland the same question before I tested this out, and he was confident the Mach 2 could do it. And, to no surprise, he was right! 🙂


Re: Final Verdict: Mach 2 Torture Test

Bill Long
 

Hello again friends,

Quick update -- 10 Micron said no go on this load on the 1000 mount of theirs. While I will not copy and paste their entire response here (as some people seem to think that is poor form) they cited the mount would not be able to perform well under that load, would be beyond its limit, and would overall suffer - especially unguided. 

So, there you have it folks. AP not only stood by me in the load I wanted to try out -- but they are also one upping me with the 12" Mak system on the Mach 2. 

Make of that, what you wish.

-Bill 


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Bill Long <bill@...>
Sent: Saturday, October 2, 2021 8:50 PM
To: AP-GTO Groups.io <ap-gto@groups.io>
Subject: [ap-gto] Final Verdict: Mach 2 Torture Test
 

[Edited Message Follows]

Hello friends,
 
It was finally time to bring the mount and telescope inside. The weather has been very poor. Rainy and very high humidity as of late. I finally pulled in the gear. It sat outside from July 25 - October 2, with 104 pounds of counterweights, 70 pounds of scope and accessories, with an OTA 17" in height, and 45" in length at critical focus. On the AP Mach 2 graph this is 5 pounds into the RED. 
 
The rig operated at seeing limited tracking and guiding at all times during the 60 day onslaught. Not once was there ever a problem with the mount in terms of the load, or in terms of its inability to meet the demands I placed on it. I want everyone reading this to be mindful that the mount sat for 2 months on a set of 2x4 piece of wood suspended 2 stories in the air (aka my deck).  The deck is old, the wood is worn, and in some places there are holes in the deck. (I do plan to get it replaced next week with some better material). I would not be wrong if I assumed other people are imaging in much better environments than I. Still, even in this environment the mount did exactly what it was asked to do. Be invisible. 
 
I did get some series of mild winds, roughly 4-5MPH sustained, with some 10MPH gusts. The guide graph did show some response to those conditions, but the images were just as good as those without the wind. So, in mild conditions, 2 stories in the air, the system seems to work fine, even under the incredible load I put it under and some, mild winds trying to encroach. 
 
So, in the end I think this mount punches significantly higher than its class would dictate. I have no intentions of posting this same review on CN, as I think it would get drowned out by people fan-boying 10 Micron mounts. That is not really a discussion I want to have, nor want to see unfold. Rather, I would prefer this to be a tale to my friends here, of how I took AP's new hot mount and put it up against the odds I did not think were possible for it.  I would also prefer this to be the time where people sat back saying, wow -- that is a remarkable achievement for AP. Especially considering the big bet they put on selling every mount with encoders. I think that was a wise decision, and I hope others with the mount agree.
 
In closing, I am more than happy with my purchase. But more importantly, I am happy that the mount Roland really wanted to be the next big thing -- is the next big thing. There is no other mount in its class that comes close to it. I believe it to be the shining jewel of A-P engineering, and while the wait list might be long -- trust me -- it is well worth the wait.
 
-Bill
 
PS: I sent 10 micron a sales request asking if they would support the scope and stuff I used on the Mach 2, on their 1000 class mount (the Mach 2 competitor) once I hear back from them I will share it with you. I asked Roland the same question before I tested this out, and he was confident the Mach 2 could do it. And, to no surprise, he was right! 🙂


Re: Is this tilt in the image train?

Tom Blahovici
 

11 months. That's nuts!


Re: Is this tilt in the image train?

Joseph Beyer
 

Looks great!  Glad to see you've got it fixed and are ready to go.  I got the CTU on my telescope and adjusted fairly well.  Just like you I was surprised how little movement the camera needed to flatten the field.  Now all I'm waiting on are clear skies.  


Re: Is this tilt in the image train?

Andy Ermolli
 

Glad you got it sorted. 
Bill is right, my FSQ went back to Japan. It took 11 months since I sent it to Huston to the time I got it back, it was worth it. I suspect that there are many FSQ's out there that need to be collimated. In my case I believe the Pezval elements (G3 and G4?) needed to be adjusted and that can not be done in Houston.


Re: Is this tilt in the image train?

Roland Christen
 

Great!

Rolando



-----Original Message-----
From: Tom Blahovici <tom.va2fsq@...>
To: main@ap-gto.groups.io
Sent: Tue, Oct 5, 2021 7:40 pm
Subject: Re: [ap-gto] Is this tilt in the image train?

Well my first shot at this was pretty poor. I had very inconsistent results, that overshot what they should be been when I adjusted the tilt plate. They they went in the wrong direction! I finally got fed up and put everything back to flush with the scope.
I got to thinking though. It really was a very very slight adjustment to the tilt screws that was needed. I was also locking down the push pull screws quite a bit. 
So I though perhaps the tightening is distorting the actual situation. So I tightened up just the pull screws which put the tilt plates flush with the telescop and just slightly tightened the opposing screws.
Result? My stars are perfect across the whole field.
So what I though was tilt or miscollimation, turned out to be a distorted field due to overtightrning the adjustment screws.
I'm back in business!

--
Roland Christen
Astro-Physics


Re: APPM + ASTAP - Inaccurate FOV

Sébastien Doré
 

Hi Ray,

it would be easy to include a checkbox in APPM's ASTAP config to exclude the -fov argument in the command line for use withapplications like NINA that provide the necessary FITS header values.
I couldn't agree more ! Thanks for considering it. I feel we are getting on the same page now. I'm sure most APPM + ASTAP user would benefit from that too (even without noticing it), be it an automatic setting or not.

Thanks for bearing with me (us) on this.

Sébastien.


Re: Is this tilt in the image train?

Tom Blahovici
 

Well my first shot at this was pretty poor. I had very inconsistent results, that overshot what they should be been when I adjusted the tilt plate. They they went in the wrong direction! I finally got fed up and put everything back to flush with the scope.
I got to thinking though. It really was a very very slight adjustment to the tilt screws that was needed. I was also locking down the push pull screws quite a bit. 
So I though perhaps the tightening is distorting the actual situation. So I tightened up just the pull screws which put the tilt plates flush with the telescop and just slightly tightened the opposing screws.
Result? My stars are perfect across the whole field.
So what I though was tilt or miscollimation, turned out to be a distorted field due to overtightrning the adjustment screws.
I'm back in business!


Re: APPM + ASTAP - Inaccurate FOV

ap@CaptivePhotons.com
 

Ray said:

 

  • I'm also curious about the "historical" aspect of the plate solve and
  • sync.  That uses the user's declare scale information right?  Maybe avoid this whole mess and just apply the historical solution to the run as well?

 

  • Historically, users calculated camera image scale based on manufacturers' specs (e.g. 100mm F/7 should be 700mm focal length).
  • However, that specification was rarely exact, and in some cases, it was pretty far off.

 

  • So, when a new user of APPM does a mapping run, the image-scale is assumed to be inaccurate, thus the reason for the "Refine image scale" checkbox. So for mapping runs, APPM "let" the plate solver apps use image information in the FITS headers, and would update the image scale appropriately.

 

  • However, once image-scale has been established and saved in APPM, the "Plate Solve Now", etc. buttons simply used the previously established image scale, instead of assuming it might be wrong.

 

Interesting, and it makes sense.  Thank you.

 

Though not completely sure why the same logic can’t extend to the point mapping run.

 

But we’re talking about 2 seconds or so per point.  If this is what you feel necessary to make it compatible with old systems, I have argued long enough (or too long).   Or maybe inspiration will strike to make it even more robust.


Thank you for the patience.


Re: APCC feature request - Get time from mount

David Diaz <night.skywatcher@...>
 

How about this device?

I thought it was a highly recommended product for APCC

MGBOX2

—DD


Re: Seeking CP3 Control Box with V2 Chip

fernandorivera3
 

Chris, "out with the old, in with the new" regarding a PEC curve.

Fernando


Re: APPM + ASTAP - Inaccurate FOV

Ray Gralak
 

Or did I misunderstand and APPM doesn't read the headers before plate solving?
There are several different paths that APPM uses for plate-solving. APPM reads the FITS headers but doesn't parse and use every
value in every case.

I'm also curious about the "historical" aspect of the plate solve and sync. That uses the user's declare scale
information right? Maybe avoid this whole mess and just apply the historical solution to the run as well?
Historically, users calculated camera image scale based on manufacturers' specs (e.g. 100mm F/7 should be 700mm focal length).
However, that specification was rarely exact, and in some cases, it was pretty far off.

So, when a new user of APPM does a mapping run, the image-scale is assumed to be inaccurate, thus the reason for the "Refine image
scale" checkbox. So for mapping runs, APPM "let" the plate solver apps use image information in the FITS headers, and would update
the image scale appropriately.

However, once image-scale has been established and saved in APPM, the "Plate Solve Now", etc. buttons simply used the previously
established image scale, instead of assuming it might be wrong.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of ap@...
Sent: Tuesday, October 5, 2021 2:58 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM + ASTAP - Inaccurate FOV

Ray wrote:

Still, it would be easy to include a checkbox in APPM's ASTAP config to exclude the -fov argument in the
command line for use with applications like NINA that provide the necessary FITS header values.

When I saw the error message, it looks like APPM is reading the file headers anyway, could it not just notice if
it has everything, and if not use -fov 0, if so omit?

Or did I misunderstand and APPM doesn't read the headers before plate solving?

I'm also curious about the "historical" aspect of the plate solve and sync. That uses the user's declare scale
information right? Maybe avoid this whole mess and just apply the historical solution to the run as well?

At least now we all understand, straight from the author, how it works. Thanks for being patient through that
process.




Re: Seeking CP3 Control Box with V2 Chip

Chris White
 

On Tue, Oct 5, 2021 at 05:36 PM, Roland Christen wrote:
Make a new curve. The old ones wear out with use.
 
Rolando
But that old pair of tattered blue jeans is still my most comfortable pair of pants!

Thanks Roland!!


Re: APPM + ASTAP - Inaccurate FOV

ap@CaptivePhotons.com
 

Ray wrote:

Still, it would be easy to include a checkbox in APPM's ASTAP config to exclude the -fov argument in the command line for use with applications like NINA that provide the necessary FITS header values.
When I saw the error message, it looks like APPM is reading the file headers anyway, could it not just notice if it has everything, and if not use -fov 0, if so omit?

Or did I misunderstand and APPM doesn't read the headers before plate solving?

I'm also curious about the "historical" aspect of the plate solve and sync. That uses the user's declare scale information right? Maybe avoid this whole mess and just apply the historical solution to the run as well?

At least now we all understand, straight from the author, how it works. Thanks for being patient through that process.


Re: APPM + ASTAP - Inaccurate FOV

Ray Gralak
 

Hi Dale,

Since APPM works with a number of different camera applications, including some old applications like CCDSoft and AstroArt, APPM
cannot assume that the necessary keywords to calculate image scale will be placed in the FITS header.

So, I asked Han what APPM should send if it cannot be sure if all FITS keywords will be present, and his answer was "-fov 0".

Still, it would be easy to include a checkbox in APPM's ASTAP config to exclude the -fov argument in the command line for use with
applications like NINA that provide the necessary FITS header values.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Dale Ghent
Sent: Tuesday, October 5, 2021 2:29 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM + ASTAP - Inaccurate FOV


On Oct 5, 2021, at 16:45, Ray Gralak <iogroups@...> wrote:

Hi Linwood,

I see you posted a question on this topic on the ASTAP forum. Thank you for doing that. I was going to
post there this evening, but you beat me to it. It will be interesting to see what Han says.

Heh, ok. So hopefully not a case of too many cooks in the kitchen, but Han is also on the NINA discord so I
asked him directly there about this question.

(I've been catching up on my email and day job work and have only been able to glance at this thread so far)

Here's what Han says regarding the "-fov 0" option:

-fov 0 was invented to find the fov. Sharcap is using it. If the last solve was good no -fov will be specified
for next image. If it fails it tries again with -fov 0. So it is a little tricky. I would suggest to use it only the first
time. After that test, i would prefer to keep it fixed. Furthermore it is good for (using with) unspecified
PNG/Jpeg files. I would suggest using -fov 0 only for a setup. Once the correct fov is found keep it fixed so
specified in the header or specified by -fov x

it was created because I got all kind of images from users with didn't solve due to the wrong fov. The -fov
0 interation loop was faster then dropping the image at nova.astrometry.net. The next step in direction of fully
blind solving was to simply to specify 180 degrees search.

So, running astap.exe with '-fov 0' should be done only if the FOV of the image is truly unknown. It's a kind of
half-blind solve where you might know the general coordinates of the image but not the FOV.

Han mentioned:

Fully blind solving is "-fov 0 -r 180".
Which would make sense, as a "full" blind solve means that one doesn't know the FOV of the image or its
coordinates, so one would ask ASTAP to figure out the FOV as well as search the entire hemisphere for a
solution. It's expected that the discovered FOV is saved for future use in that case.

In NINA, we build the FOV from the pixel size, image dimension, and the user-supplied effective focal length
of their setup. We supply the height component of this as the argument to the -fov option every time we run
ASTAP. This same information is put into the FITS headers of the image files NINA generates, so the
information is available to APPM as well if it reads those keywords. This means that APPM could always
supply the correct FOV value provided that the user specified a reasonably accurate focal length. ASTAP will
actually put a WARNING keyword into the .wcs file it generates to notify the user that, given an accurate pixel
size and image dimension, that their focal length is actually different from what they specified.

The relevant keywords are XPIXSZ/YPIXSZ, NAXIS1/NAXIS2, and FOCALLEN. Binning shouldn't need to be
considered because any binning is going to see the XPIXSZ and YPIXSZ values multiplied by the bin factor.

/dale


Re: APPM + ASTAP - Inaccurate FOV

Sébastien Doré
 
Edited

Thanks for chiming in on this Dale! Much appreciated.

Sébastien


Re: Seeking CP3 Control Box with V2 Chip

Roland Christen
 

Make a new curve. The old ones wear out with use.

Rolando

-----Original Message-----
From: Chris White <chris.white@...>
To: main@ap-gto.groups.io
Sent: Tue, Oct 5, 2021 3:53 pm
Subject: Re: [ap-gto] Seeking CP3 Control Box with V2 Chip

I'm thrilled to report that the loaner CP4 has arrived from AP.  My damaged unit probably passed it in the mail over the weekend... lol. 

I installed the loaner CP4 and all is well.  The mount behaves as it should.  It was interesting to see that there has been a case design change with the CP4.  Mine had the dovetails on the short ends of the case, while the loaner is on the long ends of the case.  I had to scoot the CP mount down the RA axis to the lower bolt mount only otherwise it hit the RA motor box.  I'm guessing that the redesign was for later generation mounts than the 900GTO?  In any event it's a non-issue.

I am curious about my PemPro Curve though.  Is this stored in the CP unit?  If so I imagine I will need to generate a new PEC curve for the loaner box.  I didnt think to make a backup of the PEC curve and if it is on the controller I sent back I'll have to see if AP can download that for me so I can reload. 

That leads me to another question, would the old curve even be valid anymore? In my testing the mount did wander a bit after the motor stalls with the old box and this was not registered by the driver.  I didnt rotate the spur gear manually or anything, so maybe that doesnt matter and the old curve would still work?

A huge thank you to AP for lending me this CP4 while mine is back for repairs! Wonderful customer service!!!

--
Roland Christen
Astro-Physics


Re: APPM + ASTAP - Inaccurate FOV

Sébastien Doré
 

Ray,

I can confidently say that it would be an improvement to ASTAP if it made its initial guess using FITS image parameters when they are available. It does this by default anyway. I cannot believe you would argue against this. LOL!!
You got me all wrong! I am not arguing against that (using FiTS header data) at all. I am arguing FOR that, just like you.

Thing is, the way APPM currently calls ASTAP exactly prevents what you and I are vouching for... Unlike all other astro software I have tested ASTAP with.

Sigh, I don’t know how else I can explain this... I just thought it would be interesting to report that even if ASTAP solves what APPM throws at it, it does it inefficiently right now, because of the way it is called by APPM.

Sébastien

5081 - 5100 of 86940