Ascom Platform Rewrite -- Questions?

[Kango_V 10]

I'm just getting into astronomy with my kids and they are loving it. All we've done at the moment is viewing. I've recently started looking at getting into astrophotography, but what I've discovered seems like a real mess!!! There does not seem to be a single specification, spi, set of interfaces for anything. Also, the bit that alarms me most is that Linux and Mac users are alienated big time.

I'm a software engineer of 22 years from everything from ZX81 assembler to RPG on IBM AS/400s through Java (my current poison lol). I'd like to redesign the Ascom framework from the ground up. I've been looking for an open source project to start for years and I think I may have just found it.

My plan is to build a server based on the OSGI framework, with drivers written as OSGI plugins that will contribute to the platform, both UI and background services. Configuration of the whole system will be web based, but there will be remote client (like EQMod) which would connecto to the server at a low level provided by a plugin. I was thinking of using GWT for the server configuration UI, so that it would run on any browser going and GWT mobile could be used or iOS or Android functionality (if this is required).

So this server would be lean enough to be installed and run on something as small as raspberry pi up to a more powerful laptop. The pi could then use its USB/Ethernet

So, there is the background. What do you all think?

Any suggestions would be very welcome.

[NickK 517]

There's a few frameworks that are ahead (by some distance):

* ASCOM - MS based technology

* INDI - Unix-based (http://en.wikipedia....buted_Interface)

* AOSX - Apple based technology (in development)

The issues are really about modern security integration (platform specific) and performance.

Edited October 21, 2012 by NickK

[GlassWalker 99]

Personally I'm amazed we even have Ascom. Can't be easy to get support from varied software and hardware providers. So to make something again from scratch, support would be key to success.

I hadn't noticed the (lack of) Ascom support outside Windows. Even an inexpensive netbook/laptop would suffice and in cost terms would not be significant compared to the rest of the kit typically involved, so it isn't necessarily a major hurdle. Having said that, Ascom of course is far from perfect. But it is here now, and it more or less works, and is generally supported. I don't know what options there are to go beyond this, if it would be possible to port it to other systems, or produce a parallel system that could be compatible with it. A new ground up system? I think that again would go back to requiring support of software and devices...

[Kango_V 10]

I agree we have ASCOM now, but it only runs on one platform. I'm investigating this as it's the first project that I'd love to get my teeth into. Also, I'd like to have a remote server based system that can sit in the obsy and remote clients connect in and configure/adminstrate and run the systems connected to it. I'd also like the web based gui and online plugin manager etc etc. This is the stuff I'd like to design into the system.

So, connect new hardware, upload new plugin, configure in web based interface and off ya go. I know, this is a bit simplified, but essentially, this is what I would like to do.

I realise I've got a LOT of research ahead of me. I don't even know how these other systems work yet LOL. I'd get it working with just mount control first and add other sub systems first. Some of the plugins could possibly be bridges to existing implementations.

Is there any good documentation for ASCOM etc? I've not found much yet.,

[StuW 89]

I'll follow this thread with interest. I was a software developer for 16yrs on and off and I've contemplated something similar myself. If you need to bounce any ideas or need any other help I'd be pleased to assist.

[Kango_V 10]

Just spent an hour reading the Whitepaper on the INDI Wire Protocol. That is good stuff. I cannot believe its from 2007 !!! There are even Java and .NET implementations of the wire protocol and library. This could be the underpinnings of the OSGI based server that I have in mind. It can even wrap ASCOM.

Well, I have my starting point. Lots to read ....

Thanks StuW. I'll keep this thread updated with developments. There is one thing that I cannot find out though, and that is what license INDI is released under. It must be an OSI approved license, otherwise it's a no go.

[Kango_V 10]

Nope, not going to touch the Java or .NET implementations as they are under closed source licenses. Basically you cannot have a look at the source . Oh well, I'll have to write my own implementation upon the spec (well, if that is open, I've got to find out).

Just to download an evaluation version you have to provide your personal details .

[pete_l 812]

I'm just getting into astronomy ... I'd like to redesign the Ascom framework from the ground up. I've been looking for an open source project to start for years and I think I may have just found it.

...

So this server would be lean enough to be installed and run on something as small as raspberry pi up to a more powerful laptop. The pi could then use its USB/Ethernet

So, there is the background. What do you all think?

Any suggestions would be very welcome.

Crikey!

This sounds like a big, BIG, BIG project.

The first thing I'd suggest is that you avail yourself of a PC running ASCOM and all the ASCOM enabled software packages. See what functionality and interconnectivity (a lot of third party s/w connects to ASCOM, and a lot of suppliers provide ASCOM drivers for their hardware) we all benefit from by using the framework.

Also, be aware that the thing which makes ASCOM so attractive is that a lot of hardware comes with ASCOM drivers. Those are drivers that someone would need to replicate for Linux, to make a new framework useful. Just keeping al that stuff up to date with new Linux kernel releases would be a full-time job.

I look forward to seeing how you get on with this project and I wish you the very best of luck with it.

