Moving to Linux - What works and alternatives

[psamathe]

1 hour ago, Vox45 said:

After years of lurking, I just ordered a Raspberry PI 3

My endgame is to install Kstars on Linux Mint (once the ubuntu-16.04 version of Mint is release in july/august) and install the INDI part on a raspberry PI. This way I can have the "control" part at the telescope and use the interface at my desk over WIFI or an ethernet cable, I'll be free from my 5m USB cable at last

...

Likewise (except KStars installation on Ubuntu VM).

I was very surprised that for me (a Linux novice) the RPi setup and Indi install was very straightforward.  Indi seem to provide an excellent level of documentation - you don't have to read vast volumes of technical stuff but there is plenty to tell you what to so (and for me it worked).  Still got to test it all though (installations done, just got to connect-up and test/learn).

One useful utility I've been pointed to is IndiStarter - a Linux utility that will startup a remove Indi server (i.e. it creates the SSH link meaning you don't have to SSH into the RPi and use command lines.  Looks like it supports starting with different profiles so could make life a lot easier (I suspect it is an important/useful addition to the Indi system). https://sourceforge.net/projects/indistarter/

Ian

Edited May 30, 2016 by psamathe

[Mak the Night]

4 hours ago, MoonNut said:

I have moved to Linux too, about 3 years ago. I have found Mint to be the better distro due to ease of use and a more "windows stye" interface (I never warmed to the Ubuntu side-bar menu).

 

After a while it became clear that I still needed Windoze programes that I have been using for many years, Fast Stone image viewer and Registax to name two, so I decided to create a dual boot system on both my Laptop and Desktop, so now I have Mint 17.3 and Windoze Vista on both. In Mint it is possible to access the Vista partition so moving files from one to the other is not a problem.

 

Mint is basically an Ubuntu fork with a different interface. Unity is relatively new on Ubuntu and the 'sidebar' dock has a show/hide facility, plus Mac-style docks can be added from the repo. The side dock can apparently be moved to the bottom of the screen in 16.04 LTS. This was always intended as a feature, although it took Canonical a while to swat most of the bugs I believe. Mint looks a lot nicer than the bog-standard Ubuntu OS though, which is in serious need of improving aesthetically in my opinion lol. The predominant reason I don't run Mint is their lackadaisical approach to security. Linux is far more secure than Windoze in many ways and most people don't even run an AV (anti-virus program) on it. I'm still paranoid about security after running Windows for so many years though, Linux is a breath of fresh air in that respect.

Around a year ago Amazon still had a few laptops with Win 7/Mint and Win 7/Ubuntu dual boots. I was very tempted to get one, but went with a laptop running Ubuntu only. I still have a Win 7 desktop though. As you say, it isn't as easy going totally Windoze-free as people think.

I'm so going iMac for my next destop lol.

[NickK]

My only concern with Ekos is that because it seems bound to kstars is that if kstars fails (due to a bug) it takes out the guiding/tracking/scheduling component of the system.. so you could end up 5 minutes out of a 8 hour unattended session. However with other apps it's almost the same and the growing number of users means the system gets a heavily tested - hence I'll accept that risk.

 

[psamathe]

1 hour ago, NickK said:

My only concern with Ekos is that because it seems bound to kstars is that if kstars fails (due to a bug) it takes out the guiding/tracking/scheduling component of the system.. so you could end up 5 minutes out of a 8 hour unattended session. However with other apps it's almost the same and the growing number of users means the system gets a heavily tested - hence I'll accept that risk.

 

I think the risks/impact vary depending on development and user situations.  Should a new release introduce a serious bug in KStars then I guess (as every good IT person says) you have your backups.  and whilst a serious bug could arise in KStars, it is also possible a serious bug could arise in Ekos as well.

I agree that it would be nice to split the two aspects, partly as I personally don't like KStars that much - but that is personal preference and it is certainly not a "bad" bit of software.

