Date   

Re: ETA on ASTAP Native?

Bill Long
 

I looked all over for that setting. Where is it?


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Edward Beshore via groups.io <ebeshore@...>
Sent: Tuesday, April 20, 2021 6:24 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] ETA on ASTAP Native?
 
Hi Bill

I have just been pretty successful at using TheSky for astrometry in a variety of setups, including imaging scales of 0.39"/pix.

I find this in TheSkyX manual which might be helpful..

"Check the All Sky Image Link Crop Options
For photos acquired with a camera that has more than 2500 pixels in one dimension, to speed searches, All Sky Image Link automatically crops the photo (see the All Sky Image Link Crop Settings under “Advanced Preferences” on page 226 to configure this option).If a photo acquired with a large format camera has few stars in it, or a very poor signal to noise ratio, the All Sky Image Link crop process can result in "not enough stars" being found.If your camera has more than 2500 pixels in either dimension, and All Sky Image Link fails, increase the default crop size to 80 percent or so and try All Sky Image Link again."

If you are by default using All Sky Image link, this could be the source of your problem. (If so, I presume you have downloaded the large sky database that TheSky uses for plate solving All Sky Image link images...) On the other hand, if your RA and DEC are approximately correct, and the OBJCTRA and OBJCTDEC keywords are being placed in your FITS header, then TheSky should default to normal ImageLink operation. That given, there are still a number of ways one can get foiled with astrometry, and it may make some sense to spend a bit of time solving your images manually with ImageLink to get the solve parameters right for your imaging setup.

If you would want to share one of your images, I would be happy to take a look at it.

Cheers, Ed Beshore 


Re: ETA on ASTAP Native?

Edward Beshore
 

Hi Bill

I have just been pretty successful at using TheSky for astrometry in a variety of setups, including imaging scales of 0.39"/pix.

I find this in TheSkyX manual which might be helpful..

"Check the All Sky Image Link Crop Options
For photos acquired with a camera that has more than 2500 pixels in one dimension, to speed searches, All Sky Image Link automatically crops the photo (see the All Sky Image Link Crop Settings under “Advanced Preferences” on page 226 to configure this option).If a photo acquired with a large format camera has few stars in it, or a very poor signal to noise ratio, the All Sky Image Link crop process can result in "not enough stars" being found.If your camera has more than 2500 pixels in either dimension, and All Sky Image Link fails, increase the default crop size to 80 percent or so and try All Sky Image Link again."

If you are by default using All Sky Image link, this could be the source of your problem. (If so, I presume you have downloaded the large sky database that TheSky uses for plate solving All Sky Image link images...) On the other hand, if your RA and DEC are approximately correct, and the OBJCTRA and OBJCTDEC keywords are being placed in your FITS header, then TheSky should default to normal ImageLink operation. That given, there are still a number of ways one can get foiled with astrometry, and it may make some sense to spend a bit of time solving your images manually with ImageLink to get the solve parameters right for your imaging setup.

If you would want to share one of your images, I would be happy to take a look at it.

Cheers, Ed Beshore 


Re: Questions.....does wireless now work correctly with latest updates AND does your Sky Safari 6 Pro allow multiple Park positions now.

ernie.mastroianni@...
 

I'm a Mach2 owner and use it with a MacBook Pro and iPhone and keypad hand controller. The recent upgrades to Sky Safari are a big improvement. I can use Sky Safari Plus to run the mount with my iPhone, even with no computer or keypad controller. The same with my Macbook. I've had occasional dropouts, but they seem to be related to the autolock on the phone, autosleep on the laptop, or conflicts with both the laptop and phone trying to simultaneously communicate to the CP5. When I keep just one device in constant active mode on the CP5 network, all seems fine.

However, there's a glitch in the disconnect commands while using my Macbook Pro with OSX Sierra (not the current OS).

1. when I request to park in its current position, it does, but stays connected.
2. When I request it to go to Park 3, it disconnects in place.
3. When I request it to disconnect at Park 4, it disconnects and slews to Park 3.
4. When I ask it to find Home, it disconnects and and then slews to Park 4.

