[Logo] Argo Navis Users' Group
  [Search] Search   [Recent Topics] Recent Topics   [Hottest Topics] Hottest Topics   [Top Downloads] Top Downloads   [Groups] Back to home page 
[Register] Register /  [Login] Login 
Messages posted by: wildcard
Forum Index » Profile for wildcard » Messages posted by wildcard
22 July 2002. Nic Healey at the ABC Australian news web site reports on the new Huntsman Telescope at the Siding Spring Observatory in Australia.

The first deep sky telescope of its kind in the Southern Hemisphere is ready to shed new light on some of the darkest parts of the universe, as it begins surveys from western New South Wales.

Developed by Macquarie University, the Huntsman Telescope has been unveiled at Siding Spring Observatory, nestled among the mountains of the Warrumbungle Range near Coonabarabran.

Project team member Sarah Caddy said the design of the Huntsman allowed highly specialised research into galaxy formation and evolution.

"When we're looking for really faint objects, things with low surface brightness, we want to collect as much light as possible," she said.

"With traditional mirror-based telescopes, they can scatter the light into parts of the field of view that we don't want … it makes it really difficult to find those really faint things around galaxies.

"What we do instead is we have 10 lenses, all looking at the same spot in the sky. We stack those images together to get as much light as possible."

Built almost entirely from off-the-shelf technology, the "eyes" of the Huntsman are 10 commercially available Canon-built telephoto lenses.

It is similar in design to the Dragonfly Telescope Array designed by astronomers from Yale University, but there are none like it in the Southern Hemisphere.

Full story, pictures here :-
Now and then we will receive an email, to which we reply, then a few days later be sent an identical email.

It then becomes obvious to us that our responses are ending up in the Junk folder of the sender.

We welcome your emails. If you do not appear to receive a reply, please check your Junk folder smilie

If you also add a phone number to your email, we have an alternate way of contacting you if we think our response has gone astray.
Hi Paul,

Thanks for the post and welcome to the forum.

When using the ServoCAT with Argo Navis the recommended wiring topology is :-

PC <-> ServoCAT <-> Argo Navis

By way of background Wildcard Innovations collaborated with StellarCAT in the development of the ServoCAT communications protocol.

In the topology above, the PC interacts with the ServoCAT via the ServoCAT's PC port. Command that need to go to the Argo Navis are then relayed to and from it.
For example, when the PC planetarium sends a command to fill the FROM PLANETARIUM catalog entry, it is relayed by the ServoCAT to the Argo Navis.

Meanwhile, the continual communication flow between ServoCAT and Argo Navis is also happening.

The communication that occurs between the Argo Navis and the ServoCAT is a subset of the ServoCAT protocol. Additional commands are available between the PC
and the ServoCAT.

I do not know how the Sync command on the ServoCAT ASCOM driver(s) have been implemented.

What I would do is after the plate solve, you know the astrometrically determined RA/Dec of where you are pointing.
One could transmit those coordinates to the Argo Navis FROM PLANETARIUM object and then one could go into MODE ALIGN and align on them.

If you connect the planetarium program directly to the Argo Navis and use the ServoCAT protocol, driving the ServoCAT will not work in that way.
The ServoCAT and the ServoCAT protocol are designed to relay data via the path PC <-> ServoCAT <-> Argo Navis and not PC <-? Argo Navis <-ServoCAT>,

One can also use the second Argo Navis serial port to connect to the PC and have it configured to run the "meade" protocol and that also allows for filling of the FROM PLANETARIUM
entry and fetching of the RA/Dec position but it won't control the ServoCAT in that way.

The Meade protocol includes the "CM# cakibrate command. If Argo Navis happens to be in MODE ALIGN STAR or MODE ALIGN or MODE FIX ALT REF when it is issued, it will be perform
the equivalent of hitting he Enter button on the Argo Navis.

I am sure I have not answered all your questions so feel free to ask more, but I hope the insight into PC <-> ServoCAT <-> Argo Navis being the recommended topology when
using the ServoCAT protocol is helping point you in the right direction.

I see you are also on the ServoCAT GroupsIO group which is a good resource as well.
ABC news in Australia provides a scrolling commentary by astronomers highlighting some of the interesting features of the JWT pictures such released

Hi Steve,

It might simply be the lithium coin cell needs replacing as a depleted one can lead to similar behaviour.

However, please don't touch it or replace it just yet.

Email me at sales@wildcard-innovations.com.au and let me know what version of the firmware you are currently running
(MODE STATUS, STATUS VERSION) and I will run you through a couple of checks to see whether that might be true.
Hi Steven,

