And it's now in, yay!

Read More...

The code is now headed for merging at github.com/indilib/indi/pull/1447 so hopefully soon you don't need to use my special branch anymore (and I don't have to keep it up with the main repo :). It's by no means "final" but I think it's suitable for merging and also I'm not aware of any regressions so it's also an improvement for us older USB Card owners.

Read More...

Good news is that I finally found the regression that prevented me from using this new driver version with my own USB Card 2.1 controller so at least now I can actually run the same code I'm developing :)

Read More...

Thanks for testing, I pushed some more debug prints that might help with this so you if you can do some simple testing with full debug logging on, that might help in locating the issue. Gorden also did some testing before I added the missing prints and it seems to have something to do with the refining move the driver does if the initial move over/undershoots the target and goes haywire doing that endlessly. Hopefully the added prints will tell me why.

Read More...

I found possible reason for the problem with absolute position by reading the Windows driver source and there was a mysterious negation of the azimuth encoder delta value, which would explain the symptoms. The sequence would have been such that for example when you start from the home sensor position (let's say at azimuth 0) and set absolute position target as azimuth 30. The driver would calculate that "ok, need to move 30 degrees clock-wise" and would send appropriate command and dome would move to roughly the right place. However the missing negation of the encoder delta value would mean that the driver would think that the dome actually moved 30 degrees counter clockwise to azimuth 330 and would then conclude that it needed to do a refining move (it does that to correct for over/undershooting the wanted position, which happens sometimes even with the inertia table) of 60 degrees clockwise. Then the dome would move to azimuth 90 degrees but the counter value would still go the opposite direction and the driver would think the dome is at 270 degrees and so on...

I pushed the fix which does this negation which hopefully finally would fix this. If possible, please test that if you start by homing (after which the encoder delta is 0 and position should show correctly in any case) and then moving for example 10 degrees clock-wise and check if the absolute position reported by the driver behaves correctly or exactly the wrong way.

Read More...

This (and focuser temperature as well if present) is saved to the FITS file if you have correct focuser configured for snooping in your camera settings in INDI panel, like this:

FOCUSPOS= 3573 / Focus position in steps
FOCUSTEM= -1.790E+00 / Focuser temperature in degrees C

Read More...

Thanks for testing, sounds promising!

Saving configuration should work (it's mostly handled by the base INDI classes, I just save a few specific items in addition), definitely does for me. Does it create/update "~/.indi/ScopeDome Dome_config.xml" file and if it does, do the contents look valid?

Read More...

Long overdue status update after I've finally had a few evenings to work on the driver. Biggest new thing is that ethernet connection now works for me at least. Set connection mode to Ethernet / TCP and fill in the host name and username/password (port number isn't actually used, but doesn't hurt either) before connecting.

Quite a lot of small and larger fixes included too, namely I found from the Windows driver source that digital input and buttons are actually inverted in the status reply, so that caused shutter open/close status confusion among other things. I also added option to set home sensor polarity as it seems to be active low for Arduino cards where as USB Card 2.1 uses active high. So if find home command finds the sensor almost immediately without actually being near the sensor, that is most probably caused by wrong polarity setting.

Hopefully someone has time to test this and report if/when things don't work :)

Read More...

Yup, SDK regression isn't out of the question, though it seems to be either camera or architecture specific as my ASI120MM-S with ARMv7 and 178MC with x64 I test with both work fine. API hasn't changed, at least the header files were identical when I updated the SDK and they usually haven't changed existing things, just added new ones.

Read More...

Libasi package also contains the udev rule file, which has that usbfs 256MB memory line in the old version, but not in new one.

Read More...

The fields are described in the protocol documentation that can be downloaded from www.scopedome.com/wp-content/uploads/202...uino_Info_5.2SDK.pdf but it's possible I've made a mistake assigning them to variables in the code and then to shutter status. So I'll override the responses from my controller with those you sent and check how the code behaves and there the error comes from.

Read More...

Excellent, thanks for the controller responses, I'll double check that parsing of the fields is correct. Unfortunately the log file didn't contain any more information as the previous one, but I think this is enough for me to progress for now. I think I'll ask ScopeDome guys if there is anything that can be done software wise with the connection breaks, I don't have any problems with my controllers, but I power them directly and they are fairly close to each other so that's expected. Unfortunately not much I can do about the shutter if there isn't connection to control it...

Read More...