Tom Gibson replied to the topic 'Headless KStars' in the forum. 2 weeks ago

I use nomachine to go from laptop to different machines and these days only occasionally have blank or white screens. ctrl+alt+0 detach / connect always clears it up.
There are reports and fixes from older versions on nomachine's support forum.

When connecting to odroid remotes I run x11vnc server since it seemed more lightweght and use TigerVNC over ssh tunnel as a client without problems.

When first bringing up an odroid I use a monitor plug to get the initial remote GUI working and to be able to set a high screen resolution, then remove the plug.


Tom Gibson replied to the topic 'New Mexico Cosmos Observatory' in the forum. 1 month ago

And there I was thinking Well at least I'm not deep in the African bush like poor old PK.



Again, I am running the stable release using an Intel machine, ubuntu 20.04.
Have problems with both imaging and guide camera, no problem with ZWO filter wheel.

Perhaps relevant to the thoughts about it being driver readiness/timing releated.
I have always run a local setup with Ekos and drivers on the same machine with
Ekos auto starting the drivers. However since updating to the recent release
the only way I found to coax the Astrophysics Experimental driver through its
initialization was to use indiserver to start the drivers. Then use Ekos remote
to the same machine without auto start. That allows the connect and cold start
buttons to be functional for the mount.

So it finally dawned on me to revert back to the original method of startup and have
Ekos start and connect to the drivers. Now both cameras connect and operate okay.
I have only gone back and forth two or three times but the results seem consistent.
No longer have cameras failing to connect, or connecting but taking 2 minutes to fill
in the indi panel controls. Also can image without it looping and restarting the image
attempt several times.

In case it is of use to anyone, local vs distributed startup playing a role?

For the moment for me it is camera or mount, pick one. I think next will try
stringing a USB2 cable to the mount instead of ethernet see if that changes the


After updating to the latest stable release I had difficulty with the ASI cameras.
After two weeks both cameras are connecting at the moment, but I need to find more consistency.

Simplifying can help, I ran with an Ekos profile using just the telescope simulator and a single camera.

Many of my failure runs seem to have been due to prior errors. I connect through hubs and have to
remove and reconnect power to them between Ekos/driver sessions. I have not gone back to without hubs
to see if it really the disconnecting of the camera that is impacting results.

Running the /usr/bin/asi_camera_test can provide a clue where to look for the problem. I think it is provided
by the install and uses the same library code.

There was a period where the camera was connecting but not fully and I mistook those as failures to connect.
Presently it takes a minute or so for the connection to become apparent. Then after another minute or
two the indi screen finally puts up the Control tab.

It might be worth examining the ~/.indi/'ZWO CCD ASI294mc_config.xml' file to see if all the name and settings
appear correct. A new guide camera was introduced and the xml file contained a mix of camera types. Probably
something I caused unknowingly.

The last time of trying to use the imaging camera an exposure would count down to 0 and then restart the exposure again without producing an image. This is an old problem, seems like a year or so since last seen. I note the ASI rules.d file has been replaced.


I ran update yesterday, picking up the new 1.8.9 release and the ZWO drivers started crashing. Ran update again today with same results.
Then removed indi-full and reinstalled without it helping. How did you go about doing the reinstall, or are there specific steps needed to recover?


Apologise for the noise but I have to reverse myself again. Today I am back to being able to control the mount.
To be brief. Mach1 VCP4-P02-08, 1.8.8, 3.5.1 stable.

Before running I look at the .indi xml files.
Telescope: Park position = 2 (weights down, telescope facing east) unpark from = last parked.
ParkData: Park Status = true, park position = 2.
Both as expected.

Power on mount
Start KStars & Ekos/INDI using the GUI interface.
INDI panel Park To selection is blank with red LED. Select Park2 and save
Use the INDI Startup: cold start button
This establishes the initial conditions to be Parked with Tracking off. Ekos and INDI panels are in agreement.
INDI select unparked, Ekos also changes. Use Ekos to select parked and INDI also changes.
Select unpark and turn tracking on. Via KStars slew to nearby object. Park scope.
This sequenced worked.

