[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
Below are a couple of snapshots I took on Friday 9 October 2020 whilst at the factory that manufactures the Argo Navis units here in Sydney.

Every single Argo Navis ever made was manufactured in Sydney.

We are particularly proud of the fact that the majority of workers involved in its production are woman.
We have always been proud of that but even more so in 2020.

The first snapshot shows racks of Argo Navis printed circuit assemblies.
These particular units have reached the quality assurance (QA) stage of the factory pipeline where they are awaiting testing and inspection.

The wires go to the battery terminals and the pink anti-static bubble-wrap is taped over the displays to protect them during handling.

Once the units are housed into their enclosures, they undergo further inspection and at least 24 hours of continual burn-in testing.

The second snapshot is a view of the testing and packaging area of the factory.


garin wrote:Thanks Gary, new firmware loaded and issue resolved. I'll leave that until after the dark sky trip.

I haven't reloaded the comet data, is there a chance you could send me an example comet tle that works and I'll compare it to the one I loaded ?

Been so long since I've been out I didn't realise how much I'd forgotten, good thing I had a practice today smilie

Thanks again for you help.


Hi Garin,

You can download them from here :-

Chances are the problem has been rectified now you are at firmware version 3.0.4 and what I recommend is that if the format looks the same
as those above (Argo Navis uses the same format as TheSky planetarium), I would recommend you try re-loading that file you have again.

If there was still a problem, I would be very interested to know and in that unlikely situation I can send you a small firmware file that you can
load like regular firmware and it will clear the LOAD CAT area.

Last year when comets like 2I/Borisov made a pass, their unusually high eccentricities 'broke' a lot of the planetarium software packages in that
they too were giving incorrect solutions.

It was these type of orbits that firmware 3.0.4 specifically addressed. We put a lot of effort into writing and testing that software so if you are
willing to be another test point then it would be appreciated.

Hi Garin,

I replied earlier to your email. I am away from the office as it is Sunday but thank you for leaving a voicemail message which I just listened to.

On rare occasions there were problems with some specific types of orbits. Rather than an ENCOUNTERED BUG occurring,
the solution for these particular orbits would be inaccurate. Version 3.0.4 saw very significant improvements in the
computation of orbital elements for comets and asteroids and these rare troublesome cases were fixed.

It is worth a shot to upgrade to 3.0.4. It will clear your LOAD CAT area automatically in any case.
Special thanks to Argo Navis user Peter Allison who made this instructional video for fellow owners on how to connect Argo Navis to the Sky Safari planetarium using Bluetooth.

Hi Thad,

Thanks for the post.

Sounds like you are in the MODE ALIGN menu rather than MODE ALIGN STAR.

The MODE ALIGN STAR provides a convenient list of bright stars that you can scroll through with the dial.

The MODE ALIGN menu presents the last object you accessed either through MODE CATALOG, MODE IDENTIFY or MODE TOUR and like MODE ALIGN STAR, defaults to ACHERNAR (the
first bright star alphabetically in the catalog) when you power it on.

So if I were a betting man, odds are you might have been having a little 'finger problem'. smilie
We think in terms of an extended family of Argo Navis owners.

We were therefore deeply saddened to learn today of the passing of George Nikolidakis of Athens, Greece, in April this year.

George was only 59 and died after a battle with COVID-19.

President of the Hellenic Amateur Astronomical Union, I know he will be missed by his family and friends.

Our deepest condolences.

Gary Kopff
Managing Director
Wildcard Innovations Pty. Ltd.
20 Kilmory Place
Mount Kuring-Gai NSW 2080
Phone +61-2-9457-9049
Twenty years in the making, the Sloan Digital Sky Survey has released the largest 3D map of the Universe ever created, filling in the troublesome gap in the middle of 11 billion years.

Sloan Digital Sky Survey wrote:
The Sloan Digital Sky Survey (SDSS) released today a comprehensive analysis of the largest three-dimensional map of the Universe ever created, filling in the most significant gaps in our possible exploration of its history.

“We know both the ancient history of the Universe and its recent expansion history fairly well, but there’s a troublesome gap in the middle 11 billion years,” says cosmologist Kyle Dawson of the University of Utah, who leads the team announcing today’s results. “For five years, we have worked to fill in that gap, and we are using that information to provide some of the most substantial advances in cosmology in the last decade.”

The new results come from the extended Baryon Oscillation Spectroscopic Survey (eBOSS), an international collaboration of more than 100 astrophysicists that is one of the SDSS’s component surveys. At the heart of the new results are detailed measurements of more than two million galaxies and quasars covering 11 billion years of cosmic time.

We know what the Universe looked like in its infancy, thanks to the thousands of scientists from around the world who have measured the relative amounts of elements created soon after the Big Bang, and who have studied the Cosmic Microwave Background. We also know its expansion history over the last few billion years from galaxy maps and distance measurements, including those from previous phases of the SDSS.

“Taken together, detailed analyses of the eBOSS map and the earlier SDSS experiments have now provided the most accurate expansion history measurements over the widest-ever range of cosmic time,” says Will Percival of the University of Waterloo, eBOSS’s Survey Scientist. “These studies allow us to connect all these measurements into a complete story of the expansion of the Universe.”

Full press release here including images and four videos :-
Good to hear you were able to resolve it in the way you described.

In any case we would have helped you restore the correct date one way or the other, but if the ends justifies the means, your prescription was simple enough.

I must admit it still leaves me with a puzzle how it was stuck in that state. The code explicitly checks for the condition that if the year is less than 2000 at power on,
it sets the RTC date to JAN 1 2000 and reads it back to check that the change was made and reports an error it is not. You can leave to me as an exercise. smilie
Thanks for the post.

By way of background, there is an internal bit within the real-time clock (RTC) that determines what century it is set at.
If the coin cell becomes depleted, this bit can then go to zero which represents the last century.

However, each time it powers on, Argo Navis checks for this condition and sets the time to 1 Jan 2000 which includes setting the century bit to a 1.

Obviously it has not done this in this case.

To be honest, it is a strange condition and armed with a deep understanding of how all this works, one that would seem logically impossible,

However, we did have at least one report of it from a customer in December 2019 and they resolved it for themselves by upgrading the firmware,
the act of which in itself magically set things right. So it remained a mystery why it was not automatically being set at power-on otherwise.

If you have an Argo Navis serial cable and USB Adapter, you could try a couple of things.

Firstly, ensure the serial port you are connected to is running with a STARTUP command of 'navis' and a BAIUD rate of 38400.
Then start Argonaut and connect to the unit.

You should get a % prompt in the Argonaut terminal window when communication is established or if you press the PC enter key in the terminal window.

Then using the Argonaut Date/Time pulldown menu, select Set Date/Time. That will transmit the date/time from the PC to the unit and it might resolve it.

Failing that, use Argonaut and load Argo Navis version 3.0.4 firmware :-

That might also resolve it,

If it does not, email me at sales@wildcard-innovations.com.au and we can try and help resolve it. It certainly is unusual.

tomrgray wrote:Thanks for your suggestions. No joy on Serial 2, but have reconfigured serial 1 as you suggest and this appears to be working OK without usb cameras attached - I’ll test it tonight as clear skies. Does that mean there is a problem with Serial 2, dirty connection?

The laptop is an old Dell Latitude with Pentium M if you can still remember these. During lockdown I restored by original DEC Digital 386 25SL 2 Mb RAM and 40MB HDD and VGA display! I can still run my original Distant Suns from floppy disks...

Have a look inside the SERIAL 2 port under good light and magnification. Check that the contacts are clean and are all sitting in the same plane.

Also have a look inside the battery compartment and check if there has been any sign of a battery having leaked or vented in the past.

If you have a multimeter, put it in continuity mode or resistance measuring mode. Power the unit off. Use Appendix C of the User Manual to identify which is the SERIAL 1 GND contact.
Try and probe it and the GND contact of the External DC Power Port for low impedance. If there has ever been a short on the SERIAL 1 line, it may have blown the associated protective ferrite.
Hi Tom,

Thanks for the post and welcome to the forum.

The Argo Navis serial port communication is extremely robust and well tested, so it is most likely to be at the laptop end.

We've tested against Autostar extensively over the years but I just ran Austostar 3.18 on a Windows 2000 machine interfaced to an Argo Navis for half an hour and the connection didn't drop.

Make sure on the Autostar end in the communications dialog that you set parity to none and flow control to none.

I gather from your description the laptop has an in-built DB-9 COM port?

For the cameras drawing power from the USB ports, if the laptop manufacturer had complied with the USB specification, it should be able to
deliver sufficient power to them without interfering with the operation of anything else.

Given it is an older laptop though, is there any indication that is running out of grunt to process the data from the cameras and Autostar?
One test would be to disconnect the cameras and see if there is any improvement to the reliability of the serial comms.

Argo Navis serial ports 1 and 2 are independent and so another test would be to configure SERIAL 1 to run the 'meade' STARTUP command at 9600
and try swapping the cable to it.

Allen Grundmeier wrote:My name is Allen Grundmeier.

I just received my Argo Navis yesterday.
I'm taking it slow to make sure I don't assume that I know where I'm at in the set up process.

This is my question:

I've got a Win 10 computer. I'm trying to find the correct COM port as descriibed on pg (Com & LPT) ports as described on pg 169.

Allen Grundmeier
Robbinsdale, Minnesota

Hi Allen,

Welcome to the forum.

The Keypan USA-19HS comes with a CDROM with software on it. Be sure to install it first before plugging in the USB Serial Adapter for the first time.

The software on the CDROM includes the Window's device driver and a convenient utility called the Keyspan Serial Assistant.

On Windows 10, locate the "This PC" icon on the Deskop, right click on it and select Properties.

A dialog will open. On the left hand side of that dialog select "Device Manager".

Once the Device Manager dialog opens, follow the instructions in the Argo Navis Users Manual and drill down through the Ports (COM & LPT) hierarchy to determine the COM port
number Windows has assigned the Keypsan USB Serial Adapter and to change it to an unused port in the range 1 thru 4 if need be.

Alternatively, click on the Window's Start button on the lower left of the Desktop, left click on it and look for the Keyspan USB Serial Adapter folder.
Within it, select the Keyspan Serial Assistant. When the approval dialog open,s allow it to make changes to your computer. Select the Port Mappings tab and change the COM port that way.

Once you have assigned the USB Serial Adapter an port number of 1 thru 4, when you open the Argonaut software utility, select the corresponding number 1 thru 4 in the Port pulldown.
Then select Connection->Connect.

Hi Mikael,

Thanks for the post and the interesting question.

When the eyepiece is replaced by the much heavier camera, one of three things can happen.

1) The OTA drops in altitude but this drop is reflected by a corresponding change in the altitude encoder values.

