Date   

Re: GTOCP4 Control Box

Seb@stro
 

Thanks Tom!


De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de Tom Blahovici <tom.va2fsq@...>
Envoyé : 27 février 2021 14:03
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] GTOCP4 Control Box
 
Hi
It's the Intel NUC8i3BEK.  The one I bought had a 240Gb SSD.  Not enough for an ASI6200 so I upgraded to 1Tb.
Tom


Re: APPM with Dome Questions

Shane Ramotowski
 

Thanks Terry.  In the "Active" case it _is_ APPM that slews the dome to the OTA.  That is the crux of my question!

- Shane

On 2/27/2021 11:28 AM, Terry White wrote:
Ditto to what Ray said. You should enter all the dome and OTA parameters in the program that directly slews your dome to the OTA, not APPM.
--
Shane Ramotowski
kor@cotse.net
https://www.kor-astro.net


Re: APPM with Dome Questions

Shane Ramotowski
 

Ray, thanks for the reply, but I don't really see anything that will help.


APPM's "Active mode" sends the telescope's destination coordinates to the dome ASCOM driver. In this case, it is the responsibility of the driver or intermediate
application to translate the RA/Dec coordinates to the appropriate dome position.
Hmmm, so how does that work?  What part of the ASCOM dome API would that be? <https://ascom-standards.org/Help/Developer/html/T_ASCOM_DriverAccess_Dome.htm>

I am definitely returning false fort the CanSlave and Slaved properties, since there is no hardware-based slaving capability in the dome controller.  And I don't see way to "send the telescope's destination coordinates" to the ASCOM driver.

The call that the ASCOM driver receives from APPM is "SlewToAzimuth()" but I think you are basing that azimuth on the center of the dome rather than the position of the telescope, which can be significantly different--consider the initial slew to zenith in which the RA axis rotates west and level and the DEC axis point strait up.  The telescope is several inches West of the center of the mount.  From what I understand, if you are going to use SlewToAzimuth(), you need to consider this.

If you look at ASCOM's DeviceHub, written by Rick and Pete, who answer most of the dome-related questions posted to the ASCOM Driver and Application Development Support Forum, it has a whole section for dome and mount geometry in it's setup section to allow slaving.

In "Passive mode" APPM waits for the dome to finish slewing by
polling the dome's driver (or intermediate application).

That is exactly what I expected.  What should I set the two passive values to to ensure that the imaging doesn't start for, say, 1 minute after the scope stops slewing?  Or am I not understanding the meaning of those two fields and their documentation in the manual?

Here is a log excerpt from one of my attempts last night.  Under Settings->Dome Settings, Passive is selected, "Delay before starting dome slew checking" is set to 30 seconds and "Settle time after dome stops slewing" is set to 10 seconds.