[Chris Rowland 97]

As one of the core ASCOM developers I wish you the best of luck.

We have been thinking that it would be nice to extend the ASCOM principle of producing a common control system into other OSes for some time but it's not trivial. In particular the clash of cultures seems to be a big problem.

What we found was that trying to develop this sort of thing by committee is at the impossible end of difficult. There are too many people with strongly held views and principles to get anything done. This not being anyone's full time job doesn't help, it's too easy for people with no real involvement to derail things.

I suggest not getting too hung up with license principles. ASCOM uses a very relaxed licence, one of the Creative Commons licenses I think. It would probably not have worked if it had been published with a more restrictive license.

Chris

[syd_malicious 19]

Hats off to you for even considering such a mammoth task. I'm not clear if you are proposing a true universal standard for things and hoping it get adopted by the wider astro community or just a "little" project for yourself.

If it is the former then I don't think you're in with much of a chance of getting things adopted (unfortunately). ASCOM is supposed to open and universal (for windows) but in reality is driven by 2 vendors (Diffraction Limited who sell Maximdl and DC3Dreams who sell ACP). Whilst it is a good idea in principle it is what these 2 programs depend on and the programs also depend on each other (Maxim an ACP to a lesser degree). ASCOM is "run" by a number of people who are mainly amateurs but there are vested interests as mentioned before - the Yahoo group is the main place to gather and discuss info. In general Maximdl is the (expensive) gold standard for astrophotography and for the aforementioned reasons I'd be astounded if would ever support anything in addition to ASCOM.

From a manufacturers perspective ASCOM is very attractive as they do just need to write a "driver" and it will pretty much work on any program that implements ASCOM.

Having said that there is much to criticise ASCOM for and it was such a refreshing change to start using CCDSoft and TheSky that did away with the clunky and unwieldy thing that ASCOM can be sometimes.

I am not doing down for one minute the work that the ASCOM developers put into a project that is free but it has many faults; there are one or two of them that are a bit snotty and arrogant and it is a bit cliquey despite what they would suggest. For a different perspective see this by Software Bisque - whilst a bit bias it has some very valid points. However, even Software Bisque are moving to make their software play more nicely with ASCOM.

Overall, congrats for even considering such a project but I think (unfortunately) ASCOM is an unstoppable juggernaut.

[syd_malicious 19]

I wrote my post just as the previous one was being posted! I am signed up to the Yahoo group but as I have minimal programming skills can't actively contribute apart from with user experiences - Chris Rowland is one of the unpaid people that spend a lot of time keeping ASCOM going. Kudos to him for that and he has only ever posted helpful comments on the forum but even he as a developer says

What we found was that trying to develop this sort of thing by committee is at the impossible end of difficult. There are too many people with strongly held views and principles to get anything done.

which is perhaps a bit more diplomatic than my first post but nonetheless quite an admission from an insider and what I was alluding to in my post.

[NickK 517]

As one of the core ASCOM developers I wish you the best of luck.

We have been thinking that it would be nice to extend the ASCOM principle of producing a common control system into other OSes for some time but it's not trivial. In particular the clash of cultures seems to be a big problem.

What we found was that trying to develop this sort of thing by committee is at the impossible end of difficult. There are too many people with strongly held views and principles to get anything done. This not being anyone's full time job doesn't help, it's too easy for people with no real involvement to derail things.

Agreed - we've had similar experiences with AOSX so far (tech and people).

In addition, there are modern moves by MS and Apple to make apps offered through their marketplaces to be highly secure and often sandboxing any integration with third party apps and devices (file access to /dev for serial access for example).

You have to be in for the long haul and have a real driver - in my case getting my gear to work natively on the mac. Like many here I've the usual experience (Software Engineering degree, 20 years of development including integrating AT&T's SMS networks in Java, writing embedded for Blackfin and ARM etc). Like many AOSX isn't my day job but does take considerable time of a couple of people - this includes writing the driver plugins for the initial device support.

Afterwards it's the usual task of attempting to get manufacturers to devote time and money developing and maintaining for that platform - usually they're smaller companies and they develop once so whatever the platform it needs to maintain a good backward compatibility. Infact I would go to the point that if the proposed platform can't take the existing drivers then it's going to face a very stiff uphill effort. This is why AOSX supports C/C++ and Objective-C/C++ plugins. I've signed an NDA with ATIK however it does mean I now have a working ATIK driver native on Mac that I'm able to release in binary form for AOSX.

Now if only I could get ASA to send me a sample DDM60 for driver development

Reading Syd's SB-ASCOM link, that's true - however I think vendors have a right to protect their own investments.. open source is great.. let the framework be that (AOSX will be opensourced).. there's nothing preventing closed components being freely available in binary form and benefitting all.. it's about making it easier to do AP.. not enforce opensource when it's detrimental out of blind conviction! (just my opinion!)

Edited October 23, 2012 by NickK

[Chris Rowland 97]

Hats off to you for even considering such a mammoth task. I'm not clear if you are proposing a true universal standard for things and hoping it get adopted by the wider astro community or just a "little" project for yourself.

