Exploring Alternatives to Windows/ASCOM...

[bseltzer]

Having been a professional *NIX systems engineer/analyst for 17 years, I've got more reason then most to dislike Windows as a platform, and I can't say I'm overly thrilled about the idea of having to funnel most of my hardware through the ASCOM platform, which itself is slavishly dependent on the aging .NET framework. So, has anyone here had any experience with any alternatives?

I've been working with the developers of the INDI library which can be used by any LINUX/MACOS applications (such as Kstars and Ekos) that are aware of it to control a growing list of devices. Unfortunately, the INDI driver for Astro-Physics mounts isn't quite ready for prime time in its current iteration. That's what I've been working on with Jasem Mutlaq og the INDI project.

So the question is, does anyone know of a *NIX-based driver for AP hardware? Thanks.

[kirkster501]

Sounds interesting.  But the phrase "if it ain't broke don't fix it" comes to mind...  The ASCOM/Windows combo is so tried and tested, not just amongst us mere amateurs but in professional observatories as well, that I can't see anyone departing from it just for "a change".....  It works, and it works very well, despite the .NET framework getting a little long in the tooth.

[Dubhar]

Sounds interesting.  But the phrase "if it ain't broke don't fix it" comes to mind...  The ASCOM/Windows combo is so tried and tested, not just amongst us mere amateurs but in professional observatories as well, that I can't see anyone departing from it just for "a change".....  It works, and it works very well, despite the .NET framework getting a little long in the tooth.

I would say that being limited to ASCOM/Windows combo makes it broken in the first place. You end up stuck on a specific platform with no alternative. You cant for example control your hardware with an embedded low power device remotely, since that would require linux as windows isnt capable of running on that type of hardware. 

Off topic but changing just for a change isnt always a bad thing, though in this case it isnt change for change. INDI exists because ASCOM doesnt provide what people need.

So the question is, does anyone know of a *NIX-based driver for AP hardware? Thanks.

I cant remember the user or link but there are one or two people here working on open source/free software with support for Linux based devices. I'm a linux user and right now im trying to figure out what the support is like for various mounts, im not actually clear if ASCOM work on anything but windows? or if its driver dependant (i.e. .net drivers not supported outside windows but ASCOM in general is) do you happen to know?

I'll need to see if i can find the links for the software people are working on, maybe the ones who post here will link to their work.

[riklaunim]

SkyWatcher released some libraries for direct mount control - https://github.com/lucemia/skywatcher_open and there some Linux QHY and ZWO ASI libraries. There is also Linux capture app for planetary cameras that has a thread somewhere on this forum. As for ASCOM - I've seen tutorials about getting it working on Wine

ASCOM has the advantage that you install it and it works - in third party apps. There are third party apps that make it matter. As for Indi - I see a package in repo but what's the use of it? It looks like for me that there is limited amount of apps that actually can use it. OpenPHD/PHD2 on Linux is new, and things like Nebulosity2 are non existed (image capture and processing). I work on Linux, but I keep Windows for astrophotography.

Note that there is more and more Intel low power boards and devices that are Windows compatible.

[perfrej]

I don't know about this... When the Linux open source community comes up with working regression testing and verification, I'm willing to listen. So far, whatever the field, Linux open source disappoints every time. How can you possibly beat the regression test that a commercial company puts their software through? I once looked at the automated test systems for regression test of Windows builds. Very difficult to beat. I have a semi-annual procedure of testing the latest Linux, and it disappoints every time. Mind you, I DO give it a shot twice a year!

Being a producer of ASCOM drivers and ASCOM software, I feel I am qualified to make statements about ASCOM, and although it leaves some to be desired, it is a pretty stable and general purpose astro platform with lots of drivers and a reasonably good structure/architecture. The ambition of running on all kinds of hardware, present in the Linux world, does have one drawback; you need to work from source code and compile for your specific hardware. So, even though it is "platform independent", it puts the burden of compilation on the end user. Most of us cannot handle that.

Anyway, I would like to see a Qt-based astro library.

And, for the record, I am actually all for INDI even though I think it will always be for the initiated few.

/per

[NickK]

Hmm, a test case only as good as it's writer. Secondly the reality is that the automated tests often has a code base are as large the product itself.  Also Linux seems to target the lowest common denominator to maximum portability.. hence speed and efficiency suffers.

My view of linux software is usually a mass of simple "me too" & I can do better software that simply just does the same thing everything else does with zero reason to exist. The number that really add value is very few.. So asking the obvious question - why recreate the wheel?