0467221 2021-02-26 20:46:21.965:       Info,   State Machine, Entering State=SlewNext
0467222 2021-02-26 20:46:22.103:       Info,        SlewNext, Starting Slew to Point 3 RA: 08h 30m 06.56s, HA: -01h 20m 00.00s, Dec: -10° 00' 00.0")
0467223 2021-02-26 20:46:22.105:       Info,       Slew Next, East=True, Dec=-10, HA=-1.33333333333333, MerDelay=-0.25, MerOffset=0
0467224 2021-02-26 20:46:22.105:       Info,        Meridian, Setting Meridian Delay to -0.25 (-00h 15m 00.00s)
0467225 2021-02-26 20:46:22.144:       Info,       SlewAsync, Begin UnSAFE Slew to RA/Dec:   8.501824 / -10.000000 ( 08h 30m 06.56s / -10° 00' 00.0")
0467226 2021-02-26 20:46:22.215:       Info,   State Machine, Entering State=PreSlewing
0467227 2021-02-26 20:46:25.482:       Info,   State Machine, Entering State=Slewing
0467228 2021-02-26 20:46:30.722:       Info,   State Machine, Entering State=StartSettle
0467229 2021-02-26 20:46:30.741:       Info,     StartSettle, Starting Settle wait time
0467230 2021-02-26 20:46:30.970:       Info,   State Machine, Entering State=WaitSettle
0467231 2021-02-26 20:46:32.974:       Info,      WaitSettle, Settling Time Complete
0467232 2021-02-26 20:46:33.022:       Info,      WaitSettle, Finished Slew to Point 3
0467233 2021-02-26 20:46:33.022:       Info,      WaitSettle, RA/Dec:   8.501833 / -10.000000 ( 08h 30m 06.60s /  -10° 00' 00.0")
0467234 2021-02-26 20:46:33.022:       Info,      WaitSettle, HA/Dec:  -1.329942 / -10.000000 (-01h 19m 47.79s /  -10° 00' 00.0")
0467235 2021-02-26 20:46:33.226:       Info,   State Machine, Entering State=StartImage
0467236 2021-02-26 20:46:33.260:       Info,   State Machine, Starting Exposure, Duration=5 LST=7.17191416666667 (07h 10m 18.89s)
0467237 2021-02-26 20:46:33.260:       Info,   State Machine, LST mid image=7.1727475 (07h 10m 21.89s)
0467238 2021-02-26 20:46:33.260:       Info,  StartTakeImage, Sequence Generator Pro: Binning=1, Subframe Type: 0, Duration=5, IsDarkFrame=False

The total time between the start of the point's processing and start of it's imaging is about 12 seconds.  Shouldn't that be at least 40 seconds to allow the dome delay and settle times to happen?  What am I misunderstanding?

The dome controller and ASCOM driver do handle Slewing property correctly, returning TRUE from the time that the slewToAzimuth() is issued until the dome is stopped at the requested position, then returning FALSE until the next slew is issued  Sometimes, DeviceHub or SGP will end up issuing more than one slew to get the dome to the final position.  The slaving software notices that the telescope has moved and starts an azimuth slew to where is while the telescope is still moving.  Once the dome arrives at that position, another azimuth slew to get to where the telescope finally stopped.  Last night, the longest time that such multiple slews took was about 20 seconds.  That is why I set the "Delay before starting dome slew checking" to 30 seconds.  I though that would make APPM not even check for a dome slew until the dome was in place and had stopped moving.  Instead, it seemed to have made no difference: the imaging started almost as soon as the telescope arrived at its position.

Thanks - Shane


On 2/27/2021 10:06 AM, Ray Gralak wrote:
Hi Shane,

APPM's "Active mode" sends the telescope's destination coordinates to the dome ASCOM driver. In this case, it is the responsibility of the driver or intermediate application to translate the RA/Dec coordinates to the appropriate dome position.

In "Passive mode" APPM waits for the dome to finish slewing by polling the dome's driver (or intermediate application).

So, it seems that your dome's ascom driver (or intermediate application) may not be correctly indicating when the dome is slewing.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski
Sent: Friday, February 26, 2021 9:19 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM with Dome Questions

Hi gang,

I am the proud owner of a brand new (well 2 weeks) Mach2 and tried to do
my first APPM model tonight. I'm having problems with the dome control
and hope someone can point in the right direction.

My observatory is a ClearSkys (I don't think they are around anymore) 8
ft dome. The pier is centered and the bottom of the mount is just about
even with the bottom of the dome. The rotation control is homemade (my
COVID quarantine project) and works very will with both ASCOM DeviceHub
and SGP. I'm using SGP for image capture and plate solve.

I can't figure out how to set up APPM to control the dome properly. If I
use "Active" in the "AP Point Mapper - Dome Settings" panel, APPM seems
to do it's calculations based on the center of the dome instead of where
the telescope is. This is not surprising since I can't seem to find any
where in the program or the documentation to set the mount and telescope
geometry. I suppose, since APCC knows that I'm using a Mach2, it
_could_ already know roughly how far from the center of the RA/DEC axes
intersection the bottom of my telescope is. But I don't see anyway that
it could know where the center of my OTA is. I really don't think it's
using the parameters from 3D view; I haven't set that up, but the
default is a much larger diameter telescope than mine.

Anyway, when I use "Active", I end up imaging across the edge of the
slot because the slot is positioned for the center of the mount instead
of where the telescope is. Most of the images ended up plate solving
anyway, but since the stars are all diffraction spikes, I don't know
the quality of those solutions. The initial slew to meridian is
probably the worst because the dome is in the exact opposite position
than it should be and my slot just goes barely past vertical. I
checked the ASCOM logs on the PC and my ASCOM debug screen on the dome
controller. The dome _is_ slewing to the position that APPM requests;
that position just doesn't seem to be based on where the telescope is.

Can anyone tell me what I'm missing? Where do I enter the offsets for
the mount/scope geometer so that APPM can got to the correct position?

So, after trying "Active", I swiched to "Passive" and tried with two
different dome slaving programs: ASCOM Device Hub and SGP. For "Delay
before starting dome slew checking", I used values ranging from 5 to 30
seconds. For "Settle time after dome stops slewing", I used values from
1 to 20 seconds. I didn't see any effect when changing these settings;
in all cases the the telescope slewed to the next position and started
imaging a few seconds after it got there--many seconds before the dome
was in position. None of those images solved since the dome was in the
way. Again, I can't figure out what I'm doing wrong--it's like I'm not
even changing the values. Is there another setting that I'm missing
that enables these timeouts?

I'm sure someone else has successfully done an APPM run from an
automated dome! What am I missing?

Thanks - Shane

--
Shane Ramotowski
kor@cotse.net
https://www.kor-astro.net








--
Shane Ramotowski
kor@cotse.net
https://www.kor-astro.net


Re: APPM with Dome Questions

Terry White
 

Ditto to what Ray said. You should enter all the dome and OTA parameters in the program that directly slews your dome to the OTA, not APPM.


CP4 firmware help

cmaier
 

 

   
 
 
 
 
 
 
 
I was following instructions to update the CP4 firmware through the USB. I opened the utility and selected the com port of the mount and proceeded to load the zip file. Pt.2 loaded fine, then instructed me to power cycle the CP4 which I did, then failed on loading PT.1. some of the dialog is:
Downloading VCP4-P01-14pt2
Programming completed successfully
please cycle power to unit
downloading VCP4-P01-14 pt1
Exception: Timeout waiting for receiver
download aborted
prep for download
starting download
exception: too many errors caught, abandoning download
I've power cycled the CP4 and restarted the utility but it still fails. When I reconnected to the CP4 in the utility, it says "the unit is stuck in a download mode please load firmware"
Any help would be appreciated 


Re: GTOCP4 Control Box

Tom Blahovici
 

Hi
It's the Intel NUC8i3BEK.  The one I bought had a 240Gb SSD.  Not enough for an ASI6200 so I upgraded to 1Tb.
Tom


Re: Small mount was Recent encoder discussion on CN

Seb@stro
 
Edited

On Fri, Feb 26, 2021 at 05:01 PM, Roland Christen wrote:
Pick any 3 out of 5.
My picks would be : LOW weight, dual encoders (unguided imaging), medium cost, LOW weight and LOW weight. Actually, at the time I put my name on list for the Mach2, that's what I would have prefered. (But don't worry, I'm gonna put it to good use once I get it.)

Also don't know if that would be economically viable, but I think giving the choice to customers to have the encoders on single or dual axis or not at all could be a nice feature. Granted this would mean a price premium for the highest performance version.

And as a side note, if that small mount comes to life one day, please put my name first on the list of cold to extremely cold (-33 to -20 Celsius) conditions beta tester... I'd be more than happy to help with that ! :D


Re: Encoders in the Mach2 vs 1100

Roland Christen
 

Periodic error means that the error occurs periodically at some recurring rate. In the case of an encoder, the error being over a 24 hour period, you will never see it because the maximum tracking time will only ever be 12 hours or less (unless you wish to follow an object below the horizon). As such, then you will have only a partial period.

While the encoder can track accurately to the level in my previous post, the scope can never hope to match that due to a huge number of other factors:

1) atmospheric refraction which will vary between zero and as much as 200 arc sec per hour

2) telescope flexure which can be anything, but never zero. Typical flexure could be on the order of 1 to 10 arc sec per hour or more depending on instrument type.

3) polar misalignment which can be anything but never zero. It is impossible to get perfect polar alignment because of atmospheric refraction. You can get either alignment with the refracted pole or alignment with the actual pole. neither one of them will achieve zero tracking drift.

4) non-recurring movement of the scope/camera caused by various things like cable drag, shifting weight of attached peripherals, unbalanced loads, shifting mirrors, focuser shift, and many more.

