ASCOM Dome - Digital Dome Works - TheSkyX Dome Add On

[Gordon Hansen]

When using the ASCOM DDW driver, the dome will respond to some direct commands from within TheSkyX Dome Add On, but, will not acknowledge the shutter open end of travel (or close) event. Also, the dome will respond to a telescope slew command from within TheSkyX, but, will not track with the mount. Any telescope commands using the mount hand controller are ignored.

ASCOM Driver: 6.0.6004.869 ASCOM Platform: 6.3 - 6.3.0.2831 Windows: Version 1703 (OS Build 15063.608); 64 bit, x64 based processor

Telescope Mount: Losmandy G-11 with Gemini2 (mini) ASCOM Driver: ASCOM Gemini Telescope.NET Version 1.0.72

TheSkyX Version 10.5.0 (Build 11086)

Results from latest attempt: Issued a Open Dome command: Dome opened and reached its limit. Waited 2 minutes after the limit was reached and then issued an Abort. (See Open_Abort.PNG for screen shot after abort command acknowledged.)

Slewed the mount from within TheSkyX: the dome immediately followed the mount. (See AfterSlew.PNG for screen shot.)

Used the hand controller to move the mount. The dome did not follow the mount (2 minute wait.) Did another slew from TheSkyX - dome followed immediately.

Gordon Hansen [e-mail]

[Tim Long]

Thanks for reporting this. I notice that in both screen shots the azimuth is being reported as nan which means Not a Number. It looks like TheSky is having problems understanding the dome azimuth. Since other programs are working correctly with this driver, this does not seem to be a driver related problem, so to get to the bottom of this we may need to gather additional diagnostics to show clearly whether or not the dome driver is reporting a valid azimuth reading. The easiest way for me to do that is to schedule a remote session with you so that I can log in to your system and see for myself what is happening. I will contact you by private email to arrange that.

[Tim Long]

This image of the DIP switch settings may provide a clue to the problem. It looks like this board is version 2 firmware. The driver was written and tested with version 4 firmware. We should look at the format of the status packet being sent back by the controller. The driver is probably discarding anything that doesn't begin with "V4". If there is enough information there then we might be able to adapt the driver to work with V2 status packets.

[Gordon Hansen]

Tim,

This is not totally unexpected. I bought the dome about two years ago. The original owner bought it I think in 1989.

Attached is a screen shot of the data log in the DDW5.2 software. It shows the data packet returned from the GINF command. The dome was at its home position. I think I have the latest documentation from Technical Innovations (May 31, 2008.) Hopefully the only thing that’s changed if the version number.

I exercised the system again this morning. The attached log is from the debugger. At time ~15 I issued a slew command to the telescope and the dome responded. I believe line 210 shows TI.DigitalDomeworks issuing the goto command to the dome (G358). Line 2963 shows the subsequent request for dome status (GINF). The dome hardware seems to have responded, but, as you said it is an unsupported firmware version.

00003119 77.34313202 [9944] TI.DigitalDomeWorks.ReceiveStateMachine[Error]: Recognizing status packet:

00003120 77.34313202 [9944] System.ApplicationException: Unsupported firmware version debugvie

Hope this helps.

Gordon

[Tim Long]

It looks like we found the smoking gun. Yours is the first V2 system I have encountered. You may be able to upgrade it by replacing the PIC chip, you'd have to contact T.I. for that. Otherwise I may be able to add support for the V2 status packet. I think there are some differences, so if we can find documentation for the V2 packet that would be a major help.

[Gordon Hansen]

Tim,

Just got off the phone with Jeremy Smith at Technical Innovations. When they bought the company the hardware had already progressed beyond V2 so they have no knowledge of command language changes.

Since my system works fine with their latest software (DDW5.2) I would think there haven’t been any or I’d have bumped into them by now. This is from the current documentation:

. There are two versions of Digital DomeWorks firmware, Versions 1 and 2 (Version 1 is in DDWModel 1, recognized by the 28 pin main processor, while Version 2 is in the DDW Models 2 and 3, recognized by the 40 pin processor).

Mine has the 40 pin processor. Its interesting the documentation doesn’t acknowledge V4.

The PIC chip on V3 and newer is replaceable. Unfortunately, the V2 is not. A new board would cost $650. My reason for changing from their software to TheSky was a matter of convenience. The $650 is too much.

If you could make the changes to support the V2 packet I would gladly be the guinea pig!

Thanks,

Gordon

[Tim Long]

