Date   

Re: Projecting APCC Meridian Limits on a plantetarium program

Dale Ghent
 

The Sky Atlas in NINA isn't set up internally to be extended by plugins. Despite the idea appearing to be simple, a lot of work would first need to be done to make it possible. Perhaps in the future but, for now, this first iteration of plugins was designed for extending sequencer functionality.

On Feb 17, 2022, at 19:43, Rick Darden <rick@...> wrote:

Since we have the .mlm file created by APCC for the meridian limits, for those using NINA (and Yes, I think a lot of us have moved that way. I know I won't look back) it seems a simple NINA plugin could integrated this data into the sky atlas and other NINA features.
--
Rick Darden, Key Largo, FL

Telescope location: Dark Sky New Mexico

Equipment:
Mount: AP100AE
Main Scope: AGO 12.5 f6.7, asi6200mm, Chroma LRGB, 3nm Ha/Oiii/Sii, Optec Leo
Piggyback Scope: TS80mm, QHY163m, Baader LRGB, 7nm Ha/Oiii/Sii, Rigel NSTEP
Software: APCC Pro, NINA, Stellarium and all the peripheral pieces


Re: AP driver V2 - getting runtime errors from Setup_Telescope

Ray Gralak
 

Run-time error '50003': Unexpected error
Unfortunately that is a bad sign that you probably have mismatched DLLs because of a previously installed product on your computer. It may be difficult to fix as it is not something specific to the driver. You could try uninstalling other products one at a time and then reinstalling the driver, until you find the culprit application.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of David Fischer
Sent: Thursday, February 17, 2022 4:41 PM
To: main@ap-gto.groups.io; David Fischer
Subject: [ap-gto] AP driver V2 - getting runtime errors from Setup_Telescope

On my new laptop I installed ASCOM 6.6 and the AP driver V2. This machine has Windows 10 with .NET 3.5
activated.

When I tried to run Setup Telescope I get these errors:

APSetup: Error when trying to create 'AstroPhysicsV@.Telescope': Cannot create ActiveX component.

Then after clearing that dialog box, another pops up:
Run-time error '50003': Unexpected error

= = = =

My other 2 laptops have had the AP driver successfully installed for a long time. I have not seen this error on
either one.

As a sanity check, I just downloaded and installed the same files on my desktop Windows 10 machine. On it
the Setup Telescope installed and ran correctly with no errors.

Could somebody please tell me what I've done wrong ?


Re: Projecting APCC Meridian Limits on a plantetarium program

Rick Darden
 

Since we have the .mlm file created by APCC for the meridian limits, for those using NINA (and Yes, I think a lot of us have moved that way. I know I won't look back) it seems a simple NINA plugin could integrated this data into the sky atlas and other NINA features. 
--
Rick Darden, Key Largo, FL

Telescope location: Dark Sky New Mexico

Equipment:
Mount: AP100AE
Main Scope: AGO 12.5 f6.7, asi6200mm, Chroma LRGB, 3nm Ha/Oiii/Sii, Optec Leo
Piggyback Scope: TS80mm, QHY163m, Baader LRGB, 7nm Ha/Oiii/Sii, Rigel NSTEP
Software: APCC Pro, NINA, Stellarium and all the peripheral pieces


AP driver V2 - getting runtime errors from Setup_Telescope

David Fischer
 

On my new laptop I installed ASCOM 6.6 and the AP driver V2.  This machine has Windows 10 with .NET 3.5 activated.

When I tried to run Setup Telescope I get these errors:

APSetup: Error when trying to create 'AstroPhysicsV@.Telescope': Cannot create ActiveX component.

Then after clearing that dialog box, another pops up:
Run-time error '50003':  Unexpected error

= = = =

My other 2 laptops have had the AP driver successfully installed for a long time.  I have not seen this error on either one.

As a sanity check, I just downloaded and installed the same files on my desktop Windows 10 machine.  On it the Setup Telescope installed and ran correctly with no errors.

Could somebody please tell me what I've done wrong ?


Re: Projecting APCC Meridian Limits on a plantetarium program

Rick Darden
 

The reason I asked this question is due to having a potential cable snag if I slew to the East in the normal CW down position. It is at a remote observatory and I can't fix it for another few months. But, using the opportunity limits of an APCC median map gives me access to most of the sky with this problem. I just need to know where an object lies with regard to my Eastern limit and then I'm good to go. 

I think having the ability to see your meridian limits projected onto any type of sky view application would be a useful tool. Even without my problem.
--
Rick Darden, Key Largo, FL

Telescope location: Dark Sky New Mexico

Equipment:
Mount: AP100AE
Main Scope: AGO 12.5 f6.7, asi6200mm, Chroma LRGB, 3nm Ha/Oiii/Sii, Optec Leo
Piggyback Scope: TS80mm, QHY163m, Baader LRGB, 7nm Ha/Oiii/Sii, Rigel NSTEP
Software: APCC Pro, NINA, Stellarium and all the peripheral pieces


Re: NINA fails to sync AP900 and sometimes causes random slew

Wenhan Chang
 

Hi Horia,

Thank you for helping me clarify my question.

I should have mentioned that I usually do plate-solve/sync after slewing away from the pole. The only reason I tested near Park 3 position is to confirm that NINA's failure to sync after plate-solving is not due to conflicts with the mount's "Recal/Sync" system; I "Recal" there was a discussion mentioning that "Recal/Sync" mainly differs by the existence a coordinate already in mount's memory (https://ap-gto.groups.io/g/main/message/75265).

In either case (near/away from the pole), I found NINA fail to sync the mount's coordiante and "mistakenly" thought it has done so.

Best,
Wenhan


Re: NINA fails to sync AP900 and sometimes causes random slew

Horia
 

Hi Wenhan,

 

>> I initiated the mount from Park 3 position, unparked the mount and connected AP V2 driver through APCC, and started NINA.

>> I then plate-solved through NINA, …

 

I may be wrong but from your description it looks like you tried to plate solve and sync the mount while the scope was very close to Park3.  This will never go well as the plate solver will have a very hard time to distinguish between camera rotation and RA position. You should first slew the mount away from the pole.

 

Kind regards,

Horia

 

 

Von: main@ap-gto.groups.io <main@ap-gto.groups.io> Im Auftrag von Wenhan Chang
Gesendet: Donnerstag, 17. Februar 2022 19:16
An: main@ap-gto.groups.io
Betreff: [ap-gto] NINA fails to sync AP900 and sometimes causes random slew

 

Hello,

I just used my AP900 (CP3 V2) for the first time, controlled by APCC (version 1.9.3) and NINA (version 1.10). The mount performed great, but I had trouble using NINA to sync the coordinates to APCC/mount after plate-solving. No APPM/PEM was used.

I initiated the mount from Park 3 position, unparked the mount and connected AP V2 driver through APCC, and started NINA. I then plate-solved through NINA, which has the "sync" function on but "reslew to target" function off. After this, NINA produced conflicting behavior: on the one hand it "should know" the sync faild, because NINA's telescope section was still showing the RA and DEC coordinates before plate-solving (i.e. consistent with APCC's coordiantes); but on the other hand it "thought" the sync succeeded, because if I immediated do another plate-solve in NINA, it thinks the RA and DEC error was basically 0. APCC's coordiantes remained unchanged during this process.

What puzzles me more is that sometimes NINA's sync function will cause the mount to start slewing, about 2-3 seconds after plate-solving/syncing, even though I turned off the "reslew to target" function in NINA. I don't know if the slew was initiated by NINA or APCC. After this, the mount would lost track of its position (e.g. can't go back to the original park position; thought it was on CW up position though it wasn't etc.), so I think this messed up with the pointing model CP3 had.

My workaround was to turn off both "sync" and "reslew to target" function in NINA, and then I manually put the plate-solved coordinates in APCC and used APCC's "sync" function. Then the coordiates were updated on both APCC and NINA, and would center my target by having another GoTo.

The above behavior existed both right after initialization from Park 3, or after a slew/GoTo from NINA/APCC.

PS: sometimes if the plate-solved coordinates were too distant from what the mount thinks (greater than 5 arcmin I remember), then APCC's sync function will produce an error message saying the new coordiates were too distant and refuse to sync. My workaround was to slew the mount as close to Park 3 position as possible, (in APCC) park it to current position but then unpark it from Park 3 position. After that, the plate-solved coordinates would be closer and APCC would sync.

Please let me know if you need any further information or have any suggestions. Thank you very much!

Best regards,
Wenhan


Re: APCC Pro Beta and AP V2 ASCOM Driver Beta with an alternative to Eltima Virtual Ports

Larry Phillips
 

Ray, should all of us who installed the previous beta which appears to work, also install this version?  Do we need to uninstall the previous beta?

Larry


Re: Looking for GPS Device Recommendations for APCC

W Hilmo
 

In my case, I have two GPS devices.

One of them is a cheap unit from Amazon.  It's sole purpose is to keep the clock in sync with NMEATime2 set up as a service.  The second unit is an MGBoxV2.  It's job is to provide both location and environmental data to APCC Pro.

You are correct that you only need to get the location data once. To that end, I rarely use the GPS tab in APCC, pretty much only when setting up for the first time at a new site.  The environmental data is used continuously by APCC.

I could get away with a single GPS device.  But with the setup that I have now, everything is pretty much automated and seamless.  I just boot up the computer and the NMEATime2 service syncs the clock - and keeps it in sync.  APCC connects to the MGBoxV2 to get the data that it wants.  The $15 to buy the cheap GPS, plus whatever the NMEATime2 license cost, was worth every penny I spent on it.

-Wade

On 2/17/22 9:24 AM, Dale Ghent wrote:
Why would you need to query the GPS for location more than once?

For APCC, it's used once - to get a location and to make a new Site entry from. It's lot like your lat/long is going to change after getting your initial location :D

Once that's done, you can have NMEATime2 have the run of it to keep the clock in sync.


Re: NINA fails to sync AP900 and sometimes causes random slew

Wenhan Chang
 

Hi Dale,

Thank you very much for the suggestions! I really appreciate it. I will test it out when Chicago sky clears up next time and keep you updated.

Best,
Wenhan


Re: NINA fails to sync AP900 and sometimes causes random slew

Dale Ghent
 

It may be that the coordinates that your mount thinks it is at, and the coordinates that the plate solve found, are so wildly different that APCC is rejecting the sync - but silently.

In APCC, go to Settings > Advanced Settings and see if "Prevent errant RECALs" is turned on, which I *think* is the default. This option will make APCC ignore syncs if they are wildly different from the mount's current notion of its coordinates. How large that difference has to be is something that I can't recall off the top of my head.

If that's the case, the sync could be silently eaten by APCC and NINA would know about it. I haven't tested this kind of condition in recent times, but this kind of condition should cause the ASCOM driver to throw an exception, thus cluing NINA in on the failed sync. Some other drivers throw exceptions a lot when being asked to sync to some coordinates (EQMOD is known for this when a sync is asked too close to the meridian) so NINA would observe an exception if the driver threw one.

If that option is on, you can test this by disabling it, doing the plate solve and sync, then re-enable it. If things go well after that, that was the cause. I would need to look into the behavior of the A-P ASCOM driver when a RECAL nee sync is rejected or ignored for being too different.

On Feb 17, 2022, at 13:15, Wenhan Chang <sjtu.wenhan@...> wrote:

Hello,

I just used my AP900 (CP3 V2) for the first time, controlled by APCC (version 1.9.3) and NINA (version 1.10). The mount performed great, but I had trouble using NINA to sync the coordinates to APCC/mount after plate-solving. No APPM/PEM was used.

I initiated the mount from Park 3 position, unparked the mount and connected AP V2 driver through APCC, and started NINA. I then plate-solved through NINA, which has the "sync" function on but "reslew to target" function off. After this, NINA produced conflicting behavior: on the one hand it "should know" the sync faild, because NINA's telescope section was still showing the RA and DEC coordinates before plate-solving (i.e. consistent with APCC's coordiantes); but on the other hand it "thought" the sync succeeded, because if I immediated do another plate-solve in NINA, it thinks the RA and DEC error was basically 0. APCC's coordiantes remained unchanged during this process.