2) The top end of the OTA "droops" in altitude as either the truss poles flex, the secondary cage shifts with respect the truss poles or the truss poles shift with respect the split blocks.

3) The camera itself shifts within the eyepiece holder.

I gather from your description you suspect the truss poles flex?

To eliminate 1) as the cause, dial up MODE ENCODER and whilst trying to accidentally nudge the OTA, note whether the altitude encoder values change when replacing the eyepiece with the camera.

Flexure of the truss poles as in 2) is a function of altitude with the maximum flexure occurring when the scope is pointed toward the horizon.
If the flexure is only small, that is within arc minutes, you might get away with a simple linear model.

One approach might be to create a simple TPAS model when the eyepiece is attached. Do a two-star alignment then sample say 6 stars using the SETUP MNT ERRORS functionality.
COMPUTE the model say using only the IE term and apply the model by selecting USE NOW.

When you replace the eyepiece with the camera, using the SET ERROR VALUES, IN USE NOW submenu, you could try changing the INDEX ERROR EL (ID) value to shift the apparent
pointing position in altitude. Perhaps with some trial and error you could ascertain a typical offset.

This approach might also work for 3).

One could also create a more dynamic offset, that is one that is a function of altitude, by creating a model that uses IE, ECEC and ECES, but finding suitable values would be more challenging.

I've never tried this, but the TPAS model and tweaking IE would be my first experiment if it were me. One assumes the shift is systematic rather than a sudden random shift.
I would be interested to hear how you get on.
erick wrote:Just catching up with the posts on this site. Wow Gary! What an experience. Congratulations. Eric

Thanks Eric,

As far as observing locations go, it is absolutely amazing.
Hi Didier,

The ServoCAT definitely won't respond to Meade protocol commands.

You can fill the Argo Navis FROM PLANETARIUM catalog entry either by connecting to the Argo Navis directly using the Meade LX200 protocol
or via the ServoCAT by a program with a servocat driver.

However, to initiate a GOTO from the planetarium, that can only be done by using a program with a servocat driver.

Otherwise if you use the approach where you directly interface to the Argo Navis using the meade protocol, you will need to press the GoTo button on the ServoCAT handpad.
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