Thanks for the post.

If you access a star, say in the MISC VARIABLE STARS catalog, so that the display that says "GUIDE" in the bottom line appears,
then if you scroll the dial clockwise it will successively show the name of each star in the internally ordered list of that particular catalog.

For example, if you enter Y AUR and then spin the dial clockwise, you will see Y CAE, Y CAR, Y CAS, Y CEP and so on.

If you spin the dial in the counter-clockwise direction, then the display will show them in reverse order in which they are internally stored.

Typically this is not the way you would access an arbitrary star. Normally you would "spell" its name out one symbol at a time using the dial and enter button in combination.
However, the feature whereby you can scroll through each item in a catalog is handy if you want to get a feel what is in there.

There are a selected subset of stars in the MISC VARIABLE STARS catalog out of all the known variable stars that exist.
For example, UY CMA and Y CVN do not appear.

You might want to make use of the User Catalog feature to load your own. The User Manual pp 174-179 explains how to do this.

The ability to scroll through a catalog one object at a time is true of all catalogs.

Appendix H gives a listing of how Argo Navis internally orders its symbols. Whereas the alphabetic characters are self-evident, the listing in Appendix H on page 239 shows, for
example, that the Σ symbol is probably most quickly accessed from within the MISC DOUBLE STAR CATALOG by spinning counterclockwise from the initial object, which happens to be A 1767,
so that you turn the A into a Σ and then use the enter button and dial from there to access the Struve object of interest. There are also O Struve objects, which are accessed by first entering a O then the Σ.

For stars in the BRIGHT STAR CATALOG, they come with constellation abbreviation first followed by Bayer or Flamsteed desigantor.

Hope these tips are helpful.

In a 28th April 2021 article at the Institute of Electrical and Electronics
Engineers Spectrum Magazine web site, researchers Alan Mantooth,
Carl-Mikael Zetterling and Ana Rusu report on the challenges of
operating electronics on a lander on the surface of Venus where the
average temperature is 464 °C, the atmosphere is dense with highly
corrosive droplets of sulphuric acid, and the atmospheric pressure at
the surface is about 90 times that of Earth.

Mantooth, et. al wrote:
But the second planet from the sun has such an extreme environment that the longest-lasting lander, the Soviet Venera 13, was able to send data for only 2 hours and 7 minutes.

Mantooth, et. al wrote:
Materials technology has advanced enough since the 1960s, when the former Soviet Union began launching its Venera series of landers to Venus, to ensure that the outer hull and mechanics of a future lander will be able to last for months. But what about those tender electronics? Today’s silicon-based systems would not last a day under Venus conditions. (We mean an Earth day, of course. A Venusian day is 243 Earth days.) Even adding active cooling systems might not give them more than an extra 24 hours.

The answer is a semiconductor that combines two plentiful elements, carbon and silicon, in a 1:1 ratio—silicon carbide. SiC can withstand extremely high temperatures and still work just fine. Scientists at the NASA Glenn Research Center have already operated SiC circuits for more than a year at 500 °C, demonstrating not only that they can take the heat but can do so over the kinds of lifetimes a Venus lander will need.

Silicon carbide is already making its mark in power electronics for solar inverters, electric-vehicle motor-drive electronics, and advanced smart-grid switch gear. But creating SiC circuits that can control a rover on the hellscape of Venus and send data from there to Earth will test this material to its limits.

Article here :-
Hi Massimo,

Your ISP is bouncing our email replies to you so I have contacted them.

In any case I suspect you don't have a problem after all and that you may just be looking at the rounded numbers that reflect the finite encoder resolution.
Thanks for the post.

You may not be aware that we provide full technical support by direct email or by telephone.
The contact details are here :-

Please drop us a line and we are here to assist. Some have described our support as the best they have ever received for any product they have ever purchased.

This forum tends to be for broader questions, though is not limited to that.

Hi BC,

Thanks for the question.

Since the pointing data is gathered with respect the arbitrary star alignment, it is not possible to merge two sets of data from two different alignments.

One way to appreciate why that is so is to consider a telescope that has arbitrary geometric pointing errors built into it.
Such a telescope never points at exactly where it is thought to be pointing.

When one does a two star alignment using such a hypothetical telescope, one is effectively declaring - "I solemnly swear that the two points I have just aligned on are free of errors."
Well we know of course that can't be true because there is nothing special about those two points compared to any other and therefore they must be polluted with the same geometric
errors as any other arbitrary two points.

