Why is it that I cannot use a high com port number with my 900 or 1200 mount using The Sky software. Is this an issue with The Sky or the mounts? The Sky offers com 1 to 254 for com ports, but I can't seem to get the mount to use anything above 8 without getting an error message...

Thanks in advance,
Norm

I'm not Marj, but I ma be able to help.
You can use these two parts to mount your EOS to the 2.7" threads.
ADA2767 and 67RLEOS
Hope this helps.

kerrywaz1 wrote:

Any idea on what could be going on here? Shouldn't I be able to do an unguided exposure with this mount for at least 10 minutes and get round stars?

In a perfect world, maybe. But using an SCT compounds this issue because the main mirror can slightly move and sometimes even locking it down doesn't work. Adding the focal length into the equation only makes it worse.

What's wrong with guiding the mount ? I'll hazard a guess that most people do exactly that.


Bill

--
William R. Mattil

http://www.celestial-images.com

John Winfield wrote:

Ray,

I just did the search. Are you aware of any other applications besides ACP
that report this error? Perhaps it is a series of commands that ACP is
issuing that causes this.

I can't remember the details of the other posts, but I use ACP exclusively for my imaging now.
It certainly wouldn't be the first time that an automation app like ACP has exposed some issue in a driver or piece of hardware, due to the repeatable nature and high speed of the commands it can issue.

I'm more interested in proving that the error sticks between multiple
commands, or if this is a randomly occurring error. Do you happen to have a
dew heater on your setup? There has been some evidence that dew heaters can
interfere with other electronic components and maybe introduce an error in
serial port communications.

Nope, no dew heater, just the mount, a cooled camera, a filterwheel and a focuser, all on their own individual PSUs, although all those PSUs are connected to the same extension power block.
My camera and USB serial port converters all run from a powered USB2.0 hub located at the scope, with a single 16' USB cable running back in to the house.

As another data point, I am using a real serial port. No USB-->Serial adapter. No dew heaters. This event doesn't happen very often, but it is very annoying when it does occur.

I seem to recall the error message is something along the lines of "Mount Rejected Coordinates"

My belief is that it is not a serial cable problem, not a USB-->Serial adapter, and not a mount problem. That leaves the driver. Not to mention that it is really the most likely culprit anyway.


Regards

Bill



--
William R. Mattil

http://www.celestial-images.com

In a message dated 6/1/2009 3:38:12 AM Central Daylight Time,
kerry.williams@... writes:

I have an AP1200 with a C-11 with a f/6.3 reducer. I have manually drift
aligned and used PEMPro over several itetations to do a detailed polar
alignment (azimuth error = 0.4 arc-mins, elevation error = 0.3 arc-min).
However, when I do an unguided 10 minute exposure (around IC5067), I still get
drift in declination. Stars look like elliptical galaxies.

See image in "Kerry's Images":
http://groups.yahoo.com/group/ap-gto/photos/album/628067733/pic/1459058421/view?picmode=original&mode=tn&order=ordinal&
start=1&dir=asc

Any idea on what could be going on here? Shouldn't I be able to do an
unguided exposure with this mount for at least 10 minutes and get round stars?

There is a very large possibility that the mount is not drifting in Dec,
and the mechanical tube assembly is also not drifting in Dec, however the
optics of your SCT may not be following the mechanics of your SCT. In other
words, the optics are shifting with gravity. Differential flexure.

Rolando


**************
We found the real ‘Hotel California’ and the ‘Seinfeld
’ diner. What will you find? Explore WhereItsAt.com.
(http://www.whereitsat.com/#/music/all-spots/355/47.796964/-66.374711/2/Youve-Found-Where-Its-At?nc
id=emlcntnew00000007)


[Non-text portions of this message have been removed]