What puzzles me more is that sometimes NINA's sync function will cause the mount to start slewing, about 2-3 seconds after plate-solving/syncing, even though I turned off the "reslew to target" function in NINA. I don't know if the slew was initiated by NINA or APCC. After this, the mount would lost track of its position (e.g. can't go back to the original park position; thought it was on CW up position though it wasn't etc.), so I think this messed up with the pointing model CP3 had.

My workaround was to turn off both "sync" and "reslew to target" function in NINA, and then I manually put the plate-solved coordinates in APCC and used APCC's "sync" function. Then the coordiates were updated on both APCC and NINA, and would center my target by having another GoTo.

The above behavior existed both right after initialization from Park 3, or after a slew/GoTo from NINA/APCC.

PS: sometimes if the plate-solved coordinates were too distant from what the mount thinks (greater than 5 arcmin I remember), then APCC's sync function will produce an error message saying the new coordiates were too distant and refuse to sync. My workaround was to slew the mount as close to Park 3 position as possible, (in APCC) park it to current position but then unpark it from Park 3 position. After that, the plate-solved coordinates would be closer and APCC would sync.

Please let me know if you need any further information or have any suggestions. Thank you very much!

Best regards,
Wenhan


NINA fails to sync AP900 and sometimes causes random slew

Wenhan Chang
 