To further exacerbate the issue, the geometric nature of many types of pointing errors is such that they are often a function of the telescope's altitude or azimuth, or possibly some harmonic of that.
In other words, many of these types of errors are not constant across the sky.

When one gathers pointing data, it therefore is built upon the scaffolding of the arbitrary two-star alignment. This is why one should never save the index error terms because they
effectively null out the finite errors of the arbitrary alignment, This is also the reason the data from two different alignments would be a challenging thing to merge.

This is a long-winded way of saying that the workaround is to indeed not power off the system and to use the same star alignment.
But I hope the above background might give you some insight as to why that is so rather than leave one thinking it is through want of functionality.

Attached is a PowerPoint presentation by Argo Navis user Scott Tannehill who contributed this document in June 2007.

Scott illustrates a procedure for centering your altitude encoder.
Hi Rick,

I trust you received my email response yesterday?

It's a Panasonic CR1220 3V or equivalent. We use the equivalent one from Renata ourselves.

The 12 code refers to the fact the battery is 12.5mm in diameter. The 20 refers to it being 2.0mm in height.

Duracell will refer to it as a DL1220
Energizer as a ECR1220
Maxell and Sony both refer to it as a CR1220.

For example, see https://www.digikey.com/en/products/filter/batteries-non-rechargeable-primary/90?s=N4IgTCBcDaIMICUC0BGMYAMIC6BfIA

See "Appendix F - How to replace the Lithium coin cell battery" of the User Manual pages 233-235
Hi Jerry,

Indeed the ability to sample multiple TPAS coordinates through the FROM PLANETARIUM interface is not supported.

In theory, one could sample the same object multiple times as its apparent position changed due to Earth rotation and this would make for valid TPAS data.
We rolled a one-off custom special version of the firmware for a solar observatory research institution in Hong Kong a few years back that provided for that.
This particular observatory just operated during the day and just looked at the Sun, so that was the only object they could sample.

However, in the design of TPAS we had a couple of major requirements. One was that it be able to help provide improved pointing via a pointing model and the second
was that it could be easily operated via an interface using just one thumb.

When the user is sampling an object, we made the design decision that should they re-sample the same object it was most likely because they weren't entirely happy
with the object being centred or possibly because they had originally misidentified it. This behaviour was also consistent with that of MODE ALIGN STAR and MODE ALIGN.
If you align on an object you already had aligned on, it simply updated that alignment point rather than create a second one.

So we purposely designed the behaviour to be that the system would only hold a single sample associated with a single unique internally referenced name.

By doing that we also thought it made the REVIEW DATA menu easier to use, You could see the name of the object you had sampled and if there was only one instance of it, there
would be no ambiguity as to which entry you might want to keep and which you might have wanted to delete.

Since the FROM PLANETARIUM pseudo catalog entry only provides a single internal reference (that is it is the "FROM PLANETARIUM" object) with no name,
the behavior is that when a new set of coordinates are sent to it, it still internally is regarded as the same object as far as TPAS is concerned.

So that provides the historical design decision background as to why the ability to use the FROM PLANETARIUM catalog entry for sampling multiple TPAS objects is not supported.

Hi Charlie,

Seasons Greetings!

Is this the affable Charlie Warren of Amateur Astronomy Magazine who was down here for the OzSky event in 2009?

I hope you have been keeping well. smilie

cbwarren wrote:My issue might simply be the connection. I am using a standard data cable to serial adapter.

In all probability, that will be your problem.

There is no such thing as a "standard data cable to serial adapter". There is no industry standard.

The RJ socket pinouts on the Argo Navis serial port and the set of connections inside the D-connector are custom designed by us.
They were carefully chosen to mininize the chance of damage should a user accidentally plug a serial cable into an encoder port.

Though serial cables for other devices may look similar, chances of them being wired the same way are small.
There are something like 24 different permutations on the RJ plug alone. Then the RJ plugs at either end can be wired in two different orientations.
Then the multiplicity of possible connections from the RJ socket at the back of the D-connector to the D-connector pins makes the chance of plugging in
some arbitrary cable and it working impossibly slim.

In fact one has to be careful. If one uses the wrong serial cable, it can cause a short, possibly damaging the unit and/or PC.

What you want to make sure you have is the genuine Argo Navis Serial Cable :-

These can be ordered online from here :-

If you need frther assistance, please don't hesitate to contact us at sales@wildcard-innovations.com.au