Ray, John,
All also try to get some time on the stress tester. I concur, using ACP has
been the only precipitator of this condition in my system. The only errored
response that I have seen is the bogus response to set target Dec or RA. the
reponse character is not always the same but it is not a "1". One issue
with detecting the repeated rejections is, I think, that time is somehow
involved. If you happen to be watching the automated run when it occurs,
you'll likely be able to reproduce the condition, over and over. Often I
don't find things stopped until morning and it's too late to retry the slew.
I have not received the error very much as of late. But, I doubt that it is
a comport issue. I have used serveral comports, built in, multiple types of
USB and multiple different machines. What sealed that feeling for me is the
repeated rejects of the same coordinates. On one occation, after repeated
rejects an ACP target, I used Maxin to slew to the same target (maybe
slightly different coordinates than my framed ACP Target) which immediately
worked, then reran my ACP plan, and everything went on fine.
As I said, I'll try to get some time on the stress tester and report back
soon.
Best Regards,
Mark
_____

From: ap-gto@... [mailto:ap-gto@...] On Behalf Of
John Winfield
Sent: Monday, June 01, 2009 3:46 AM
To: ap-gto@...
Subject: [ap-gto] Re: New ASCOM driver eta?





Actually, I just managed to get the ASCOM serial logging working on my Vista
PC, so I'll leave that enabled from now on, to hopefully catch some evidence
of what's going on next time it happens.

I'll also run the new stresstest app one night this week, if I can get home
from work at a reasonable hour.

John

--- In ap-gto@yahoogroups. <mailto:ap-gto%40yahoogroups.com> com, "John
Winfield" <winfij@...> wrote:

Ray,

I just did the search. Are you aware of any other applications besides

ACP

that report this error? Perhaps it is a series of commands that ACP is
issuing that causes this.

I can't remember the details of the other posts, but I use ACP exclusively

for my imaging now.

It certainly wouldn't be the first time that an automation app like ACP

has exposed some issue in a driver or piece of hardware, due to the
repeatable nature and high speed of the commands it can issue.

I'm more interested in proving that the error sticks between multiple
commands, or if this is a randomly occurring error. Do you happen to

have a

dew heater on your setup? There has been some evidence that dew heaters

can

interfere with other electronic components and maybe introduce an error

in

serial port communications.

Nope, no dew heater, just the mount, a cooled camera, a filterwheel and a

focuser, all on their own individual PSUs, although all those PSUs are
connected to the same extension power block.

My camera and USB serial port converters all run from a powered USB2.0 hub

located at the scope, with a single 16' USB cable running back in to the
house.

You can introduce the ASCOM driver into the chain by connecting it to

one of

APCC's virtual COM ports. The new ASCOM driver is going to be a hub so
multiple apps can connect through it simultaneously. At some point APCC

may

itself sport an ASCOM driver interface, but until then it will gladly

share

the COM port with other apps in a controlled way.

So an ASCOM app will connect to the new ASCOM v2 telescope driver, which

then connects to a virtual COM port in APCC, which then connects to the
physical COM port on the mount?

Is it the APCC component which will be providing the advanced

functionality Howard was demoing at AIC, like the custom tracking limits,
pointing model etc?

Could one connect the ASCOM driver directly to the mount's physical COM

port if those were not required for a given scenario?

That will be AP's decision, but I wouldn't have a problem with the

driver

being open source.

I'll cross my fingers :)


Cheers,

John

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.339 / Virus Database: 270.12.46/2145 - Release Date: 05/31/09
05:53:00

I have an AP1200 with a C-11 with a f/6.3 reducer. I have manually drift aligned and used PEMPro over several itetations to do a detailed polar alignment (azimuth error = 0.4 arc-mins, elevation error = 0.3 arc-min). However, when I do an unguided 10 minute exposure (around IC5067), I still get drift in declination. Stars look like elliptical galaxies.

See image in "Kerry's Images": http://groups.yahoo.com/group/ap-gto/photos/album/628067733/pic/1459058421/view?picmode=original&mode=tn&order=ordinal&start=1&dir=asc

Any idea on what could be going on here? Shouldn't I be able to do an unguided exposure with this mount for at least 10 minutes and get round stars?

Thanks,
Kerry

Actually, I just managed to get the ASCOM serial logging working on my Vista PC, so I'll leave that enabled from now on, to hopefully catch some evidence of what's going on next time it happens.

I'll also run the new stresstest app one night this week, if I can get home from work at a reasonable hour.

John

Ray,

I just did the search. Are you aware of any other applications besides ACP
that report this error? Perhaps it is a series of commands that ACP is
issuing that causes this.

