If you are using the SD card then the camera data is read from the camera through the USB interface and written to the SD card using the SD interface. Using two interfaces may be more efficient because they may be able to run in parallel using different hardware. The amount of data transferred through the USB interface is 72Mb.
Using the USB SSD the data is read from the camera using the USB interface and then written to the SSD also using the USB interface. That's twice as much data being transferred through what is probably a single connection to the Pi. Is is a surprise that transferring twice the data takes twice the time?
Looking at the drivers that support variable speed they seem to have an additional move command which has direction, speed and time. It looks as if this is the one to implement to get joystick control. I've no idea how, I suggest that you look at the sources for other focusers to see what they do. Some seem to ignore the speed control and use time in some way.
The MC_MOVE_POS and MC_MOVE_NEG commands are the ones to use, These take a byte in the range 0 to 9 and move at the appropiate rate, 0 being stop and 9 being full speed. The telescope axes use all 9 rates, the focuser seems to select 3 of the rates. You may find a code example using this in the celestron telescope driver. Set zero rate to stop. The Abort command uses this.
Hope this helps.
Visual filters for imaging can give problems because they may let IR through. For example the Baader visual OIII filter does this while the more expensive CCD OIII filter doesn't A crude test is to try to operate an IR remote throuh the filter. If you can it will let iR through.
Yes, CR is me.
I'm not sure why you need variable move speed, or how to achieve it.
The driver is designed to move to a position and does so using the MC_GOTO_FAST Celestron AUX command. This doesn't have any management of speed.
The MC_MOVE_POS and MC_MOVE_NEG commands have the ability to move at a variable rate but not to a specified position, the move continues until a rate of zero is set.
The INDI commands are moves to positions, either absolute or relative and don't seem to specify a rate.
All this seems to make setting a move speed a bit tricky to implement.
There is one possibility, there are commands which can set the rate used for the MC_GOTO_FAST command. It's the one used to restrict the maximum slew rate for the mounts.
I've never tried to use this but the commands are:
// custom rate 9 commands from EFA
SET_CUSTOM_RATE9 = 32,
GET_CUSTOM_RATE9 = 33,
SET_CUSTOM_RATE9_ENABLED = 34,
GET_CUSTOM_RATE9_ENABLED = 35,
I don't know what the units are, it seems to be continuously variable.
This is as far as I can take this, hope it helps.
What happened between "I ended up with Celestron AVX and I love it..."
and "I had tons of issues with AVX."?
Anything we could have helped with?
If you want to help debug this your best bet is to contact the author directly, their email is in the sources.
From what I can see this is designed for an alt az mounted scope, not a polar mounted scope such as an AVX.
The driver looks like early beta to me, really only of use for testing and debugging.
All mounts need to have some sort of alignment so the relationship between axis positions and celestial positions can be determined. This need not be more than specifying the initial pointing direction, mount type, position and time. With an AVX using the HC set the mount to the index marks - counterweight down, dec 90 - and do a quick align.
It looks as if you can post. Or is there more to it?
I discovered that I was using out of date sources so if this is a recent change i wouldn't have seen it.
Tried this with the simulators. A 2x2 mosaic of NGC188 was more or less OK but a 2x2 mosaic of Polaris had Polaris in the correct position but there is a lot or rotation between the images at different right ascensions.
I've just tried using the guide simulator and it seems fine. The first frame prompted me to cover and uncover the scope and took and saved a dark, then subsequent frames subtracted that dark. the Dark checkbox is checked throughout.
I did the first frame using Capture though and maybe that makes a difference.
It may be that ZWO does nothing to the WB_? values in their firmware and the 52/95 values are the defaults set by the CMOS chip hardware. Perhaps they give a reasonable white balance for terrestrial photos.
And maybe their ASCOM driver sets values of 50/50.
If that's the case then perhaps the Indi driver should default to 50/50 and set this, not read it from the low level driver.
Is there even a need - a use case - for a user to be able to control this? Or many of the other controls that are available?
I think that the mount park lock functionality should stay in the telescope base class because it can prevent unpark and a subsequent slew before it starts. The WDT may not know that the mount has unparked for long enough that a slew into the roof is already in progress. The functionality seems to belong in the telescope base class which snoops on the dome park state. It shouldn't affect individual drivers because it's implemented in the base class.
But the mount lock UI seems to belong with the other observatory management functionility in the WDT. Is it possible to have this? The UI in the WDT but the functionality in the telescope base class. This doesn't seem to fit with the way that Indi properties are implemented.
Or is it possible to implement some sort of check functionality where the telescope and dome driver checks the WDT to see if it's OK to unpark? I suppose that's more snooping.
AIUI the idea of the new Watchdog is that it can manage the telescope/dome/ROR parking in bad weather with no intervention by the the telescope and dome/ROR drivers. The intent is that the existing auto park behaviour in the telescope and dome base drivers is removed. This means:
Telescope Dome policy in the telescope driver must be set to none.
In the ROR driver the Dome Telescope policy is set to none and AutoPark is set to Disabled.
The Ekos Observatory module has the alert and warning actions unchecked.
The scheduler need not be running.
In the WDT simulator main tab:
Weather threshold is set to 0 so that the close down happens immediately.
The trigger is set to Weather.
Shutdown has Park Dome and Park Telescope checked.
In the WDT Simulator Options tab:
The Mount Policy is set to "Mount locks. Dome must wait for mount to park before it can start the parking procedure."
Set the weather to unsafe (I start it raining).
This works as expected. The Telescope starts to park and when it reports parked the ROR starts to park. The times in the various logs bear this out. I assume that Park also closes the shutter.
Stop the rain, unpark ROR, unpark Scope.
Just a thought, should the scope be allowed to unpark when the ROR is parked? If that should be inhibited then the telescope will still need to snoop on the dome and check the dome park status. The Dome policy would still need to be available because not all users require this.
Set the Mount policy (in the WDT) to "Mount is ignored. Dome can start parking without waiting for mount to complete parking. "
Start the rain:
The telescope and ROR start to park at the same time as expected.
The telescope can be unparked and slewed to an object with the ROR parked and the weather unsafe.
Setting the Telescope Dome Policy to "Dome parking policy set to: Dome locks. This disallows the scope from unparking when dome is parked" will prevent this so it looks as if the dome snooping needs to be retained and the policy still be available for the ignore and dome locks states at least.
This seems pretty close. It seems easier to set up the observatory behaviour in the WDT than in multiple places, the only outstanding thing is preventing telescope unpark and slews when the roof is closed, that is set in the telescope driver.
I've not looked at how Ekos copes with an observatory that's closed down but even if it keeps going the equipment should be safe. Ekos can monitor the weather and do it's own orderly shut down.
Opening and starting or resuming a sequence when the weather improves probably belongs in Ekos.