In this thread we attempt to post some tips on performing an alignment

Alignment object queue
Argo Navis maintains a queue of alignment objects and by default its alignment is based on the last object you aligned on and the one previous to that.

There is a SETUP menu called SETUP ALIGN PICK which can change the depth of that queue, but we recommend to keep that setting at its default value of

The SETUP ALIGN PICK menu is deprecated in favour of more advanced functionality, in particular the Telescope Pointing Analysis System (TPAS) which is controlled from within the SETUP MNT ERRORS menu.

Altitude reference
Telescopes are fitted with incremental encoders and these have no inherent zero reference point when they are powered on.
As it transpires, one only needs to define the altitude reference point. This is the job of the FIX ALT REF menu.

Setting the altitude reference point need not be onerous thanks to an Argo Navis feature called AUTO ADJUST ON when you perform the FIX ALT REF step.

To set it up, DIAL up MODE SETUP, SETUP ALT REF and enter a value of +090.000.
Then when you perform the FIX ALT REF STEP, DIAL up ALT REF=+090.000 AUTO ADJUST ON.

Perform your two star alignment as normal. The WARP factor should then be 0.00 (A) where the (A) indicates the ALT REF point was automatically adjusted.
If you see a non-zero WARP factor when AUTO ADJUST is ON or an (X) instead of an (A), it means something is amiss, such as a misidentified star or cable not plugged in.

Keep in mind that though a WARP factor of 0.00 is a prerequisite for good pointing performance, it does not necessarily guarantee good performance.
The reason is that the AUTO ADJUST mechanism bends over backwards to correct the ALT REF point so as to produce a WARP factor of zero wherever possible, even if you have misidentified the alignment stars.

The altitude reference point is with respect the mount's own axis and not the local horizontal as defined by gravity.
One common question user's have is, "Do I need to level the mount", to which the answer is "No".

To illustrate the point, the telescope below is resting on sloping ground. Note that the ALT REF 90° angle occurs when the optical axis of the scope is parallel to the mount's own azimuth axis.


When orienting the OTA using AUTO ADJUST ON, one need only provide the roughest of hints as to the actual angle.
For example, if the OTA were angled at only 80° and the ALT REF point was declared as 90°, AUTO ADJUST ON will still converge to the correct result after the two star alignment.
What this typically means in practice on a Dob is to simply push the OTA to point upward until the mirror box hits the back of the rocker box and will go no further and then perform your FIX ALT REF step.
The whole process should take you only a few seconds.

Only two alignment stars are required to define an alignment
Just as two points define a straight line, two stars are sufficient to define a perfect alignment.

Choice of alignment stars
When using AUTO ADJUST ON, the two alignment stars must have different azimuths in order for its magic to work.
That is to say, when you choose a second star, make sure that it entailed the mount moving in azimuth.

The encoders have a finite resolution. A 10,000 step encoder has a resolution of about 2.1 arc minutes per step. Typically the alignment stars will have angular separations
that are way in excess of the finite resolution of the encoders.

Apart from that, there are no other rules in theory that govern the selection of alignment stars.

In practice, all mounts have fabrication errors of varying amounts that can impact on the pointing performance.
In the face of mount errors, the pointing error residuals will tend to be smallest n the vicinity of the two alignment stars.
With that in mind, it can be beneficial to choose one of the alignment stars to be in the vicinity of the area you are about to observe in.

When moving to a new part of the sky, if it is found that the pointing error has become large, one strategy is to either use MODE ALIGN STAR or
perhaps MODE IDENTIFY in combination with MODE ALIGN to align on a new star in that new area.

When doing that, be mindful of maintaining reasonable angular separation between successive alignment stars. The oldest star will be bumped off the queue and
the one previous to that will take its place. So you will again be aligning on the star you just aligned on and the one previous to that.
For AUTO ADJUST ON to do its magic, those two stars require movement of the mount in azimuth.

Time between alignments
After aligning on the first star, there is no pressing urgency to align on the second.
Though the Earth is rotating, Argo Navis is keeping track of relative time and taking that into account.
In fact it is even taking into account the tiny corrections needed for atmospheric refraction.
So after you align on the first star, you could go inside and drink coffee, chat to a friend on the phone and come back an hour late and complete the alignment on the second star without any penalty in accuracy.

Date, time and location
In general, Argo Navis does not require you to have set the date, time and location in order to perform a star alignment.

However, having the date and time set allows Argo Navis to compute the position of solar system objects and it also is used to compute the small corrections for atmospheric fraction when SETUP REFRACTION is switched to ON
and for precession.