I can't remember the details of the other posts, but I use ACP exclusively for my imaging now.
It certainly wouldn't be the first time that an automation app like ACP has exposed some issue in a driver or piece of hardware, due to the repeatable nature and high speed of the commands it can issue.

I'm more interested in proving that the error sticks between multiple
commands, or if this is a randomly occurring error. Do you happen to have a
dew heater on your setup? There has been some evidence that dew heaters can
interfere with other electronic components and maybe introduce an error in
serial port communications.

Nope, no dew heater, just the mount, a cooled camera, a filterwheel and a focuser, all on their own individual PSUs, although all those PSUs are connected to the same extension power block.
My camera and USB serial port converters all run from a powered USB2.0 hub located at the scope, with a single 16' USB cable running back in to the house.

You can introduce the ASCOM driver into the chain by connecting it to one of
APCC's virtual COM ports. The new ASCOM driver is going to be a hub so
multiple apps can connect through it simultaneously. At some point APCC may
itself sport an ASCOM driver interface, but until then it will gladly share
the COM port with other apps in a controlled way.

So an ASCOM app will connect to the new ASCOM v2 telescope driver, which then connects to a virtual COM port in APCC, which then connects to the physical COM port on the mount?
Is it the APCC component which will be providing the advanced functionality Howard was demoing at AIC, like the custom tracking limits, pointing model etc?
Could one connect the ASCOM driver directly to the mount's physical COM port if those were not required for a given scenario?

That will be AP's decision, but I wouldn't have a problem with the driver
being open source.

I'll cross my fingers :)


Cheers,

John

John,

If you saw my later posts you then saw that I wrote a utility to
stress test the connection to the mount. You can do the test during
the

Yep - spotted that - I'll give it a go, to see if it gets any
failures under stress, thanks for putting it together.

OK, let me know.

All the more reason the client application you are running

should be

designed robustly to handle cases like this. The error

could be in the

serial port interface, the hardware, or the driver.

It does what it can, but if it can't control the mount, it's
options for fail-safe are limited.

The error is that a coordinate is rejected. An attempt to stop tracking
could and perhaps should be tried. There's no reason to believe that mount
tracking can't be stopped.

I have not seen a log
that shows that a repeat of the command fails.

I realize there's not been a capture of it, but it's
certainly happened to more than one person, according to
reports on this forum.
I tried searching back through the forum for the historical
posts, but Yahoo's broken again.

I just did the search. Are you aware of any other applications besides ACP
that report this error? Perhaps it is a series of commands that ACP is
issuing that causes this.

If that is the case I'm not
sure what the ASCOM driver should do then. Try to stop tracking? Or
leave that to the client app.

Sure, I wasn't implying that the driver could fix the issue
if it were indeed a mount or comms problem, but rather that
maybe we could use the low level interface available to the
driver to try and narrow down the nature of the problem once
it occurs.
There's not much to see from the ASCOM app level besides the
error message we already know about.

I'm more interested in proving that the error sticks between multiple
commands, or if this is a randomly occurring error. Do you happen to have a
dew heater on your setup? There has been some evidence that dew heaters can
interfere with other electronic components and maybe introduce an error in
serial port communications.

I'll try running your comms stress test app to see if there
is an easily reproducible problem with my mount or comms
gear. Thanks again for that.

It will be done when it is ready. There are too many variables to
predict anything at this point.

Indeed.

BTW, the new AP ASCOM driver is not going to be part of the

AP Command

Center (because of the issues with Vista SP1 and the UDP protocol).
They will be separate installations.

I'm happy to hear that.
In fact, much of the high level APCC functionality would be
really useful to most mounts, although since I assume AP is
funding the development, I doubt it's likely that it could be
available as a generic shim layer in the ASCOM control chain
between the high level app and the hardware driver?

You can introduce the ASCOM driver into the chain by connecting it to one of
APCC's virtual COM ports. The new ASCOM driver is going to be a hub so
multiple apps can connect through it simultaneously. At some point APCC may
itself sport an ASCOM driver interface, but until then it will gladly share
the COM port with other apps in a controlled way.

