bujin9 wrote:
Hi all...

tried the Argo Navis last night for the first time on my 22" Obsession. Did the one time setup and then the alignment (two star) and then to an introductory run. Everything seems pretty straight forward but I seem to be off still in the targets.
After aligning (using Polaris and Dubhe)....even though my 'warp' was within acceptable limits (-.3 one time and .5 another), pointing was still off.
I setup for 'Alt/Az Dob Mounts'....Tube is pointing straight up....after aligning the 2nd star, I exit out to the 'Mode Catalog' to do the 'Introductory Run'.
What other factors affect pointing? I'm not on super level ground but it's pretty good. But if I read the documentation right...that shouldn't affect it as it's more important to make sure the tube to base alignment is correct. And like I said, it's not level like a granite table ...but it's not bad either (my driveway).
This is of course assuming my initial one time setup was done correctly (although it seemed pretty much by the numbers).
If the initial one time setup was done incorrectly, can I go back and re-do it? I'm using the batteries that came with the unit so I'm assuming they're fresh.
Is there something else I should be considering that I'm not doing?
Thanks,
Joe

Hi Joe,

Dave Kriege at Obsession always preconfigures the encoder direction sense setup parameters prior to shipping units.

However, let us assume you want to establish the encoder direction senses, which are the +/- signs in SETUP ALT STEPS and SETUP AZ STEPS.
Rather than use the method described in the User Manual to establish, I highly recommend to use the procedure I will describe here to establish them.
This also has the advantage that you can do it, say, in the garage indoors during the daytime.


To check the SETUP ALT STEPS sign, point the Optical Tube Assembly (OTA) to the vertical and DIAL up MODE FIX ALT REF, ALT REF=+90, AUTO ADJUST OFF and then press ENTER.
Now DIAL up MODE ENCODER. The right-hand displayed value should be close to +90 degrees.
Now push the OTA downward in Altitude toward the horizon.
The right-hand displayed value should decrease, +89, +88, ... +3, +2, +1, 0 as you go from the zenith toward the horizon.
If not, reverse the SETUP ALT STEPS sign and repeat the test.

To check the SETUP AZ STEPS sign, rotate the scope in Az clockwise whilst observing the left-hand displayed value in MODE ENCODER.
The Az angle should increase. If it does not, reverse the SETUP AZ STEPS sign.

As mentioned in the User Manual, irrespective of which way the arrows point in GUIDE mode, always push the scope in a direction that makes the GUIDE angles closer to zero.
One can later change the convention of which way the arrows point using SETUP GUIDE as a matter of personal preference for your particular installation.

Once you have correctly established the encoder direction senses, we also recommend you use 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.


There is no need to level the base as part of the alignment process. To appreciate that and o gain further tips, see this post here -
https://www.wildcard-innovations.com.au/forum/posts/list/78.page

For support, I highly recommend you contact us directly at sales@wildcard-innovations.com.au
Alternatively you can post here but the email always gets our immediate attention.

I recommend you avoid seeking assistance on the Cloudy Nights forum.
It's legal fine terms and conditions means as a company, we choose not participate on it.
As you have seen, Cloudy Nights can be a bit of a rabble.
Though many responses to posts such as yours are well intentioned, many completely miss the mark and more still have nothing to do with your appeal for assistance.
In reference to the nebulous nature of Cloudy Nights, I refer to it as the "Blind leading the blind forum".
Anyway, the good news is that for the very best support, we are always here.

The Argo Navis one page Quickstart guide provides for a handy reference for performing an initial alignment and for locating objects

owenb wrote:I just wondered since it has been over three years since the release of the 3.0.4 firmware if there are likely to be any further releases of firmware for the AN units or have they gone as far as they can?

We have two types of firmware releases, General Releases and Production Releases.

3.0.4 is still the most current General Release.

3.0.6 is the most current Production Release.
In other words, if you buy a new unit today it is loaded with 3.0.6.

The functionality of these two different types of releases at any point in time is essentially identical.
However, Production Releases such as 3.0.6 contain device drivers specific to the newer components on the latest hardware revision.

One of the wonderful things about Argo Navis is that ever since the original firmware 1.0.0 release there has never been a major bug.
It has always worked as printed on the tin. That doesn't come by accident, but through decades of experience in software and hardware engineering,
a lot of care and a lot of testing.

What we are also proud of is that we provided major enhancements such as TPAS to all owners, irrespective of the vintage of their units.

At the moment we are currently deeply involved in bringing to market a next generation servo controller.
So no new Argo Navis firmware development is taking place at this moment in time.

However, it is likely that new firmware that in part leverages off that development might be release in the future.

Hi Dave,

Thanks for the link.

Indeed, since we are between Last Quarter and New Moon, the best chance will be on the return leg when the Moon is risen at night.

Ted Molczan posted these visual magnitude estimates back in late August but they were based on a August 29th 2022 launch date.
They might still provide some rough estimate.

http://satobs.org/seesat/Aug-2022/0236.html

Over at the British Astronomical Association one enthusiast reported that "I detected the Israeli Beresheet lunar lander when approx 1/3rd of the way there and
have seen the Russian Spektr-R mission near apogee, but neither appeared near the Moon, so I am keen to give it a go – cloud permitting."

davefmccoy wrote:Hi Gary,

This may be the easy way to get the pointing information:
https://ssd.jpl.nasa.gov/horizons/app.html#/

Dave

Hi Dave.