So your answer in real life setups is unanswerable.

Rolando



-----Original Message-----
From: Seb@stro <sebastiendore1@...>
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Sent: Sat, Feb 27, 2021 12:22 pm
Subject: Re: [ap-gto] Encoders in the Mach2 vs 1100

 there is no real "periodic" error. The error tends to be a single smooth sine wave over a 24 hour period
Well, a sine wave is by nature periodic but I understand you're meaning that it's at a frequency irrelevant to a few minutes sub or a few seconds guide frame. Then over what period (1 hour, indefinitely, in-between ?) would the Mach2's "un-periodic" error stays under 0.25 arc-sec,  assuming a near-perfect PA, ideal sky conditions and for example a FL of 1400mm (1 a-s/pixel) setup ? Another way to put it would be to what "standard" conditions does the 0.25 a-s refers ?

My Mach2 being scheduled for shipment soon, I'm just trying to figure out what should reasonably be my expections in this regards. As well as trying to understand a bit more in-depth how the encoders works...  

BTW, thanks for the much-valued information you continuously share on this forum, Rolando. Definitely makes intermediate-newb like me want to know more about your products and keep learning on the matter.

Regards,
Sébastien


De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de Roland Christen via groups.io <chris1011@...>
Envoyé : 26 février 2021 11:24
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] Encoders in the Mach2 vs 1100
 
The error in an encoder mount is not periodic, so there is no real "periodic" error. The error tends to be a single smooth sine wave over a 24 hour period.

Rolando



-----Original Message-----
From: Seb@stro <sebastiendore1@...>
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Sent: Fri, Feb 26, 2021 8:22 am
Subject: Re: [ap-gto] Encoders in the Mach2 vs 1100

Thanks for the explanations Rolando. That clears it up a bit. Indeed resolution and accuracy are two different beasts...

What I was missing is the fact that the accuracy spec is for an entire revolution of the ring. I also had a somewhat hard time wrapping my head around the fact that the pitch of the ticks (or barcodes) is the same for any ring size (at 30 microns) and that its not giving any benefits in actual resolution (ticks per arc-sec). But reading further, I understood that the output resolution is not solely dependant on the mechanical aspect, but also on the encoding protocol used. 

So my understanding at this point is that even if the pitch is the same for every size of ring, hence giving more "barcodes" on larger rings, the readhead is nonetheless outputting a value that is limited by the characteristics of the serial protocol used (26 bits for the Mach 2, as you stated). 

I also understand that these figures of 0.16 and 0.12 arc-sec accuracy are theoretical and achievable only under hypothetical ideal conditions. 

From all this, should I also understand that the Mach2's stated native periodic error of 0.25 arc-sec (peak-to-peak) is also a per-hour figure or am I still missing some parts of the puzzle ? (Is periodic error the same as accuracy in this context with encoders ?)

Sébastien


De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de Roland Christen via groups.io <chris1011@...>
Envoyé : 24 février 2021 19:41
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] Encoders in the Mach2 vs 1100
 

I would have thought that a bigger ring gives more space to mark a higher number of "ticks", hence giving higher resolution and so accuracy...
Resolution is not the same as accuracy.

There are 2^26 individual addresses (67,108,864) that can be accessed in the RESA encoder, whether it is 75mm or 100mm. Therefore the resolution is the same for both rings.

The stated accuracy is a measure of how accurate the encoder is over a 24 hour period of revolution (360 degree total angle of rotation). For the 75mm ring, accuracy would be approximately +-3.82arcsec/24hr or 0.16 arc sec per hour of tracking. For the 100mm ring it would be 0.12 arc sec. per hour.

In reality one can never get the ring to have zero runout, so the practical accuracy will come in at perhaps +-0.5 arc sec per hour, more or less. So whether you have a 100mm ring or a 75mm ring, it makes no practical difference. Star motion due to atmospheric refraction will be an order of magnitude higher if you are anywhere but at the exact zenith.

The way the RESA works is not like any other encoder system. It does not read "ticks" the way an ordinary encoder does. It reads a barcode that is imprinted on the steel ring. The barcode is read over a fairly large circumference angle. The readhead is a miniature camera, not a photodiode that registers black and white tick marks. It's really quite revolutionary how it works, and it does work splendidly for telescope mounts.

Rolando




-----Original Message-----
From: Seb@stro <sebastiendore1@...>
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Sent: Wed, Feb 24, 2021 4:40 pm
Subject: Re: [ap-gto] Encoders in the Mach2 vs 1100

Hello Roland,

Your post made me take a quick look at Renishaw's spec for the Resolute extended temp encoder and I found two interesting observations (not related to the low temp version) which made me realize I'm probably missing something in my understanding of how the encoders actually works...

First, when we look at the following table, the "system accuracy" is increasing with the diameter of the ring (kind of opposite of what you stated earlier), which made sense to me since I would have thought that a bigger ring gives more space to mark a higher number of "ticks", hence giving higher resolution and so accuracy... So I assume the "system accuracy" of the encoder (which is defined as graduation + SDE by Renishaw) doesn't directly translate into the "tracking accuracy" of the mount.



Second observation, still looking at that table, the order of magnitude of that system accuracy seems to be more than ten-fold lower in comparison to the spec'ed tracking accuracy of the mount (+/- 3.82 arc-sec "system accuracy" for the 75 mm ring vs +/- 0.25 arc-sec "tracking accuracy" of the Mach2).

To explain these differences, my guess would be that some (gear/pulley) ratio somewhere does indeed make the tracking accuracy similar throughout the mount models and while at the same time increasing it by a factor of about 10X relative to the Renishaw's specs, but I wondered if there was more to it...

Am I lost in space ? 

Regards,
Sébastien


De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de Roland Christen via groups.io <chris1011@...>
Envoyé : 24 février 2021 11:48
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : [ap-gto] Encoders in the Mach2 vs 1100
 