If it is the former then I don't think you're in with much of a chance of getting things adopted (unfortunately). ASCOM is supposed to open and universal (for windows) but in reality is driven by 2 vendors (Diffraction Limited who sell Maximdl and DC3Dreams who sell ACP). Whilst it is a good idea in principle it is what these 2 programs depend on and the programs also depend on each other (Maxim an ACP to a lesser degree). ASCOM is "run" by a number of people who are mainly amateurs but there are vested interests as mentioned before - the Yahoo group is the main place to gather and discuss info. In general Maximdl is the (expensive) gold standard for astrophotography and for the aforementioned reasons I'd be astounded if would ever support anything in addition to ASCOM.

From a manufacturers perspective ASCOM is very attractive as they do just need to write a "driver" and it will pretty much work on any program that implements ASCOM.

Having said that there is much to criticise ASCOM for and it was such a refreshing change to start using CCDSoft and TheSky that did away with the clunky and unwieldy thing that ASCOM can be sometimes.

I am not doing down for one minute the work that the ASCOM developers put into a project that is free but it has many faults; there are one or two of them that are a bit snotty and arrogant and it is a bit cliquey despite what they would suggest. For a different perspective see thisby Software Bisque - whilst a bit bias it has some very valid points. However, even Software Bisque are moving to make their software play more nicely with ASCOM.

Overall, congrats for even considering such a project but I think (unfortunately) ASCOM is an unstoppable juggernaut.

Hats off to you for even considering such a mammoth task. I'm not clear if you are proposing a true universal standard for things and hoping it get adopted by the wider astro community or just a "little" project for yourself.

If it is the former then I don't think you're in with much of a chance of getting things adopted (unfortunately). ASCOM is supposed to open and universal (for windows) but in reality is driven by 2 vendors (Diffraction Limited who sell Maximdl and DC3Dreams who sell ACP).

Not true.

Whilst it is a good idea in principle it is what these 2 programs depend on and the programs also depend on each other (Maxim an ACP to a lesser degree). ASCOM is "run" by a number of people who are mainly amateurs but there are vested interests as mentioned before - the Yahoo group is the main place to gather and discuss info. In general Maximdl is the (expensive) gold standard for astrophotography and for the aforementioned reasons I'd be astounded if would ever support anything in addition to ASCOM.

Your post is typical of so many ignorant posts on the internet. opinions posted as fact. ASCOM is not written round two vendors. There are lots involved. There are no vested interests.

From a manufacturers perspective ASCOM is very attractive as they do just need to write a "driver" and it will pretty much work on any program that implements ASCOM.

Having said that there is much to criticise ASCOM for and it was such a refreshing change to start using CCDSoft and TheSky that did away with the clunky and unwieldy thing that ASCOM can be sometimes.

Vague slurs are not a criticism they are just mud throwing. If you can come up with something rational then do so.

I am not doing down for one minute the work that the ASCOM developers put into a project that is free but it has many faults; there are one or two of them that are a bit snotty and arrogant and it is a bit cliquey despite what they would suggest. For a different perspective see thisby Software Bisque - whilst a bit bias it has some very valid points. However, even Software Bisque are moving to make their software play more nicely with ASCOM.

Your whole post is a slur on the work the ASCOM developers do.

SB are not keen on ASCOM and their software does not play well with it. We have had to jump through all sorts of hoops to make it work with their software. For example we have to add a load of DCOM registration purely because the SB products require it. No other application needs that.

Overall, congrats for even considering such a project but I think (unfortunately) ASCOM is an unstoppable juggernaut.

[Chris Rowland 97]

I wrote my post just as the previous one was being posted! I am signed up to the Yahoo group but as I have minimal programming skills can't actively contribute apart from with user experiences - Chris Rowland is one of the unpaid people that spend a lot of time keeping ASCOM going. Kudos to him for that and he has only ever posted helpful comments on the forum but even he as a developer says

which is perhaps a bit more diplomatic than my first post but nonetheless quite an admission from an insider and what I was alluding to in my post.

Malicious is quoting me out of context. This is not what I said, or what I meant.

If you want to see what I mean by development by committee look at the Telescope V2 discussion on ASCOM-talk. In brief it took over a year to get a few properties added to the Telescope interface. Just as we thought it was finished someone would pop up with more suggestions and the process would continue for another couple of months.

Malicious, do not distort my words to suit your own agenda. It is not polite. We understand that you don't like ASCOM. That's fine, nobody is forcing you to use it. If you want to help and are able to provide rational criticism then please do so. But we aren't going to rewrite it and orphan dozens of drivers.

One thing we desperately need is people who are prepared to help with documentation, also people who are prepared to test and provide meaningful feedback. None of these need programming experience - in fact experience is a disadvantage - but we find it incredibly difficult to get any reports more meaningful than "it didn't work" or "has problems". Suggesting that somebody who has problems is in a perfect position to help us write better documentation is, I find, an infallible way to cause them to go quiet. Not what I really want but at least more peaceful.

Chris