Except when observing artificial satellites, the time and location need not be GPS accurate.

The Moon is close enough to the Earth that its position varies appreciably according to your location on Earth. Set the latitude and longitude in SETUP LOCATION to at least those of your nearest city or town.

When using the ServoCAT, Argo Navis computes where the local horizon is based on your time and location. If an object is computed to be beneath the local horizon, then the ServoCAT will not take the slew.
Therefore you should set the date, time zone and time in SETUP DATE/TIME and location in SETUP LOCATION.
Time zones west of Greenwich such as in the Americas are always negative.

Altitude encoder check for Obsession owners
The altitude encoder needs to be mounted at the precise center of rotation.
On the Obsessions the encoder is mounted on a bracket, The bracket is attached to either the edge of the mirror box or the cross bar of the altitude trunnion.
This bracket can be adjusted left or right if required by loosening the thread cutting screws that pass through the slots in the bracket. Re-fasten once positioned.
The encoder is held in pace by a hex nut and can be adjusted up or down. The center of rotation by design lies in the plane of the top edge of the mirror box or the top surface of the bar across the altitude trunnion.

The altitude encoder bracket fastened to the top edge of the mirror box like on the 18" Obsession Classic is depicted in the drawing below

The importance of the exact centering of the altitude encoder cannot be over-emphasized.
If the encoder is not centered, it will precess around the true altitude axis and this will result in a pointing error residual.

On the Obsessions, the two brass thumbscrews at the far end of the altitude tangent arm should be kept slightly loose as depicted in the drawing below :-

Since the tangent arm is mounted at an angle, gravity will keep it in place so it maintains its reference.
The reason for keeping them loose is because if the encoder is not exactly centered or if the bearing is slightly eccentric, the encoder will precess around the true altitude axis and the
far end of the tangent arm will then want to move radially in or out. If the thumbscrews are tight, then a sideways force will be exerted on the encoder.
The encoders don't "like' sideways force and it can cause them to misread and in the worse case mechanically fail.
Loosening the thumbscrews therefore provides a certain amount of "give".

Myths and misconceptions
Aligning on Polaris is fine. It is just another star in the sky. There is nothing special about it because of its proximity to the celestial pole.

Some users say they will align on a star, then align on a second, then go back and re-align on the first star again in the belief this incantation makes the pointing better.
Whenever you re-align on one of the two alignment stars, the alignment queue is maintained and the information for the star you just aligned on will be updated.
However, doing this is totally unnecessary unless you believe you had not accurately centred the star in the first place.

You probably don't need a reticle eyepiece for alignment. Most of us are pretty good at estimating the center of any plain eyepiece without the need for the cross-hairs of a reticle.
If you have one, by all means feel free to use it. If you don't, a high powered eyepiece is fine.

As discussed above, you don't need to level the mount. Some users mistakenly believe that levelling the mount with a spirit level will improve the alignment. It will not.
Unlike the exaggerated slope in the drawing above, chances are you will setup on reasonably level and flat ground. If the telescope can shift in any way in addition to its altitude and azimuth
motions, it will bring about a random pointing error. If you need a ladder to observe, setting up on level ground makes sense in any case. But it is not a prerequisite for using your Argo Navis.

Mount fabrication errors
For the majority of users, the fabrication errors within the mount are small enough that using AUTO ADJUST ON and a two-star alignment are sufficient.

Ensuring that the altitude encoder is centred and performing what we refer to as the Daytime Encoder Test should be the first port of call for those who are not meeting their pointing performance goal.

See the Argo Navis User Manual pp 123-124 on how to perform the Daytime Encoder Test.

Argo Navis has a powerful featured called the Telescope Pointing Analysis System (TPAS).
TPAS provides a means whereby during performing a star pointing test, it can analyse and potentially compensate for some of the more common systematic fabrication errors found within mounts.
For example, see this page for descriptions and animated examples of the pointing error that is induced if the azimuth axis and altitude axis are not precisely at right angles or if the optical axis is not precisely at
right angles with respect the altitude axis :-

The Argo Navis User Manual has a comprehensive section describing the use of the Telescope Pointing Analysis System (TPAS). See page 122.

A quick tutorial on the use of TPAS appears on this forum here :-

Forum Index » Profile for wildcard » Messages posted by wildcard
Go to:   
Mobile view
Powered by JForum 2.6.2 © 2019 JForum Team • Maintained by Andowson Chang and Ulf Dittmer