Despite the command mix-ups, the mount does reconnect and accurately follows commands to any star or object. I've sent this info along the the Sky Safari folks.

Ernie Mastroianni
Milwaukee, Wis.


Re: Powering Remote Imaging Systems

Steve Reilly
 

Thanks Dale,

 

NUCs are a bit new to me and have always built my own custom systems based on the observatory needs such as serial and USB ports wanting to have as many "native" as possible which is generally fine for universities and other installments where it is being manned. My experience at SRO even though there is staff there to assist when needed is different in that they need to be my eyes and then I need to ask the right questions and think without the aid of visual assistance. I asked for a picture of the back panel on the PC to see the LAN connections and it was then that I realized the CP4 is connected to the switch and not the 2nd port on the computer but more importantly I saw how dirty the back side and especially the fan section was alerting me to the fact that it had a dire need to be blown out. No telling how much dust/dirt is on the heat sync/fan.

 

From what little I've read on these NUC units I should be able to get most of what's needed and then use a StarTech ICUSB23241 for my needed serial ports. My issue with remote is the handicap it presents when trying to visualize the needs in resolving issues. I’ll need to physically prepare and load the necessary programs on the NUC here at home and then have it ready to be connected to the equipment at SRO. Of course once it’s online I can make adjustments but the more ready it is ahead of time the less down time there should be. The next question this brings to mind is location of the NUC. I’m guessing the unit can be mounted to the pier or other very close location making cabling maybe a bit better in terms of possibly un-needed extensions? Would long duct straps be an acceptable method of securing this unit to say the pier?

 

-Steve

 

 

 

 

 

-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Dale Ghent
Sent: Tuesday, April 20, 2021 8:30 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Powering Remote Imaging Systems

 

 

Hi Steve,

 

I use units from OnLogic, specifically the ML100G-51 model. They have a variety of system in industrial and rugged designs. I would keep to i3 or better systems. Celerons, especially N-series Celeron CPUs, don't really have the core count or clock speed when it comes to Windows. OnLogic systems are made in the US, and support is out of the US as well.

 

In the US and UK, there is SimplyNUC and their Porcoolpine line of passively-cooled units, but a recent update saw an emphasis on Thunderbolt instead of classic USB ports. They're still fine if you need only 1 or 2 USB connections to the box (ie, you have a USB hub).

 

There are of course a lot of options on Amazon and AliExpress, such as the Kingdel units that Luca mentions, as well as ones from Topton.

 

 

> On Apr 18, 2021, at 11:19, Steve Reilly <sreilly24590@...> wrote:

>

> Thanks for the reply Dale. I probably should replace at least the SRO computer. Any particular brand or vendor you can recommend for getting these? Hopefully they can be well configured which is what I think kept me from using these early on.

>

> -Steve

>

>

> -----Original Message-----

> From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Dale Ghent

> Sent: Sunday, April 18, 2021 11:08 AM

> To: main@ap-gto.groups.io

> Subject: Re: [ap-gto] Powering Remote Imaging Systems

>

>

> I wouldn't worry about computers needing a "rest" unless you have power availability considerations that would necessitate a complete shutdown of everything during idle periods. Computers are pretty resilient things. You can get fanless systems with SSDs and be completely free of any moving parts that could wear out from long periods of running. It's far better to have a fanless system that is designed to be fanless, than one that relies on a fan for cooling and is in trouble if that fan breaks or gets clogged up with the kind of dust and gunk that often floats around inside observatories.

>

> I don't know what your current in-observatory system is, but I would just opt for a low power system instead of trying to come up with some power management/synchronization machination for a single remote PC. Something NUC-ish is suitable for almost any observatory's control and acquisition system. You can find small systems with 15W TDP Intel i3 or i5 CPUs that sip power are completely adequate for the task.

>