This is perfect.

Select Ephemeris Type as "Observer Table".

Select Target Body: Artemis 1 (spacecraft) (Orion)

Select your Time Specification. You can even define it in 1 minutes steps.

The table will produce lines with dates and times along with RA and Dec in terms of ICRF. which is exactly what you are after.

An RA/Dec coordinate can be entered into the SETUP SCRATCH menu on Argo Navis as a scratch object and then you can go to MODE CATALOG, SCRATCH OBJECTS and Argo Navis will guide you to it.

In the header of the table it will tell you if there is a "Visual Interferer", namely the Moon, which makes sense as you are heading toward it.

Hi Dave,

Further thoughts.
The state vector will be geocentric and so in addition to my above post, one would need to also do a conversion to apparent topocentric position.
Like the Moon itself, it's "close" and parallax is otherwise significant.

Unistellar might also publish RA/Dec positions for Artemis on their web site here. They have a blog page suggesting they will.
https://unistellaroptics.com/ephemeris/
Playing with it using the JWT telescope as a test target, I note the page gives a result you can expand that provides the RA/Dec for your location.

I would not be surprised if similar pages to this pop up on the net

Hi Dave,

Thanks for the interesting post and great to hear you are going to attempt to track Artemis with your scope.

TLI takes place very early in the mission, at 1 hour 33 minutes 21 seconds. So there won't be any orbit around the Earth to make the use of TLE (three line orbital elements) possible.

At first blush, doing the conversion from the state vectors they will announce to RA/Dec sounds like the go. Someone on the net may end up automating it.
NASA are saying the state vectors will be with respect the Earth-centered inertial coordinate frame J2000.
See https://www.tumblr.com/nasaorion/692871881822502912/how-to-use-data-from-nasas-arow-tweets

Don't forget to normalize the x,y,z position to the unit sphere.

Find the norm first :-
norm = sqrt(x * x + y * y + z * z);
Then :-
x = x/norm;
y = y/norm;
z - z/norm;

Find Right Ascension :-
ra = atan2(y, x);
Then put ra in the range of 0 to 2*PI and convert from radians to hh::mm:ss

Then compute Declination :-
rho = x * x + y * y;
dec= atan2(z, sqrt(rho));
Convert declination from radians to degrees.

Something like this anyway. It's Sunday afternoon here in Sydney and I might have missed something in this quick back of the napkin response.

Argo Navis has the MODE SETUP, SETUP SCRATCH feature where you can manually enter an RA/Dec.
It then appears under MODE CATALOG under SCRATCH OBJECTS.

I'd really be interested to hear if you have success observing it.

Hi Paul,

Thanks for the question.

Strictly speaking, Argo Navis doesn't use a sidereal rate when SETUP REFRACTION is switched to ON. Since refraction raises the apparent position of an object as a function of elevation above the horizon, the tracking rates continually and dynamically change accordingly.

To use SETUP REFRACTION, ensure your time is set correctly and that your approximate location is set in SETUP LOCATION. Switch SETUP REFRACTION to ON.

The best way to understand what tracking rate is is use at any one time is as follows.

If the object comes from one of the internal Argo Navis catalogs and it is a solar system object, Argo Navis will provide the tracking rates inherent to that object.
SmartTrack(TM) in that instance kicks in and provides tracking rates inherent to the target object when you are within 5° radius of a satellite or 2.5° radius of any other type of solar system object.

The tracking rates for any non-solar system object are sky position based rather than object based per se.

What that means is that the tracking rates are calculated according to where the scope is pointing in an RA/Dec sense at any one instant, again making small corrections for refraction.
So if you were to point at a star, then internally Argo Navis fetches the stars RA/Dec position and uses those coordinates to compute the tracking rates. As you move a little away from that position, likewise the tracking rates, being the first differential of pointing with respect time, will change by tiny, tiny amounts accordingly. In other words, the tracking rates in this instance are following the sky rather than following the object. Since star and deep space objects have essentially fixed RA/Dec's with respect time (over the time scales we are dealing with here), the tracking rates for them will be correct.

With this in mind, when one uses the FROM PLANETARIUM feature, what gets transmitted from the planetarium program is just a raw RA/Dec position rather than any information about the target. Since Argo Navis cannot determine whether the FROM PLANETARIUM position happens to be a solar system object or not, it always applies inherent position based tracking rates. This is due to the fact that ASCOM has no support to convey target information, it only conveys target RA/Dec coordinates.

It is not possible to override the tracking rates using ASCOM. What's more, from its very design inception, ASCOM made what I thought was a poor choice in tracking rate support. What it should have done is simply support the ability to set or retrieve arbitrary tracking rates for both axis in terms of radians/second. Instead, the designers chose to support the notion of four rates which they designated sidereal, lunar, solar (for the Sun) and King (which refers to tracking rate corrections to attempt to correct for refraction that were published by Edward Skinner King in 1931 - archaic today).

So even if we wanted to support tracking of say Jupiter from a planetarium at its inherent rate, to the best of my knowledge ASCOM unfortunately does not support it.

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 :-
https://www.abc.net.au/news/2022-07-22/huntsman-space-telescope-launches-nsw-siding-spring-observatory/101256796

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

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

https://www.abc.net.au/news/2022-07-14/tour-through-nasa-james-webb-space-telescope-images/101231818

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 :-
https://spectrum.ieee.org/semiconductors/materials/the-radio-we-could-send-to-hell