Hello Astronuts,

To clear up any confusion about mount encoders, both Mach2 and 1100/1600 use the same Renishaw RESA high resolution encoders. The main difference is that the ring diameter of the 1100/1600 mounts is 100mm, the Mach2 uses a 75mm ring. Resolution and accuracy is the same for all. The readheads are the same RESA readheads, except that they are matched to their respective diameters, so that the 75mm readheads cannot be used on the 100mm rings and vice versa.

Roland Christen
Astro-Physics Inc.

--
Roland Christen
Astro-Physics

--
Roland Christen
Astro-Physics

--
Roland Christen
Astro-Physics

--
Roland Christen
Astro-Physics


Re: Encoders in the Mach2 vs 1100

Bill Long
 

Over a 24 hour period, and since you don't image for 24 hours at a time, it's irrelevant. It's still irrelevant if you did image for 24 hour periods, just moreso since you don't. That's my understanding anyhow.


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Seb@stro <sebastiendore1@...>
Sent: Saturday, February 27, 2021 10:22 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Encoders in the Mach2 vs 1100
 
 there is no real "periodic" error. The error tends to be a single smooth sine wave over a 24 hour period
Well, a sine wave is by nature periodic but I understand you're meaning that it's at a frequency irrelevant to a few minutes sub or a few seconds guide frame. Then over what period (1 hour, indefinitely, in-between ?) would the Mach2's "un-periodic" error stays under 0.25 arc-sec,  assuming a near-perfect PA, ideal sky conditions and for example a FL of 1400mm (1 a-s/pixel) setup ? Another way to put it would be to what "standard" conditions does the 0.25 a-s refers ?

My Mach2 being scheduled for shipment soon, I'm just trying to figure out what should reasonably be my expections in this regards. As well as trying to understand a bit more in-depth how the encoders works...  

BTW, thanks for the much-valued information you continuously share on this forum, Rolando. Definitely makes intermediate-newb like me want to know more about your products and keep learning on the matter.

Regards,
Sébastien


De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de Roland Christen via groups.io <chris1011@...>
Envoyé : 26 février 2021 11:24
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] Encoders in the Mach2 vs 1100
 
The error in an encoder mount is not periodic, so there is no real "periodic" error. The error tends to be a single smooth sine wave over a 24 hour period.

Rolando



-----Original Message-----
From: Seb@stro <sebastiendore1@...>
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Sent: Fri, Feb 26, 2021 8:22 am
Subject: Re: [ap-gto] Encoders in the Mach2 vs 1100

Thanks for the explanations Rolando. That clears it up a bit. Indeed resolution and accuracy are two different beasts...

What I was missing is the fact that the accuracy spec is for an entire revolution of the ring. I also had a somewhat hard time wrapping my head around the fact that the pitch of the ticks (or barcodes) is the same for any ring size (at 30 microns) and that its not giving any benefits in actual resolution (ticks per arc-sec). But reading further, I understood that the output resolution is not solely dependant on the mechanical aspect, but also on the encoding protocol used. 

So my understanding at this point is that even if the pitch is the same for every size of ring, hence giving more "barcodes" on larger rings, the readhead is nonetheless outputting a value that is limited by the characteristics of the serial protocol used (26 bits for the Mach 2, as you stated). 

I also understand that these figures of 0.16 and 0.12 arc-sec accuracy are theoretical and achievable only under hypothetical ideal conditions. 

From all this, should I also understand that the Mach2's stated native periodic error of 0.25 arc-sec (peak-to-peak) is also a per-hour figure or am I still missing some parts of the puzzle ? (Is periodic error the same as accuracy in this context with encoders ?)

Sébastien


De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de Roland Christen via groups.io <chris1011@...>
Envoyé : 24 février 2021 19:41
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] Encoders in the Mach2 vs 1100
 

I would have thought that a bigger ring gives more space to mark a higher number of "ticks", hence giving higher resolution and so accuracy...
Resolution is not the same as accuracy.

There are 2^26 individual addresses (67,108,864) that can be accessed in the RESA encoder, whether it is 75mm or 100mm. Therefore the resolution is the same for both rings.

The stated accuracy is a measure of how accurate the encoder is over a 24 hour period of revolution (360 degree total angle of rotation). For the 75mm ring, accuracy would be approximately +-3.82arcsec/24hr or 0.16 arc sec per hour of tracking. For the 100mm ring it would be 0.12 arc sec. per hour.

In reality one can never get the ring to have zero runout, so the practical accuracy will come in at perhaps +-0.5 arc sec per hour, more or less. So whether you have a 100mm ring or a 75mm ring, it makes no practical difference. Star motion due to atmospheric refraction will be an order of magnitude higher if you are anywhere but at the exact zenith.

The way the RESA works is not like any other encoder system. It does not read "ticks" the way an ordinary encoder does. It reads a barcode that is imprinted on the steel ring. The barcode is read over a fairly large circumference angle. The readhead is a miniature camera, not a photodiode that registers black and white tick marks. It's really quite revolutionary how it works, and it does work splendidly for telescope mounts.

Rolando




-----Original Message-----
From: Seb@stro <sebastiendore1@...>
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Sent: Wed, Feb 24, 2021 4:40 pm
Subject: Re: [ap-gto] Encoders in the Mach2 vs 1100

Hello Roland,

Your post made me take a quick look at Renishaw's spec for the Resolute extended temp encoder and I found two interesting observations (not related to the low temp version) which made me realize I'm probably missing something in my understanding of how the encoders actually works...

First, when we look at the following table, the "system accuracy" is increasing with the diameter of the ring (kind of opposite of what you stated earlier), which made sense to me since I would have thought that a bigger ring gives more space to mark a higher number of "ticks", hence giving higher resolution and so accuracy... So I assume the "system accuracy" of the encoder (which is defined as graduation + SDE by Renishaw) doesn't directly translate into the "tracking accuracy" of the mount.



Second observation, still looking at that table, the order of magnitude of that system accuracy seems to be more than ten-fold lower in comparison to the spec'ed tracking accuracy of the mount (+/- 3.82 arc-sec "system accuracy" for the 75 mm ring vs +/- 0.25 arc-sec "tracking accuracy" of the Mach2).