Hello,

I just used my AP900 (CP3 V2) for the first time, controlled by APCC (version 1.9.3) and NINA (version 1.10). The mount performed great, but I had trouble using NINA to sync the coordinates to APCC/mount after plate-solving. No APPM/PEM was used.

I initiated the mount from Park 3 position, unparked the mount and connected AP V2 driver through APCC, and started NINA. I then plate-solved through NINA, which has the "sync" function on but "reslew to target" function off. After this, NINA produced conflicting behavior: on the one hand it "should know" the sync faild, because NINA's telescope section was still showing the RA and DEC coordinates before plate-solving (i.e. consistent with APCC's coordiantes); but on the other hand it "thought" the sync succeeded, because if I immediated do another plate-solve in NINA, it thinks the RA and DEC error was basically 0. APCC's coordiantes remained unchanged during this process.

What puzzles me more is that sometimes NINA's sync function will cause the mount to start slewing, about 2-3 seconds after plate-solving/syncing, even though I turned off the "reslew to target" function in NINA. I don't know if the slew was initiated by NINA or APCC. After this, the mount would lost track of its position (e.g. can't go back to the original park position; thought it was on CW up position though it wasn't etc.), so I think this messed up with the pointing model CP3 had.

My workaround was to turn off both "sync" and "reslew to target" function in NINA, and then I manually put the plate-solved coordinates in APCC and used APCC's "sync" function. Then the coordiates were updated on both APCC and NINA, and would center my target by having another GoTo.

