That was my thought with a missing "o". Maybe it sounds cool and a reference to many automobiles called "GTO".

Peter

Title says it all. Does it stand for "Grand Touring Optics". :-)

Is it based on your favorite cars like Pontiac GTO?

Peter

Does anyone know if AP still sells boxes and foam that can be used to ship a Mach 1? I know there was a recent discussion about buying boxes for the 1100GTO, but I'm wondering about the Mach1, since it's no longer in production?

Thanks,

Patrick Spencer

Ray Gralak wrote:

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?

Well, there's some line from Sherlock Holms about what remains after you eliminate all other possibilities being true, so it must be.

First, I didn’t even realize the bottom bar was active, I thought it was status only, so I learned something. At that time I was on a Android phone on an RDP client, where I drag fingers around to zoom into various parts of the screen. It's certainly possible I touched that bar, it's even possible the result was a click or double click though that usually takes more effort as you drag a pointer onto the thing you want to click, then tap it. But it's awkward working on a tiny screen and who knows. And I was half asleep.

I think I also figured out the half empty ASCOM logs, though not entirely. I keep the ASCOM driver set to default to PARK 2, since that's where a safety park will send it from NINA if it detects rain (or at end of sequence), aiming the OTA sideways not up. I keep the APCC set to Park 3, as that's where I load and unload. That means when I manually park, I do it from APCC, which I guess is rather invisible to ASCOM?

So my GUESS is that ASCOM figured out at 10pm that I parked, stopped logging. After 6am NINA parked it at the end of a sequence through ASCOM. I then unparked it in NINA to run another sequence for flats, and it started logging. What I don't quite understand is the 10pm stop was definitely from clicking on a slew-stop (I think) or emergency stop (possibly) in APCC when I realized I needed to go balance things. So not quite sure how ASCOM figured out it was parked.

Anyway, I think the logging being off was from me jumping the line, as it were, and using APCC directly so ASCOM got confused and left logging off even though it was running for hours live and unparked.

I do rather like having two different default park positions, at first that seemed redundant, but it's quite handy.

Thanks for playing Sherlock for my mystery. I learned several things... all this actually started by not remembering to turn off a questionable model, so I got to see how that affected guiding as well. My guess is that smaller model didn’t even cover the section of sky I was in by 5am -- I haven't had a chance to do the whole, entire, cloud free sky since I got the mount. Dry season is coming, I hope....

Thanks again,

Linwood

On Sep 26, 2021, at 6:58 AM, Ray Gralak <iogroups@...> wrote:

If you are planning high-speed+high-resolution video capture for solar imaging, then you may want to be careful with the specs of the computer.

Yes. I was thinking the same after I sent the earlier msg. Thx for mentioning it.

Thank you, Andrea.

Glenn

Hi Jeff,

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.

If you are planning high-speed+high-resolution video capture for solar imaging, then you may want to be careful with the specs of the computer. It can take more CPU to handle high megapixel and/or high frame rate video. Also, disk performance will be a factor, so choose a computer with at least a SATA SSD, and maybe even an x4 NVME SSD.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Jeffc
Sent: Saturday, September 25, 2021 9:33 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Off Topic-NUC Computer

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.

As for the 2012 i5 Mac mini… I run SGP, APCC, ASTAP, TheSky5 (old school, I didn’t like X), MGBox,
sharpcap (polar alignment) , UPBV2 , with a QHY-268m camera.


The i5 performance is more than adequate afaict. (I use a separate laptop for processing - Apple Mackbook
Air w/ the M1 processor. The MBA is also used for RemoteDesktop to run SGP, etc, on the MacMini at night.)

-jeff


On Sep 25, 2021, at 7:05 PM, Bill Long <bill@...> wrote:




CDC and HNSKY Planetariums do not cause any problems on my current MiniX so they should work
well on this one.

SkyX works fine as well, but I do not pan around SkyX looking at the planetarium directly, I only use it
for object lookup which is instant. SkyX Image Link does delay on my MiniX a few seconds longer than a
normal machine would. I have moved over to ASTAP for everything though, which is also practically instant.

-Bill

________________________________

From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Seb@stro
<sebastiendore1@...>
Sent: Saturday, September 25, 2021 6:58 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Off Topic-NUC Computer

I can also vouch for this particular Minix model. I've been using the J50C-4 Max since last April with no
issue whatsoever. I can indeed run a powerbox advance client, Ascom OCH, APPC, NINA (Canon DSLR),
PHD2 (QHY5III-174M guider), APT (ASI183MC Pro), and SharpCap Pro (Polemaster) all at once and I get a
snappy user experience.

Adding Stellarium to the mix shows the hardware's limit though (GPU is an onchip Intel UHD 605 with
shared memory) and significantly impairs performance. So I just don't run it while imaging.I suspect it would
be the same with other realtime planetarium software.

