Date   

Re: Interesting Behavior with APCC Pro and Pegasus Astro UPBv2

John Jennings
 

Yes Yes Yes Yes!!!!!!!!!

I've been diagnosing a "mount problem" for 2 weeks. Mach1, APPC Pro, AP155.+Flattener. Perfect round stars on 8 minute unguided exposures repeated one night after a new model. Next week, bad bad bad carrot!!!!!  Tore the mount apart, cleaned all gears,  re-greased, re-meshed, reset backlash on RA  axis and set perfect balance with pinion disengaged (remove gear), generally spent 2 days on mount mechanics.  It absolutely looked like the tracking rate was incorrect.... New medium model, no dice! 

Same Pegasus UPBV2 with latest software.... Did not have this behavior for quite sometime. Not to complain, but Pegaus has had a lot of bugs in their software. I've updated my system 3 times for bugs introduced in new versions. Twice in 24 hours. 

Saw this post and checked the temp in APPC Pro window. Sure enough, 65 degrees C reported. Pegasus reports 65 degrees F in its box.  I would have been searching for another month without this post. Gonna try it tonight with manual temp input. I was so careful about entering the station pressure too. It's always something.

John


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

Robert Berta
 

The latest Sky Safari Pro release has a new issue with the time. You can set the time correctly but it will be an hour behind....(check at the upper right to see what time is shown). I have verified this with two different Android devices. Both had correct time before but now lagging one hour. For the time being you can just manually work around this. I am a BETA tester and have notified them of issue. If you have the notice that an update is available you may want to hold off a bit until it is addressed. I don't know if this is the same issue with the IOS version. I also don't know if the non BETA version has this or not as I have the BETA version.


Re: Powering Remote Imaging Systems

Ben Koltenbah
 

Steve:

I also recommend you take a look at OnLogic.  They have a wide selection of units including fanless, extended temperature range components if that's a concern, lots customization.  I have two computers from them, and they have performed very well.  You mentioned your need for serial ports.  Many of their configurations have multiple ports and expandability.

Ben


Re: Interesting Behavior with APCC Pro and Pegasus Astro UPBv2

W Hilmo
 

Thanks for the response.

 

I’m using the latest version of the Pegasus Astro software for the UPBv2, so it sounds like I need to contact them regarding the temperature reporting issue.  I’ve not yet confirmed that after switching back to Celcius, that it restores the unguided accuracy.  I should be able to give that a try tonight.

 

As for the Advanced Sequencer, I saw it for the first time yesterday.  I was expecting a UI similar to the original sequencer, which it’s not – but I think that it’s better.  I really like to flexibility.  I’m already thinking ahead to when Astro-Physics updates APCC to support the new few-stars tracking model that they introduced with the Mach2.  It would be really cool to write a script to sample and plate solve 6 or 8 points along the target’s declination for unguided imaging, and then have NINA invoke the script at the start of an imaging session.

 

-Wade

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Dale Ghent
Sent: Tuesday, April 20, 2021 4:34 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Interesting Behavior with APCC Pro and Pegasus Astro UPBv2

 

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: 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

5221 - 5240 of 83125