Thanks Eric for the reply.

It did not happen on Indi EQMOD .but on Win Eqmod - however as my next step is to move my main obsys to Indi I wanted to know if there was any routines installed in the Indi Eqmod that took account of the possible "cork screw effect". The developer of EQMOD on Windows said there is and from he told me and the you tube infi it does try to avoid this issue by quote from Chris Shillito "Eqmod will by default move in a way that keeps the counterweights downward. If moving to a park position that is counterweights up then the move is performed such that the dec movement is completed whilst in a counterweights down position so that any counterweights don movement only occurs in RA"

Hence the question on what Indi Eqmod did.

I hate wires :-)


Hi something that has reared its head on Windows Eqmod but on ANY Indi mount control software are there safety algorythms to prevent OTA doing more than , for example 270 degree's , "cork screw slews". Reason "wiring corked screw" has happened to me when using Goto Slew which has meant wiring has wrapped around the pier and twice damaged the cabling. Wondered if Indi versions did some limiting to stop this problem.

Windows Eqmod does have a "safe move" process !


Clive Stachon replied to the topic 'well this has put the cat amongst the pidgeons - if it works' in the forum. 1 week ago

"I went through the published Alpaca spec and without trying to be catty it still follows the ASCOM protocol restrictions" - are you talking Ascom std message protocol or something else - Indi has its own "message protocol std" all client servers have too in my experience?

Having done some testing and even attempted Linux to Windows Ascom Alpaca connection ( it connected no problem) the biggest problem is I hate the Web interface its all over the place and too complicated ,IMHO, for "average Joe". You are expected to know/remember too much IP info and REST is far to talkative IMO (e.g. must I keep getting the temperature - Look at Wireshark output ). Why not use the MQTT model where the user only has to know the Broker IP name or address everything else is Topic and levels - e.g. Main Topic Camera - SiteA/Camera/DSLR/Canon/100d , SiteA/guidingCamera/CCD/ZWO/120mc and we are at least going to be talking - even if the nitty gritty has still to be set up - e.g. Gain,Exposure etc. Maybe RK's MQTT admin program will do all this automatically :-)

Surely its not too much today to expect software to "poll" for servers/clients to find out Camera1, Telescope2 ,ServerHub1 etc on SITEA at the press of a single button ( I am not talking DNS here) - at least on a home network (how many will use it across the Internet) and NOT expect a user to set up lots of connection variables (I am not even talking about device variables here just Alpaca) e.g. Device numbers,driver numbers. And those little POP UPS,e.g. chooser and Remote Client windows - you dont see because they are hidden and you didn't notice your task bar just added another widget icon - appalling IMO - Most user unfriendly. OK its early days for Ascom Alpaca and Indi have Serial Assistant etc so maybe there is hope.

Having said that the Ascom Remote Client works very well for existing software without changes(just confusing set up's) - so PHD,APT,EQMOD,CDC (in real full blown Alpaca mode) etc all work (up to now in my testing at least ) and I was able to run software across 3 Windows PC's - 2 Mini's and a desktop. - same as Indi. Peter Wilson Well done :-)

So the jury is still out but IMO both Indi and Ascom still need to make their software more user friendly so that set up is semi automatic and less complicated (hidden) without IP knowledge IMHO. I.E remove the initial steep learning curve so I don't hear "that's doing my head in" or "mind blowing" etc from users :-)

Its not knocking all the hard work developers do (thank you) but maybe the direction/priorities and remembering most users are not (and should not need to be) IT savvy developers :-)

Of course if all the manufactures got together and had a OS Independent standard message protocol that would be a hallelujah moment (wont happen) . :-)

I will now get back under my stone and wait for the flack - LOL


Clive Stachon replied to the topic 'Anyone been able to get PyIndi to install on Windows 10' in the forum. 3 weeks ago

Hadn't seen that - thanks I will read the details. :-)


Clive Stachon replied to the topic 'Raspberry Pi 3b+ INDI server not installing with Raspbian' in the forum. 4 weeks ago

I think you are being grossly unfair Mike the RPI3B+ has been out less than a year and has changed the boot load process - Note RPI Charity had a head start as they knew what was coming but they still had a number of problem - over heating,duff memory etc. Ubuntu Mate playing catch up is the problem no Indi.

