drive.google.com/file/d/0B6wodUGwdoDZMmE...iew?usp=docslist_api

This is link to a document describing maxdome protocol.

Thanks for the document.

Our plans here for some time now have been to build a roll off for 'his and hers' telescopes later this spring. But, plans may be changing, I've found a relatively inexpensive dome option, such that we may well go with twin domes instead. The controller for that dome will be arduino based, so I'm contemplating various options for working with it. I've mucked up a quick and dirty prototype of an arduino firmware that can deal with rotation, shutter control yet to come, communication link between the two hasn't been figured out yet.

My original thought is, if i implement the MaxDome protocol in the arduino, then I dont have to write a new dome driver, just use this one. But, over time I'll probably expand it some, I already see one major difference between the two. MaxDome seems to treat shutter as an 'opened' or 'closed' device, I dont see the ability to partially open in there. The one we are looking at will have the ability to not only control opening of the shutter, but, also control just how far it's opened. Ie, if not pointing up to zenith, dont open the shutter all the way. That's a very helpful bit for managing dew control, because if the telescope is not exposed to the sky strait up, then dew will form on the outside of the roof, instead of on the scope under that roof. If aiming at anything under about 60 degrees in elevation, the shutter can be left partially closed to help mitigate dew buildup.

I think in the long run, if we do go down this route, which isn't firmly decided yet, then I'll start with the maxdome driver to get all the sync math, and expand on it to add more capability for better shutter control.

I'm going to go see the domes in question in mid January, and will make up my mind about them then. But for now, I'm seriously contemplating scrapping the roll off plan, and moving to twinned domes instead. With this new option we've found, it will be no more espensive than building a roll off.

You don't need to start with MaxDome driver for this, all the math is in the INDI::Dome class.

So I've started working with domes here, and the slaving with telescopes. Using the dome simulator, I found a couple problems in order of events etc, and have just committed some changes to the base class for dome, to work around these issues.

The big one was, on startup, dome simulator always seemed to slew to 270 degrees, and I tracked that down to unintialized variables. Start dome first, then start telescope, you end up with the dome auto-sync kicking in, but the telescope has not finished fleshing out ra/dec and lat/long yet. I added flags so that autosync will not start until they have all been fleshed out by the telescope properly. This change is in the base class, so will affect all domes derived from it.


Another issue I found, if the telescope is already running, and you 'load config' for the dome, auto-sync gets enabled first, before all the dimensions have been fleshed in, which also results in a spurious movement of the dome. I changed the order of saving variables so that on re-load, the auto-sync flag will not be loaded until all the rest are initialized.

One other minor change, in the dome simulator. Telescope base class doesn't emit ra/dec updates if ra/dec are not changing, so the dome never gets updated co-ords in the snooping function, therefor never actually tracks. This is apparent using dome simulator with telescope simulator, doesn't happen with EQMod becuuse it's continually updating co-ordintes, and there are very small deltas on each update. I added a timer into dome simulator, so if it goes a period without any updates on ra/dec from the telescope, it will re-calculate alt/az to track the telescope position.

That sounds like great progress. I'll do an update tonight (in approx 10 hrs) to try it out and see how it goes. I assume builds for RPi should be ready by then?

Do you have any plans or ideas to handle dome placement based on anticipation of where the scope will be? By that, I mean when the scope is issued a goto that will significantly change its position and therefore the dome's opening - will it detect this event and start moving to the required position at the same time the scope slews, instead of waiting until the scope stops moving?

I started looking into making the dome anticipate scope movement, and it can be done, but it will require adding more things to the base telescope class. right now, the dome gets no indication of where a given slew is headed, just starts to see ra/dec changing. To give the dome a hint, I need to define a new property in the telescopes, and then fill that one in with numbers for 'destination' when the telescope processes a goto command.

As for when various builds are ready, I dunno, I dont build them here, I just commit code into the svn repository, and jasem looks after building.

I just committed a set of changes to the base dome, and base telescope classes.

Base telescope now has a read only property added, TARGET_EOD_COORD. This is an Ra/Dec co-ordinate pair, set by base telescope when the underlying driver returns success for the start of a slew thru the goto function. Base dome now snoops this property, and when it is set, starts the dome motion to the new co-ordinates, so the dome now anticipates a target, and starts moving as soon as the telescope starts to move.

In testing with dome and telescope simulators, if they are both set for the same rate of slew, they arrive on the target at the same time now.

This change does not affect the existing tracking functions, and they continue to get processed as they did in the past. The only change is, instead of waiting for a telescope slew to complete before starting dome movement, dome will start moving now as soon as the telescope starts. If there is a discrepancy between the two once the slews are complete, the original logic will pick that up, and correct. This will be the case if you have a very slow dome, and a narrow slit configured. By the time the dome arrives at target, it will have moved a little bit, and the normal tracking logic will re-sync them after the first slew is complete.

Tested with dome simulator and telescope simulator, but, should work just fine with real hardware, no changes to the interface(s) between the underlying drivers.