To explain these differences, my guess would be that some (gear/pulley) ratio somewhere does indeed make the tracking accuracy similar throughout the mount models and while at the same time increasing it by a factor of about 10X relative to the Renishaw's specs, but I wondered if there was more to it...

Am I lost in space ? 

Regards,
Sébastien


De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de Roland Christen via groups.io <chris1011@...>
Envoyé : 24 février 2021 11:48
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : [ap-gto] Encoders in the Mach2 vs 1100
 
Hello Astronuts,

To clear up any confusion about mount encoders, both Mach2 and 1100/1600 use the same Renishaw RESA high resolution encoders. The main difference is that the ring diameter of the 1100/1600 mounts is 100mm, the Mach2 uses a 75mm ring. Resolution and accuracy is the same for all. The readheads are the same RESA readheads, except that they are matched to their respective diameters, so that the 75mm readheads cannot be used on the 100mm rings and vice versa.

Roland Christen
Astro-Physics Inc.

--
Roland Christen
Astro-Physics

--
Roland Christen
Astro-Physics

--
Roland Christen
Astro-Physics


Re: Encoders in the Mach2 vs 1100

Seb@stro
 

 there is no real "periodic" error. The error tends to be a single smooth sine wave over a 24 hour period
Well, a sine wave is by nature periodic but I understand you're meaning that it's at a frequency irrelevant to a few minutes sub or a few seconds guide frame. Then over what period (1 hour, indefinitely, in-between ?) would the Mach2's "un-periodic" error stays under 0.25 arc-sec,  assuming a near-perfect PA, ideal sky conditions and for example a FL of 1400mm (1 a-s/pixel) setup ? Another way to put it would be to what "standard" conditions does the 0.25 a-s refers ?

My Mach2 being scheduled for shipment soon, I'm just trying to figure out what should reasonably be my expections in this regards. As well as trying to understand a bit more in-depth how the encoders works...  

BTW, thanks for the much-valued information you continuously share on this forum, Rolando. Definitely makes intermediate-newb like me want to know more about your products and keep learning on the matter.

Regards,
Sébastien


De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de Roland Christen via groups.io <chris1011@...>
Envoyé : 26 février 2021 11:24
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] Encoders in the Mach2 vs 1100
 
The error in an encoder mount is not periodic, so there is no real "periodic" error. The error tends to be a single smooth sine wave over a 24 hour period.

Rolando



-----Original Message-----
From: Seb@stro <sebastiendore1@...>
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Sent: Fri, Feb 26, 2021 8:22 am
Subject: Re: [ap-gto] Encoders in the Mach2 vs 1100

Thanks for the explanations Rolando. That clears it up a bit. Indeed resolution and accuracy are two different beasts...

What I was missing is the fact that the accuracy spec is for an entire revolution of the ring. I also had a somewhat hard time wrapping my head around the fact that the pitch of the ticks (or barcodes) is the same for any ring size (at 30 microns) and that its not giving any benefits in actual resolution (ticks per arc-sec). But reading further, I understood that the output resolution is not solely dependant on the mechanical aspect, but also on the encoding protocol used. 

So my understanding at this point is that even if the pitch is the same for every size of ring, hence giving more "barcodes" on larger rings, the readhead is nonetheless outputting a value that is limited by the characteristics of the serial protocol used (26 bits for the Mach 2, as you stated). 

I also understand that these figures of 0.16 and 0.12 arc-sec accuracy are theoretical and achievable only under hypothetical ideal conditions. 

From all this, should I also understand that the Mach2's stated native periodic error of 0.25 arc-sec (peak-to-peak) is also a per-hour figure or am I still missing some parts of the puzzle ? (Is periodic error the same as accuracy in this context with encoders ?)

Sébastien


De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de Roland Christen via groups.io <chris1011@...>
Envoyé : 24 février 2021 19:41
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] Encoders in the Mach2 vs 1100
 

I would have thought that a bigger ring gives more space to mark a higher number of "ticks", hence giving higher resolution and so accuracy...
Resolution is not the same as accuracy.

There are 2^26 individual addresses (67,108,864) that can be accessed in the RESA encoder, whether it is 75mm or 100mm. Therefore the resolution is the same for both rings.

The stated accuracy is a measure of how accurate the encoder is over a 24 hour period of revolution (360 degree total angle of rotation). For the 75mm ring, accuracy would be approximately +-3.82arcsec/24hr or 0.16 arc sec per hour of tracking. For the 100mm ring it would be 0.12 arc sec. per hour.

In reality one can never get the ring to have zero runout, so the practical accuracy will come in at perhaps +-0.5 arc sec per hour, more or less. So whether you have a 100mm ring or a 75mm ring, it makes no practical difference. Star motion due to atmospheric refraction will be an order of magnitude higher if you are anywhere but at the exact zenith.

The way the RESA works is not like any other encoder system. It does not read "ticks" the way an ordinary encoder does. It reads a barcode that is imprinted on the steel ring. The barcode is read over a fairly large circumference angle. The readhead is a miniature camera, not a photodiode that registers black and white tick marks. It's really quite revolutionary how it works, and it does work splendidly for telescope mounts.

Rolando




-----Original Message-----
From: Seb@stro <sebastiendore1@...>
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Sent: Wed, Feb 24, 2021 4:40 pm
Subject: Re: [ap-gto] Encoders in the Mach2 vs 1100

Hello Roland,

Your post made me take a quick look at Renishaw's spec for the Resolute extended temp encoder and I found two interesting observations (not related to the low temp version) which made me realize I'm probably missing something in my understanding of how the encoders actually works...

First, when we look at the following table, the "system accuracy" is increasing with the diameter of the ring (kind of opposite of what you stated earlier), which made sense to me since I would have thought that a bigger ring gives more space to mark a higher number of "ticks", hence giving higher resolution and so accuracy... So I assume the "system accuracy" of the encoder (which is defined as graduation + SDE by Renishaw) doesn't directly translate into the "tracking accuracy" of the mount.