I'd love a open source astro platform that doesn't require you to install linux on your platform before it will work (thinking of many included libraries). And here is the problem - to reduce the complexity where you're focusing on the astro problem and not writing/maintaining enablers (i.e. libraries or drivers) needs review.

The reason I use OSX and Xcode is simply because of the cross platform complexity would be too much - the drivers I have are C++ (with Objective-C++ wrapper).. 

To answer the OP's question - no, ASCOM has dominated the PC hence there are no serious alternatives unless you take SB's X2 interface with TheSkyX: http://www.bisque.com/help/theskyx%20pro%20info/welcome.htm

Astro-Physics™

GTO series mounts

All models*, including:

 

• Mach1GTO

• 900GTO

• 1200GTO

• 3600GTO

 

*TheSkyX Professional Edition's native Astro-Physics mount driver states that firmware version G or later is required to control Astro-Physics compatible telescopes.  Note that if you own an older model AP controller that uses an earlier firmware version, TheSkyX Professional Edition will still control it; however, newer firmware features will not be available.

 

Software Bisque strongly recommends using the latest available firmware for your telescope.  Contact Astro-Physics for details about upgrading your mount's firmware.  

 

However SB isn't Linux.. So - no.

My view on INDI is:
* does it do the job? I don't mean being able to send "move here" and "sync" etc, I mean can it manage scopes in realtime with corrections for pointing schemes etc.

* XML - nice.. but I really feel it's not going to cut the performance requirement for the point above.

* does it "just work" .. i.e. just click?

This leads me to my linux bug bear which is having to spend more time in admin rather than using..

[Dubhar]

I don't know about this... When the Linux open source community comes up with working regression testing and verification, I'm willing to listen. So far, whatever the field, Linux open source disappoints every time. How can you possibly beat the regression test that a commercial company puts their software through? I once looked at the automated test systems for regression test of Windows builds. Very difficult to beat. I have a semi-annual procedure of testing the latest Linux, and it disappoints every time. Mind you, I DO give it a shot twice a year!

Being a producer of ASCOM drivers and ASCOM software, I feel I am qualified to make statements about ASCOM, and although it leaves some to be desired, it is a pretty stable and general purpose astro platform with lots of drivers and a reasonably good structure/architecture. The ambition of running on all kinds of hardware, present in the Linux world, does have one drawback; you need to work from source code and compile for your specific hardware. So, even though it is "platform independent", it puts the burden of compilation on the end user. Most of us cannot handle that.

Anyway, I would like to see a Qt-based astro library.

And, for the record, I am actually all for INDI even though I think it will always be for the initiated few.

/per

I don't want to derail the topic, but its worth mentioning, what about Linux? You say open source software cant beat what commercial companies do, but the Linux kernel has I would argue(among other things, apache, nginx, python,  qt, etc) . But I don't disagree, tools could be improved and one of the problems with open source software is people will work on what interests them which lease more specialised software (like astro software) with very few developers, meaning open astro software can lag behind on lack support until the developer(s) implement those features.

INDI only has 4 core developers, thats very little considering there goals.

Doesn't INDI use Qt? at least from what ive seen it does. 

My view of linux software is usually a mass of simple "me too" & I can do better software that simply just does the same thing everything else does with zero reason to exist. The number that really add value is very few.. So asking the obvious question - why recreate the wheel?

[...]

This leads me to my linux bug bear which is having to spend more time in admin rather than using..

Theres two reasons to recreate the wheel, software doesnt work on your computer so you make your own (competition is good! i guess thats another reason ) and/or you want control over your computer and prefer free/open software (a common theme among Linux users) .

Your bug bear.. how are you having to spend so much time admining your system than using..? (maybe that should be a sepate topic if you ever try linux again) im wondering if its just choice of distro or not used to the different OS? I spend 1 min every few nights typing one command to update software and let it do its thing, all good.

Unfortunately I believe the answer is contribute to INDI and help develop existing (or create) software that's open and cross platform. Because its specialist software it does mean the pool of active developers for open astro software you could very likely count off on your hands. 

[NickK]

The way that INDI is architected is highly inefficient. The model it uses - a single thread performing i/o for all clients/drivers (looking at indiserver.c) - is a major design issue. The same technique copies data needlessly for example:

* Looking at the libxml.c library, it uses malloc & memset to zero - calloc performs a zeroing at a lower level and hence is better performance (without needing the memset).