> You can have it do stuff during the daytime, too. Run a weather station, monitor inside temperature/humidity sensors, or an all-sky or security cameras, for example.

>

>

>> On Apr 18, 2021, at 08:17, Steve Reilly <sreilly24590@...> wrote:

>>

>> While not directly mount related it does concern powering systems. For a system I run at SRO and one at home I have Web Power switches for the scripting the powering of equipment on/off through ACP Expert which works great but now years after just leaving the computers on 24/7 forever I wonder about the intelligence of that practice. I do have the computer’s BIOS set to restore to previous state should there be a power loss so that it turns back on and in turn opens the programs I have in the Start Menu which is fine for emergencies but I suspect I wouldn’t want to force stop/start it like that on a regular basis if not necessary. I’ve read a bit about Wake On LAN but that requires a computer that is on that network to access the computer you want woken which in this case is doable even with SRO as they have a VPN that sets the remote computer as part of your local network. I can Remote Desktop into that system using the IP address from home when the VPN is connected.

>>

>> But of course I’m looking for more fool proofing such as not relaying on memory to connect and turn on each system every day  as that will most certainly be forgotten from time to time and likely on the very best of nights. So the real question hidden deep in this post is if anyone knows of a mostly foolproof method to have remote computers turn on and off at predetermined times. I would expect you’d want to calculate the earliest time for On in your area considering DST and off by the latest morning time. Say you may want 4PM start for the winter when you could be imaging by 5:30pm in some areas and off at 9am in the morning which would/should allow time for sky flats should you take them both evening and morning. This at least gives the computer a rest of 15+ hours a day and in my case where I use a Starlight Xpress UltraStar guider t to would be powered down as it’s always on when connected to the computer’s USB.

>>

>> Just think there should be a more reasonable way to run these system that would be easier on the computers as well as being more efficient. Anything obvious I’m missing? Suggestions?

>>

>

>

>

>

>

>

>

>

>

>

>

 

 

 

 


Re: Powering Remote Imaging Systems

Dale Ghent
 

Hi Steve,

I use units from OnLogic, specifically the ML100G-51 model. They have a variety of system in industrial and rugged designs. I would keep to i3 or better systems. Celerons, especially N-series Celeron CPUs, don't really have the core count or clock speed when it comes to Windows. OnLogic systems are made in the US, and support is out of the US as well.

In the US and UK, there is SimplyNUC and their Porcoolpine line of passively-cooled units, but a recent update saw an emphasis on Thunderbolt instead of classic USB ports. They're still fine if you need only 1 or 2 USB connections to the box (ie, you have a USB hub).

There are of course a lot of options on Amazon and AliExpress, such as the Kingdel units that Luca mentions, as well as ones from Topton.

On Apr 18, 2021, at 11:19, Steve Reilly <sreilly24590@centurylink.net> wrote:

Thanks for the reply Dale. I probably should replace at least the SRO computer. Any particular brand or vendor you can recommend for getting these? Hopefully they can be well configured which is what I think kept me from using these early on.

-Steve


-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Dale Ghent
Sent: Sunday, April 18, 2021 11:08 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Powering Remote Imaging Systems


I wouldn't worry about computers needing a "rest" unless you have power availability considerations that would necessitate a complete shutdown of everything during idle periods. Computers are pretty resilient things. You can get fanless systems with SSDs and be completely free of any moving parts that could wear out from long periods of running. It's far better to have a fanless system that is designed to be fanless, than one that relies on a fan for cooling and is in trouble if that fan breaks or gets clogged up with the kind of dust and gunk that often floats around inside observatories.

I don't know what your current in-observatory system is, but I would just opt for a low power system instead of trying to come up with some power management/synchronization machination for a single remote PC. Something NUC-ish is suitable for almost any observatory's control and acquisition system. You can find small systems with 15W TDP Intel i3 or i5 CPUs that sip power are completely adequate for the task.

You can have it do stuff during the daytime, too. Run a weather station, monitor inside temperature/humidity sensors, or an all-sky or security cameras, for example.


