Date   

Re: APCC feature request - Get time from mount

Keith Olsen
 

On Wed, Oct 6, 2021 at 11:00 AM, W Hilmo wrote:
I'm not sure what you mean by "they are both timed exactly".
What I mean is the GPS Status section UTC Time and my pc system time are exact.   I'm assuming that the UTC Time field in the GPS Status section of APCC Pro is getting the time from the MGBOX2 gps info and not from the pc system time.  


Re: #APCC #Mach2 - 3D viewer weird scope position while it is parked (or even while slewing sometimes) #apcc #APCC

Roland Christen
 

Check your keypad time setting. It has to be the same as your computer time if you are going to switch back and forth between the two.

Roland

-----Original Message-----
From: Seb@stro <sebastiendore1@...>
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Sent: Wed, Oct 6, 2021 3:09 pm
Subject: Re: [ap-gto] #APCC #Mach2 - 3D viewer weird scope position while it is parked (or even while slewing sometimes) #apcc #apcc #mach2

Correction: the mount is at *park3* right now (moved it with the keypad to do my flats this morning). Re-attached screenshot, so you can see in decent resolution. Maybe that is the issue (re-parking from the keypad) ?
 
Hi Roland,

Thanks for your reply. My computer is permanently connected to Internet and time is correct. 

One important thing I omitted in my previous message is that, at the time I park the mount, the 3d viewer shows the correct position (park 3). But sometimes, like this morning, it gets pretty obvious. It looks like the 3d viewer shows the mount is still tracking even if it is not. See for yourself below. I am positive it still is parked at park3 right now (and not at the position showed, obviously).

Sébastien


--
Roland Christen
Astro-Physics


Re: #APCC #Mach2 - 3D viewer weird scope position while it is parked (or even while slewing sometimes) #apcc #APCC

Roland Christen
 

Nope. Makes no difference how you park it. Mach 2 ALWAYS parks the scope at the correct gear angle determined internally via the two absolute encoders. Doesn't matter where the park command comes from. Doesn't matter if it was sent to an errant position due to invalid sync or whatever, by any external client including the keypad.

APCC does NOT use the internal encoder park positions to determine the 3d Viewer orientation. It uses time and location to determine the mount's hour angle based on the last object that you synced to. Therefore the two can be out of sync by any of the three that could be in error (time, location and sync)

Roland

-----Original Message-----
From: Seb@stro <sebastiendore1@...>
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Sent: Wed, Oct 6, 2021 3:09 pm
Subject: Re: [ap-gto] #APCC #Mach2 - 3D viewer weird scope position while it is parked (or even while slewing sometimes) #apcc #apcc #mach2

Correction: the mount is at *park3* right now (moved it with the keypad to do my flats this morning). Re-attached screenshot, so you can see in decent resolution. Maybe that is the issue (re-parking from the keypad) ?
 
Hi Roland,

Thanks for your reply. My computer is permanently connected to Internet and time is correct. 

One important thing I omitted in my previous message is that, at the time I park the mount, the 3d viewer shows the correct position (park 3). But sometimes, like this morning, it gets pretty obvious. It looks like the 3d viewer shows the mount is still tracking even if it is not. See for yourself below. I am positive it still is parked at park3 right now (and not at the position showed, obviously).

Sébastien


--
Roland Christen
Astro-Physics


Possible bug in APCC with park?

Tom Blahovici
 

Last night from Voyager, I did a move to the zenith and stopped tracking so I could do flats. When they were finished I attempted to park the scope. It reported it was parked. My usual location is park 3.
I closed out Voyager completely, and attempted to start tracking again.
Apcc reported the mount as parked. Pointing at the zenith.
I then did an unpark and tried a park 3 at the point. It went back to the zenith.
I had to use apcc, and then reopen it. Then. I could do a park 3.
I guess Voyager could have set a new park position but then why wouldn't apcc park at 3 like I requested?
Thanks 


Re: #APCC #Mach2 - 3D viewer weird scope position while it is parked (or even while slewing sometimes) #apcc #APCC

Sébastien Doré
 

Correction: the mount is at *park3* right now (moved it with the keypad to do my flats this morning). Re-attached screenshot, so you can see in decent resolution. Maybe that is the issue (re-parking from the keypad) ?
 

Hi Roland,

Thanks for your reply. My computer is permanently connected to Internet and time is correct. 

One important thing I omitted in my previous message is that, at the time I park the mount, the 3d viewer shows the correct position (park 3). But sometimes, like this morning, it gets pretty obvious. It looks like the 3d viewer shows the mount is still tracking even if it is not. See for yourself below. I am positive it still is parked at park3 right now (and not at the position showed, obviously).

Sébastien