* Using sockets between local components is a waste - also memset is slower than copying using memory mapping calls (that only copy the only the pages that are written but share unchanged mapped pages).

The design focus is to place an image to a file which is ok at the end of a long exposure, but not such a good idea for high frame rate applications.

Also looking at the mount control - it's slew control, it's _not_ tracking adjustments. These would have to occur within the driver.

However we're getting off topic from the original ask

[Dave_D]

How can you possibly beat the regression test that a commercial company puts their software through?

/per

And there is the crux of the matter... why are these self-same commercial companies so lazy as to only produce software for a single platform when there are 3 major platforms, and in the scientific community, i can say from experience that windows is a sad 3rd to linux and apple.

And of course it's swings and roundabouts comparing commercial to open source software. there's open source that wipes the floor with commercial and vice-versa...

[tekkydave]

Personally I would love to use a Linux program over a windows one anyday but most commercial activity is around windows cos it's the easiest area to make money. I have written my own programs in Java to talk to my Nexstar mount that run on both platforms but that's all it does. It wont talk to any other mount or device as I don't own one to experiment with. I suppose what we need is for Ascom to be rewritten in Java or C/C++ and use a technology other than COM (the reason it only works on windows). The use of .net is irrelavent really as it just gives C# or VB the libraries to create/access the COM object. Let me know if that last bit is incorrect btw.

[NickK]

And there is the crux of the matter... why are these self-same commercial companies so lazy as to only produce software for a single platform when there are 3 major platforms, and in the scientific community, i can say from experience that windows is a sad 3rd to linux and apple.

And of course it's swings and roundabouts comparing commercial to open source software. there's open source that wipes the floor with commercial and vice-versa...

To develop, or port then test require additional skills/developers and usually additional testing (test case or manual). That has to be stacked up against the business case - now open sourcing means you're not only not going to make any sales revenue but also that you're not going to have a differentiator for very long as your competitors can simply lift the code into their own. I hear the open source argument of - make money by supporting.. really? Except for enterprise you're not going to get much revenue from just support.

But… I think that open source vs commercial is for another thread

[tekkydave]

To develop, or port then test require additional skills/developers and usually additional testing (test case or manual). That has to be stacked up against the business case - now open sourcing means you're not only not going to make any sales revenue but also that you're not going to have a differentiator for very long as your competitors can simply lift the code into their own. I hear the open source argument of - make money by supporting.. really? Except for enterprise you're not going to get much revenue from just support.

But… I think that open source vs commercial is for another thread

Exactly. Ascom is great and owes a lot to dedicated non-commercial programmers but the people making the money are the equipment manufacturers. Is it in their interest to switch to a platform-agnostic ascom or other product? Why would they?

[NickK]

Exactly. Ascom is great and owes a lot to dedicated non-commercial programmers but the people making the money are the equipment manufacturers. Is it in their interest to switch to a platform-agnostic ascom or other product? Why would they?

But that equipment manufacturer needs to survive, people have mortgages and R&D budget has to come from somewhere.

[Chris Rowland]

The ASCOM platform is Windows only because it uses Windows components.

There are two sections, driver interface definitions and support components. The support components are Windows only but the interface definitions are text and could be implemented on Linux as dlls (or whatever the equivalent is).  They use properties and methods, not events.

There's a lot more about ASCOM and why it's the way it is on the ASCOM site but one of the most important considerations is stability. This allows drivers and application written many years ago to continue to work with current applications and drivers.

There is an application that allows ASCOM to work over a network - Eros Lite.  AFAIK it is currently only Windows to Windows but there's no reason in theory why it should not be implemented on Linux or Mac, by implementing the wire protocol on the other systems.

The ASCOM platform is developed and maintained by a very small number of people in their spare time, I'm one of them. We do our best to do a good job but are constrained by our lack of resources, especially testing.

Drivers are developed separately and their quality and support is variable.

Chris

[malc-c]

Interesting thread.

I played with K-Stars on a linux disty but couldn't get it to talk through INDI to my HEQ5.  But what was more disappointing was the fact that the Windows version of K-Stars didn't support ASCOM, and no matter how many tickets I raise nothing has been forthcoming.  Just wondering as some of you guys seem very knowledgeable on  the subject, how hard would it be to add ASCOM support to K-Stars which seems an open source application.

[tekkydave]

The ASCOM platform is Windows only because it uses Windows components.

There are two sections, driver interface definitions and support components. The support components are Windows only but the interface definitions are text and could be implemented on Linux as dlls (or whatever the equivalent is).  They use properties and methods, not events.

