Unfortunately no progress from my side, the driver should be feature complete, but I haven't been able to go to our club observatory to actually test it (due to covid, general family busyness and pure laziness due to bad weather)

I'm at my observatory now for at least a month. Is there someway you can send me the code?

Thanks,
Bob

The code is available as a branch in my INDI fork at github.com/jpaana/indi/tree/ddw_driver

If the code is almost feature complete, maybe submit it to INDI? At least it would make it to the nightly PPA which would make testing it a lot more accessible.

I would love to (maintaining a separate branch is a chore), but I'd also like to run it with actual hardware at least once before releasing something with my name on it

On another front, I manged to get DDW loaded under wine. It "starts" OK in that the usual image appears. However, I can't get the program to connect to the control box using a COM device. It should work (famous last words). The dos devices (like COM1, OOM2, etc) are automatically mapped to the /dev/ttyS* devices.

I'll give jpaana's code a shot.

So now I need guidance. I've created a "shallow clone" of indi in a separate directory. There are two main directories: build & indi.
I've downloaded jpaana's directory of indi-ddw_driver.

What's the process of the configure/make/make install?

Thanks.

My repo is a fork of the main INDI repository with an extra driver added so you can follow the regular instructions on how to compile the core INDI lib from indilib.org/forum/general/210-howto-buil...st-libindi-ekos.html

You only need to follow step 2, just no need to clone the repo as you already have that. It's a straight forward build configured with CMake if you have compiled those before.

Limited success! Limited only by what I was willing to try.

Fired-up kstars, went to the device handler, and there, under domes, was Digital Dome Works.

Was able to open and close the shutter. It's getting dark and very cold here in SW New Mexico so I want to wait until I can get someone in the dome next to the kill switch if something goes awry.

In the area at the bottom of the screen there was a constant chatter of something like
Error Message Unrecognized character: <blank> or 1, or 2 or some random number between 0 and 9. Did not seem to have any effect on operation.

I was surprised it was connecting via /dev/ttyUSB0. From my playing around with wine I thought it would use /dev/ttyS0 (or 1, 2, etc).

Cheers,
Bob

Using the hint from the INDi driver, I configured /dev/ttyUSB0 to link to com3 in the wine I was using to test the MS version of DDW. And it worked. Was able to raise and lower shutter.
Will run more tests tomorrow (should be better weather).

Excellent, thank you! There is probably something in the protocol that I either misunderstood or just plain old mistake in handling the response. If you could get a log from the driver (enable driver debug via KStars/Ekos) I might be able to fix that spam.

OK -- let's see if this helps.

While the shutter worked fine, I could not get the azimuth to move. At first the az would not budge. Later, every time I tried to move the az, the indi lib crashed.

So roughly, for every session:

1. Connect
2. Run shutter just to confirm minimal operation
3. Try az motion.
4. Park, unpark dome
5. Again try az motion.

For a couple of sessions the az refused to move. Later, as soon as I issued an az command , indi would crash. I tried logging out/in. Still crashed. I rebooted the system. Crash. I cycled the power on the DDW control box. Crash.

The one oddity is that, if I told the dome to park, it would move the az to roughly due north. Park is actually around 12 deg, but the point is that the park command actuated the azimuth.

You can see from the logs that sometimes was confused about whether the dome was parked or not. I would issue commands and the log would say I first needed to unpark the dome and then when I did issue a command to unpark the dome the response would be that the dome is already unparked.

Hope this helps.

Oh -- one other gotcha. The log file names are not conducive to copying using a file manager. I probably could have done it via the command line, but the kde file manager (Dolphin) did not like the log names with the times. So I just sequentially renamed them.

Good luck. Let me know if I can provide more testing.