One thing to account for is the relatively short range of the internal WiFi patch antennas. These are
perfect for indoor usage or if you have an outdoor signal booster in your backyard for example. But in my
case, I just bought 2 of these (watch out for the U.Fl connector type on your wifi adapter if you go this route) :

https://www.amazon.ca/gp/product/B07QKF18KM/ref=ppx_yo_dt_b_asin_title_o03_s00?ie=UTF8&psc=
1
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.amazon.ca%2Fgp%2Fproduct%2
FB07QKF18KM%2Fref%3Dppx_yo_dt_b_asin_title_o03_s00%3Fie%3DUTF8%26psc%3D1&data=04%7C01%
7C%7Ce5e6e9bc665b4d3785b808d980912538%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63768
2183146812471%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
LCJXVCI6Mn0%3D%7C1000&sdata=ojufO7LNdDbGKnOn84cytk1RYpqRxvL762h5vEUlAW4%3D&reserved=0

Monted them on a side panel and it almost quadrupled the orignial range around my house (about 70
feet radius now) with no other modifications. Enough to reliably connect to my home router from my backyard
portable setup in most places.

Of course ethernet works just fine too for that matter.

It is true the 12V input is protected and needs to be below about 13.V for it to power on but I found that
to be a problem only with a freshly charged battery. My workaround is to connect and power up evey other
equipment (mainly cameras through the PPBAv, heater bands and the Mach2) before hitting the power on
button. Never had any issue after I started doing that routinely.

Sébastien

________________________________

De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de Bill Long <bill@...>
Envoyé : 25 septembre 2021 19:43
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] Off Topic-NUC Computer

I dont think it would have any problems running all of that. I have a lot of devices on it. Powerbox,
MGBoxV2, PL16803 camera, CFW5-7, Ultrastar, AG Thermal box, Nitecrawler, etc and mine is the older
version with less power.

________________________________

From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Steve Reilly
<sreilly24590@...>
Sent: Saturday, September 25, 2021 4:40 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Off Topic-NUC Computer


For me with APCC, ACP Expert, MaxIm, FocusMax, and the rest of the automation software/hardware
and weather stuff that may be pushing it for me but then again I often over do the specs to be safe.



-Steve



From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Bill Long
Sent: Saturday, September 25, 2021 6:10 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Off Topic-NUC Computer



I use a MiniX Mini PC that works well. The specific model I use is no longer made, but they have a
newer one:



Amazon.com: MINIX NEO J50C-8SE, 8GB/240GB Intel Pentium Silver Mini PC with Windows 10 Pro (64-
bit) [Dual-Band Wi-Fi/Gigabit Ethernet/4K @ 60Hz/Triple Display/USB-C/Auto Power On/Vesa Mount] :
Electronics
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.amazon.com%2Fdp%2FB09B266
PFW%2Fref%3Dsspa_dk_detail_0%3Fpd_rd_i%3DB09B266PFW%26pd_rd_w%3Dj1OoF%26pf_rd_p%3D5d8
46283-ed3e-4512-a744-
a30f97c5d738%26pd_rd_wg%3D22BBx%26pf_rd_r%3DS5PHHRSDB2V4SB33HMEP%26pd_rd_r%3D15ec97
ba-e624-4b1b-a186-
bd93eb76e95f%26spLa%3DZW5jcnlwdGVkUXVhbGlmaWVyPUExQ1NHQlZORVpMV0pEJmVuY3J5cHRlZElk
PUEwMTQyODk0MjJHTDBLRzREQVhLRyZlbmNyeXB0ZWRBZElkPUEwMjYwMjA0NDRQQk8zRU1XWU9LJnd
pZGdldE5hbWU9c3BfZGV0YWlsX3RoZW1hdGljJmFjdGlvbj1jbGlja1JlZGlyZWN0JmRvTm90TG9nQ2xpY2s9dH
J1ZQ%26th%3D1&data=04%7C01%7C%7Ce5e6e9bc665b4d3785b808d980912538%7C84df9e7fe9f640afb435
aaaaaaaaaaaa%7C1%7C0%7C637682183146812471%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XmtHb01ZEps8f8yNo3haFTLmBTVi
x9SCxGA%2FPkVw2Uk%3D&reserved=0>



Works really good, but the one thing to keep in mind is that it really wants a 12v regulated power input.
If the voltage is too high, it wont turn on.



I run Voyager, SkyX, APCC Pro, PHD2, and my AGO Thermal Control software on it no problem. This
one has a better processor than mine as well. The Win 10 Pro they include is authentic as well, which can be a
challenge from some Amazon mini-PC products.



If you decide you want more RAM or storage you can upgrade it. 8GB of memory and 240GB of
storage should be plenty though, IMO.



-Bill

Apparently (haven't tried it but have heard) that regular Irish Spring soap shavings or pieces, placed in ziplock baggies with holes poked to let the scent out, placed around the inside base of the observatory, will keep mice away.  

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@...
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@...
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.