In terms of processing power/processor selection, you do not need much for general astrophotography image capture and dome control.  You only really need faster processors when you get into image processing on-board and planetary video.  So if you plan to use the NUC just to capture images, control the mount, track the guide star, etc, then you can get away with something as simple as a Google Playbook.  If you are going to do CMOS with lots of sub frames, then you would want to put more money into the storage.  If you are going to do planetary video with concurrent processing, then you will want to invest more into the processing speed.  I don't have one of these, but Primaluce lab sum up the differences here:  https://www.primalucelab.com/blog/support/eagle4-s-or-pro-which-model-to-choose-quale-modello-scegliere/

Linwood,

From the log file, I eliminated all possibilities except for manual double-clicking of the park-status on APCC's status bar, which matches the expected command sequence from that action (two Q commands and the KA).

So, is it possible you had double-clicked the park field in the status bar?

-Ray

Thanks. Everything's put away, but not firing it up to look until I am operating on more sleep.

OK, I lied, curiosity got the better of rational steps like sleeping. Found the :KA# (at 5:46:33.247) but have no idea where it came from.

Also, the ASCOM log is weird, it jumps from 20:03 to 6:29 at an unpark, but that's an unpark I did after the sequence completed and parked so I could do flats. It's way later than my unpark done about 5:56am to fix the park that occurred then. Weird. But including it.

So here's the logs. Again -- I'm pretty sure I hit some button or did something, too big a coincidence I was changing things and it parked -- but odd that there was a several minute delay, or seemed to be. I would be very curious what I did.

https://drive.google.com/file/d/1LCk-aief4JtknRSBNTzKHQwWC-SRiaG4/view?usp=sharing

I also reviewed the rather detailed NINA logs at that time. It was in the middle of a 300s exposure. The exposure started at 5:46:07 and completed at 5:51:11, so it really was not doing anything at the point it parked. PHD2 was guiding at the time.

Now sleep.... 😊

Ray said:

The title on that page says this is for mounts "Shipped prior to 11-13-00".
Just to be clear, that's November 13th, 2000 -- almost 21 years ago. :-)

Sigh... the downside of Google, you land mid-page and never even look at the top. ☹

The command to park the mount is ":KA#" in all firmware that can be used with APCC.

Additionally, the mount may auto-park if you disconnect from APCC for a short period, or if the mount loses power. And, if you double-click the park status field in the very lower left of APCC's main window, it will toggle park.

Thanks. Everything's put away, but not firing it up to look until I am operating on more sleep. Clouds and testing a new imaging train kept me awake way too much of the night.

Note my search for :Me# was based on the last paragraph in this document:

https://astro-physics.info/tech_support/mounts/command_lang.htm

The title on that page says this is for mounts "Shipped prior to 11-13-00".

Just to be clear, that's November 13th, 2000 -- almost 21 years ago. :-)

The command to park the mount is ":KA#" in all firmware that can be used with APCC.

Additionally, the mount may auto-park if you disconnect from APCC for a short period, or if the mount loses power. And, if you double-click the park status field in the very lower left of APCC's main window, it will toggle park.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of ap@CaptivePhotons.com
Sent: Sunday, September 26, 2021 4:37 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] AP1100AE Unexpected park?

Ray wrote:

I've been staring at logs and cannot figure out why it parked. I see
in APCC logs the unpark dialog and process, but nothing about parking
(I searched for ":Me#" which is what the documentation says does a park, also the "*PARK" command I've

seen when it parks in a position).

There are various ways that the mount can park, but ":Me#" is not one of them. That command moves the

mount East at the current

move rate, which is usually the guide rate. >Also, be careful trying to decipher the commands starting with

"*". Those are commands from the

AP V2 ASCOM driver to APCC, not to the mount. When APCC gets one of those commands, it interprets

them and can do anything from a simple

response to invoking a multi-state operation such as parking.

If you want to zip and post a link to the log files I will take a look. Or, if you desire to look for yourself, you

can search for the reponses

to the :GOS# command. The mount is parked when the first character of the response turns to a "P",

I'm tearing down now to bring it in, will look later after I get some sleep. Thanks for the quick response.

Note my search for :Me# was based on the last paragraph in this document:

https://astro-physics.info/tech_support/mounts/command_lang.htm

But I'll look as described, and if not found will send off to you. Thanks.

Oddly the AP_ASCOM log ended hours earlier, not sure why.

To save disk space, the ASCOM driver will stop logging a few minutes after the mount parks.

Hmmm... so the ASCOM log ended about 10pm or so, and this all occurred at 5:56am. Does the logging not
restart when the mount unparks? I did park it last night, as soon as I started my first slew I realized I had not
balanced it, so hit emergency stop which does a park. Balanced (it was close), unparked, and the night
continued, but the ascom log stopped around then?