On Apr 18, 2021, at 08:17, Steve Reilly <sreilly24590@centurylink.net> wrote:

While not directly mount related it does concern powering systems. For a system I run at SRO and one at home I have Web Power switches for the scripting the powering of equipment on/off through ACP Expert which works great but now years after just leaving the computers on 24/7 forever I wonder about the intelligence of that practice. I do have the computer’s BIOS set to restore to previous state should there be a power loss so that it turns back on and in turn opens the programs I have in the Start Menu which is fine for emergencies but I suspect I wouldn’t want to force stop/start it like that on a regular basis if not necessary. I’ve read a bit about Wake On LAN but that requires a computer that is on that network to access the computer you want woken which in this case is doable even with SRO as they have a VPN that sets the remote computer as part of your local network. I can Remote Desktop into that system using the IP address from home when the VPN is connected.

But of course I’m looking for more fool proofing such as not relaying on memory to connect and turn on each system every day as that will most certainly be forgotten from time to time and likely on the very best of nights. So the real question hidden deep in this post is if anyone knows of a mostly foolproof method to have remote computers turn on and off at predetermined times. I would expect you’d want to calculate the earliest time for On in your area considering DST and off by the latest morning time. Say you may want 4PM start for the winter when you could be imaging by 5:30pm in some areas and off at 9am in the morning which would/should allow time for sky flats should you take them both evening and morning. This at least gives the computer a rest of 15+ hours a day and in my case where I use a Starlight Xpress UltraStar guider t to would be powered down as it’s always on when connected to the computer’s USB.

Just think there should be a more reasonable way to run these system that would be easier on the computers as well as being more efficient. Anything obvious I’m missing? Suggestions?










Re: Interesting Behavior with APCC Pro and Pegasus Astro UPBv2

Dale Ghent
 

Hi Wade,

You may need to update your Pegasus software to fix this issue.

Older versions of the Pegasus UPBv2 console app and ObservingConditions driver will relay the Fahrenheit temperature to downstream consumers such as NINA or APCC when the console app is set to display units in Fahrenheit. 

The ASCOM ObservingConditions interface specification specifies that the values for its various meteorological properties must be in SI units (ie, Celsius when it comes to temperature), so that is what APCC is expecting. Pegasus issued a fix for this last year so you might just need an update unless they’ve reintroduced the bug in a recent version.

This issue was even more obvious to those who have NINA set to convert the SI units too imperial for display. This caused NINA to convert the Fahrenheit temperature to Fahrenheit again, resulting in some outlandish temperature values being reported. 

Aside from that, your description is quite an interesting depiction of how much temperature can alter the tracking of the mount under a model, though. Glad you were able to work out the cause. Hope you like the Advanced Sequencer, too. It is of course a work in progress but it’s maturing nicely. 

On Apr 20, 2021, at 00:35, W Hilmo <y.groups@...> wrote:

I've been doing some unguided imaging with my AP1600 w/Absolute Encoders and APCC Pro and have seen some interesting behavior with unguided imaging.

The first few nights that I run unguided after building a model of about 180 points, everything was great.  I was blown away by how well it worked.  The last few nights, not so much.  I am seeing elongated stars and some image drift over the course of the night.

I do not believe that this is flexure.  I'm imaging with my AP130GTX, and I've double checked all connections.  I've double checked to make sure that the pointing model is enabled.  I verified that the polar alignment is still spot on.  It's a bit difficult to troubleshoot because, without guiding, there aren't any log files to examine.  All I have are the subs that I can inspect.

Since we're getting into more moonlight, I've done some software updates (switched to the daily builds for NINA so that I can use the advanced scheduler).  I've also set up for doing tonight's run with the guider enabled so that I can get some logs.  As I was watching the session get started, I noticed something odd.  Specifically, I noticed that APCC reported the temperature at over 40 degrees C, which is very wrong.  I am using the Pegasus Astro Ultimate PowerBox v2 as the weather sensor.