Re: #APCC #Mach2 - 3D viewer weird scope position while it is parked (or even while slewing sometimes) #apcc #APCC

Sébastien Doré
 

Hi Roland,

Thanks for your reply. My computer is permanently connected to Internet and time is correct. 

One important thing I omitted in my previous message is that, at the time I park the mount, the 3d viewer shows the correct position (park 2). But sometimes, like this morning, it gets pretty obvious. It looks like the 3d viewer shows the mount is still tracking even if it is not. See for yourself below. I am positive it still is parked at park2 right now (and not at the position showed, obviously).

Sébastien




De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de Roland Christen via groups.io <chris1011@...>
Envoyé : 6 octobre 2021 14:43
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] #APCC #Mach2 - 3D viewer weird scope position while it is parked (or even while slewing sometimes) #apcc #apcc #mach2
 
The Mach2 mount always parks the actual telescope at the same gear angle - that is controlled by the internal encoders. The parks are independent of time or hour angle. Same with Home.

APCC calculates scope position using time and hour angle. Any error in sync or recal will affect where the scope is shown in the viewer. In your case it appears that your computer clock time is off by 6 hours. It doesn't appear that you did an errant sync because the viewer shows the Dec axis to be correct. Just the RA axis is off by 6 hours, so I suspect either a 6 hour clock time offset somewhere in your applications or you have a 6 hour error in the longitude.

Roland
_._,_._,_


Re: #APCC #Mach2 - 3D viewer weird scope position while it is parked (or even while slewing sometimes) #apcc #APCC

Roland Christen
 

The Mach2 mount always parks the actual telescope at the same gear angle - that is controlled by the internal encoders. The parks are independent of time or hour angle. Same with Home.

APCC calculates scope position using time and hour angle. Any error in sync or recal will affect where the scope is shown in the viewer. In your case it appears that your computer clock time is off by 6 hours. It doesn't appear that you did an errant sync because the viewer shows the Dec axis to be correct. Just the RA axis is off by 6 hours, so I suspect either a 6 hour clock time offset somewhere in your applications or you have a 6 hour error in the longitude.

Roland

-----Original Message-----
From: Seb@stro <sebastiendore1@...>
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Sent: Wed, Oct 6, 2021 12:53 pm
Subject: [ap-gto] #APCC #Mach2 - 3D viewer weird scope position while it is parked (or even while slewing sometimes) #apcc

Hi,

When I use the 3D viewer in APPC (which is a great feature), it seems to get de-synchronized from the mount position sometimes. Like in the example  below where the mount was parked at park 2 at around 9:30 AM (time of the screenshot is 12:30). 

One thing that might explains this is I do not quite fully understand what "correctly calibrated with the night sky" means in the warning window when the 3D viewer is launched. 

I would have thought "Find Home" (encoder tab) would be a valid calibration process for encoder mount in this regards. Or maybe the sync at the beginning of an APPM run, or from a third party software, but it doesn't seem to prevent that from happening, so obviously I'm missing something. My prerogative was that since the mount (with encoders) always knows where it is at, the 3D viewer should too, but it seems that at least in my case, it does not. 

From the manual, I understand this warning/pre-requisite is probably there for non-encoder mount when clutches are loosen but I couldn't find any information relative to this for encoder mounts or more specifically for the Mach2 (which is one of a kind species in itself, I know). But I might have missed it too. 



Hitting Sync -> Re-sync 3D view does fix it but it would be nice (and less scary, especially when slewing at 1800X) if it were always showing the correct orientation. 

Still, it works 95% of the time. Just trying to understand how I can get the last 5%... I can provide logs if required, but I feel it's just me not doing something I should. Anybody can pinpoint where I need to correctly "calibrate on the night sky", if that is indeed my issue ?

Thanks,

Sébastien




--
Roland Christen
Astro-Physics


#APCC #Mach2 - 3D viewer weird scope position while it is parked (or even while slewing sometimes) #apcc #APCC

Sébastien Doré
 

Hi,

When I use the 3D viewer in APPC (which is a great feature), it seems to get de-synchronized from the mount position sometimes. Like in the example  below where the mount was parked at park 2 at around 9:30 AM (time of the screenshot is 12:30). 

One thing that might explains this is I do not quite fully understand what "correctly calibrated with the night sky" means in the warning window when the 3D viewer is launched. 

I would have thought "Find Home" (encoder tab) would be a valid calibration process for encoder mount in this regards. Or maybe the sync at the beginning of an APPM run, or from a third party software, but it doesn't seem to prevent that from happening, so obviously I'm missing something. My prerogative was that since the mount (with encoders) always knows where it is at, the 3D viewer should too, but it seems that at least in my case, it does not. 