Second observation, still looking at that table, the order of magnitude of that system accuracy seems to be more than ten-fold lower in comparison to the spec'ed tracking accuracy of the mount (+/- 3.82 arc-sec "system accuracy" for the 75 mm ring vs +/- 0.25 arc-sec "tracking accuracy" of the Mach2).

To explain these differences, my guess would be that some (gear/pulley) ratio somewhere does indeed make the tracking accuracy similar throughout the mount models and while at the same time increasing it by a factor of about 10X relative to the Renishaw's specs, but I wondered if there was more to it...

Am I lost in space ? 

Regards,
Sébastien


De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de Roland Christen via groups.io <chris1011@...>
Envoyé : 24 février 2021 11:48
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : [ap-gto] Encoders in the Mach2 vs 1100
 
Hello Astronuts,

To clear up any confusion about mount encoders, both Mach2 and 1100/1600 use the same Renishaw RESA high resolution encoders. The main difference is that the ring diameter of the 1100/1600 mounts is 100mm, the Mach2 uses a 75mm ring. Resolution and accuracy is the same for all. The readheads are the same RESA readheads, except that they are matched to their respective diameters, so that the 75mm readheads cannot be used on the 100mm rings and vice versa.

Roland Christen
Astro-Physics Inc.

--
Roland Christen
Astro-Physics

--
Roland Christen
Astro-Physics

--
Roland Christen
Astro-Physics


Re: Small mount was Recent encoder discussion on CN

Ray Gralak
 

APCC-APPM is that the AP mounts will fine tune the RA speed so that it’s not 1x
sidereal to account for DEC drift.
I forgot to mention that the above statement is not accurate.

APCC Pro adjusts both RA and Dec tracking rates to match the apparent rate of stars at the current RA/Dec. The rate will dynamically change over time based on the set of data points that APPM collects.

BTW, APPM collects the sky mapping points that APCC Pro uses to create a pointing/tracking rate model. APPM can also do miscellaneous tasks like a plate solve+recals. However, APPM does not take part in the tracking rate adjustments to the mount. It is APCC Pro that makes the real-time tracking rate adjustments based on the data previously collected by APPM. APPM does not even need to be running for APCC Pro to make tracking rate corrections.

-Ray



-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of alan.dang@gmail.com
Sent: Friday, February 26, 2021 9:26 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Small mount was Recent encoder discussion on CN

I understood that one of the differences between many mounts with “pointing models” such as they in an entry
level Celestron CG5 and APCC-APPM is that the AP mounts will fine tune the RA speed so that it’s not 1x
sidereal to account for DEC drift. I guess my question is that, how bad does the PE have to be for that to stop
mattering? That is what is the equivalent PE difference between a 1x sidereal vs. advanced sky model?

User focused is that you really focus on what amateurs need and you try to give your customers, whether they
bought new or old, the same kind of technical support you’d give to your friends or family. User focused is
exactly what you just mentioned — all of your mounts share the same software. In contrast, other companies
will tier their software to meet specific price points and artificially
enable or disable features depending where you enter in the product line. User focused is that you don’t inflate
carrying capacity and make sure people understand torque. User focused is going with notifications lists
instead of using eBay, rewarding the patient astronomer as opposed to the merely wealthy astronomer.

User focused is being a celebrity in the amateur astronomy world but taking time to talk with hobbyists across
the world you have never actually met :)


Re: Small mount was Recent encoder discussion on CN

Ray Gralak
 

I understood that one of the differences between many mounts with “pointing models” such as they in an entry
level Celestron CG5 and APCC-APPM is that the AP mounts will fine tune the RA speed so that it’s not 1x
sidereal to account for DEC drift. I guess my question is that, how bad does the PE have to be for that to stop
mattering? That is what is the equivalent PE difference between a 1x sidereal vs. advanced sky model?
There is no one answer for that because every setup is different. Even the amount of polar misalignment will change drift values throughout the sky.

A typical setup without modeling can drift up to many hundreds of arc-seconds per hour. The drift can happen in either axis, and will change depending on the part of the sky the scope is aiming.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of alan.dang@gmail.com
Sent: Friday, February 26, 2021 9:26 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Small mount was Recent encoder discussion on CN

I understood that one of the differences between many mounts with “pointing models” such as they in an entry
level Celestron CG5 and APCC-APPM is that the AP mounts will fine tune the RA speed so that it’s not 1x
sidereal to account for DEC drift. I guess my question is that, how bad does the PE have to be for that to stop
mattering? That is what is the equivalent PE difference between a 1x sidereal vs. advanced sky model?

User focused is that you really focus on what amateurs need and you try to give your customers, whether they
bought new or old, the same kind of technical support you’d give to your friends or family. User focused is
exactly what you just mentioned — all of your mounts share the same software. In contrast, other companies
will tier their software to meet specific price points and artificially
enable or disable features depending where you enter in the product line. User focused is that you don’t inflate
carrying capacity and make sure people understand torque. User focused is going with notifications lists
instead of using eBay, rewarding the patient astronomer as opposed to the merely wealthy astronomer.

User focused is being a celebrity in the amateur astronomy world but taking time to talk with hobbyists across
the world you have never actually met :)


Re: APPM with Dome Questions

Ray Gralak
 

Hi Shane,

APPM's "Active mode" sends the telescope's destination coordinates to the dome ASCOM driver. In this case, it is the responsibility of the driver or intermediate application to translate the RA/Dec coordinates to the appropriate dome position.

In "Passive mode" APPM waits for the dome to finish slewing by polling the dome's driver (or intermediate application).

So, it seems that your dome's ascom driver (or intermediate application) may not be correctly indicating when the dome is slewing.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski
Sent: Friday, February 26, 2021 9:19 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM with Dome Questions

Hi gang,

I am the proud owner of a brand new (well 2 weeks) Mach2 and tried to do
my first APPM model tonight. I'm having problems with the dome control
and hope someone can point in the right direction.