FYI Downloading and running Ubuntu 16.04 from Berryboot gives you a working system from the start ,on a RPI3b+,you can then just use the std instructions for Indi installation on Ubuntu Mate - a short and painless exercise - if that is what you want . Else use Radeks Astroberry which comes with everything and more - ready to go - remember he does this for free in his own time.

You could shell out $$ and buy Stellarmate which also runs on RPI3b+.

Where in Windows does Astro software come fully loaded ?

Ok Indi is not all a bed of roses and I am the first to admit there are parts I still prefer on Windows but it s ok as many here will testify.

Question is why do you want Raspbian ?

Clear Skies :-)


Clive Stachon replied to the topic 'well this has put the cat amongst the pidgeons - if it works' in the forum. 4 weeks ago

:ohmy: Mr Ascom - honoured we are :-)

Its funny you saying about UDP as Sky Watcher uses UDP for their connections to the mount from Synscan App and it works.

The UDP problem is lakin to the RS232 hand shaking options DTR/DTS,xon/xoff etc - they were there when hardware was slow and unreliable now things have changed we nearly all just use tx,rx and Gnd. Personally I think "they" were wrong are you were right , UDP would have worked well - but thats "water under bridge".

I guess people get to emotionally tied to their "baby".

IMHO Ascom Alpaca could be a way forward in joining the best from each world as it seems easier to interact with and all we need ,LOL, is a simple translation bridge,
I say this as neither Indi or Ascom will ,in my view, adopt each others protocol's.


Clive Stachon replied to the topic 'well this has put the cat amongst the pidgeons - if it works' in the forum. 4 weeks ago

Hi ,

This is not the orig paper which i cant find. I never found the wrapper just references to it :-)

link is here


Clive Stachon replied to the topic 'INDI on multiple devices' in the forum. 1 month ago

If you have static IP addresses for your devices then no but if your IP addresses are dynamic (i.e. change as they are allocated by DHCP for example) then its easier to remember and if you use scripts to start Indiserver you will not need to change the scripts every time the IP address changes - hope that helps.:-)


Clive Stachon replied to the topic 'well this has put the cat amongst the pidgeons - if it works' in the forum. 1 month ago

Hi Patrick,

I had tried that DSLR Ascom a while back - didn't work for me with APT :-)

The Disconnection error also occurs when using the Synscan App (windows) with Remote Ascom. Its onl a problem in that it nearly does a deadly embrace and you cannot do anything else.

Love CDC and have been using it for years :-)


Clive Stachon replied to the topic 'well this has put the cat amongst the pidgeons - if it works' in the forum. 1 month ago

Well tried it out between Up Core Windows 10 and a desktop.

I have to say the terminology doesn't make a lot of sense - remote client , server is fine nothing knew but IMHO the set up is confusing and of course still depends on the user knowing IP addresses etc - plus good old Win10 Firewall sticking its nose in.

Anyhow I got it working but of course Ascom doesn't have a DSLR driver but running APT on the UP Core which was on the mount (my good old SWAZ GoTo) together with Synscan App Pro (no handset) and CDC on a desktop it ran for 2hrs no problem. Slewing here and there no problem. Plus APT PlateSolving worked too.

CDC did initially moan something about "Object Instance error" and loops horribly if the mount get disconnected (does that anyway) - but it worked too.

Response time were fine but I wasn't downloading CCD images between the UP Core and the desktop.

So initial impressions - Impressed it worked so well - wish it had a Ascom DSLR driver - set up not for end users. So just need an Indi interface (especially for DSLR) Ekos and your cooking. Obviously its early days and it was a quick test :-)

As the old Canned Heat record said " Come Come lets work together" LOL


Clive Stachon replied to the topic 'well this has put the cat amongst the pidgeons - if it works' in the forum. 1 month ago

Radek -

great minds think alike LOL

At the moment mine isn't for Indi just to use Gphoto2 connected camera from anywhere bu the principle is the same.

IBM wrote a good paper on using MQTT for "serious" Astronomy to share/control data/devices over the world. Biggest plus as I see it is not having to know where the device are. IBM had developed an Ascom wrapper for MQTT but now with Alpaca/Indi maybe it will provide best of all flavours.

Will keep an eye out for your progress !!!!

Good luck


Clive Stachon replied to the topic 'well this has put the cat amongst the pidgeons - if it works' in the forum. 1 month ago

Put MQTT in there and you dont even have know/care where devices are or how may devices are doing the same thing all at the same time - being cheeky sorry :-)