From the manual, I understand this warning/pre-requisite is probably there for non-encoder mount when clutches are loosen but I couldn't find any information relative to this for encoder mounts or more specifically for the Mach2 (which is one of a kind species in itself, I know). But I might have missed it too. 



Hitting Sync -> Re-sync 3D view does fix it but it would be nice (and less scary, especially when slewing at 1800X) if it were always showing the correct orientation. 

Still, it works 95% of the time. Just trying to understand how I can get the last 5%... I can provide logs if required, but I feel it's just me not doing something I should. Anybody can pinpoint where I need to correctly "calibrate on the night sky", if that is indeed my issue ?

Thanks,

Sébastien




Re: APCC feature request - Get time from mount

ap@CaptivePhotons.com
 

W Hilmo wrote:

 

  • If you want to sync the computer time from GPS, you will need software specifically to do that.  I use NMEATime2, which installs as a service and keeps the computer time in sync.  Note that NMEATime2 cannot connect to the GPS at the same time as any other software, so I have two different GPS receivers.  One of them is in my MGBoxV2, with APCC Pro connected.  The second one is a cheap USB receiver, with NMEATime2 connected.

There is another option with potentially more accuracy (relevant possibly if you chase satellites), and that is build a small time server, easiest with a raspberry pi.  All the software is native to it, you wire up (not plug in) a GPS capable of 1PPS signals (most of the PC board versions are), and  you have a VERY accurate time source.  Then run NTP on the rPi, and run a NTP client on the computer running APCC, probably the best known (and free) is the Meinberg one.

A nice aspect of this is no COM ports and all their flakiness involved, no running-with-privilege, it just sits and works, and updates the clock in a service.  You can also set the Meinberg to use a fallback of internet time so if the time server (perhaps on your mount) is not available, it still maintains good time.  APCC gets the system clock, APCC sets the mount, all are in sync.

This (+/- your network) is going to be more accurate than a GPS USB connected to the PC. But again, almost anything is plenty accurate for anything but fast moving satellites – DSO objects do not need sub-millisecond time, except for bragging rights.

The whole time server can be built for probably $50-75 depending on what kind of casing you want for it, and requires a few solder joints for the 4 (if I recall) module pins to the GPIO pins, and some configuration (lots of tutorials online to do it). PPS or 1PPS or stratum 1.  PPS is Pulse Per Second (sometimes prefaced with 1) which allows a more accurate determination of the 1-per-second NMEA messages, since those are serial encoded and so irregular in timing.  USB cannot do PPS.   Here’s my GPS module in a project box (rPi is elsewhere).  The white gunk is adhesive from trying different positions, the thing on the left wall is the separate antenna.  No jokes on my soldering, it’s not something I am good at, so you also can definitely do it.  For size scale that’s cat 5e cable.

Below is an example from my telescope’s NUC.  At present the time server is off line, the mount in the house, so it’s getting time from my router.  The .234 address would be a wired ethernet connection to the time server, the .3 is a wifi connection to the time server.  All else fails it uses the PC’s real time clock. So lots of failover possibilities because it’s real NTP.

But again – no reason to obsess if you do planetary or DSO – a sundial is almost accurate enough for that, certainly a USB GPS, but even a cell phone time set on the PC.  And a lot of the USB tools do some long term averaging of the delays to get better accuracy than the actual connection gives with each pulse, so they are probably good enough for satellites also.  


Re: APCC feature request - Get time from mount

Konstantin v. Poschinger
 

Hi Howard,

I use the MGBOX2 and I do not shut it down, cause I use the temperature humidity and pressure information in APCC!

Konstantin


Konstantin v. Poschinger

Hammerichstr. 5
22605 Hamburg
040/8805747
0171 1983476

Am 06.10.2021 um 17:24 schrieb Howard Hedlund <howard@...>:

The MGBOX2 has its own software app.  I am not positive of this, but I believe that this software cannot run simultaneously with a program like APCC.  However, The MGBOX2 could be used at the start of a session to calibrate the computer system clock.  Then, shut down the MGBOX2 software and start APCC.  APCC will then be getting the same time source that was used for the PC.


Re: APCC feature request - Get time from mount

W Hilmo
 

Neither the MGBox app, nor APCC, update the computer clock.

I'm not sure what you mean by "they are both timed exactly".  APCC does (by default) update the mount's time from the computer clock, so they will always be in sync.  Of course, if the computer clock is off, they'll both be in sync to whatever time the computer thinks it is.  Also, if the computer running APCC is internet connected, it is likely syncing to a time service independent of APCC or any GPS receiver, so in that case, the computer clock may be very accurate.

