Our astronomy club has the DDW dome controller and I planned to take a shot at making a driver for it to be able to image Mars there with my Ubuntu laptop without manually rotating the dome, but haven't had the time as my precious little hobby programming time is currently taken by writing support for ScopeDome Arduino card in my ScopeDome driver. But good to know if there is additional interest, that would make it more motivating.

Taking an existing dome driver as a base and converting the command set is in theory fairly straight forward as most controllers have a text based serial protocol and similar functionality, but being competent with C++ and especially debugging code does help. The DDW command set is pretty well documented and doesn't seem to have that many quirks that implementation should be fairly easy for someone that has tinkered with INDI drivers before and has the device at hand for testing how it actually behaves.

Read More...

Jarno Paananen replied to the topic 'Home & Park position' in the forum. 2 weeks ago

Autohoming requires a physical index and sensors in the axis which EQ8 has but HEQ5 and others don't.

Read More...

ScopeDome also promised to send me a card to test with next week so that should help a lot in initial bring up. Can't test stuff that requires a dome but at least basic communications and other simple things. Just need to get coding :)

Read More...

It's actually better that they are non-blocking as things like abort wouldn't work very well otherwise. The older USB card works the same way, for example opening the shutter is just turning on a relay and the driver polls input status until the open limit switch triggers and turns the relay off. The hardware also stops the motors automatically when limits are reached. Currently the driver polls status every second by default, I wonder if that's too fast for the HTTP server in the Arduino as the driver source says the device should respond within 1-9s, but we'll see when you get to test it :)

PS: thanks, looking forward to that :)

Read More...

Got Windows driver source from ScopeDome so I can check some details from there, but the basic operation seems to be quite similar to the old card so should be fairly straight forward. I started the implementation with some restructuring and placeholders copied from old card code. I will probably implement USB connection first as that's simpler, but adding ethernet support after that should be quick. It requires HTTP so I'll probably use curl library for that as it's used by some other INDI drivers as well.

Read More...

Good to hear about tracking working, sorry about the shutter controller... I'm currently also waiting for a new PCB for my controller, so I know the feeling.

Read More...

The drivers use base classes from the main library and if they don't match, there will be runtime linker errors among other problems as C++ is not tolerant to changes in class members. So the drivers need to be compiled against the same version of INDI as in the system. If you want to stay with stable release, you could recompile the new drivers you need against those libraries and they should work.

Read More...

Oh, I meant shell command called indi_getprop which comes with INDI, it would do all the parsing for you and you can also give it just a subset of the properties to return.

Read More...

You can poll those values from INDI server with indi_getprop command, for example my EQ8 gives:
EQMod Mount.EQUATORIAL_EOD_COORD.RA=3.0200912594207576234
EQMod Mount.EQUATORIAL_EOD_COORD.DEC=89.684600000000003206
EQMod Mount.TELESCOPE_PIER_SIDE.PIER_WEST=On
EQMod Mount.TELESCOPE_PIER_SIDE.PIER_EAST=Off

Read More...

The command set seems to be fairly well documented in scopedome.com/Doc/ScopeDomeArduinoCard/S...Arduino_Info_5.2.pdf and the commands correspond almost 1:1 to binary commands in the older controller so mapping them should be fairly straight forward. I originally tried to make the base ScopeDome driver generic and leave the communication details to card drivers, but unfortunately some implementation details specific to my own controller are still there so they would have to be abstracted away a bit more. Also there are a lot of features that aren't strictly necessary for basic operation, like sensor reading etc. (and some are still placeholders and actually don't do anything), so just mapping the shutter open/close, rotate dome, abort etc. commands would make it usable.

I'm quite used to reading Google translated Polish as I originally wrote the driver based on the Windows driver source which has comments in Polish, but fortunately variable names etc. were in English :)

In case you are willing to do some beta testing, I could start doing the basic implementation blind and hope for the best.

Read More...

Unfortunately the driver currently only supports the older ScopeDome USB Card v2.1 which I have personally. The protocol has changed totally with the new Arduino card from a binary stream to text based so it would require new code. The driver is in theory structured with this in mind as there are also older versions which differ from the 2.1 too, but it would still need to be written and especially tested as I don't have the new card to work with.

Read More...