Check the actions you have set when your mount hits your horizon limits for example. One of them is to Park. 

Also if there was a disconnection between APCC and the mount for a pre-determined length of time (typically 1 min) one of the options is for the mount to Park. I have this set in APCC to Park 2. If for example your PC restarts or crashes the mount will park itself and there will be nothing to show in the log (as far as I understand).

Roberto

Ray wrote:

I've been staring at logs and cannot figure out why it parked. I see
in APCC logs the unpark dialog and process, but nothing about parking
(I searched for ":Me#" which is what the documentation says does a park, also the "*PARK" command I've seen when it parks in a position).

There are various ways that the mount can park, but ":Me#" is not one of them. That command moves the mount East at the current
move rate, which is usually the guide rate. >Also, be careful trying to decipher the commands starting with "*". Those are commands from the
AP V2 ASCOM driver to APCC, not to the mount. When APCC gets one of those commands, it interprets them and can do anything from a simple
response to invoking a multi-state operation such as parking.

If you want to zip and post a link to the log files I will take a look. Or, if you desire to look for yourself, you can search for the reponses
to the :GOS# command. The mount is parked when the first character of the response turns to a "P",

I'm tearing down now to bring it in, will look later after I get some sleep. Thanks for the quick response.

Note my search for :Me# was based on the last paragraph in this document:

https://astro-physics.info/tech_support/mounts/command_lang.htm

But I'll look as described, and if not found will send off to you. Thanks.

Oddly the AP_ASCOM log ended hours earlier, not sure why.

To save disk space, the ASCOM driver will stop logging a few minutes after the mount parks.

Hmmm... so the ASCOM log ended about 10pm or so, and this all occurred at 5:56am. Does the logging not restart when the mount unparks? I did park it last night, as soon as I started my first slew I realized I had not balanced it, so hit emergency stop which does a park. Balanced (it was close), unparked, and the night continued, but the ascom log stopped around then?

Hi Linwood,

I've been staring at logs and cannot figure out why it parked. I see in APCC logs the unpark dialog and
process, but nothing about parking (I searched for ":Me#" which is what the documentation says does a park,
also the "*PARK" command I've seen when it parks in a position).

There are various ways that the mount can park, but ":Me#" is not one of them. That command moves the mount East at the current move rate, which is usually the guide rate. Also, be careful trying to decipher the commands starting with "*". Those are commands from the AP V2 ASCOM driver to APCC, not to the mount. When APCC gets one of those commands, it interprets them and can do anything from a simple response to invoking a multi-state operation such as parking.

If you want to zip and post a link to the log files I will take a look. Or, if you desire to look for yourself, you can search for the reponses to the :GOS# command. The mount is parked when the first character of the response turns to a "P",

Oddly the AP_ASCOM log ended hours earlier, not sure why.

To save disk space, the ASCOM driver will stop logging a few minutes after the mount parks.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of ap@CaptivePhotons.com
Sent: Sunday, September 26, 2021 3:38 AM
To: main@ap-gto.groups.io
Subject: [ap-gto] AP1100AE Unexpected park?

New AP1100AE and novice imager so I am pretty sure I caused this, but would like to understand how and
cannot find it in the logs...

Woke up a hour or so before dawn, rolled over and connected the phone to check on how things were going.
Guiding had gotten bad (ok, my standards have gone up, guiding had degraded to around 0.4" RMS). It
looked to be chasing something. I poked around and realized I had the pointing/tracking corrections on even
though I did not build a model; it was running a very small model from a prior night after quite a lot of
changes and setup movement. Mea culpa. Turned off pointing and tracking corrections, watched for 5
minutes or so - better.

Was about to go back to sleep when the familiar and awful "star lost" ding started. Long story shortened: The
mount was parked. Stars streaking. Nowhere near meridian or horizon.

I unparked, recentered, started everything up again and it is running great, guiding back at 0.3" now after
about 30 minutes.

I've been staring at logs and cannot figure out why it parked. I see in APCC logs the unpark dialog and
process, but nothing about parking (I searched for ":Me#" which is what the documentation says does a park,
also the "*PARK" command I've seen when it parks in a position). I also looked at NINA's log and see nothing
other than the star lost stuff. Oddly the AP_ASCOM log ended hours earlier, not sure why. There's no
indication of a timeout that I can find (I'm ethernet cable connected, NUC is right by the mount).

I'd like to think I hit a button. There's no park button visible on the screen I had up, but there is an emergency
stop; the apcc log doesn't have "stop" or "emergency" in it anywhere though (no clue what to look for, and it's
imaging so don't want to try it).

What could I have done that caused a park?

What can I look for in the logs (which?) to find out what happened? At this point it's mostly curiosity, since I
just by the fact I was changing things (and on a cell phone at that time) I am sure it was something i did. But I
would like to know what. And learn in the process more about debugging through the logs.

Linwood

Very well done, congratulations.

New AP1100AE and novice imager so I am pretty sure I caused this, but would like to understand how and cannot find it in the logs... 

Woke up a hour or so before dawn, rolled over and connected the phone to check on how things were going.  Guiding had gotten bad (ok, my standards have gone up, guiding had degraded to around 0.4" RMS).  It looked to be chasing something.  I poked around and realized I had the pointing/tracking corrections on even though I did not build a model; it was running a very small model from a prior night after quite a lot of changes and setup movement.  Mea culpa.  Turned off pointing and tracking corrections, watched for 5 minutes or so - better.

Was about to go back to sleep when the familiar and awful "star lost" ding started.  Long story shortened: The mount was parked. Stars streaking.  Nowhere near meridian or horizon.

I unparked, recentered, started everything up again and it is running great, guiding back at 0.3" now after about 30 minutes.

I've been staring at logs and cannot figure out why it parked.  I see in APCC logs the unpark dialog and process, but nothing about parking (I searched for ":Me#" which is what the documentation says does a park, also the "*PARK" command I've seen when it parks in a position).  I also looked at NINA's log and see nothing other than the star lost stuff.  Oddly the AP_ASCOM log ended hours earlier, not sure why.  There's no indication of a timeout that I can find (I'm ethernet cable connected, NUC is right by the mount). 

I'd like to think I hit a button.  There's no park button visible on the screen I had up, but there is an emergency stop; the apcc log doesn't have "stop" or "emergency" in it anywhere though (no clue what to look for, and it's imaging so don't want to try it). 

What could I have done that caused a park?

What can I look for in the logs (which?) to find out what happened?   At this point it's mostly curiosity, since I just by the fact I was changing things (and on a cell phone at that time) I am sure it was something i did.  But I would like to know what.  And learn in the process more about debugging through the logs.

Linwood

Thx for the pointer on minix.   I’ve seen these and wondered if they were underpowered.   Now that I think about it the minix might be appropriate for mount 2 which I’m thinking will initially be doing mostly solar ha imaging.  

Ok thank you Ray.

I pops up on some slews only. 

V1.9.0.11 is working perfectly for me too.

Thanks,

Rouz

Any part of the Cygnus loop is a treat for visual astronomers and astrophotographers alike. The many intricacies of its structure make it unique in the night sky.

I shot Pickering's Triangle through narrowband filters with the intent of producing a Hubble palette (SHO) image. However, the SII signal was largely superimposed on the Ha and didn't add anything useful, so I left out the SII and made a bicolor image with the other two filters. Here's the link:

https://astrob.in/lyde7q/B/

Thanks for looking. 

Glenn Diekmann

On Sat, Sep 25, 2021 at 03:46 PM, ap@... wrote:

Finally there’s using three different AC -> DC adapters.  I’m a proponent of grounding all of those together so there are no floating voltages against their ground, because if there are, these tend to flow over other connections not intended to carry significant current, notably USB cables. 

  In general, it's not necessary to do more than connect your AC adapters into outlets which are closely coupled, as on a power strip. All AC adapters with two-prong plugs, and most with three prong plugs provide isolation between the DC output and the contacts in an AC outlet. If you use a power strip near the telescope and plug all of the adapters into it, you should have no problems at all. Even if you run an Ethernet cable back into your house, there's little risk of problems because the connections are transformer coupled on each end (meaning that there's no direct path for current to flow from the Ethernet cable to the electronics on either end). USB is a little different since it relies upon current flow at both ends of the cable, so you may not want to run that between your office and telescope, however connections between cameras, filter wheels, computers, etc., at the telescope should not present any issues.

  The recommendation to ensure that you have GFCI protection for any line voltage used outdoors is a good one. An inexpensive ground fault detector is a worthwhile tool for any homeowner. These provide a button that allows a small current to pass between line voltage and ground, which will trip a GFCI if there is one in the circuit. If you plug the tester into an outdoor outlet and the lights on the tester don't go off as soon as the test button is pressed, either the existing GFCI has failed or there wasn't one to begin with. That's not a good thing.

  In many houses, the GFCI protecting outdoor outlets is installed in one of the bathrooms. If you have a GFCI in a bathroom, you can plug a lamp into an outdoor outlet then press the test button the GFCI. If the lamp goes off, the outdoor circuit is properly protected.