Exploring Alternatives to Windows/ASCOM...

[perfrej]

Being a driver developer under ASCOM, as well as a software writer who started programming in 1974, I have seen and used a fair number of systems and architectures. Windows (the NT-track) is actually pretty modern in architecture and full of security precautions inside. How many of you know that each access to objects in the kernel and other parts of the system triggers a security check where the caller has to provide a session ticket that is compared against the access control list withing the object? Dave Cutler did a good job on grabbing the good stuff from DEC's extremely stable VMS operating system. Anyway, back to Astro...

ASCOM is a good standard and relies on COM. In my view, it should be possible to use it with DCOM as well, shouldn't it? Has anyone even tried? Chris?

Creating a system-agnostic communications protocol for astro stuff shouldn't be that difficult, now should it? With modern network technology and the fast connections that with have, especially locally, the latency involved shouldn't really cause any problems. I run a complete data collection system on a polar ice-breaker based almost entirely on UDP broadcasts. Never lost a value, and many of them come in at alarming rates. I am not proposing UDP for astro, but rather want to point out that the network can be used for transport, between and within computers.

/per

[NickK]

The only thing really is the interface between driver and platform. If they're the same and behave the same.. you and easily port the driver.. but hacking OS specific mechanisms in there is asking for trouble.

One last point that people without experience miss - subtle design differences. For example - when reading Nbytes from the USB pipe with a timer expiry, if N-1 bytes have been send and the timer expires… windows will return the N-1 bytes to you at expiry whereas OSX will not (you either get N bytes you asked for or no bytes and the bytes are left in the queue). Now if you want to flush bytes until no bytes remain - if something crashed the device is part way transferring data but you don't know exactly how much.. this becomes a PITA on OSX. It's things like this that make porting drivers interesting and far more of an issue. Better to have a low level layer implementation to cocoon the driver developers away from the USB implementation (no copying of data please.. just simply put from the USB interface into the user data area please - but that depends on how efficient the device protocols have been designed!).

Per - re professional systems design vs the user with a old cables, old routers. UDP can and does work, however getting a vendor manufacture to understand how to use UDP is probably more difficult - they're far more likely to want to use a chip manufacturer and not have any retry logic in their systems (hence TCP and USB).

(Per - I was born in 1973 hehe..)

[tekkydave]

I'm not a systems developer so I bow to your superior knowledge. I am a dba now but I have been a developer, mainly databases (oracle pl/sql) where the low-level stuff we are talking about does not come in to play. Thinking about it oracle is a good example. It runs on windows, linux, solaris etc but works the same way as far as the user/developer is concerned. The differences are hidden away in the binaries supplied by oracle. Presumably most of the code is identical with os-specific code modules at the level it talks to the os.

What we need for astro is a binary that hides the subtleties of the os it is running on but allows people to write drivers that will run on any os. If this ever comes to anything Ill be happy to do some testing on Linux.

[Cath]

Ahh, the old OS war eh

I've found the best solution is often to write/design your own 'whatever' to do 'whatever' it is you want/need, any other way is often a compromise. I've been part of various open source projects over tne years, but these days I go it alone, too tired to carry on trying to get poorly written/buggy beginner code removed/replaced from the various branches etc.

Why don't you guys get together and develop nix and osx compatible versions of ASCOM ? - if you want something to do that is.

[Chris Rowland]

I've mentioned Eros-Lite before, here is a link to it http://research.lightbuckets.com/eros/?doc=lite

They seem to have got ASCOM going for PC to PC communication but there's no obvious reason why their protocol should not be implemented on anything else.  It's at least worth a look.  Maybe it would save reinventing this wheel.

I'm not going to presume to tell the Linux, iOS or Android people how this should be implemented on their end but it looks as if it should map onto whatever works for them.  I definitely prefer the idea of cooperation to war.

Chris

[perfrej]

Cool! A web site with grey background and grey text...

[tekkydave]

Ahh, the old OS war eh

I've found the best solution is often to write/design your own 'whatever' to do 'whatever' it is you want/need, any other way is often a compromise. I've been part of various open source projects over tne years, but these days I go it alone, too tired to carry on trying to get poorly written/buggy beginner code removed/replaced from the various branches etc.

Why don't you guys get together and develop nix and osx compatible versions of ASCOM ? - if you want something to do that is.

This thread started as an enquiry about astro software on Linux and seems to have drifted somewhat towards why ascom wont work on Linux.

I suspect Cath that it wouldn't be worth making that happen as not many people are interested in using it. It would be far better to produce something new that fitted the Linux/Open source ethos. If it used non-proprietry language(s)/hardware/standards it could always be ported to Windows as most things of any use in Linux have been.

Heres my initial spec.

1) Simple hardware-based interface to mounts/focusers/domes etc which can be implemented by cheap microcrontrollers e.g. arduino. Interface is ip-based. Standardised command set.

2) Central platform written in a language that can be compiled & run on the most-used paltforms (Linux, Windows, Mac, Unix, Android, ARM). This might be difficult only C/C++ and Java spring to mind unless an interpreted language is used in which case there are squillions to choose from (python, perl(urgh) etc etc). This talks to the hardware-based devices defined above via ip (network cable or wifi).

3) Port all of the bits in step 2 to Windows & increase the user base to point where it overtakes ascom

4) Get equipment suppliers to build the ip parts defined in section 1 into the equipment.

Any takers? I don't have the time, knowledge or experience to organise and manage any of this but I'll certainly contribute if anyone else fancies picking it up.

