KStars/Ekos New Release

[StevieDvd]

4 minutes ago, Steve in Boulder said:

Gotcha.  Currently my RPi is creating its own WiFi network, called "Astroberry."  I can connect to it from my laptop by joining that network, but I lose Internet connectivity.  Is there a way to have the RPi join my home network and allow me to connect through that?

Sure is a way.  Easier if you can plug a network cable connected to the home network into the Astroberry before booting up:

Details with some pictures on theis SGL thread same process for Astroberry & Stellarmate too.

[Steve in Boulder]

Thanks much, Stuart and StevieDVD!

[CedricTheBrave]

easiest way is to use a monitor and keyboard on the rpi and just connect to the local wifi

make sure you either remove the hotspot setup or change its priority to stop it being the prefered network on boot

1 hour ago, Steve in Boulder said:

Thanks much, Stuart and StevieDVD!

 

[Steve in Boulder]

1 hour ago, CedricTheBrave said:

easiest way is to use a monitor and keyboard on the rpi and just connect to the local wifi

make sure you either remove the hotspot setup or change its priority to stop it being the prefered network on boot

 

Is there some file I need to edit to change the priorities?  I'd like to use the Astroberry WiFi network while in the field and use my home network at, well, home.  

[Steve in Boulder]

Never mind, I found the Network Settings widget.  Thanks again!

[Richard Wesson]

On 19/09/2021 at 03:05, teoria_del_big_bang said:

I just I have had a few minor issues with crashes where KStars just shuts down. I also suffer with slow screen updates when using the planetarium over remote connections over WiFi, which I admit are more likely WiFi issues although the WiFi with a WiFi dongle is very good now.

Which wifi dongle do you use? I am struggling to find a dongle that will actually work with Stellarmate - the one available from the PI Hut states 'This product no longer works with the provided driver/instructions due to a kernel change in Raspberry Pi OS.'

[Stuart1971]

1 hour ago, Richard Wesson said:

Which wifi dongle do you use? I am struggling to find a dongle that will actually work with Stellarmate - the one available from the PI Hut states 'This product no longer works with the provided driver/instructions due to a kernel change in Raspberry Pi OS.'

Most of the Brostrend ones work well with SM…👍🏼

[wornish]

I paid about £40 for a 50 Meter Ethernet cable and run that to my RPi on the Mount in the garden when I set it up.  Using VNC now just works! No pauses no drop outs. Wish I had done it long ago.  Trying to get a reliable WiFi connection just caused more frustration.

Edited October 1, 2021 by wornish

[Kev M]

4 minutes ago, wornish said:

I paid about £40 for a 50 Meter Ethernet cable and run that to my RPi on the Mount in the garden when I set it up.  Using VNC now just works! No pauses no drop outs. Wish I had done it long ago.  Trying to get a reliable WiFi connection just caused more frustration.

Sensible choice.....if it doesn't move, run a fixed cable to it.......wifi is just for portable things like phones, tablets etc.

Wifi causes lower speeds, higher latency and as mentioned, frequent disconnections.

[RadekK]

Interesting discussion indeed 😉

Updates to KStars and INDI will be released not ealier than mid October. I'm also planning to release new version of astroberry image (v2.0.4), which should have all the latest software preinstalled. No major changes to the system itself.

Let me comment a few points discussed earlier in this thread:

• client-server architecture is not operating system specific and has nothing to do with linux in particular. While accessing this website you use client-server architecture and it does not matter what operating system you use. In such the case a server component is a web server which serves this website and client component is your preferred web browser. The same way INDI is a server, which serves all devices and possibility of control and KStars/EKOS is a client. BTW KStars/Ekos is not the only client you can use (the same like IE is not the only browser) - you can use many others inluding Cartes du Ciel and Stellarium, see list of supported clients here
• INDI server has been developed for linux or other unix-like systems and cannot be just rewritten to other systems like some of you would expect. Philosophy of accessing low-level hardware just differs significantly (to be moderate) between unix/linux/macos and windows. I cannot say that it will never happen. I'm not aware of such plans at the moment.
• ASCOM is not a standard and if some of you believe it is, so is INDI. Applications like Cartes du Ciel, Stellarium and many others support both INDI and ASCOM. KStars supports INDI and does not support ASCOM. Why? The reason is as simple as this - nobody added ASCOM support to KStars. Hey, it's open source software! Anybody can develop and submit any change or add new functionalities to it. Discuss it at your local club, find people interested in it,  find programmers willing to accept a challenge and fill the gap if you think there's one. That's how it works in open source world where people create software and share it for free with everyone, including right to modify.
• Finally, there is not one-fits-all solution. I go with linux and every single photon I capture with my setup comes from "open source astronomy". But this is just me 😉

Clear skies to everyone!

[dan_adi]

On 19/09/2021 at 23:43, JonCarleton said:

ALPACA seems a backward project to me.  It lets a Linux or MAC connect to a computer running Windows and ASCOM drivers.  I can't imagine ever wanting to do that.  I suppose it might make sense if you were running a Windows-based NUC box with drivers on the telescope, but then, I'm perfectly happy with Pi's running Linux doing my device control. 

Linux/UNIX was designed for distributed computing from the outset.  Now, running a Windows box for overall operations with remote Linux computers running INDI drivers...that makes since if one is a a Windows user.  But, Windows software with that capability, and not just KStars, has been around a while.

Alpaca is OS independet. You don’t need windows to run it. I use Linux on my main machine, but use windows on an intel nuc in the observatory. As much as I like linux, there is astronomy software I use that doesn’t exist on Linux.
Alpaca will enable gear to inter-comunicate whatever OS we use. I think we should encourage manufactures to write Alpaca drivers. Optec already offers such drivers and yesterday I was controling my focuser via a webpage on linux, with the focuser driver installed on windows.... cool stuff. So all you will need is an Alpaca driver for your stuff, no use for either Indi or Ascom! Then you can control your scope from Linux, Windows, IOS, Android

In my case there is no Linux equal to Prism v.10 or Skyguard, and when I will have access to all alpaca drivers I’ll need, I will install Linux on the obsy PC for stability and reliability, and make a Windows virtual machine on my main linux box to run my software. That would be cool.

Edited November 16, 2021 by dan_adi

[Stuart1971]

6 hours ago, dan_adi said:

Alpaca is OS independet. You don’t need windows to run it. I use Linux on my main machine, but use windows on an intel nuc in the observatory. As much as I like linux, there is astronomy software I use that doesn’t exist on Linux.
Alpaca will enable gear to inter-comunicate whatever OS we use. I think we should encourage manufactures to write Alpaca drivers. Optec already offers such drivers and yesterday I was controling my focuser via a webpage on linux, with the focuser driver installed on windows.... cool stuff. So all you will need is an Alpaca driver for your stuff, no use for either Indi or Ascom! Then you can control your scope from Linux, Windows, IOS, Android

In my case there is no Linux equal to Prism v.10 or Skyguard, and when I will have access to all alpaca drivers I’ll need, I will install Linux on the obsy PC for stability and reliability, and make a Windows virtual machine on my main linux box to run my software. That would be cool.

That all sounds just so complicated….

An RPI on the mount with INdI installed, Kstars / Ekos on the windows  PC indoors, and a perfect wireless set up and full control of your kit…and any other windows software you need….👍🏼

[dan_adi]

9 hours ago, Stuart1971 said:

That all sounds just so complicated….

An RPI on the mount with INdI installed, Kstars / Ekos on the windows  PC indoors, and a perfect wireless set up and full control of your kit…and any other windows software you need….👍🏼

It's not complicated at all. All I had to do is install an alpaca driver for my focuser, took 2 minutes, afterwards you can control the focuser from every OS you like. 

Regarding WiFi, I've tried it, but sometimes the connection drops. That's why I switched to Ethernet conections, much more reliable than wifi or USB/comm ports. 