It occurred to me that I made a change to the Pegasus software a few days ago to change from reporting the temperature in C, to reporting the temperature in F.  It looks like both APCC and NINA are reporting the Fahrenheit value as Celcius.  I am wondering if the significantly incorrect temperature interpretation has effected the model such that it's lost accuracy.  I have reverted the Pegasus software back to reporting in C, and after tonight's run, I'm going back to unguided operation to see if I get that great result back that I was getting the first couple of nights.

-Wade


Re: Interesting Behavior with APCC Pro and Pegasus Astro UPBv2

Bill Long
 

IIRC temperature is probably the most important of all the variables used by the model. 


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of W Hilmo <y.groups@...>
Sent: Monday, April 19, 2021 9:35 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: [ap-gto] Interesting Behavior with APCC Pro and Pegasus Astro UPBv2
 
I've been doing some unguided imaging with my AP1600 w/Absolute Encoders and APCC Pro and have seen some interesting behavior with unguided imaging.

The first few nights that I run unguided after building a model of about 180 points, everything was great.  I was blown away by how well it worked.  The last few nights, not so much.  I am seeing elongated stars and some image drift over the course of the night.

I do not believe that this is flexure.  I'm imaging with my AP130GTX, and I've double checked all connections.  I've double checked to make sure that the pointing model is enabled.  I verified that the polar alignment is still spot on.  It's a bit difficult to troubleshoot because, without guiding, there aren't any log files to examine.  All I have are the subs that I can inspect.

Since we're getting into more moonlight, I've done some software updates (switched to the daily builds for NINA so that I can use the advanced scheduler).  I've also set up for doing tonight's run with the guider enabled so that I can get some logs.  As I was watching the session get started, I noticed something odd.  Specifically, I noticed that APCC reported the temperature at over 40 degrees C, which is very wrong.  I am using the Pegasus Astro Ultimate PowerBox v2 as the weather sensor.

It occurred to me that I made a change to the Pegasus software a few days ago to change from reporting the temperature in C, to reporting the temperature in F.  It looks like both APCC and NINA are reporting the Fahrenheit value as Celcius.  I am wondering if the significantly incorrect temperature interpretation has effected the model such that it's lost accuracy.  I have reverted the Pegasus software back to reporting in C, and after tonight's run, I'm going back to unguided operation to see if I get that great result back that I was getting the first couple of nights.

-Wade


Interesting Behavior with APCC Pro and Pegasus Astro UPBv2

W Hilmo
 

I've been doing some unguided imaging with my AP1600 w/Absolute Encoders and APCC Pro and have seen some interesting behavior with unguided imaging.

The first few nights that I run unguided after building a model of about 180 points, everything was great.  I was blown away by how well it worked.  The last few nights, not so much.  I am seeing elongated stars and some image drift over the course of the night.

I do not believe that this is flexure.  I'm imaging with my AP130GTX, and I've double checked all connections.  I've double checked to make sure that the pointing model is enabled.  I verified that the polar alignment is still spot on.  It's a bit difficult to troubleshoot because, without guiding, there aren't any log files to examine.  All I have are the subs that I can inspect.

Since we're getting into more moonlight, I've done some software updates (switched to the daily builds for NINA so that I can use the advanced scheduler).  I've also set up for doing tonight's run with the guider enabled so that I can get some logs.  As I was watching the session get started, I noticed something odd.  Specifically, I noticed that APCC reported the temperature at over 40 degrees C, which is very wrong.  I am using the Pegasus Astro Ultimate PowerBox v2 as the weather sensor.

It occurred to me that I made a change to the Pegasus software a few days ago to change from reporting the temperature in C, to reporting the temperature in F.  It looks like both APCC and NINA are reporting the Fahrenheit value as Celcius.  I am wondering if the significantly incorrect temperature interpretation has effected the model such that it's lost accuracy.  I have reverted the Pegasus software back to reporting in C, and after tonight's run, I'm going back to unguided operation to see if I get that great result back that I was getting the first couple of nights.