My observatory is a ClearSkys (I don't think they are around anymore) 8
ft dome. The pier is centered and the bottom of the mount is just about
even with the bottom of the dome. The rotation control is homemade (my
COVID quarantine project) and works very will with both ASCOM DeviceHub
and SGP. I'm using SGP for image capture and plate solve.

I can't figure out how to set up APPM to control the dome properly. If I
use "Active" in the "AP Point Mapper - Dome Settings" panel, APPM seems
to do it's calculations based on the center of the dome instead of where
the telescope is. This is not surprising since I can't seem to find any
where in the program or the documentation to set the mount and telescope
geometry. I suppose, since APCC knows that I'm using a Mach2, it
_could_ already know roughly how far from the center of the RA/DEC axes
intersection the bottom of my telescope is. But I don't see anyway that
it could know where the center of my OTA is. I really don't think it's
using the parameters from 3D view; I haven't set that up, but the
default is a much larger diameter telescope than mine.

Anyway, when I use "Active", I end up imaging across the edge of the
slot because the slot is positioned for the center of the mount instead
of where the telescope is. Most of the images ended up plate solving
anyway, but since the stars are all diffraction spikes, I don't know
the quality of those solutions. The initial slew to meridian is
probably the worst because the dome is in the exact opposite position
than it should be and my slot just goes barely past vertical. I
checked the ASCOM logs on the PC and my ASCOM debug screen on the dome
controller. The dome _is_ slewing to the position that APPM requests;
that position just doesn't seem to be based on where the telescope is.

Can anyone tell me what I'm missing? Where do I enter the offsets for
the mount/scope geometer so that APPM can got to the correct position?

So, after trying "Active", I swiched to "Passive" and tried with two
different dome slaving programs: ASCOM Device Hub and SGP. For "Delay
before starting dome slew checking", I used values ranging from 5 to 30
seconds. For "Settle time after dome stops slewing", I used values from
1 to 20 seconds. I didn't see any effect when changing these settings;
in all cases the the telescope slewed to the next position and started
imaging a few seconds after it got there--many seconds before the dome
was in position. None of those images solved since the dome was in the
way. Again, I can't figure out what I'm doing wrong--it's like I'm not
even changing the values. Is there another setting that I'm missing
that enables these timeouts?

I'm sure someone else has successfully done an APPM run from an
automated dome! What am I missing?

Thanks - Shane

--
Shane Ramotowski
kor@cotse.net
https://www.kor-astro.net




Re: GTOCP4 Control Box

Seb@stro
 

Thanks for sharing, Tom. You definitely put a lot of thought into it. Really a nice compact setup, love it. Any specific model for the NUC (besides it being an i5 from last year) ?


Re: Keypad V5.xxx Software Status?

Martin Rabanser
 

I'd like to second those thoughts.

The AP website still mentions that software version 5 for CP4 owners will (should have been) released by late December 2020 or early January 2021. We're now approaching March 2021 and there's still no word. Not to mention the fact it should have been released a year ago. At least the AP website should have been updated to reflect this.

I'm sure the folks at AP face a lot of issues, but at least comunicate, give some updates on the status. That would have been helpful.

Martin


Large Eagle Hand Knobs

Bill Long
 

Are these sold in a set separately? I could use a spare set if so. If anyone knows the part number I can look up that would be helpful. Otherwise I can call AP on Monday.


Re: Small mount was Recent encoder discussion on CN

alan.dang@...
 

I understood that one of the differences between many mounts with “pointing models” such as they in an entry level Celestron CG5 and APCC-APPM is that the AP mounts will fine tune the RA speed so that it’s not 1x sidereal to account for DEC drift.  I guess my question is that, how bad does the PE have to be for that to stop mattering?  That is what is the equivalent PE difference between a 1x sidereal vs. advanced sky model?

User focused is that you really focus on what amateurs need and you try to give your customers, whether they bought new or old, the same kind of technical support you’d give to your friends or family.  User focused is exactly what you just mentioned — all of your mounts share the same software.  In contrast, other companies will tier their software to meet specific price points and artificially
enable or disable features depending where you enter in the product line.  User focused is that you don’t inflate carrying capacity and make sure people understand torque.  User focused is going with notifications lists instead of using eBay, rewarding the patient astronomer as opposed to the merely wealthy astronomer.

User focused is being a celebrity in the amateur astronomy world but taking time to talk with hobbyists across the world you have never actually met :)


APPM with Dome Questions

Shane Ramotowski
 

Hi gang,

I am the proud owner of a brand new (well 2 weeks) Mach2 and tried to do my first APPM model tonight.  I'm having problems with the dome control and hope someone can point in the right direction.