There's a lot more about ASCOM and why it's the way it is on the ASCOM site but one of the most important considerations is stability. This allows drivers and application written many years ago to continue to work with current applications and drivers.

There is an application that allows ASCOM to work over a network - Eros Lite.  AFAIK it is currently only Windows to Windows but there's no reason in theory why it should not be implemented on Linux or Mac, by implementing the wire protocol on the other systems.

The ASCOM platform is developed and maintained by a very small number of people in their spare time, I'm one of them. We do our best to do a good job but are constrained by our lack of resources, especially testing.

Drivers are developed separately and their quality and support is variable.

Chris

Chris, how easy (or not) do you think it would be to move the entire ascom platform to an agnostic technology? Are there any candidate technologies that would allow the platform to function? Users would need to be able to install the platform on their windows/linux/mac. Equipment providers and amateur programmers like me would be able to write drivers in a language that can be compiled on any of the target operating system. Furthermore the drivers would need to interface with the ascom platform in the same way on all operating systems. Sounds mostly impossible to me. Inevitably it would need to work differently on each os.

PS keep up the good work. As far as I can see ascom enables astronomers to use their gear without needing to be an engineer and/or programmer which is the object of the exercise to me.

[JamesF]

I think there's a certain amount of anti-Linux/anti-open source comment here that is either FUD or just demonstrates a lack of understanding of the open source "community" (for want of a better word).  It's possible to produce hokey software on any environment, whether it's paid for or free, just as it's possible to produce high quality software on any environment.  That software is commercial is no guarantee of quality just as being open source doesn't mean it's poorly written, tested or supported.  Anyone who thinks otherwise is kidding themselves.  Nor is it valid to extend the experience that a given piece of open source software works poorly to the entire open source world (and the same argument applies to the commercial software world equally).

James

[JamesF]

Oh for those who weren't aware, I am the developer of the oacapture open source planetary capture application, just so my position is clear

James

[JamesF]

I hear the open source argument of - make money by supporting.. really? Except for enterprise you're not going to get much revenue from just support.

There are plenty of examples where this does or has worked, but I suspect in those cases it is where the products are not for the niche market.  I suspect that is probably the real sticking point for this model for astro software.  The market for support alone probably just isn't big enough to carry the other costs.

James

[sandyshaw]

There are plenty of examples where this does or has worked, but I suspect in those cases it is where the products are not for the niche market.  I suspect that is probably the real sticking point for this model for astro software.  The market for support alone probably just isn't big enough to carry the other costs.

James

*cough* RedHat *cough*

[JamesF]

*cough* RedHat *cough*

They are the obvious example, yes

James

[sandyshaw]

They are the obvious example, yes

James

Run Wine on Linux, ASCOm uses Common Objet Model, Unix typically uses CORBA, perhaps there is a COM subsystem for Linux somewhere. I dono. If i wanted to live in the 70s again I would use Linux. I just want to get the job done without having to modify some archane files if im lucky, or recompile source.

[tekkydave]

If i wanted to live in the 70s again I would use Linux

Bit harsh. I wouldn't say windows is any less arcane - it just hides it better.

[sandyshaw]

Bit harsh. I wouldn't say windows is any less arcane - it just hides it better.

Exactly my point.

[Chris Rowland]

Chris, how easy (or not) do you think it would be to move the entire ascom platform to an agnostic technology?

We had an effort to do something like this a few years ago - ASCOM-X.

The sort of thing we were thinking of was something like this:

• Develop a wire protocol that maps the ASCOM property and method calls and responses to platform agnostic messages on a network.
• Implement handlers for this, both for applications and drivers, on every platform.
• Develop a way for remote devices to be discovered and ideally configured remotely.  This is difficult.

I managed the first and the second on Windows, including a demo application, but made the mistake of using UDP for the transport layer and people couldn't see beyond that to the concept.  I gave up and no one else moved it forwards.  Eros-Lite seems to do much the same thing.  There's no obvious reason why the ASCOM interface should not be mapped onto something that would work with Linux or iOS.

This all means that an ASCOM - or ASCOM like - platform is developed separately on each platform, using the technology that is appropriate for that platform and a common wire protocol.  Windows can stay with COM while Linux uses dlls, or whatever they find works best for them.  This would be LASCOM and iASCOM I suppose.

This looses the concept of one source that runs everywhere but from what I've seen this doesn't work very well for the sort of things that drivers need to do.

Trying to be code compatible would be really difficult, personally I wouldn't go there.

Chris