If you want to sync the computer time from GPS, you will need software specifically to do that.  I use NMEATime2, which installs as a service and keeps the computer time in sync.  Note that NMEATime2 cannot connect to the GPS at the same time as any other software, so I have two different GPS receivers.  One of them is in my MGBoxV2, with APCC Pro connected.  The second one is a cheap USB receiver, with NMEATime2 connected.

On 10/6/21 9:01 AM, Keith Olsen wrote:
I also have the MGBOX2 and APPC Pro does show the UTC time from the box.  What I don't know for sure if APPC uses that time to update the computer system clock.  It looks to me like it does because they are both timed exactly when I run APPC Pro.  But I could be wrong about this.


Re: APCC feature request - Get time from mount

Dale Ghent
 

Yes, COM port access is exclusive to one application at a time.

There are systems such as the free com0com and commercial Eltima (which is what APCC uses) that can sit on top of a COM port and replicate it however many times. At least in the com0com case, this works best for apps that only read from the COM port, which is what an app that can read NMEA sentences from a GPS does. So at the expense of some additional latency, a GPS' COM port can be replicated such that APCC and another app can read the NMEA sentences coming off the receiver. I've used this kind of setup with the NMEATime2 app to keep my PC's clock properly sync'd and let APCC read from the GPS at the same time.

On Oct 6, 2021, at 12:33, Andrea Lucchetti <andlucchett@...> wrote:

MGBOX is a cool little piece of hardware.
The only issue for me is a tendency to "steal" USB ports (COM ports).
I need to remember to add it at the end otherwise I run into issues with APCC.
Probably it is my fault in setting some of the parameters.
Andrea

Il giorno mer 6 ott 2021 alle ore 18:08 Worsel via groups.io <bryancashion@...> ha scritto:
Besides GPS coords., MGBOX also provides T, P, and RH. APPC Pro uses this data for adjusting the APPM generated model

Bryan



Re: APCC feature request - Get time from mount

Andrea Lucchetti
 

MGBOX is a cool little piece of hardware.
The only issue for me is a tendency to "steal" USB ports (COM ports).
I need to remember to add it at the end otherwise I run into issues with APCC.
Probably it is my fault in setting some of the parameters.
Andrea

Il giorno mer 6 ott 2021 alle ore 18:08 Worsel via groups.io <bryancashion=yahoo.com@groups.io> ha scritto:
Besides GPS coords., MGBOX also provides T, P, and RH.  APPC Pro uses this data for adjusting the APPM generated model

Bryan


Re: APCC feature request - Get time from mount

Worsel
 

Besides GPS coords., MGBOX also provides T, P, and RH.  APPC Pro uses this data for adjusting the APPM generated model

Bryan


Re: APCC feature request - Get time from mount

Keith Olsen
 

I also have the MGBOX2 and APPC Pro does show the UTC time from the box.  What I don't know for sure if APPC uses that time to update the computer system clock.  It looks to me like it does because they are both timed exactly when I run APPC Pro.  But I could be wrong about this.


Re: APCC feature request - Get time from mount

 

MGBox V2 has ascom drivers for connecting to the device, including GPS

the OP was talking about a need for getting PC time accurate, and while i love my MGBox v2, it's a lot more than a $18 GPS for the PC

On Wed, Oct 6, 2021 at 8:35 AM Worsel via groups.io <bryancashion=yahoo.com@groups.io> wrote:
FYI

I have an MGBOX2.  APCC Pro accesses it directly, not through the MGBOX2 app, AND automatically.  See GPS Tab, Connection section. 

Bryan



--
Brian 



Brian Valente


Re: APCC: RA limit reached while in Park 3? #APCC

Glenn
 

Thank you, Howard, I’ll talk to you soon.

Kind regards,

Glenn


Re: APCC feature request - Get time from mount

Konstantin von Poschinger
 

I forgot to mention, that you should use the MGbox V2 ASCOM Local Server!




Konstantin


Konstantin v. Poschinger

Hammerichstr. 5
22605 Hamburg
040/8805747
0171 1983476

Am 06.10.2021 um 17:35 schrieb Worsel via groups.io <bryancashion@...>:

FYI

I have an MGBOX2.  APCC Pro accesses it directly, not through the MGBOX2 app, AND automatically.  See GPS Tab, Connection section. 

Bryan


Re: APCC feature request - Get time from mount

Worsel
 

FYI

I have an MGBOX2.  APCC Pro accesses it directly, not through the MGBOX2 app, AND automatically.  See GPS Tab, Connection section. 

Bryan


Re: APCC: RA limit reached while in Park 3? #APCC

Howard Hedlund
 

I'm sure this can be fixed quickly.  Give me a call at AP and we'll get it figured out.

4961 - 4980 of 86841