The above behavior existed both right after initialization from Park 3, or after a slew/GoTo from NINA/APCC.

PS: sometimes if the plate-solved coordinates were too distant from what the mount thinks (greater than 5 arcmin I remember), then APCC's sync function will produce an error message saying the new coordiates were too distant and refuse to sync. My workaround was to slew the mount as close to Park 3 position as possible, (in APCC) park it to current position but then unpark it from Park 3 position. After that, the plate-solved coordinates would be closer and APCC would sync.

Please let me know if you need any further information or have any suggestions. Thank you very much!

Best regards,
Wenhan


Re: Looking for GPS Device Recommendations for APCC

ap@CaptivePhotons.com
 

On Thu, Feb 17, 2022 at 12:24 PM, Dale Ghent wrote:
Why would you need to query the GPS for location more than once?
Well, don't some people chase eclipses from moving airplanes.  :)

The issue is needing to coordinate this stuff with people who like automation.  It's utterly trivial to wait for UPS lock, start APCC and let it get the location, (Not sure if you have to then disconnect), then start your time sync program, then whatever... 

But some people like to automate and not do trivial things manually; it's just a quirk you have to work around if there's a com port conflict.

Heck... I haven't figured out why I need a GPS for lat/long, it's not like I drive around and randomly stop somewhere to observe (and even if I did, I'd have to move quite a long way to matter).   I set up a site in APCC before I leave home based on google maps -- done.

But if you WANT a GPS for lat/long, these are quirks you have to work with if you also want time sync.

Now time I like, not because precision is required, but because windows and some hardware keep lousy time, and if you are not doing some sync you can be minutes off over months.  

Linwood


Re: Looking for GPS Device Recommendations for APCC

Dale Ghent
 

On Feb 17, 2022, at 12:31, Mike Dodd <mike@...> wrote:

On 2/17/2022 12:24 PM, Dale Ghent wrote:
Why would you need to query the GPS for location more than once?
It's lot like your lat/long is going to change after getting your initial location :D
That was my question, too. Why not use a handheld GPS unit (or car GPS in Pedestrian mode), or even your cell phone to get the coordinates?
The luxury of not having to type things in yourself, I suppose.


Once that's done, you can have NMEATime2 have the run of it to keep the clock in sync.
Yup. I use Dimension 4, but there are several good programs to query an Internet time server.
Dimension4 is NTP; which is different. However one can make a stratum 1 time server with one of these USB GNSS modules and something like a Raspberry Pi, and use Dimension4 to keep PC clocks in sync with that time server.

NMEATime2 is useful for if you don't have such a network and time server on it, or Internet access so that you can use a public time server. Just plug the USB module in and NMEAtime2 will wait for it to get sufficient lock and start slewing the PC's clock to it.


Re: Looking for GPS Device Recommendations for APCC

Mike Dodd
 

On 2/17/2022 12:24 PM, Dale Ghent wrote:
Why would you need to query the GPS for location more than once?
It's lot like your lat/long is going to change after getting your initial location :D
That was my question, too. Why not use a handheld GPS unit (or car GPS in Pedestrian mode), or even your cell phone to get the coordinates?
Once that's done, you can have NMEATime2 have the run of it to keep the clock in sync.
Yup. I use Dimension 4, but there are several good programs to query an Internet time server.

--- Mike


Re: Looking for GPS Device Recommendations for APCC

Dale Ghent
 

Why would you need to query the GPS for location more than once?

For APCC, it's used once - to get a location and to make a new Site entry from. It's lot like your lat/long is going to change after getting your initial location :D

Once that's done, you can have NMEATime2 have the run of it to keep the clock in sync.

On Feb 17, 2022, at 12:20, ap@... <ap@...> wrote:

Unless I'm mistaken though you cannot use the GPS for time and for APCC as a com port at the same time, as it will only present one COM port and whatever software sets the time will tie it up (or vice versa for APCC).

Though for $12 each you could always use two.


Also note that depending on the physical arrangement, nearby computers or other EMI sources, shielding by metal of the mount from a sky view, etc. may prevent these from working in practice. Some people use a USB extension to separate them, or a USB device with an external antenna which you can move further away. You won't know until you try.

The best software I found for time sync was not free, it was NMEATime2. It tried hard to work around the USB limitations; precise time cannot be found on a USB device because of timing issues, it requires "1PPS" which is a hardware signal to more precisely synchronize the receipt of the text string with the time. This gets you really close though. Not that you need precise time for DSO and planetary, maybe for satellite chasing.

One problem with all this is coordinating lat/long changes with "sites" in both APCC and your favorite session manager software, which probably needs to be done semi-manually.

Linwood



Re: Looking for GPS Device Recommendations for APCC

ap@CaptivePhotons.com
 

Unless I'm mistaken though you cannot use the GPS for time and for APCC as a com port at the same time, as it will only present one COM port and whatever software sets the time will tie it up (or vice versa for APCC). 

Though for $12 each you could always use two. 

Also note that depending on the physical arrangement, nearby computers or other EMI sources, shielding by metal of the mount from a sky view, etc. may prevent these from working in practice.  Some people use a USB extension to separate them, or a USB device with an external antenna which you can move further away.  You won't know until  you try. 

The best software I found for time sync was not free, it was NMEATime2.  It tried hard to work around the USB limitations; precise time cannot be found on a USB device because of timing issues, it requires "1PPS" which is a hardware signal to more precisely synchronize the receipt of the text string with the time. This gets you really close though.  Not that you need precise time for DSO and planetary, maybe for satellite chasing. 

One problem with all this is coordinating lat/long changes with "sites" in both APCC and your favorite session manager software, which probably needs to be done semi-manually. 

Linwood


Re: Looking for GPS Device Recommendations for APCC

Dale Ghent
 

The $10-$15 white USB GNSS sticks based on the ublox chips seem to work well in my experience. They can operate in one of two modes - exposing themselves as a serial port that spews forth NMEA sentences at the prescribed 4800bps data rate or, with a driver, integrated as a sensor in Windows. For these purposes, you will want the former, which means the thing is basically plug and play.

APCC will fetch location from a locked GPS, but for time syncing purposes you will want an app such as NMEAtime2.

On Feb 17, 2022, at 11:56, Ben Koltenbah <benjamin.e.c.koltenbah@...> wrote:

Greetings!

I would like to get a Windows PC-connected GPS device that is accessible by APCC (both Standard and Pro). I have found some inexpensive choices on Amazon as well as more expensive options, but before ordering, I thought I'd ask here if there are some particular and well-proven recommendations that are well-suited for establishing time and location through APCC for my Mach1GTO and 1100GTO mounts as well as general Windows applications.

Thanks!

Best Regards,
Ben


Re: Looking for GPS Device Recommendations for APCC

 

Hi Ben

a lot of folks (including myself) use the MGBox V2, which includes GPS among many other instruments

it's a lot more than GPS but the other instruments (temperature, pressure, etc.) can all feed APCC as well, very handy


Brian


On Thu, Feb 17, 2022 at 8:56 AM Ben Koltenbah <benjamin.e.c.koltenbah@...> wrote:
Greetings!

I would like to get a Windows PC-connected GPS device that is accessible by APCC (both Standard and Pro).  I have found some inexpensive choices on Amazon as well as more expensive options, but before ordering, I thought I'd ask here if there are some particular and well-proven recommendations that are well-suited for establishing time and location through APCC for my Mach1GTO and 1100GTO mounts as well as general Windows applications.

Thanks!

Best Regards,
Ben



--
Brian 



Brian Valente


Looking for GPS Device Recommendations for APCC

Ben Koltenbah
 

Greetings!

I would like to get a Windows PC-connected GPS device that is accessible by APCC (both Standard and Pro).  I have found some inexpensive choices on Amazon as well as more expensive options, but before ordering, I thought I'd ask here if there are some particular and well-proven recommendations that are well-suited for establishing time and location through APCC for my Mach1GTO and 1100GTO mounts as well as general Windows applications.

Thanks!

Best Regards,
Ben

5461 - 5480 of 90466