In my own situation, I am a beginner just looking to start astrophotography, so I suspect that by the time I sort out buying auto-guiding gear and get t the point where I am more dependent on Ekos, other packages will be including the functionality.  I believe/hope that Indi is taking off right now and more and more existing software packages are including/adding support for Indi (e.g. PixInSight, PHD2?, AstroImager (CloudMakers), AstroTelescope (CloudMakers), AstroGuider (CloudMakers), etc.) plus others who have the aims to develop Indi support (e.g. Software Bisque TheSkyX - has asked for people to use the X2 interface to develop Indi support, which would quickly add a powerful and complete client side (auto-guiding, camera control/imaging, planetarium, plate solving, etc.).  So I suspect it wont be long until there are a lot more choices of Indi client.  And in my own case, I'll probably have more choice by the time my needs become more crucial.

(Sorry, just noted who I am quoting/responding to so not for me to be pointing out where Software Bisque are aiming to go Indi wise and development wise - but TheSkyX's (whole package NOT specific diver support) development status on Mac is another matter).

Ian

Edited May 31, 2016 by psamathe

[NickK]

21 hours ago, psamathe said:

(Sorry, just noted who I am quoting/responding to so not for me to be pointing out where Software Bisque are aiming to go Indi wise and development wise - but TheSkyX's (whole package NOT specific diver support) development status on Mac is another matter).

I developed a driver for ATIK on OSX and also rewrote TheSkyX plugin for ATIK on OSX for Software Bisque/ATIK.

They both have different approaches and challenges, however for me one thing with the seperate user level drivers in apps is that if one component fails then it's faster to restart just that component that effectively shutdown the guider, the capture and restart and align.. That's less of a problem if you have more predictable clear skies compared to the cloud ridden and AP-limiting UK climate! INDI's development came out of observatory use, globally, in clearer locations. Now with the adoption by more "amateur" users, new requirements appear.

 

[perfrej]

I confirm that I will spend some time with INDI, most likely in July or August, and produce a driver for 10Micron products and the Remote Control USB Hub. Being a remote buff, Ekos scheduler is the thing that finally got my attention, and I will most likely contribute at least logic input, if not code, to that project.

Luckily, I do not do guided imaging at all, so one less component to worry about. I am interested in novel ways of focusing the telescope, but I have not yet researched how that is done in the Ekos environment.

At this time, my vision is to use a Pi 2 or 3 in a Losmandy extension unit between mount and scope, and to run an INDI device server in that. The rest of the logic (Ekos) can execute either in that thing or in a separate and more powerful computer elsewhere. All I need is one 12V feed and one Ethernet up to the mount. Perhaps I can have this running in my remote observatory in Provence by Christmas or so. I plan to go down in late November and should have something ready and balcony tested by then.

Whoah!

 

/per

[Gina]

Using an RPi at my pierhear/scope/multi-imaging rig would be great IMO.  Could be fine for DSO imaging but too slow for planetary that will need USB3.  Should be fine for all sky cam too.  Pi 3 has wifi I gather   In which case the ASC would require just a 12v power cable only

[ajk]

@Vox45 HitecAstroDCFocuser has arrived. However, after installing the software I see the EULA states no reverse engineering is permitted without their consent. Do you want to reach out to them and see if you can get any joy from them in terms of permissions (and even better technical specifications)?

 

[psamathe]

6 minutes ago, ajk said:

@Vox45 HitecAstroDCFocuser has arrived. However, after installing the software I see the EULA states no reverse engineering is permitted without their consent. Do you want to reach out to them and see if you can get any joy from them in terms of permissions (and even better technical specifications)?

 

I can see why manufacturers put in such constraints and can appreciate why they might not want anybody/everybody developing software for public release.  Whilst some of that software would probably be excellent and would significantly enhance their product, other software (e.g. novice developers) might be a bit "inadequate" and you could end-up with bad reviews that could reflect badly on their product (e.g. "High cost Systems mount with NoviceDev software - bug ridden, keeps failing and losing sync and could not follow anything for more than 2 mins ..." which might be the failing of the software but is closely linked to their hardware.

I think there are now several platforms emerging that deserve support from mainstream hardware and that manufacturers would be sensible to provide (or 3rd party contract) software/drivers for these platforms.  I think the hardware independent platforms are more important to many than their own software packages.

Ian

[JamesF]

2 minutes ago, ajk said:

@Vox45 HitecAstroDCFocuser has arrived. However, after installing the software I see the EULA states no reverse engineering is permitted without their consent. Do you want to reach out to them and see if you can get any joy from them in terms of permissions (and even better technical specifications)?

 

I'm fairly sure that's not enforceable in Europe.  As far as I recall there's a European Directive that effectively enshrines in law the user's right to reverse engineer software and those rights can't be taken away by the EULA.

James

[ajk]

Ian

Yeah, I can understand that point of view. I may email themselves so "present my CV" so they can have some faith (I've been writing device drivers in C and Assembler for 30 odd years now).

One thing does pop out at me though. They sell a second DC Focuser with an alternative PID code and separate driver install so people can use two focusers at the same time. Strictly speaking this isn't how you are suppose to implement USB devices (image not being able to use two or more printers/serial ports/etc of the same type). So, they either did what they did to save of development costs at the expense of wasting a PID or they don't fully understand the USB specification (my guess is the former as it's cheapest simplest solution). Until you want to add a third focuser that is

 

[JamesF]

1 minute ago, JamesF said:

I'm fairly sure that's not enforceable in Europe.  As far as I recall there's a European Directive that effectively enshrines in law the user's right to reverse engineer software and those rights can't be taken away by the EULA.

James

Here's a reference: https://en.wikipedia.org/wiki/Reverse_engineering#European_Union

James

[ajk]

1 minute ago, JamesF said:

I'm fairly sure that's not enforceable in Europe.  As far as I recall there's a European Directive that effectively enshrines in law the user's right to reverse engineer software and those rights can't be taken away by the EULA.

Generally, if I cannot affords a lawyer to clarify this in court and I may loose I prefer not to engage.

[ajk]

@JamesF Thanks for the wikipedia reference but being an engineer and that text being lawyer speak it means nothing to me. 

[JamesF]

Just now, ajk said:

@JamesF Thanks for the wikipedia reference but being an engineer and that text being lawyer speak it means nothing to me. 

To be honest I think it's pretty clear compared with a lot of legalese.  And if it weren't safe I'm sure we'd have seen an awful lot of Europeans who have reverse-engineered systems for the purposes of creating open-source software (including myself, potentially) get sued already.

James

[psamathe]

13 minutes ago, ajk said:

Ian

Yeah, I can understand that point of view. I may email themselves so "present my CV" so they can have some faith (I've been writing device drivers in C and Assembler for 30 odd years now)....

If it were me I'd be going for the Indi driver route.  Maybe propose to them that you do it without their blessing and help (and are more likely to give-up of miss aspects) for personal use/distribution or do it with their help for general release to the Indi library and they benefit from wider software support and that maybe they would like to make a donation to the Indi project once the completed drivers were released ...

Ian

[JamesF]

And as regards writing a driver, I'd suggest that it's far less pain and much more portable to write a user-space driver layered on top of libusb than to attempt to do anything at a lower level.  It's not like there's a huge performance issue here.

Could be useful to plug the device in and see what device class the USB layer thinks it is.  It might be something really simple.  For example, the SX filter wheels turned out to be HID devices and there's already an open source library to do all the HID interface stuff (libhidapi) which takes away a load more work.

And as a bonus it means the code will usually run unmodified on OSX as well as Linux.

James

[ajk]

18 minutes ago, psamathe said:

If it were me I'd be going for the Indi driver route

I intend to. The focuser presents itself to the OS as a HID Class device and it loads up a standard driver anyway. All that needs reverse engineer here is the command structure they are using. In essence "what button press/wheel spin represents what control of the focuser?"). No bespoke USB code required so the Indy driver would be the natural route.

[JamesF]

Sounds like a doddle then.  Should be done by the end of the evening

James

[ajk]

@psamathe @Vox45 @JamesF

For the record I have emailed/contacted HitecAstro. It would be way simpler if they gave me/us/whoever both permission and the specification of the device. Lets see what they say.

[Vox45]

This is what happens when passion, knowledge and opensource come together.... Magic !

[perfrej]

19 hours ago, Gina said:

Using an RPi at my pierhear/scope/multi-imaging rig would be great IMO.  Could be fine for DSO imaging but too slow for planetary that will need USB3.  Should be fine for all sky cam too.  Pi 3 has wifi I gather   In which case the ASC would require just a 12v power cable only

Oh, don't ever venture down the dark WiFi path! It inevitably leads to utter despair! Cable it...

 

/per

[perfrej]

11 hours ago, ajk said:

One thing does pop out at me though. They sell a second DC Focuser with an alternative PID code and separate driver install so people can use two focusers at the same time.

That is so that they can use two instances of an ASCOM driver. ASCOM does have the slight disadvantage of only permitting one device per GUID, but on the other hand, if you had two focusers with the same data in the hardware description, how would you keep track of which focuser is which? You really need to give them separate IDs some way.

 

/per

[Gina]

2 hours ago, perfrej said:

Oh, don't ever venture down the dark WiFi path! It inevitably leads to utter despair! Cable it...

/per

I've been using WiFi to connect to my observatory laptop all along with no problem - the distance is only around 20m or so.  OTOH I have had problems with rats chewing the cables where I have run cable.

[ajk]

6 hours ago, perfrej said:

That is so that they can use two instances of an ASCOM driver. ASCOM does have the slight disadvantage of only permitting one device per GUID, but on the other hand, if you had two focusers with the same data in the hardware description, how would you keep track of which focuser is which? You really need to give them separate IDs some way.

 

/per

So ASCOM is the pinch point in it all. Not used Indy yet, we'll see if they have the same issue.