Just built a new SD installation for a Raspi 3 running Mate 18.04 and it worked with no problems.
Thanks for all the wor on this scripting, it's a great help.
I'm running on a PC using Firefox and don't see any forum menu bar either.
I have a very hard attitude to untested code. - it doesn't work, it is broken.
It remains so until it has been tested and demonstrated to work.
Publishing untested, aka broken, code isn't a good idea. It delegates ensuring that it works to others and in a way that makes it much more labour intensive to fix.
I'm also uneasy about a 'fix' to help with one device applied to the default driver because this is now applied to every driver.
Couldn't the existing limits, inherited from the default driver, be modified in the hardware specific driver and if an additional control really needed being made available to the user could that have been done in the driver.
I would have done what the OP originally did, set the polling interval in the driver and ignore the property in the default driver. Maybe see if there was a way to remove it from the default UI.
Does Nano clone with CH340C USB chip on board has any chance to work with Moonlite (non Ascom) stand alone app or its Ascom driver?
I tried already to connect Maxfocuser preloaded CH340C Nano board with DTR pin mod (no reset during serial initi., no bootloader)
Board is communicating with Arduino IDE w/o any problem. Regardless of modification this board is NOT recognized by any Moonlite factory software or driver .
What prevents it from connecting - any ideas ?
I'm not going to go and buy this hardware in order to help you with this.
It's one of the problems with trying to leech off existing drivers, you have to ensure that your hardware is compatible.
I wrote the MoonLite ASCOM drivers for MoonLite.
What's happening is that the Arduino is designed so it runs the boot code on reset, this takes about a second before it drops into the user code.
The circuit is designed so that a reset is done when the serial port is connected.
Drivers using an Arduino need to wait after the serial port connection before starting to communicate, I use a two second delay. The real MoonLite focuser controller doesn't use an Arduino so doesn't need to do this.
The 100uF capacitor to the reset pin disables the short reset when the serial port connects so avoids the boot phase. Not sure how you reprogram the Arduino after that.
AIUI the moonlite temperature probe is one of the Dallas one wire temperature sensors, is the ZWO temperature probe the same and does it have the same connections to the jack plug?
Even if the two systems use the same probe there are six different ways to connect 3 wires to a 3 pin plug so unless they say that the probe and connections are the same it's like throwing a double six.
I don't think that the mount will spontaneously start tracking after a slew if tracking was turned off before the slew. A log file showing the commands sent to the mount would help.
Updating the documentation is tricky, I didn't even know there was any and people who's talent is software may not also have a talent for documentation and web site design.
1) Correct, only the HC connection provides the mount Ra and Dec information. The internal AUX bus protocol only handles low level mount axis commands.
2) This is a feature of how Celestron manages backlash on slews. It isn't under INDI's control.
3) If the mount has tracking turned off on the HC then subsequent moves leave tracking off. Perhaps the INDI driver is turning tracking back on at the end of a slew. Is this really a problem for the setting a horizon use case? The position is only changing by an arc minute every 4 seconds.
That link needs updating, it's quite out of date.
try rotating the filter relative to the camera. If the spot moves it's on the filter, if it doesn't it's on the camera. It's also possible to calculate the distance the dust spot is from the sensor from its size and the focal ratio of the scope.
This was probably a side load, not along the draw tube. Lucky that a bearing broke and not something less easily repairable.
Neither of the positions for Jupiter shown in the attachment seem to be correct, using CdC I get 16h 52m, -22d 10m.
One thought, is the date and time in the mount correct? If it isn't then the position that it thinks Jupiter is at will be incorrect.
The problem is probably the low limit, this doesn't allow for the mount being on a wedge so needs to be set to a negative value. Try setting your latitude - 90 so -40 if you are at a latitude of 50 degrees.
It's in the HC, the Scope Setup section I think.
Why would backlash in the Ra axis matter? The axis is always being driven in the same direction and all that guiding is doing is changing the drive rate , not the direction.
Check for and carefully adjust the backlash in the RA worm gear if you can.
I need the full log, not a fragment lasting a couple of seconds.
The Celestron focuser needs to be calibrated, this can be done using the standalone INDI focuser driver.