Does this mean there will be an opportunity to make the core
ASCOM driver open-source, since presumably the licensed 3rd
party libraries you mentioned previously are part of the
APCC, not the core driver?

That will be AP's decision, but I wouldn't have a problem with the driver
being open source.

-Ray

Ray,

If you saw my later posts you then saw that I wrote a utility to stress test
the connection to the mount. You can do the test during the

Yep - spotted that - I'll give it a go, to see if it gets any failures under stress, thanks for putting it together.

All the more reason the client application you are running should be
designed robustly to handle cases like this. The error could be in the
serial port interface, the hardware, or the driver.

It does what it can, but if it can't control the mount, it's options for fail-safe are limited.

I have not seen a log
that shows that a repeat of the command fails.

I realize there's not been a capture of it, but it's certainly happened to more than one person, according to reports on this forum.
I tried searching back through the forum for the historical posts, but Yahoo's broken again.

If that is the case I'm not
sure what the ASCOM driver should do then. Try to stop tracking? Or leave
that to the client app.

Sure, I wasn't implying that the driver could fix the issue if it were indeed a mount or comms problem, but rather that maybe we could use the low level interface available to the driver to try and narrow down the nature of the problem once it occurs.
There's not much to see from the ASCOM app level besides the error message we already know about.

I'll try running your comms stress test app to see if there is an easily reproducible problem with my mount or comms gear. Thanks again for that.

It will be done when it is ready. There are too many variables to predict
anything at this point.

Indeed.

BTW, the new AP ASCOM driver is not going to be part
of the AP Command Center (because of the issues with Vista SP1 and the UDP
protocol). They will be separate installations.

I'm happy to hear that.
In fact, much of the high level APCC functionality would be really useful to most mounts, although since I assume AP is funding the development, I doubt it's likely that it could be available as a generic shim layer in the ASCOM control chain between the high level app and the hardware driver?

Does this mean there will be an opportunity to make the core ASCOM driver open-source, since presumably the licensed 3rd party libraries you mentioned previously are part of the APCC, not the core driver?

John

John,

It only happens infrequently though, so it may be some time
before it happens again. Portmon also has the limitation of
needing to connect to the serial port before the ASCOM driver
- what's the betting that the run which fails in a few months
time will be the one where I forget to connect it up first...

If you saw my later posts you then saw that I wrote a utility to stress test
the connection to the mount. You can do the test during the daytime if you
want but if there is a connection problem this might find it. I did the test
overnight and there were no errors in 378,000 * 4 commands/replies.

Alternatively, if it gets stuck with tracking on, the scope
could collide with the pier.

All the more reason the client application you are running should be
designed robustly to handle cases like this. The error could be in the
serial port interface, the hardware, or the driver. I have not seen a log
that shows that a repeat of the command fails. If that is the case I'm not
sure what the ASCOM driver should do then. Try to stop tracking? Or leave
that to the client app.

However, I am hoping that with an actively maintained driver,
we may have the possibility of adding enough diagnostic code
to try and get to the bottom of it at long last.

Try my stress test app. It even includes source code so you (or others) can
add your own tests.

Do you have any idea on the rough timeline for release -
sometime this year?
I saw the demo at AIC and it did look impressive.

It will be done when it is ready. There are too many variables to predict
anything at this point. BTW, the new AP ASCOM driver is not going to be part
of the AP Command Center (because of the issues with Vista SP1 and the UDP
protocol). They will be separate installations.

-Ray

I'll do that Ray, thanks for the pointer.

It only happens infrequently though, so it may be some time before it happens again. Portmon also has the limitation of needing to connect to the serial port before the ASCOM driver - what's the betting that the run which fails in a few months time will be the one where I forget to connect it up first...


When it does happen though, I lose the night's run and the mount could potentially get stuck in a position which would put it at risk of pointing at the rising sun, which is a concern if I don't wake up in time to cover the scope first. Normally the automation software parks the scope into a safe position, but obviously it can't do that if the mount is refusing to slew.
Alternatively, if it gets stuck with tracking on, the scope could collide with the pier.


If this were a serial comms failure, it seems odd that it would get stuck in this mode for repeated slew attempts.
Also, some people have reported that it is cleared by slewing to a different target, which doesn't sound like it should affect things if it were a hardware buffering problem.