Right - I think someone is conflating the firmware version with the hardware revision. There are two hardware revisions (1 and 2) but at least 4 firmware versions, the latest being version 4 (hence the V4 at the start of the status packet).

I will be at my observatory later in the week and I'll have a look at the software then. I seem to recall that I did try to add V2 support at one point and may have disabled it for some reason. Will let you know what I find.

[Gordon Hansen]

OK

Gordon

[Gordon Hansen]

Tim,

Any new info?

Gordon

[Tim Long]

Not yet Gordon, sorry. I’m at the observatory again tomorrow and will try to make some progress on it then.

Best regards, Tim Long

[Tim Long]

In the source code repository, there is a comment that support for V2 systems was removed in 2011. I'm not sure why it was removed. Unfortunately I can't recover whatever code was there because that was when I first added the project to version control. I will investigate whether it will be possible to re-add support for V2.

[Tim Long]

Gordon, can you give this a go? https://bitbucket.org/tigra-astronomy/digital-domeworks-ascom-driver/downloads/DDW-ASCOM-6.3-Integration.zip

If it doesn't work then we should probably look at setting up a remote session so I can get "hands on" with it.

[Gordon Hansen]

Tim, Did some more playing with the dome today. As I said in my last note, the dome will sync up with the telescope initially, but, fails to track with it. Today I played with one of the parameters in TheSkyX setup. Specifically, the max angle from the slit edge. As I understand it this controls how frequently the dome moves as the scope tracks. Regardless of how I set the parameter, somewhere in the 2-3 minute window, the dome hardware beeps signaling its lost contact with the computer and the initiates a shut down with the dome rotating towards home. It then stops and turns back but now stops at the wrong position. A new slew of the telescope results in dome rotation, but, again to the wrong place. Disconnecting the dome from the telescope and then to home re-syncs the dome and it will now go to where the scope is pointing.

I’ve noticed with the DDW5.2 software a GINF request is sent to the hardware every couple of seconds. I believe this resets the hardware timer. My impression is the combination TheSkyX / ASCOM setup is not communicating with the hardware frequently enough causing the time out. The DDW manual is a bit confusing, referencing an 8 minute timeout and a 4 minute. I tried 3 times today and the timeout warning beeps came after 2-3 minutes. Shorter with my V2 version?

Can the driver be modified to send the GINF to the hardware every couple of seconds?

The parameter I played with sets up a dead zone so TheSkyX doesn’t send move commands too frequently. The DDW hardware also establishes a dead zone where it won’t execute a move command. Could this be the cause of the timeouts?

Gordon

[Tim Long]

Gordon, you may want to investigate the driver’s settings. You can prevent the dome from closing due to inactivity by setting one of the options in the ASCOM driver setup dialog. From memory I think it is called “Keep-alive timer enabled”. This will then give you the same behaviour as DDWCP. I thought this option was on by default but perhaps I am mistaken. I think the GINF poll is sent every 1 to 2 minutes.

Best regards, Tim Long

[Gordon Hansen]

Tim,

The “Keep-alive” was enabled.

I experimented more with the dome and found the following:

• The DDW5.2 software sends a GINF to the hardware every 90 seconds.

• Disconnecting the dome hardware from any computer results in a timeout in just over 3 minutes

• Using the ASCOM driver the dome followed a telescope slew successfully.

• From the Dbgview log there were no transmissions to the dome hardware (tx: GINF) until 459 seconds after the slew. The dome had already returned to home and closed

• The next transmission (tx: GINF) occurred after another 360 sec.

Newer versions of the firmware have longer timeout settings?

I also discovered another issue this time with TheSkyX dome add-on software. The resolution to that issue would require me to make modifications to the wiring from my telescope and a change to the communication system (from Ethernet to USB) that I am not willing to make. Software Bisque agreed to refund the cost of the Dome Add-on.

Pursuing any further changes to the ASCOM driver is not necessary.

I really appreciate all the help you provided in trying to resolve this issue.

Regards,

Gordon Hansen

[Tim Long]

Gordon, OK thanks.

Just for completeness (in case you want to use the ASCOM driver with something else) I think there is a setting that controls the frequency of the “keep alive” polls. Not all of the settings are exposed in the setup dialog but you can look at them (and edit them) in the ASCOM Profile Explorer. I think the timeout on V4 firmware is about 8 minutes so it does sound like that got longer. I will look at the defaults and see if I can change it to something less than 3 minutes.

Best regards, Tim Long