-Wade


Re: M 81

Jeff B
 

Cool.


On Mon, Apr 19, 2021 at 8:40 PM KHursh via groups.io <khursh=yahoo.com@groups.io> wrote:
Thanks Jeff. It was the Esprit 120, which is a triplet


Re: M 81

KHursh
 

Thanks Jeff. It was the Esprit 120, which is a triplet


Re: M 81

KHursh
 

Thanks Howard


Re: Side-by-side saddle and dovetail suggestions

michael mccann
 

Great instructions.

Marty I’ve sent an email, let me know if you haven’t received it.

I have some Losmandy saddles and had purchased the “Easy Balance Saddle” initially. I’ll try the SBS18”  with my existing saddles and see if that works. I’ll see if my 3D adjustable saddle can handle the 130mm.  I hadn’t thought to check if I could mount the Easy Balance saddle (162) horizontally. So I’ll try that

thanks


Re: Side-by-side saddle and dovetail suggestions

Christopher Erickson
 

Balancing isn't that big of a deal. All it takes is a wooden pencil and a few pieces of blue painter's tape.

On the floor, use the pencil to find the center of gravity for each OTA setup. Have your cams, wheels, etc. in place and refractors set to approximate focus.

Mark the center of gravity on each OTA dovetail bar with bits of the painter's tape.

Mount the OTA's on your double/triple/quadruple, etc. tandem dovetail bar.

Center them in their dovetail brackets using the tape marks.

Put the entire assembly on the floor and find the center of gravity for the whole assembly with the pencil and mark it with the painter's tape.

Make sure your mount has enough counterweights on it.

Remove the OTA's.

Mount the tandem bar assembly on the mount.

Mount the OTA's on the tandem bar, starting with the biggest/heaviest.

Check EVERY KNOB THREE TIMES for tightness and security.

Go forth and slew.

P.S. ADM makes extra-long dovetail bars for building up double/triple/quadruple OTA assemblies.

P.P.S. I'll guarantee that none of the OTA's will point to exactly the same point in the sky. Use adjustable dovetail X-Y stages or focal plane X-Y stages for all but the biggest/heaviest OTA.

 



Roland's suggestion is best. Get another AP mount or three. LOL

"My advice is always free and worth every penny!"

-Christopher Erickson
Observatory Engineer
Summit Kinetics
Waikoloa, Hawaii


On Mon, Apr 19, 2021 at 12:53 PM mjb87 via groups.io <mjb87=verizon.net@groups.io> wrote:
Happy to help if I can. One thing to remember is that the mount balancing gets VERY complicated this way. There is an excellent write-up available from Astro-Physics that explains the various steps required.

BTW, if you have trouble securing the 18" SBS bar -- if Astro-Physics can't supply one in a reasonable time -- let me know. Mine is serving as a paperweight now.

Marty


Re: Side-by-side saddle and dovetail suggestions

mjb87@...
 

Happy to help if I can. One thing to remember is that the mount balancing gets VERY complicated this way. There is an excellent write-up available from Astro-Physics that explains the various steps required.

BTW, if you have trouble securing the 18" SBS bar -- if Astro-Physics can't supply one in a reasonable time -- let me know. Mine is serving as a paperweight now.

Marty


Re: Side-by-side saddle and dovetail suggestions

michael mccann
 

Thanks 

I actually just figuring my new “used” mount . As they say spend your money on the mount. I did

. until I have enough for much larger “galaxy killer “, I’ll make my three scopes work.  I’ll look into that  saddle and plate configuration.  Right now I’m learning the software.  Which image capturing software are you using?


Re: Side-by-side saddle and dovetail suggestions

mjb87@...
 
Edited

Indeed, Roland. That is excellent advice -- and why my brand new Mach2 was delivered in November!! (Remember the washer?)

I now have two mounts in operation. Much better solution for me (not to mention Astro-Physics.) The problem now is that I am spoiled by the absolute encoders, which is why I'm wait listed on them for the 1100.

Marty