[gilesco]

On 19/09/2021 at 17:23, alacant said:

If you want to give it a go, Ascom Remote/Alpaca tries to do this.

I'd venture however that it's of little or no interest to Linux users who've had native client-server from the outset.

Cheers

 

I think you're right, in fact, if you're settled with Windows then you are going to prefer ASCOM, if you're settled in Windows, and require some client / server then you're going to look for something like ASCOM Alpaca.

If you're settled with Linux then you are always going to look at INDI, and driver development for INDI is actually not as challenging as one might think, with lots of volunteers contributing to support new equipment, astronomy device manufacturers releasing their APIs and Command Sets to developers quite easily (not much proprietary concealment).

If you're looking at operating a remote site, which might be battery powered with Solar / Wind charging then you're probably going to have to look at INDI, as it is the only thing that will run on a low power platform such as a Raspberry Pi, which can be remotely controlled by Ekos (running either on a Windows or Linux system).

I would probably try and always suggest that people should use the base platform that they're already comfortable with, Astronomy/Astrophotography has a steep enough learning curve as it is, without having to learn the Windows way if accustomed to UNIX, or, vice-versa, the UNIX was if accustomed to Windows. I say UNIX, as it appears to me that INDI could be ported to just about any Operating System, not just Linux, and I don't think there is all that much of a barrier to port to Windows, except that no one has really spent any effort in that regard.

Historically, while ASCOM was initially developed first (around 1997/1998), and INDI came later (around 2003/2004), any one doing serious astronomy in between 1997 - 2004 was probably using UNIX systems, and not Windows 95 / 98 / Windows NT systems. This was simply that manually creating a pipe to send control commands to remote equipment is actually a one liner of code, and creating a basic short interface can also be done in less than 10 lines of scripting. INDI was just there to create a common framework and allow devices to share their states with each other and the server, and by extension the client.

[Stuart1971]

2 hours ago, dan_adi said:

It's not complicated at all. All I had to do is install an alpaca driver for my focuser, took 2 minutes, afterwards you can control the focuser from every OS you like. 

Regarding WiFi, I've tried it, but sometimes the connection drops. That's why I switched to Ethernet conections, much more reliable than wifi or USB/comm ports. 

So can you explain to me a bit more about Ascom remote, or Alpaca, as I am a bit confused on what it actually does or is, am I correct in thinking that it can work like current INdI system where I could have a small low powered PC on the mount with Alpaca installed with drivers for my kit, and remote to that from a separate windows PC with, say NINA running on it and control my set up that way…? Or am I way off….

[StevieDvd]

So if I understand this correctly:

• Either the remote or local computer must run Windows (server for Ascom)
• Windows can use remote, local, com calls to run devices
• Linux, Mac need drivers to control local devices
• Linux, Mac clients need options added to configure alpaca settings

So at present it may be a better solution for a dual WIndows setup, so api calls can be use across networks rather than long run cables from indoors to the mount etc. But needs a lot of work for any OS other than Windows - which will need new drivers & clients to change over from indilib (or support both). That seems to be a big ask for device makers and client developers.

 

 

 

[dan_adi]

5 hours ago, StevieDvd said:

So if I understand this correctly:

• Either the remote or local computer must run Windows (server for Ascom)
• Windows can use remote, local, com calls to run devices
• Linux, Mac need drivers to control local devices
• Linux, Mac clients need options added to configure alpaca settings

So at present it may be a better solution for a dual WIndows setup, so api calls can be use across networks rather than long run cables from indoors to the mount etc. But needs a lot of work for any OS other than Windows - which will need new drivers & clients to change over from indilib (or support both). That seems to be a big ask for device makers and client developers.

 

 

 

You don't need windows at all. All you need is a Alpaca driver for you device. That is it.

Here is a clear demo: 

 

Edited November 17, 2021 by dan_adi

[dan_adi]

8 hours ago, Stuart1971 said:

So can you explain to me a bit more about Ascom remote, or Alpaca, as I am a bit confused on what it actually does or is, am I correct in thinking that it can work like current INdI system where I could have a small low powered PC on the mount with Alpaca installed with drivers for my kit, and remote to that from a separate windows PC with, say NINA running on it and control my set up that way…? Or am I way off….

Yes you can have a small Raspberry with Alpca drivers installed on it for your gear. Then you can access it from every OS you like. I watched this demo:

 

 

[StevieDvd]

Sorry @dan_adi I don't agree with it being as simple as the need for just an alpaca driver on the device to get a single network cable and power cable to run everything!

Currently on Windows, Ascom 6.5 is used as a go between and as I found out today on Linux you can use INDIGO to act as a similar go between.

As stated in the video it needs astro software to be able to display/use the api for each device (not simply a browser call for each).  Lot's of development for drivers and software before it could ever become a standard across systems.

 

 

 

[dan_adi]

11 hours ago, StevieDvd said:

Sorry @dan_adi I don't agree with it being as simple as the need for just an alpaca driver on the device to get a single network cable and power cable to run everything!

Currently on Windows, Ascom 6.5 is used as a go between and as I found out today on Linux you can use INDIGO to act as a similar go between.

As stated in the video it needs astro software to be able to display/use the api for each device (not simply a browser call for each).  Lot's of development for drivers and software before it could ever become a standard across systems.

 

 

 

I'm sure it will take some time to implement, it won't happen over night. But it is a good step forward to controlling your equipment with whatever OS you like. On my main machine I like to use Linux, but for my astrostuff I'm forced to use Windows, and that is ok.

Optec adopted alpaca fairly quickly, so I am guessing it doesn't take years to make a driver compliant with alpaca. 

From little conversation I had with my camera maker and mount maker, they are aware of alpaca, and are planning to roll out drivers, because there is a demand out there. We can make it happen earlier if we simply email and ask our astro gear providers to provide such drivers, no harm in asking for support.

So let's hope for the best, this is a good thing for the community at large, no matter if you are a Linux, Windows or IOS fan.

Clear skies!

[jerk]

So, time for my humble opinion, ASCOM isn't that great, the tie in with Windows COM is a bit too closely coupled, alpaca on the other hand is http/https based, using the same concepts as ASCOM but without the Windows bias. It can run on Linux/OSX/Windows and clients such as CCDCiel are available as well as sky simulators like sky_simulator to help with development. There is a whole slew of standards involved in http getting and posting various formats such as images and commands. On the other hand INDI is XML based, commands are sent by encoding your requirements over a single non-standard TCP socket which is kept open continuously, with no natural point at which to close or restart that socket. Back in the real world a lot of manufacturers only supply INDI or ASCOM drivers that run only on Windows, and hardware that uses those drivers can have a very long life and needs supporting. The magic solution is for manufacturers to give their devices sufficient intelligence to support alpaca, or else control them from a legacy windows driver solution. The latter stopgap is probably what people are thinking of when they say alpaca is backward looking. When will manufacturers move to alpaca? When customers start to prefer devices that come with such drivers. Meanwhile it would be helpful for the open source community to embrace dual INDI/alpaca support, the way CCDCiel does it. Another difference, INDI works by asking what the driver supports in the form of a list of XML capabilities, this is complex compared to the alpaca approach of simply asking the driver, do you have capability X (which I need)

 

[Rallemikken]

20 hours ago, jerk said:

Another difference, INDI works by asking what the driver supports in the form of a list of XML capabilities, this is complex compared to the alpaca approach of simply asking the driver, do you have capability X (which I need)

This is one thing I like, gives you a glimse of the capabilities of new or unknown gear. Didn't get good guiding untill I took a deepdive into the settings of my new guidecamera. That beeing said, the GUI (graphical user interface) where you actually do theese adjustments looks like something from RedHat 7.2...   Btw, thats not RHEL I'm talking about.

Edited June 23, 2022 by Rallemikken