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 !
"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
Hadn't seen that - thanks I will read the details.
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 ?
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.
This is not the orig paper which i cant find. I never found the wrapper just references to it
link is here www.google.co.uk/url?sa=t&rct=j&q=&esrc=...Ap_BkIHh-O3IEgw9Ortk
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.
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
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
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 !!!!
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