Personally, I don't really have any strong opinion as to where the problem may lie - there doesn't seems to be a body of evidence pointing at any one thing.

However, I am hoping that with an actively maintained driver, we may have the possibility of adding enough diagnostic code to try and get to the bottom of it at long last.

Do you have any idea on the rough timeline for release - sometime this year?
I saw the demo at AIC and it did look impressive.

Cheers,

John

I don't use the other adaptor for isolation, its the reverse cable for future reference. Tried it last night and it worked.

thanks to those who helped.


Jan

I've got an AP900 GTOCP2 I bought used about a year ago. I considered the upgrade and opted to not do it. The biggest reason to upgrade is the ability to download and edit the PEC routine. This can probably reduce PE by 10% - 20% on average (total guesstimate on my part). When my PE is in the neighborhood of 4 - 5 arc seconds with the CP2 already it may give me another arc second better PE over the whole worm cycle. Not worth the money for me when I'm guiding with 2 - 3 second corrections anyway.

Chris

jhall153 wrote:

Cool photo and nice rig!



Stuart



To: ap-gto@...
From: David@...
Date: Sun, 31 May 2009 11:19:30 +0000
Subject: [ap-gto] First imaging project with the AP1200







QSOs and Twin Quasar Q0957+561 Near NGC3079 Galaxy that was taken May 24, 2009 from my driveway.

This image has the folllowing interesting objects.

The brightest is the edge-on spiral Seyfert galaxy NGC3079 with active galactic nuclei (AGN).
The Twin Quasar is caused by gravitational lens at magnitude 16.7.
QSO PC 0958+5625 (Q 0958+5625) redshift is 3.216527 with a light travel-time of 11.323 Gyr.
The light from QSO PC 0958+5625 is over twice as old as our solar system. QSO PC 0958+5625 magnitude is 20.08.
4C 55.17 is a Blazar with a 17.9 magnitude.

Also, the mage scale of 2.12 arcsec/pix. The Twin Quasars are only 6 arcsec apart. I am happly to split the Twin Quasars at this low resolution image scale.
http://www.stargazing.net/david/QSO/Q0957_561nl.html

Telescope setup is at
http://www.stargazing.net/david/QSI/QSI532NP127is.html

Clear and dark skies,
David Haworth
http://www.stargazing.net/david

Mark/John,

I wrote a little utility to stress test the Set RA/Dec coordinates and let
it run over night. It issued over 374,000 requests to set the RA and Dec
coordinates (each) as well as queried RA/Dec that many times as well. Every
one of the requests returned a "1" and there were no timeouts.

If you would like to try out the stress test on your setups to see if there
might be a com port connection issue I uploaded the full VB.Net project
including Source code into the Files section of this group under the "Ray
Gralak" folder. If you don't have VB.Net installed you should be able to run
the EXE in the bin/Debug directory.

To use the app, run it, select the COM port, set the values in the RA and
Dec coordinate fields then press "Start". There is also a jpeg in the
directory showing what the app looks like:

http://tech.groups.yahoo.com/group/ap-gto/files/Ray%20Gralak/

-Ray

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the ap-gto
group.

File : /Ray Gralak/StressTest.jpg
Uploaded by : raygralak <yahoo@...>
Description : Picture of the Stress Test App

You can access this file at the URL:
http://groups.yahoo.com/group/ap-gto/files/Ray%20Gralak/StressTest.jpg

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/l/us/yahoo/groups/original/members/web/index.htmlfiles

Regards,

raygralak <yahoo@...>

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the ap-gto
group.

File : /Ray Gralak/APSetRaDecTest.zip
Uploaded by : raygralak <yahoo@...>
Description : Set RA/Dec Stress Test application. Full VB.Net 2008 Solution/Source Code

You can access this file at the URL:
http://groups.yahoo.com/group/ap-gto/files/Ray%20Gralak/APSetRaDecTest.zip

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/l/us/yahoo/groups/original/members/web/index.htmlfiles

Regards,

raygralak <yahoo@...>

Can anyone tell me what the difference is between these two and if it would be worth the upgrade?

Thanks!