PS: 3 & 4 above are a bit unlikely so don't take them too seriously folks.

[tekkydave]

I've mentioned Eros-Lite before, here is a link to it http://research.lightbuckets.com/eros/?doc=lite

They seem to have got ASCOM going for PC to PC communication but there's no obvious reason why their protocol should not be implemented on anything else.  It's at least worth a look.  Maybe it would save reinventing this wheel.

I'm not going to presume to tell the Linux, iOS or Android people how this should be implemented on their end but it looks as if it should map onto whatever works for them.  I definitely prefer the idea of cooperation to war.

Chris

All it does is allow you to have a low-powered pc running the hardware and you run the resource-intensive apps on your pc inside in the warm. You could run the apps on the outside pc if it can take it and remote to it from anywhere. Doesn't address the problem in hand as neither pc can be running linux as they both need .net

[sandyshaw]

Definatly has to be platform agnostic, and there you are into services rather than object broker models (aka COM vs CORBA wars).

But certinally not running in a service host such as a bloated web service IIS / Apache et al, a simple background exe host will do.

Also simplified flat structured datatype blob files local rather than centralised database bloat.

[tekkydave]

Personally I would like to build small control modules using arduinos or even rapberry pi to connect to the hardware at the scope (mount, focusser, camera)  and run a cat5 cable to the pc or plug in a wifi dongle. The PC which can be in an obsy or in the house can run the usual windows-based or linux applications (Stellarium, Sharpcap, BYE, APT, PHD) and connect to the module at the mount. In the case of windows that connectivity could be built into ascom. For the other OSes we would need a new ascom-like platform that apps can use to get the same connection.

[sandyshaw]

Personally I would like to build small control modules using arduinos or even rapberry pi to connect to the hardware at the scope (mount, focusser, camera)  and run a cat5 cable to the pc or plug in a wifi dongle. The PC which can be in an obsy or in the house can run the usual windows-based or linux applications (Stellarium, Sharpcap, BYE, APT, PHD) and connect to the module at the mount. In the case of windows that connectivity could be built into ascom. For the other OSes we would need a new ascom-like platform that apps can use to get the same connection.

So then we are talking 50 to 100 even as high as 200 GBP for a solution.

[sandyshaw]

So then we are talking 50 to 100 even as high as 200 GBP for a solution.

In this case I would recommend using a common communication BUS with subscribers and publishers onto this common bus.

[Chris Rowland]

I get the impressions that people are over thinking this.

All I think is needed is something like a TCP/IP stream which allows a conversation between two systems, something like:

>"Can you tell me the right ascension please"

<"The right ascension is 15hrs thirty minutes and 14.7 seconds"

>"Thanks, by the way I need the declination as well"

<"no problem, its plus 15 degrees 14 minutes and 5 seconds"

All that's needed is a TCP/IP connection at each end that can read and write lines of data.

It might be better to have something a bit less chatty, more like:

>"get,rightascension"

<"get,rightascension,15.525"

>"get,declinaton"

<"get,declination,15.24"

Or is Linux unable to open a TCP/IP stream and read and write lines of text?

Chris

[sandyshaw]

I get the impressions that people are over thinking this.

All I think is needed is something like a TCP/IP stream which allows a conversation between two systems, something like:

>"Can you tell me the right ascension please"

<"The right ascension is 15hrs thirty minutes and 14.7 seconds"

>"Thanks, by the way I need the declination as well"

<"no problem, its plus 15 degrees 14 minutes and 5 seconds"

All that's needed is a TCP/IP connection at each end that can read and write lines of data.

It might be better to have something a bit less chatty, more like:

>"get,rightascension"

<"get,rightascension,15.525"

>"get,declinaton"

<"get,declination,15.24"

Or is Linux unable to open a TCP/IP stream and read and write lines of text?

Chris

So you want basically something like the Hayes AT command set.

[JamesF]

So you want basically something like the Hayes AT command set.

When it comes to controlling a mount I think even the AT command set might be a bit over-engineered

James

[sandyshaw]

When it comes to controlling a mount I think even the AT command set might be a bit over-engineered

James

Nah simple commands for control sure, but what kind of mechanism do you want to receive notifications such as ERRORS, WARNINGS, SLEW RATES, ROOF state these are important for fully automatic observatories.

[knro]

The primary issue with INDI is 3rd party drivers. With ASCOM, commercial companies, in addition to independent developers, release drivers for all the astronomical equipments currently supported. These drivers are usually thoroughly tested by the equipment manufacturer. This is not the case with INDI, commercial companies only supports ASCOM and while I do hope this changes with time, this leaves the burden of developing drivers upon INDI developers who are quite a few since especially this is a niche area. Nevertheless, the number of devices supported under INDI, and the quality of existing drivers is improving with time. The lack of access to actual hardware to test is also a major limitation, and it is only with the help of end users that drivers are currently improved.

Furthermore, INDI is mostly concerned with operating & controlling devices at the basic level, higher level functionality is usually the responsibility of INDI clients such as Ekos. However, with INDI Library v0.9.8 release, there is a new alignment subsystem that provides support for telescope alignment using a database of stored sync points. Support is also provided for "Math Plugin Modules". Other higher level functions such as plate solving, sequencing..etc are handled by clients, not INDI drivers.

[skybadger]

What about simply adding a network listener interface to the com ascom spec. Use event registration and subscription patterns to receive alerts etc.. This would provide what ypu want with very little change.

I guess the next steps are for a central directory of registered devices and authorisation.

CORBA anyone ?

Mike