My observatory is a ClearSkys (I don't think they are around anymore) 8 ft dome.  The pier is centered and the bottom of the mount is just about even with the bottom of the dome.  The rotation control is homemade (my COVID quarantine project) and works very will with both ASCOM DeviceHub and SGP.  I'm using SGP for image capture and plate solve.

I can't figure out how to set up APPM to control the dome properly. If I use "Active" in the "AP Point Mapper - Dome Settings" panel, APPM seems to do it's calculations based on the center of the dome instead of where the telescope is.  This is not surprising since I can't seem to find any where in the program or the documentation to set the mount and telescope geometry.  I suppose, since APCC knows that I'm using a Mach2, it _could_ already know roughly how far from the center of the RA/DEC axes intersection the bottom of my telescope is.  But I don't see anyway that it could know where the center of my OTA is.  I really don't think it's using the parameters from 3D view; I haven't set that up, but the default is a much larger diameter telescope than mine.

 Anyway, when I use "Active", I end up imaging across the edge of the slot because the slot is positioned for the center of the mount instead of where the telescope is.  Most of the images ended up plate solving anyway, but since  the stars are all diffraction spikes, I don't know the quality of those solutions.  The initial slew to meridian is probably the worst because the dome is in the exact opposite position than it should be and my slot just goes barely past vertical.   I checked the ASCOM logs on the PC and my ASCOM debug screen on the dome controller.  The dome _is_ slewing to the position that APPM requests; that position just doesn't seem to be based on where the telescope is.

Can anyone tell me what I'm missing?  Where do I enter the offsets for the mount/scope geometer so that APPM can got to the correct position?

So, after trying "Active", I swiched to "Passive" and tried with two different dome slaving programs: ASCOM Device Hub and SGP.  For "Delay before starting dome slew checking", I used values ranging from 5 to 30 seconds.  For "Settle time after dome stops slewing", I used values from 1 to 20 seconds.  I didn't see any effect when changing these settings; in all cases the the telescope slewed to the next position and started imaging a few seconds after it got there--many seconds before the dome was in position.  None of those images solved since the dome was in the way.  Again, I can't figure out what I'm doing wrong--it's like I'm not even changing the values.  Is there another setting that I'm missing that enables these timeouts?

I'm sure someone else has successfully done an APPM run from an automated dome!  What am I missing?

Thanks - Shane

--
Shane Ramotowski
kor@cotse.net
https://www.kor-astro.net


Re: Small mount was Recent encoder discussion on CN

Bill Long
 

If you built a correction model when using the mount it would not matter at all. Throw the guider in the drawer. 


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of W Hilmo <y.groups@...>
Sent: Friday, February 26, 2021 8:27 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Small mount was Recent encoder discussion on CN
 

The biggest benefit to an encoder on the dec axis is elimination of declination backlash.  If the mount doesn’t have significant backlash, then this would be ok.

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Roland Christen via groups.io
Sent: Friday, February 26, 2021 4:32 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Small mount was Recent encoder discussion on CN

 

Do you need a Dec encoder for what? Remember, Dec doesn't have to track.

 

Rolando

 

 

 

-----Original Message-----
From: Bill Long <bill@...>
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Sent: Fri, Feb 26, 2021 4:07 pm
Subject: Re: [ap-gto] Small mount was Recent encoder discussion on CN

Low weight, medium cost, dual absolute encoders.  🙂 

 


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Roland Christen via groups.io <chris1011@...>
Sent: Friday, February 26, 2021 2:01 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Small mount was Recent encoder discussion on CN

 

I guess if you need just an imaging mount with no clutches (no way to use manually without power), it can be very small and light weight.

A universal mount like the Mach2 or 10-Micron has more components than a non-clutched mount like the MYT or Rainbow mounts.

A non-clutched mount without encoders would be slightly less weight, and less cost, but will always require aggressive guiding.

A non-clutched mount with just an RA encoder to eliminate the periodic error would be medium cost and light weight.

 

There are a lot of permutations and possibilities, and it would depend on what you want to do with this mount. Some people just want a light weight mount that they can haul out from the basement to the driveway, put a scope on it, put an eyepiece on it and do a Moon Cruise or examine the planets. They don't need encoders or PE correction. Others want one as small as possible for airline travel and may or may not want to guide. Others want a precision universal mount that they can do anything with, but must have low weight because their back hurts. The possibilities are endless.

 

Low cost, medium or high cost. Medium weight low weight or ultra-low weight. Low tracking performance, medium or ultra-high performance. Clutched or non-clutched - universal or targeted. Single encoder or dual absolute encoders.

 

Pick any 3 out of 5.

 

Rolando

 

 

 

-----Original Message-----
From: alan.dang@...
To: main@ap-gto.groups.io
Sent: Fri, Feb 26, 2021 2:46 pm
Subject: Re: [ap-gto] Small mount was Recent encoder discussion on CN

And not just older people, but young enthusiasts who just want a lighter no-fuss mount that more easily travels when going on a group road trip where you have limited space for the Astro gear along with clothes and other travel essentials.

A real question is what is the smallest mount that would work with a AP105 and have encoders?  You might not save production cost over a mount that handles a C11 or AP130EDT — but if the mount is dramatically smaller or lighter, it could be interesting.


--
Roland Christen
Astro-Physics


--
Roland Christen
Astro-Physics


Re: Small mount was Recent encoder discussion on CN

W Hilmo
 

The biggest benefit to an encoder on the dec axis is elimination of declination backlash.  If the mount doesn’t have significant backlash, then this would be ok.

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Roland Christen via groups.io
Sent: Friday, February 26, 2021 4:32 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Small mount was Recent encoder discussion on CN

 

Do you need a Dec encoder for what? Remember, Dec doesn't have to track.

 

Rolando

 

 

 

-----Original Message-----
From: Bill Long <bill@...>
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Sent: Fri, Feb 26, 2021 4:07 pm
Subject: Re: [ap-gto] Small mount was Recent encoder discussion on CN

Low weight, medium cost, dual absolute encoders.  🙂 

 


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Roland Christen via groups.io <chris1011@...>
Sent: Friday, February 26, 2021 2:01 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Small mount was Recent encoder discussion on CN

 

I guess if you need just an imaging mount with no clutches (no way to use manually without power), it can be very small and light weight.

A universal mount like the Mach2 or 10-Micron has more components than a non-clutched mount like the MYT or Rainbow mounts.

A non-clutched mount without encoders would be slightly less weight, and less cost, but will always require aggressive guiding.

A non-clutched mount with just an RA encoder to eliminate the periodic error would be medium cost and light weight.

 

There are a lot of permutations and possibilities, and it would depend on what you want to do with this mount. Some people just want a light weight mount that they can haul out from the basement to the driveway, put a scope on it, put an eyepiece on it and do a Moon Cruise or examine the planets. They don't need encoders or PE correction. Others want one as small as possible for airline travel and may or may not want to guide. Others want a precision universal mount that they can do anything with, but must have low weight because their back hurts. The possibilities are endless.

 

Low cost, medium or high cost. Medium weight low weight or ultra-low weight. Low tracking performance, medium or ultra-high performance. Clutched or non-clutched - universal or targeted. Single encoder or dual absolute encoders.

 

Pick any 3 out of 5.

 

Rolando

 

 

 

-----Original Message-----
From: alan.dang@...
To: main@ap-gto.groups.io
Sent: Fri, Feb 26, 2021 2:46 pm
Subject: Re: [ap-gto] Small mount was Recent encoder discussion on CN

And not just older people, but young enthusiasts who just want a lighter no-fuss mount that more easily travels when going on a group road trip where you have limited space for the Astro gear along with clothes and other travel essentials.

A real question is what is the smallest mount that would work with a AP105 and have encoders?  You might not save production cost over a mount that handles a C11 or AP130EDT — but if the mount is dramatically smaller or lighter, it could be interesting.


--
Roland Christen
Astro-Physics


--
Roland Christen
Astro-Physics

2461 - 2480 of 79018