Since the previous driver default unparked conditions was tracking, any suggestions on how to setup for the scheduler?
I have to pre-setup the mount using the cold start button? I did not see a way to have tracking start when changing from parked to unparked, or after slewing to a target. So do I also have to leave the mount unparked and tracking, selecting a target that will still be safe when the scheduled time arrives?

Items to be looked into.
- Why the INDI `Park To' field is lost from time to time.
- Why enabling verbose logging to file appears to prevent the mount indi options save button working if that is still true.
- How to automate the cold start, unpark, track sequence.


The mount initialization is well understood I think. The recent updates have always seemed to hint of confusion between the state between Ekos, INDI and the mount.
Doubt we can get far at this time without some fixes, see the second edit I am about to make to my previous post.


See if using the cold start button in the indi panel allows you to unpark the mount.


I have not used it this winter so only have superficial impressions noted in my last but one post.

There is some odd behavior in the indi panel using the save button. I had to disable logging in the EKOS setup panel. That removes the logging check boxes from the telescope's INDI panel and then the save button would work.

But the main thing was the introduction of the cold start button in the INDI panel. The user has to locate it in the INDI panel and push it before any of the EKOS mount controls such has park/unpark will work. Not sure how that will play with the scheduler since it does not offer such an option. The initial startup conditions are different now: unparked and not tracking. However one can not slew to a position or do anything else until the cold start button is used. I think that is true even if the mount has not been powered down from one EKOS run to another. I would prefer whatever cold start does, for it to be automated or its requirement be conditional on identifying older mount firmware.

I think some of my initial difficulty with getting it to work was that the cold start button was not there or was not working, can't remember which. This was because was not defined in my mount's INDI XML file due to the file being retained across installs. When I tumbled onto that and edited the file things started to work.

Now I am happy to find the mount can be parked/unparked and slew to a position which appears to be accurate. This is west of Greenwich which I understood to have been an issue previously. This means I can stay with Ekos and will have an imaging session one fine night to try it out more fully.


The driver is being reworked and will hopefully be updated again soon.
Using EKOS I could get it to park/unpark by first using the cold start button. Since the introduction of the cold start button is recent I had to first
edit the configuration file to add the cold start button definition. Being a new install you might already have it working. See the post before yours.

Are you presently testing via EKOS.

Do you see the cold start button in the telescope's INDI configuration screen panel?



If you still have your setup installed, I am getting signs of life here. Presently running EKos stable with INDI 1.8.8 but hopefully the same for a normal stable install. I running Mach1 with VCP4-P02-08 firmware.

To get the options tab, save and load buttons to work I needed to disable verbose logging in the EKos profile.

Options tab: Load and Save buttons not responding.
To reproduce. In the EKos profile being used, open "Logs" setting. Enable verbose logging
to file, along with some Ekos and INDI options selected.
In telescope INDI window the Debug levels, Logging Levels and Log Output entries will then
appear in the Options tab. At this point the options save button does not work.

Then needed to manually edit ~/.indi/AstroPhysics Experimental_config.xml to add an entry for the
cold start buttons:

<newSwitchVector device="AstroPhysics Experimental" name="STARTUP">
<oneSwitch name="COLD">
<oneSwitch name="WARM">

Without the edit, manually selecting cold start first thing each time Ekos is started has the same effect.

Can now park/unpark, slew and return to park.


Tom Gibson replied to the topic 'Driver development tutorials' in the forum. 4 months ago

There is a rolloff driver example at
Might provide ideas on error handling and setting up the Ekos interface.
A couple of Arduino examples on sending back status and error information.
Driver is an edit from the Rolloff driver example.


Tom Gibson replied to the topic 'Induino Meteostation wind gust' in the forum. 5 months ago

It appears your listed device WH4000 is supported by the weewx product -. . That would provide viewing of local conditions. There might be the possibility of using the tie in to the Weather Radio driver:


Tom Gibson replied to the topic 'Persistent Serial Port Mapping' in the forum. 7 months ago

You can confirm it works when defining it manually.

sudo unlink /dev/ttymount
sudo ln -s /dev/ttyUSB0 /dev/ttymount
ls -l /dev/ttymount should show /dev/ttyUSB0

Then in the connection tab use /dev/ttymount (include /dev and no hyphen in tty-mount)