If I understand this correctly, then all the dome control UI elements in the observatory panel are grayed out, because no dome driver is loaded.
Ekos does not know that the dome is attached to 10 micron mount and the 10 micron driver does not implement INDI::Dome. So the scheduler cannot open the dome and I fear opening the dome in the startup script might open the dome in bad weather conditions.

I could instead attach the dome to the PC running indilib and use the indi_baader_dome driver, but then the dome would not center the telescope inside the opening, at least not precise enough. The 10 micron mount, on the other hand, takes the exact size and position of the telescope into account. Neither the 10 micron nor the baader dome driver have similar parameters to specify the geometry. Also, using the telescope visually without computer is much easier, if the dome just follows the telescope.

So I wonder what the best solution is. Perhaps to implement INDI::Dome interface in the 10 micron driver will do the trick? I could also control dome flap and shutter with the driver. Above a certain altitude, closing the flap can reduce light from the nearby street. In the long run, I want to open and close it automatically.

The most simple solution for now might be to setup the mount to open the dome when unparked. This would work, as scheduler won't unpark unless weather is not safe.

I wonder how other people have set it up (assuming I am not the only one with both a 10 Micron mount and Baader dome).

Read More...

Just go to: kstars.kde.org/de/download/
then, right click with the mouse to copy the link. Paste the link in the location bar and edit the version number. This should allow you to fetch older versions.
Example:
www.indilib.org/jdownloads/kstars/kstars-3.7.0.dmg

Best, Peter

Read More...

Hi Everybody

I have a 10 Micron mount inside a Baader dome. So far, I have always used the 10 Micron to drive the dome directly, which works fine. But, with Ekos Scheduler I like to open and close the dome automatically. The mount is programmed to close the dome when parked, but it will not open the dome when unparked. The 10 Micron driver does not act as a indi 'dome device'.

What is the best way to proceed? I think there are (at least) 4 options:

• Let the 10 micron driver open the dome when unparked, or
• Extend the 10 micron driver, to act as dome, or
• Attach the dome to the PC directly and use the indi_baader_dome driver, or
• Open the dome with a startup script in the scheduler

Sorry, to hear that. So the problem still persists. Whatever the reason, perhaps you like to try this workaround?

You can use the 'tor browser' to connect through another country. That will route the traffic through a few other countries, and you can also change that route randomly if it is blocked. The tor browser is slow, but it should work (unless tor is illegal or blocked in your country). Or, you can try to use a VPN to another country.

Read More...

Hi Everybody

I also noticed the outage, and it (for me) took place only with indilib.org. I was not investigating, as servers sometimes go down. It might very much have been the mentioned root-server problem. DNS issues can be very strange and location/provider make a difference. Fact is, that the internet is very fragile. My strategy: not having control, I relax and wait for the issue to go away.

Cheers, Peter

Read More...

Hi Everybody

I could not compile indiprop on my ubuntu 22.04 system. I created a fix and a PR for the original repository, although the github account seems to be inactive since a number of years.
My fork with the fix is here:
github.com/peter-englmaier/indiprop/tree/fix-compile-issues

Does anyone know why the github account is no longer active? Is Indiprop still a useful tool to have?

Best, Peter

Read More...

It took me quite a while to finish this project, as I was changing job and had some other problems with higher 'priority'.

But finally, I submitted the pull request for the new driver:
github.com/indilib/indi/pull/1991

If somebody is using it, I would be happy to get some feedback. Could be, I am the only user of indi who owns an Alluna telescope, because they are expensive.

Read More...

If you have all the indi drivers already, you may not need windows a lot and the dual boot option is just fine.

Perhaps the following is interesting for you.

I have an ASUS PN50 with Linux (Ubuntu 20.04.xx LTS) single boot without display, but with Windows 10 in a virtualbox VM. Devices are connected through a powered USB3 hub on the telescope (Moravian C4, C1, Teleskop control), 10Micron Mount via TCP/IP. I can connect to Linux with ssh/nomachine and to Windows with RDP.

Of course, you could do it the other way around as well. Which one works better for you depends on your preferences.

Dual boot has the advantage, that both systems will perform well - but you have to attach a monitor and keyboard when you want to boot in the non-default system.

Installing Kstars/Ekos/Indi in Ubuntu is working quite well. You may have to set up additional repos, but it will install without conflicts.

This setup works fine, although the Windows VM does not perform well (virtualization is not fast enough for USB3). Nevertheless, it is good as a fallback and for testing. I was hoping to use ASCOM on the virtual windows machine and use those windows only devices through Alpaca in indi on the linux side, but this doesn't work, because Alpaca does only provide one way access (accessing indi devices from windows but not the other way).

Currently, I am only missing a driver for the telescope control system (focuser, heating, etc.). So I started writing an indi driver and I got it working within half a day. I will submit a PR once it is polished and properly documented.

Read More...

A first version is available here .
Any input welcome!
 

Read More...

Hi

I have started developing a driver for the TCS2 controller used by Alluna Optics Telescopes (I am not affiliated). This is the first indi driver I develop. Nevertheless, after some fiddling, I managed to clone the indi 'skeleton' focuser driver and got it to handshake the device. Now, before going deeper, I have a few design questions:

• are new drivers expected to be inside the 'drivers' subfolder, or should new drivers be shipped separate from indi?
• can I later add more functionality not related to focusing to the same driver? The TCS2 can do more than just drive the focuser, e.g. it opens the dust cover and controls climate, rotator (if existing). Would it still be OK, to have the driver in drivers/focuser? There seems to be no category for such multi-purpose "telescope control" devices.
• can I somehow switch the serial line to line buffering? Or, is the only supported method to read until the next 'newline' character?
• some device commands like FocuserGoTo send multiple lines back (it reports every small focuser step). Should I capture and process those messages in the TimerHit method or in the MoveAbsFocuser method? The output looks like this:

I# // indicates that focuser starts moving
K#number // indicates current focuser position
K#number
...
J# // indicates that focuser stopped moving

• In case the TimerHit is only expected to send its own commands to the device, e.g. check temperature, do I need take care of not sending commands while the focuser is moving or is this already guranteed by the framework (single threaded execution)?
• Is there a programmer's guide for timing issues in indi? I.e., about how to avoid blocking I/O and methods to run for too long.

Finally, I got Alccd-QHY9 and QHY 5-II working. I can make image, set cooling temperature, etc.

The trick was to either connect in 'local mode' or to start indiserver with my regular user and without systemd. I am sure, there is a way to start it with systemd too, but for now I am doing it without.

Peter

Read More...