Re: Questions.....does wireless now work correctly with latest updates AND does your Sky Safari 6 Pro allow multiple Park positions now.

Allen Ruckle
 

Yes and NO,

The upgrade for the iPad iOS  v 1.8.+  does everything added for my A-P Mach2 GTO.    I began to wonder if the Mac OS version would be updated with the new A-P features.  

On March 31, the Mac OS version 1.8.0 was of SkySafari was released.   At first appears to have the A-P park Home, 3, & 4 positions added.  however upon trying it out with my MacBook Pro laptop I was surprised to find out that the selection of the Home Position goes to Position 4,   Selecting Park 3 goes to Park Position 4,   Selecting Park Positon 3.    It is nice to now be able to choose a park position on shut down but It would help if it parked in the position 3 when selecting position 3.   Since the A-P, APCC manual describes the Home Position as NCP with counterweight down, Sky Safari should send the scope position to NCP counterweight down.

On April 7th  an update to Sky Safari 1.8.0 was updated to 1.8.1,   However correcting the park positions was not included in that update for my MacBook pro with the Mach2 GTO attached.

I attempted to notify Simulation Curriculum of the issue on April 8th but my attempts to register an account to their SkySafari forum were not successful.  

Howard, Please bring this issue to them since I have been unable to.

aruckle


Re: Side-by-side saddle and dovetail suggestions

Roland Christen
 


Also, the refractor was for imaging but the CFF was mainly visual and I'd often want to use each but at different targets.
You need another mount Smile

Rolando


-----Original Message-----
From: mjb87 via groups.io <mjb87@...>
To: main@ap-gto.groups.io
Sent: Mon, Apr 19, 2021 2:33 pm
Subject: Re: [ap-gto] Side-by-side saddle and dovetail suggestions

Hi Mike,

I mounted a CFF300 (about 38lbs) and my 130mm GTX on an 1100 mount. With all accessories I was pushing the limits at about 105lbs. I mounted the DOVELM162 sideways on the mount and then used the 18" SBS plate in that. I then mounted the DOVELM162 on one side (for the CFF300) and for the refractor I used the shorter 10"  saddle in order to save weight.  The challenge was that I was fully loaded on the counterweight bar as you can see.



Given the diameter of the C11 I think you will need to use the full 18" SBS plate. Unfortunately, the combination of the two 16" saddles, the 18" SBS and the 10" saddle meant that I was carrying a lot of weight even before I got to the telescopes.

It did work but had disadvantages. For one, whichever telescope was on the "down" side barely cleared the walls. Also, the refractor was for imaging but the CFF was mainly visual and I'd often want to use each but at different targets.

Marty

--
Roland Christen
Astro-Physics


Re: Side-by-side saddle and dovetail suggestions

mjb87@...
 

Hi Mike,

I mounted a CFF300 (about 38lbs) and my 130mm GTX on an 1100 mount. With all accessories I was pushing the limits at about 105lbs. I mounted the DOVELM162 sideways on the mount and then used the 18" SBS plate in that. I then mounted the DOVELM162 on one side (for the CFF300) and for the refractor I used the shorter 10"  saddle in order to save weight.  The challenge was that I was fully loaded on the counterweight bar as you can see.



Given the diameter of the C11 I think you will need to use the full 18" SBS plate. Unfortunately, the combination of the two 16" saddles, the 18" SBS and the 10" saddle meant that I was carrying a lot of weight even before I got to the telescopes.

It did work but had disadvantages. For one, whichever telescope was on the "down" side barely cleared the walls. Also, the refractor was for imaging but the CFF was mainly visual and I'd often want to use each but at different targets.

Marty


Side-by-side saddle and dovetail suggestions

michael mccann
 

Hi
trying to mount C11 edge, 130mm and 80mm refractors on AP mount. The Astro-Physics mounts offer a variety of saddle and dovetail options. I’m looking for recommendations and links/images of how AP users resolved this. 


thanks

Mike

1781 - 1800 of 79681