Date   

Re: INDI or ASCOM Alpaca?

David
 

Ray,

Honestly, right now INDIGO seems farther along than Alpaca.  Let me be clear Im not a programmer, but from the resources I can see and download, INDIGO seems more developed and has more people working on it right now.


David



Re: INDI or ASCOM Alpaca?

Ron Kramer
 

Dales right - it shouldn't be either or. It should be all.  Also remember asking people who are already using and supported by AP/ASCOM which they want supported is a bit of a loaded question.  Come ask that same question in the INDI forum and you'll get 100% INDI requests.
Alpaca isn't ready yet... it's in the future and will be great.  INDI is years old and quite mature.  The alter also doesn't need AP to pay programmers.  Just share to the programming public the information that the INDI coding donators can use to make the best possible AP drivers. It's a no brainer and AP would want ALL facets supported.



On Sat, Apr 27, 2019 at 5:09 PM Ron Kramer <ronkramer1957@...> wrote:
BOTH - but indi first since many people are using it and Alpaca isn't really ready  yet.  

Here is my config.  I moved my 600 NUC out of the dome and replaced it with a 38.00 PI.  (A big plus when leaving a computer in teh dome 24/7 for years). Cheap swap... I have several PI's sitting around I can swap out. 
All devices (I have everything cloudwatcher, rotator, headers - snapcap, mount, 2 cameras active, 2 focusers, NexDome, rotator and shutter etc.  ALL plugged into the PI.  The PI runs a OS called  Stellarmate. (yes like the 179.00 device).  If you have your own PI, (38.00) you can install the OS (buy from stellarmate) for 49.00).
It includes a small Ubuntu linix and some great utilities as well as the open source (and pheaking amazing) Kstars... ekos combo.  (When I ask for a feature I have it in 3 days)!  SOMETIMES in a hour.,

So again just the cheap PI and all USB's into it.  (most are into a 3.0 powered hub on the scope first) then to the 4 USB ports on the PI.
The stellarmate OS has a server that handles the devices. (I had no problems adding any of my hardware, all were supported).

The PI is not a powerhouse - it isn't the best at running kstars/ekos  (IT CAN) but it's no speed demon.  So - what I do it run the server on the PI.   It connects to my home wifi and I run WINDOWS 10 in the house on one of my desktops (powerful/faster lots of ram).  When I run Kstars/Ekos on the windows machine....  (you could also do this on OSX) or linux box.
It connects to the  PI / INDI drivers in the dome and they interface/communicate.  I have ZERO LAG.   (I also use team viewer sometimes and IT HAS LAG).  Some in comparison (NO LAG).

The windows desktop runs  JUST LIKE ITS CONNECTED TO THE HARDWARE  IN THE DOME.  The PI and INDI drivers in the dome are integrated seamlessly.   The feature set "because the planetarium program (Kstars) IS integrated into everything else it does it all.  I plate solve and that module tells the planetarium program to update and it will auto center on the target you clicked on in Kstars.   Rotator?  you rotate your frame and it rotates to make in the planetarium program.  Click auto focus - and in a few seconds - it's tack sharp. 

What is cool if you can do this from any machine anywhere. You can use a Mac... Linux or windows and the software is open source and ALL FREE.  I used SGP for 2 years and getting them to do ANY tweaks or upgrades was worse than pulling teeth.  I'd had enough. 

A PROBLEM.  So - with a PI in the dome and the PC in the house running all the software.   I ran into a issue when I wanted to go out and tweak something in the dome but I can't see the monitors in the house.  Solution?  I ran team viewer on my ipad and walked out to the dome... I saw focusing (to set my OAG focus I had to nudge the camera or or down) so I was able to nudge in the dome, looking at Kstars/Ekos on my ipad - which was teamviewer'ing from my desktop 100 yards away in the house.   SWEET.

I can also bring my laptop Anywhere on the planet with an internet connection and run kstars/ekos on it and log into the PI indi server and control my setup remotely. 

Everything works GREAT (except I'm having some issues with the Mach1 due to (I'm told) not much support from AP) the programmers (who donate their talents)  need the support from AP on how to control the mount and query it at different times to verify its status.
REALLY don't need INDI support we have it -  WE JUST NEED A LITTLE PARTNERSHIP from AP to share the communications codes.  There are GTO2 and 3 drivers already the new GTO4 is in beta stages due to limited knowledge (openness of the protocols to communicate with the GTO4) 

The indi team of programmers will take the reigns if AP can give them what they need to do the driver properly.  It works as is, but they have to jump through hoops and do workarounds because they're unaware of the proper codes and protocols.

THEN  AP  and concentrate on  Alpaca which will be great - but is following along behind what INDI can already do.  Of course, the big plus with Alpaca is it will run on the most popular platform.   Though Kstars/Ekos runs on Windows  (INDI server and DRIVERS are not on windows yet).  So the server has to be a PI or other linux box. 
The other great thing about the PI is you can strap it to your scope if you travel to dark sights. 

Guys are often asking how they can get away from windows. (if they hate it as much as I do) and also ask often what mount they should get that will be Indi compatible.  Due to GTo4 being "in beta" without much forward progress at this point. (dead end) AP mounts never get suggested. = (
Without such support - I do have given up on considering the Mach2 as my next upgrade.  

I hope this explains things a bit.  If you're on facebook and have interest in INDI I have a new FB group you can search for and join. Else if you want to jump in head first... come over to  INDIlib.ORG and join the forum.  Talk about support. I had a dome issue and the lead team programmer logged into my dome from his home in Kuwait (YES THAT Kuwait) and hot swapped my driver as it wrote the tweaks and was controller my PI server and observatory from the other side of the earth.  (in real time).






On Fri, Apr 26, 2019 at 8:38 PM 'Ray Gralak (Groups)' groups3@... [ap-gto] <ap-gto@...> wrote:
 

Hello all,

Of those users wishing for a non-Windows support for your mount, which platform would you prefer Astro-Physics to devote resources?

INDI or ASCOM Alpaca?

INDI has been around for some time and runs on LINUX and MAC OSX and Windows. ASCOM Alpaca is still in the early stages of development. There are no significant applications that work on LINUX or MACs, and there may not be for some time.

However, ASCOM Alpaca is modular as opposed to INDI's monolithic design. Once drivers are available Alpaca devices can be standalone (over the network or wifi) or on another computer. I believe INDI only works on the computer it is running unless the device has a network interface.

There may be other advantages or disadvantages to INDI or ASCOM Alpaca. Please contribute your knowledge or preferences if you are interested in this topic.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver



--



Tracking Issue

Craig Young
 

Setup: AP1600GTO w/absolute encoders, APCC 1.7.1.1, CP4

Procedure: Downloaded the latest APCC and then created a new 100 point model for the Eastern sky only.  I then slewed the telescope to RA: -3 hours (HA), DEC: observatory latitude so it would pass through the zenith when at the meridian.  I then recorded 60 second images every 5 minutes for one hour.  This gave me 12 images.  Images were then measured using Pinpoint (full version) and UCAC4 catalog.

First Test: model correction disabled, so no tracking adjustments or refraction correction applied.  Over the one hour the drift in RA was -34 arcsec and the DEC drift was -38 arcsec.

Second Test: model correction enabled and refraction checked.  Same test, same location in the sky, in other words I slewed the telescope back to RA -3 hours (HA).  Over the one hour drift the RA was -31 arcsec and DEC drfit was -6 arcsec.  So there was a small change in RA and a good correction in DEC.

It appears there is some sort of problem in RA tracking.  Notice both RA drifts seem to indicate the RA motor is running too fast.  With the encoders this should not happen unless the time base is off or maybe the encoders are not calibrated.  This might also account for why each time a restart APCC on subsequent nights, the pointing shows an increasing drift in RA.  It is as if there is a problem with the internal clock in the firmware or APCC.

In any case, has anyone run into this problem and been able to fix it?  Are there any other diagnostics I could run to try and pinpoint the problem.  The mount is two years old and this RA drift problem has been with the mount since the initial installation.


Craig



Re: INDI or ASCOM Alpaca?

Ron Kramer
 

BOTH - but indi first since many people are using it and Alpaca isn't really ready  yet.  

Here is my config.  I moved my 600 NUC out of the dome and replaced it with a 38.00 PI.  (A big plus when leaving a computer in teh dome 24/7 for years). Cheap swap... I have several PI's sitting around I can swap out. 
All devices (I have everything cloudwatcher, rotator, headers - snapcap, mount, 2 cameras active, 2 focusers, NexDome, rotator and shutter etc.  ALL plugged into the PI.  The PI runs a OS called  Stellarmate. (yes like the 179.00 device).  If you have your own PI, (38.00) you can install the OS (buy from stellarmate) for 49.00).
It includes a small Ubuntu linix and some great utilities as well as the open source (and pheaking amazing) Kstars... ekos combo.  (When I ask for a feature I have it in 3 days)!  SOMETIMES in a hour.,

So again just the cheap PI and all USB's into it.  (most are into a 3.0 powered hub on the scope first) then to the 4 USB ports on the PI.
The stellarmate OS has a server that handles the devices. (I had no problems adding any of my hardware, all were supported).

The PI is not a powerhouse - it isn't the best at running kstars/ekos  (IT CAN) but it's no speed demon.  So - what I do it run the server on the PI.   It connects to my home wifi and I run WINDOWS 10 in the house on one of my desktops (powerful/faster lots of ram).  When I run Kstars/Ekos on the windows machine....  (you could also do this on OSX) or linux box.
It connects to the  PI / INDI drivers in the dome and they interface/communicate.  I have ZERO LAG.   (I also use team viewer sometimes and IT HAS LAG).  Some in comparison (NO LAG).

The windows desktop runs  JUST LIKE ITS CONNECTED TO THE HARDWARE  IN THE DOME.  The PI and INDI drivers in the dome are integrated seamlessly.   The feature set "because the planetarium program (Kstars) IS integrated into everything else it does it all.  I plate solve and that module tells the planetarium program to update and it will auto center on the target you clicked on in Kstars.   Rotator?  you rotate your frame and it rotates to make in the planetarium program.  Click auto focus - and in a few seconds - it's tack sharp. 

What is cool if you can do this from any machine anywhere. You can use a Mac... Linux or windows and the software is open source and ALL FREE.  I used SGP for 2 years and getting them to do ANY tweaks or upgrades was worse than pulling teeth.  I'd had enough. 

A PROBLEM.  So - with a PI in the dome and the PC in the house running all the software.   I ran into a issue when I wanted to go out and tweak something in the dome but I can't see the monitors in the house.  Solution?  I ran team viewer on my ipad and walked out to the dome... I saw focusing (to set my OAG focus I had to nudge the camera or or down) so I was able to nudge in the dome, looking at Kstars/Ekos on my ipad - which was teamviewer'ing from my desktop 100 yards away in the house.   SWEET.

I can also bring my laptop Anywhere on the planet with an internet connection and run kstars/ekos on it and log into the PI indi server and control my setup remotely. 

Everything works GREAT (except I'm having some issues with the Mach1 due to (I'm told) not much support from AP) the programmers (who donate their talents)  need the support from AP on how to control the mount and query it at different times to verify its status.
REALLY don't need INDI support we have it -  WE JUST NEED A LITTLE PARTNERSHIP from AP to share the communications codes.  There are GTO2 and 3 drivers already the new GTO4 is in beta stages due to limited knowledge (openness of the protocols to communicate with the GTO4) 

The indi team of programmers will take the reigns if AP can give them what they need to do the driver properly.  It works as is, but they have to jump through hoops and do workarounds because they're unaware of the proper codes and protocols.

THEN  AP  and concentrate on  Alpaca which will be great - but is following along behind what INDI can already do.  Of course, the big plus with Alpaca is it will run on the most popular platform.   Though Kstars/Ekos runs on Windows  (INDI server and DRIVERS are not on windows yet).  So the server has to be a PI or other linux box. 
The other great thing about the PI is you can strap it to your scope if you travel to dark sights. 

Guys are often asking how they can get away from windows. (if they hate it as much as I do) and also ask often what mount they should get that will be Indi compatible.  Due to GTo4 being "in beta" without much forward progress at this point. (dead end) AP mounts never get suggested. = (
Without such support - I do have given up on considering the Mach2 as my next upgrade.  

I hope this explains things a bit.  If you're on facebook and have interest in INDI I have a new FB group you can search for and join. Else if you want to jump in head first... come over to  INDIlib.ORG and join the forum.  Talk about support. I had a dome issue and the lead team programmer logged into my dome from his home in Kuwait (YES THAT Kuwait) and hot swapped my driver as it wrote the tweaks and was controller my PI server and observatory from the other side of the earth.  (in real time).






On Fri, Apr 26, 2019 at 8:38 PM 'Ray Gralak (Groups)' groups3@... [ap-gto] <ap-gto@...> wrote:
 

Hello all,

Of those users wishing for a non-Windows support for your mount, which platform would you prefer Astro-Physics to devote resources?

INDI or ASCOM Alpaca?

INDI has been around for some time and runs on LINUX and MAC OSX and Windows. ASCOM Alpaca is still in the early stages of development. There are no significant applications that work on LINUX or MACs, and there may not be for some time.

However, ASCOM Alpaca is modular as opposed to INDI's monolithic design. Once drivers are available Alpaca devices can be standalone (over the network or wifi) or on another computer. I believe INDI only works on the computer it is running unless the device has a network interface.

There may be other advantages or disadvantages to INDI or ASCOM Alpaca. Please contribute your knowledge or preferences if you are interested in this topic.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver




Re: INDI or ASCOM Alpaca?

Bill Long
 

There is likely a good middle ground here though where AP can keep their secrets and users safe, and developers can have access to the tools they need to write their own software.


From: ap-gto@... on behalf of 'Ray Gralak (Groups)' groups3@... [ap-gto]
Sent: Saturday, April 27, 2019 12:35 PM
To: ap-gto@...
Subject: RE: [ap-gto] INDI or ASCOM Alpaca?
 
 

> I believe it would be possible to make parts of the protocol required for decent
> operation of the mount available without spilling the secret sauce or undermining
> sales of APCC.

I think you would be very disappointed if you think that having the complete protocol will "spoil the secret sauce" for APCC. Most of what APCC does requires a lot of logic that has nothing to do with the command protocol. Most of the calculations and features of APCC are in APCC, not the mount firmware.

For instance the mount firmware doesn't even have a notion of the park positions. That's all in the software.

That said, a few of the reasons the entire protocol has not been published are:

1) Another vendor once copied much of the command protocol to the point that they could even use the Astro-Physics V2 ASCOM driver until they created their own driver a few years later.

2) Along the same line some of the commands would give hints to other vendors how the encoders and limits and other features work in the firmware.

3) Some of the commands are "dangerous" and should only be used by Astro-Physics to reconfigure the control boxes. Accidental or experimental changes by a user causing their mount to not operate as it should would cause a significant number of support calls.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

> -----Original Message-----
> From: ap-gto@... [mailto:ap-gto@...]
> Sent: Saturday, April 27, 2019 11:48 AM
> To: ap-gto@...
> Subject: Re: [ap-gto] INDI or ASCOM Alpaca?
>
>
>
> 1.
>
> I think this is just good practice to provide documentation for high end devices. This used to be the default but in
> recent years more and more rare.
>
> I imagine most developers would take their chances on having _any_ information compared to the decade+ old
> protocol documentation that currently exists.
>
> Well they would except the protocol documentation doesn't seem to even exist any more - the two links a web
> search turns up:
>
> http://astro-physics.com/tech_support/mounts/protocol-G.pdf
>
> http://astro-physics.com/tech_support/mounts/command_lang.htm
>
> both give 404 errors.
>
> Fortunately I have a copied safely stored away and the date of the document is "Text modified: 07-04-06".
>
> Case in point - sending a "pulse guide" to the mount.
>
> The 'G' level documentation says the command is ':Mnxxx#' where 'n' is the direction and 'xxx' is the duration in
> milleseconds.
>
> For longer pulses you have to do a convoluted sequence for changing the mount move speed to guide, then initiate
> and time a mount move and then terminate the move.
>
> To make it more fun there are apparently no return codes for any of the steps you have to do nor a way to verify the
> mount is at the guide speed before you move it
>
> So on the off chance the change rate command failed you might move the mount for 2500ms at slew speed, for
> example.
>
> Hopefully there has been progress in the protocol design so you can do this with a saner atomic operation.
>
> I found by experimenting my 'V' level CP4 will actually accept up to 9999ms for a guide request but since this is not
> documented I am not going to release code to the public with it coded that way.
>
> I could ask Howard and he could confirm it but that doesn't really help the AP community as now the info is available
> but obfuscated in source code somewhere.
>
> Having adequate and up to date documentation should be the minimum hurdle when producing high end equipment.
> I would venture most low end mounts have better documentation available. I know the Explore Scientific PMC-Eight
> INDI driver I helped with gives documentation for the entire (admitted very simple) protocol API to developers.
>
> I believe it would be possible to make parts of the protocol required for decent operation of the mount available
> without spilling the secret sauce or undermining sales of APCC.
>
> 2.
>
> Here we get into the 'non-Windows' crowd which is statistically a minority across the general public and therefore
> more difficult to make a business case for. I hear rumors that most institutional users of AP mounts are
> predominately non-Windows but I have seen no firm studies to show this. Clearly AP would benefit in knowing this
> info as it could be more relevant to them than say someone who writes general purpose software.
>
> What I think is important is to have a minimum level of support for alternative environments. As long as the
> information is available for tools to be constructed by motivated individuals or business interests to construct a
> solution I don't know that I would expect AP to do more in terms of writing software on these environments.
>
> 3.
>
> I would just be happy with running these apps on alternative OS/architectures. The Raspberry Pi is such an under-
> powered platform I wouldn't waste time trying to get stuff running on it.
>
> I really am not sure developing and writing software for anything other than Windows is a good business case for
> AP. I would never suggest it as unless institutional users are demanding it I don't know demand is great enough.
>
> I suspect there are a large number of technically talented people with AP mount that could make some impressive
> things happen if given enough information. AP just needs to stoke the fire slightly.
>
> 4-6.
>
> I don't really know how to respond about Alpaca because as far as I know it is all theoretical.
>
> I don't personally see myself ever having one machine talk to another at the device control level over a network. It
> is an interesting theoretical possibility with INDI but for imaging I've found it too hindered by network traffic that I just
> run all things locally on a computer dedicated to the mount/camera at the mount.
>
> If Alpaca means 'ASCOM-like' drivers can be written so the source is more cross-platform compatible (you can
> recompile it on another arch) then that sounds like a good step. My understanding is the 'COM' part of ASCOM has
> been a bit of an albatross for awhile now that made this not possible.
>
> Final Thoughts
>
> I will fully admit I'm an outlier for these things. I enjoy developing code for my astro equipment as much as I enjoy
> using the equipment. If the software I have doesn't do it how I'd like it done I change it or write new code to do it.
>
> For this to be possible I just need enough knowledge of what is under the hood so I can tinker.
>
> But I suspect what I want for different reasons would actually help a wide swath of AP users who just want to avoid
> Microsoft in any way possible. That is not just a 'PC/Mac' thing any more - people can have many legitimate
> reasons to not deal with a particular computer vendor these days. I prefer to not get into whether a particular
> solution is 'best' or 'right' - it all comes back to personal choice on the user side and is it a legitimate business case
> on the supplier side.
>
> At least if the documentation is up to snuff the user has a recourse for a solution even if the supplier cannot justify
> constructing the solution from a business viability viewpoint.
>
> I appreciate AP considering the use cases of all users - hopefully we can move towards wider support of some
> fashion.
>
> Michael Fulbright
>
>
> On 4/27/19 1:07 PM, 'Ray Gralak (Groups)' groups3@... [ap-gto] wrote:
>
>
>
>
> So what do people hope will see happen with increased support for Alpaca or INDI?
>
> For example:
>
> 1. Just document the specs and let the LINUX and Mac developers figure it out?
>
> (I think developers may be disappointed with this because most of the cool features in APCC require a lot of
> work that will not be included in command specs and many features don't use any of the undocumented commands)
>
> 2. More MAC and LINUX applications?
>
> 3. Ability to run APCC and other apps on a Raspberry Pi 3 or other small low power computer?
>
> 4. Have the ability from ASCOM applications on Windows to talk to standalone Alpaca devices?
>
> 5. Have the ability from ASCOM applications on Windows to talk to devices on other computers running
> LINUX or Mac/OSX?
>
> 6. Other things?
>
> -Ray Gralak
> Author of APCC (Astro-Physics Command Center): http://www.astro-
> physics.com/index.htm?products/accessories/software/apcc/apcc
> Author of PEMPro V3: https://www.ccdware.com
> Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver
>
> > -----Original Message-----
> > From: ap-gto@... [mailto:ap-gto@...]
> > Sent: Friday, April 26, 2019 8:02 PM
> > To: ap-gto@...
> > Subject: Re: [ap-gto] INDI or ASCOM Alpaca?
> >
> >
> >
> > I agree, Michael, if the mount commands are fully documented, A-P can devote their resources to whatever
> they
> > see fit, and if something new pops up or A-P's choice doesn't fit their needs, then people will be able to
> write the
> > software that does what they need. Making information like that available fosters an environment where
> people can
> > create new innovative solutions. That's good for AP and the users.
> >
> > thomas
> >
> > On 4/27/2019 12:52 AM, Michael Fulbright mike.fulbright@... [ap-gto] wrote:
> >
> >
> >
> >
> > If sources are available for the Alpaca driver it would be a possible option.
> >
> > Alternately I would just prefer adequate documentation to allow users to implement solutions to meet their
> > use cases.
> >
> > Is Alpaca even something that is realistic in the next year or two?
> >
> > Michael Fulbright
> >
> >
> >
> >
> > On 4/26/19 8:38 PM, 'Ray Gralak (Groups)' groups3@... [ap-gto] wrote:
> >
> >
> >
> >
> > Hello all,
> >
> > Of those users wishing for a non-Windows support for your mount, which platform would you prefer
> > Astro-Physics to devote resources?
> >
> > INDI or ASCOM Alpaca?
> >
> > INDI has been around for some time and runs on LINUX and MAC OSX and Windows. ASCOM
> > Alpaca is still in the early stages of development. There are no significant applications that work on LINUX
> or MACs,
> > and there may not be for some time.
> >
> > However, ASCOM Alpaca is modular as opposed to INDI's monolithic design. Once drivers are
> > available Alpaca devices can be standalone (over the network or wifi) or on another computer. I believe
> INDI only
> > works on the computer it is running unless the device has a network interface.
> >
> > There may be other advantages or disadvantages to INDI or ASCOM Alpaca. Please contribute your
> > knowledge or preferences if you are interested in this topic.
> >
> > -Ray Gralak
> > Author of APCC (Astro-Physics Command Center): http://www.astro-
> > physics.com/index.htm?products/accessories/software/apcc/apcc
> > Author of PEMPro V3: https://www.ccdware.com
> > Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver
> >
> >
> >
> >
> >
> >
>
>
>
>
>


Re: INDI or ASCOM Alpaca?

Ignacio Diaz Bobillo
 

Hi everyone,

I have been experimenting with INDI + Ekos + Kstars lately, on my AP1100 CP4, as there already is a (somewhat buggy) driver available. I ran it with Apogee CCDs (Alta and Aspen) & FW, robofocus, and QHY guide cam.

It is quite an impressive and integrated platform, from my point of view, for full end-to-end observatory automation. The suit includes planetarium app with lots of loadable professional DBs (including DSS alla Aladin), a sophisticated sequencer, astrometry plate-solving, auto-guiding, auto-focusing, auto meridian flips, dome control, etc. As with most things Linux/opensource, it is a bit unstable and buggy, but quite matured to the point of being usable. Also, the pace of development/debugging is quite impressive. And not that I haven't had problems with commercial software in the past!

BTW, it has a client/server architecture, so one can run the INDI sever on a small form factor local computer (I ran it on a Raspberry Pi 3B+ attached to the OTA), and have all the observatory hardware driven from there, while controlling/monitoring it from clients (Kstars, Ekos, Astrometry) running on the same LAN (laptop/PC running any OS, android devices, etc). So no need to run remote desktop apps, while keeping low the load on the server.

I would definitely support this effort! And given the comparative stages of development (INDI vs ASCOM Alpaca), I would suggest to start with INDI, and then add Alpaca when the time comes.

The current experimental driver for AP mounts is already quite usable, particularly when connected thru USB (had some issues thru ethernet).

Hope it helps,
Ignacio






Re: INDI or ASCOM Alpaca?

Ray Gralak
 

Having to send a command twice because the
protocol is poorly designed is unfortunate I
understand for older mounts.
It is a workaround to make it extremely reliable. If you are not doing that in your experimental INDI driver, maybe you should if you detect an early version of firmware.

A-P didn't design the original protocol and it has to be supported as there are mounts that still use the protocol. Remember this post is about INDI/Alpaca, so we are talking about supporting all versions of the firmware.

It is simply not that hard to do two commands, one to start and one to stop. BTW, do you also think that separate commands for RA and Dec are wrong too? You almost always want both if you want one of them. But you have to send two commands.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver


-----Original Message-----
From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
Sent: Saturday, April 27, 2019 12:37 PM
To: ap-gto@yahoogroups.com
Subject: Re: [ap-gto] INDI or ASCOM Alpaca?



If newer firmwares support a better command for longer pulse requests then clearly you'd want to use it no? At the
moment that isn't even an option as it isn't documented

Having to send a command twice because the protocol is poorly designed is unfortunate I understand for older
mounts. It is not optimal but what can you do?

I've already set things up so for pre-V level firmwares there is a minimal functional legacy INDI driver. I have no
intention of working on it. It is out there for anyone who wants to contribute..

I understand AP doesn't have this much flexibility although I believe APCC does set a "you have to be this tall to
ride" threshold for firmware level as well. Which only makes sense.

I think you've swerved a bit into a specific example away from the larger picture.

How do you tell with protocol 'G' if the mount has been unparked and initialized?

How do you tell which firmware level the mount has?

How do you set a meridian delay?

Etc.

I've been through all this with the helpful feedback with Howard as there are things you need to do with the mount
you simply can't with the available documentation.

I gave my feedback as you requested Ray.

I'd really be interested in what Astro-Physics has to say.

Michael


On 4/27/19 3:24 PM, 'Ray Gralak (Groups)' groups3@gralak.com [ap-gto] wrote:




Hi Michael,

> Case in point - sending a "pulse guide" to the mount.

Okay, I think I can provide insight into this.

> The 'G' level documentation says the command is ':Mnxxx#' where 'n' is the direction
> and 'xxx' is the duration in milleseconds.

But that's not even the least common denominator. Rev D had no 'xxx'! :-) There are still some control
boxes with that version in use. What's a driver author to do about that? :-)

> For longer pulses you have to do a convoluted sequence for changing the mount move
> speed to guide, then initiate and time a mount move and then terminate the move.

Convoluted? Dictionary Definition: "Extremely complex and difficult to follow".

Here are the steps:

1. Set Guide Speed
2. Start move and timer
3. When timer event occurs, send "stop move" twice.

The above is what the ASCOM driver does for early mounts and long duration moves.

BTW, a "Stop move" is sent twice in case the first stop failed. Pretty simple fail safe, right? It's worked for
many years in the ASCOM driver.

That said, the above logic requires very basic programming skills so I am not sure why you think it is
"convoluted"? Besides Astro-Physics didn't even invent that protocol. It is the generic Meade protocol.

> To make it more fun there are apparently no return codes for any of the steps you have to do nor
> a way to verify the mount is at the guide speed before you move it.

That's why you always change the speed and start the move right after each other. Regarding "no
responses", that's the Meade protocol. But it has worked fine for 20 years.

> So on the off chance the change rate command failed you might move the mount for
> 2500ms at slew speed, for example.

I've not seen evidence of that happening, but you could send the "change rate" command twice. Also, you
can send the change rate command followed by the start move all in one string. This virtually guarantees that if the
rate is not accepted neither will the start of the move.

> Hopefully there has been progress in the protocol design so you can do this with a saner
> atomic operation.

Even if there was a complete redesign of the command protocol you can't expect the thousands of existing
mounts with older control boxes to all upgrade! So, you *still* have to make due with all versions of the protocol.

And even Rev D, with simple start/stop moves, can be made to autoguide well with just a few common
sense rules when sending commands to the mount. Can someone break that? Sure, but if you are the only
driver/software talking to the mount you have control over what is sent so that shouldn't happen.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-
physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

> -----Original Message-----
> From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
> Sent: Saturday, April 27, 2019 11:48 AM
> To: ap-gto@yahoogroups.com
> Subject: Re: [ap-gto] INDI or ASCOM Alpaca?
>
>
>
> 1.
>
> I think this is just good practice to provide documentation for high end devices. This used to be the default
but in
> recent years more and more rare.
>
> I imagine most developers would take their chances on having _any_ information compared to the
decade+ old
> protocol documentation that currently exists.
>
> Well they would except the protocol documentation doesn't seem to even exist any more - the two links a
web
> search turns up:
>
> http://astro-physics.com/tech_support/mounts/protocol-G.pdf
>
> http://astro-physics.com/tech_support/mounts/command_lang.htm
>
> both give 404 errors.
>
> Fortunately I have a copied safely stored away and the date of the document is "Text modified: 07-04-06".
>
> Case in point - sending a "pulse guide" to the mount.
>
> The 'G' level documentation says the command is ':Mnxxx#' where 'n' is the direction and 'xxx' is the
duration in
> milleseconds.
>
> For longer pulses you have to do a convoluted sequence for changing the mount move speed to guide,
then initiate
> and time a mount move and then terminate the move.
>
> To make it more fun there are apparently no return codes for any of the steps you have to do nor a way to
verify the
> mount is at the guide speed before you move it
>
> So on the off chance the change rate command failed you might move the mount for 2500ms at slew
speed, for
> example.
>
> Hopefully there has been progress in the protocol design so you can do this with a saner atomic operation.
>
> I found by experimenting my 'V' level CP4 will actually accept up to 9999ms for a guide request but since
this is not
> documented I am not going to release code to the public with it coded that way.
>
> I could ask Howard and he could confirm it but that doesn't really help the AP community as now the info
is available
> but obfuscated in source code somewhere.
>
> Having adequate and up to date documentation should be the minimum hurdle when producing high end
equipment.
> I would venture most low end mounts have better documentation available. I know the Explore Scientific
PMC-Eight
> INDI driver I helped with gives documentation for the entire (admitted very simple) protocol API to
developers.
>
> I believe it would be possible to make parts of the protocol required for decent operation of the mount
available
> without spilling the secret sauce or undermining sales of APCC.
>
> 2.
>
> Here we get into the 'non-Windows' crowd which is statistically a minority across the general public and
therefore
> more difficult to make a business case for. I hear rumors that most institutional users of AP mounts are
> predominately non-Windows but I have seen no firm studies to show this. Clearly AP would benefit in
knowing this
> info as it could be more relevant to them than say someone who writes general purpose software.
>
> What I think is important is to have a minimum level of support for alternative environments. As long as
the
> information is available for tools to be constructed by motivated individuals or business interests to
construct a
> solution I don't know that I would expect AP to do more in terms of writing software on these
environments.
>
> 3.
>
> I would just be happy with running these apps on alternative OS/architectures. The Raspberry Pi is such
an under-
> powered platform I wouldn't waste time trying to get stuff running on it.
>
> I really am not sure developing and writing software for anything other than Windows is a good business
case for
> AP. I would never suggest it as unless institutional users are demanding it I don't know demand is great
enough.
>
> I suspect there are a large number of technically talented people with AP mount that could make some
impressive
> things happen if given enough information. AP just needs to stoke the fire slightly.
>
> 4-6.
>
> I don't really know how to respond about Alpaca because as far as I know it is all theoretical.
>
> I don't personally see myself ever having one machine talk to another at the device control level over a
network. It
> is an interesting theoretical possibility with INDI but for imaging I've found it too hindered by network traffic
that I just
> run all things locally on a computer dedicated to the mount/camera at the mount.
>
> If Alpaca means 'ASCOM-like' drivers can be written so the source is more cross-platform compatible (you
can
> recompile it on another arch) then that sounds like a good step. My understanding is the 'COM' part of
ASCOM has
> been a bit of an albatross for awhile now that made this not possible.
>
> Final Thoughts
>
> I will fully admit I'm an outlier for these things. I enjoy developing code for my astro equipment as much as
I enjoy
> using the equipment. If the software I have doesn't do it how I'd like it done I change it or write new code
to do it.
>
> For this to be possible I just need enough knowledge of what is under the hood so I can tinker.
>
> But I suspect what I want for different reasons would actually help a wide swath of AP users who just want
to avoid
> Microsoft in any way possible. That is not just a 'PC/Mac' thing any more - people can have many
legitimate
> reasons to not deal with a particular computer vendor these days. I prefer to not get into whether a
particular
> solution is 'best' or 'right' - it all comes back to personal choice on the user side and is it a legitimate
business case
> on the supplier side.
>
> At least if the documentation is up to snuff the user has a recourse for a solution even if the supplier
cannot justify
> constructing the solution from a business viability viewpoint.
>
> I appreciate AP considering the use cases of all users - hopefully we can move towards wider support of
some
> fashion.
>
> Michael Fulbright
>
>
> On 4/27/19 1:07 PM, 'Ray Gralak (Groups)' groups3@gralak.com [ap-gto] wrote:
>
>
>
>
> So what do people hope will see happen with increased support for Alpaca or INDI?
>
> For example:
>
> 1. Just document the specs and let the LINUX and Mac developers figure it out?
>
> (I think developers may be disappointed with this because most of the cool features in APCC require a lot
of
> work that will not be included in command specs and many features don't use any of the undocumented
commands)
>
> 2. More MAC and LINUX applications?
>
> 3. Ability to run APCC and other apps on a Raspberry Pi 3 or other small low power computer?
>
> 4. Have the ability from ASCOM applications on Windows to talk to standalone Alpaca devices?
>
> 5. Have the ability from ASCOM applications on Windows to talk to devices on other computers running
> LINUX or Mac/OSX?
>
> 6. Other things?
>
> -Ray Gralak
> Author of APCC (Astro-Physics Command Center): http://www.astro-
> physics.com/index.htm?products/accessories/software/apcc/apcc
> Author of PEMPro V3: https://www.ccdware.com
> Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver
>
> > -----Original Message-----
> > From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
> > Sent: Friday, April 26, 2019 8:02 PM
> > To: ap-gto@yahoogroups.com
> > Subject: Re: [ap-gto] INDI or ASCOM Alpaca?
> >
> >
> >
> > I agree, Michael, if the mount commands are fully documented, A-P can devote their resources to
whatever
> they
> > see fit, and if something new pops up or A-P's choice doesn't fit their needs, then people will be able to
> write the
> > software that does what they need. Making information like that available fosters an environment where
> people can
> > create new innovative solutions. That's good for AP and the users.
> >
> > thomas
> >
> > On 4/27/2019 12:52 AM, Michael Fulbright mike.fulbright@pobox.com [ap-gto] wrote:
> >
> >
> >
> >
> > If sources are available for the Alpaca driver it would be a possible option.
> >
> > Alternately I would just prefer adequate documentation to allow users to implement solutions to meet
their
> > use cases.
> >
> > Is Alpaca even something that is realistic in the next year or two?
> >
> > Michael Fulbright
> >
> >
> >
> >
> > On 4/26/19 8:38 PM, 'Ray Gralak (Groups)' groups3@gralak.com [ap-gto] wrote:
> >
> >
> >
> >
> > Hello all,
> >
> > Of those users wishing for a non-Windows support for your mount, which platform would you prefer
> > Astro-Physics to devote resources?
> >
> > INDI or ASCOM Alpaca?
> >
> > INDI has been around for some time and runs on LINUX and MAC OSX and Windows. ASCOM
> > Alpaca is still in the early stages of development. There are no significant applications that work on
LINUX
> or MACs,
> > and there may not be for some time.
> >
> > However, ASCOM Alpaca is modular as opposed to INDI's monolithic design. Once drivers are
> > available Alpaca devices can be standalone (over the network or wifi) or on another computer. I believe
> INDI only
> > works on the computer it is running unless the device has a network interface.
> >
> > There may be other advantages or disadvantages to INDI or ASCOM Alpaca. Please contribute your
> > knowledge or preferences if you are interested in this topic.
> >
> > -Ray Gralak
> > Author of APCC (Astro-Physics Command Center): http://www.astro-
> > physics.com/index.htm?products/accessories/software/apcc/apcc
> > Author of PEMPro V3: https://www.ccdware.com
> > Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver
> >
> >
> >
> >
> >
> >
>
>
>
>
>





Re: INDI or ASCOM Alpaca?

Michael Fulbright <mike.fulbright@...>
 

I have never suggested anything approaching the entire protocol.

Of course there are commands which have specialized use which you don't release to end users.

I think it is indisputable that there are reasonable operations one would want to take with their modern AP mount which are not covered adequately in the 'G' document.

Michael Fulbright

On 4/27/19 3:35 PM, 'Ray Gralak (Groups)' groups3@... [ap-gto] wrote:
 

> I believe it would be possible to make parts of the protocol required for decent
> operation of the mount available without spilling the secret sauce or undermining
> sales of APCC.

I think you would be very disappointed if you think that having the complete protocol will "spoil the secret sauce" for APCC. Most of what APCC does requires a lot of logic that has nothing to do with the command protocol. Most of the calculations and features of APCC are in APCC, not the mount firmware.

For instance the mount firmware doesn't even have a notion of the park positions. That's all in the software.

That said, a few of the reasons the entire protocol has not been published are:

1) Another vendor once copied much of the command protocol to the point that they could even use the Astro-Physics V2 ASCOM driver until they created their own driver a few years later.

2) Along the same line some of the commands would give hints to other vendors how the encoders and limits and other features work in the firmware.

3) Some of the commands are "dangerous" and should only be used by Astro-Physics to reconfigure the control boxes. Accidental or experimental changes by a user causing their mount to not operate as it should would cause a significant number of support calls.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

> -----Original Message-----
> From: ap-gto@... [mailto:ap-gto@...]
> Sent: Saturday, April 27, 2019 11:48 AM
> To: ap-gto@...
> Subject: Re: [ap-gto] INDI or ASCOM Alpaca?
>
>
>
> 1.
>
> I think this is just good practice to provide documentation for high end devices. This used to be the default but in
> recent years more and more rare.
>
> I imagine most developers would take their chances on having _any_ information compared to the decade+ old
> protocol documentation that currently exists.
>
> Well they would except the protocol documentation doesn't seem to even exist any more - the two links a web
> search turns up:
>
> http://astro-physics.com/tech_support/mounts/protocol-G.pdf
>
> http://astro-physics.com/tech_support/mounts/command_lang.htm
>
> both give 404 errors.
>
> Fortunately I have a copied safely stored away and the date of the document is "Text modified: 07-04-06".
>
> Case in point - sending a "pulse guide" to the mount.
>
> The 'G' level documentation says the command is ':Mnxxx#' where 'n' is the direction and 'xxx' is the duration in
> milleseconds.
>
> For longer pulses you have to do a convoluted sequence for changing the mount move speed to guide, then initiate
> and time a mount move and then terminate the move.
>
> To make it more fun there are apparently no return codes for any of the steps you have to do nor a way to verify the
> mount is at the guide speed before you move it
>
> So on the off chance the change rate command failed you might move the mount for 2500ms at slew speed, for
> example.
>
> Hopefully there has been progress in the protocol design so you can do this with a saner atomic operation.
>
> I found by experimenting my 'V' level CP4 will actually accept up to 9999ms for a guide request but since this is not
> documented I am not going to release code to the public with it coded that way.
>
> I could ask Howard and he could confirm it but that doesn't really help the AP community as now the info is available
> but obfuscated in source code somewhere.
>
> Having adequate and up to date documentation should be the minimum hurdle when producing high end equipment.
> I would venture most low end mounts have better documentation available. I know the Explore Scientific PMC-Eight
> INDI driver I helped with gives documentation for the entire (admitted very simple) protocol API to developers.
>
> I believe it would be possible to make parts of the protocol required for decent operation of the mount available
> without spilling the secret sauce or undermining sales of APCC.
>
> 2.
>
> Here we get into the 'non-Windows' crowd which is statistically a minority across the general public and therefore
> more difficult to make a business case for. I hear rumors that most institutional users of AP mounts are
> predominately non-Windows but I have seen no firm studies to show this. Clearly AP would benefit in knowing this
> info as it could be more relevant to them than say someone who writes general purpose software.
>
> What I think is important is to have a minimum level of support for alternative environments. As long as the
> information is available for tools to be constructed by motivated individuals or business interests to construct a
> solution I don't know that I would expect AP to do more in terms of writing software on these environments.
>
> 3.
>
> I would just be happy with running these apps on alternative OS/architectures. The Raspberry Pi is such an under-
> powered platform I wouldn't waste time trying to get stuff running on it.
>
> I really am not sure developing and writing software for anything other than Windows is a good business case for
> AP. I would never suggest it as unless institutional users are demanding it I don't know demand is great enough.
>
> I suspect there are a large number of technically talented people with AP mount that could make some impressive
> things happen if given enough information. AP just needs to stoke the fire slightly.
>
> 4-6.
>
> I don't really know how to respond about Alpaca because as far as I know it is all theoretical.
>
> I don't personally see myself ever having one machine talk to another at the device control level over a network. It
> is an interesting theoretical possibility with INDI but for imaging I've found it too hindered by network traffic that I just
> run all things locally on a computer dedicated to the mount/camera at the mount.
>
> If Alpaca means 'ASCOM-like' drivers can be written so the source is more cross-platform compatible (you can
> recompile it on another arch) then that sounds like a good step. My understanding is the 'COM' part of ASCOM has
> been a bit of an albatross for awhile now that made this not possible.
>
> Final Thoughts
>
> I will fully admit I'm an outlier for these things. I enjoy developing code for my astro equipment as much as I enjoy
> using the equipment. If the software I have doesn't do it how I'd like it done I change it or write new code to do it.
>
> For this to be possible I just need enough knowledge of what is under the hood so I can tinker.
>
> But I suspect what I want for different reasons would actually help a wide swath of AP users who just want to avoid
> Microsoft in any way possible. That is not just a 'PC/Mac' thing any more - people can have many legitimate
> reasons to not deal with a particular computer vendor these days. I prefer to not get into whether a particular
> solution is 'best' or 'right' - it all comes back to personal choice on the user side and is it a legitimate business case
> on the supplier side.
>
> At least if the documentation is up to snuff the user has a recourse for a solution even if the supplier cannot justify
> constructing the solution from a business viability viewpoint.
>
> I appreciate AP considering the use cases of all users - hopefully we can move towards wider support of some
> fashion.
>
> Michael Fulbright
>
>
> On 4/27/19 1:07 PM, 'Ray Gralak (Groups)' groups3@... [ap-gto] wrote:
>
>
>
>
> So what do people hope will see happen with increased support for Alpaca or INDI?
>
> For example:
>
> 1. Just document the specs and let the LINUX and Mac developers figure it out?
>
> (I think developers may be disappointed with this because most of the cool features in APCC require a lot of
> work that will not be included in command specs and many features don't use any of the undocumented commands)
>
> 2. More MAC and LINUX applications?
>
> 3. Ability to run APCC and other apps on a Raspberry Pi 3 or other small low power computer?
>
> 4. Have the ability from ASCOM applications on Windows to talk to standalone Alpaca devices?
>
> 5. Have the ability from ASCOM applications on Windows to talk to devices on other computers running
> LINUX or Mac/OSX?
>
> 6. Other things?
>
> -Ray Gralak
> Author of APCC (Astro-Physics Command Center): http://www.astro-
> physics.com/index.htm?products/accessories/software/apcc/apcc
> Author of PEMPro V3: https://www.ccdware.com
> Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver
>
> > -----Original Message-----
> > From: ap-gto@... [mailto:ap-gto@...]
> > Sent: Friday, April 26, 2019 8:02 PM
> > To: ap-gto@...
> > Subject: Re: [ap-gto] INDI or ASCOM Alpaca?
> >
> >
> >
> > I agree, Michael, if the mount commands are fully documented, A-P can devote their resources to whatever
> they
> > see fit, and if something new pops up or A-P's choice doesn't fit their needs, then people will be able to
> write the
> > software that does what they need. Making information like that available fosters an environment where
> people can
> > create new innovative solutions. That's good for AP and the users.
> >
> > thomas
> >
> > On 4/27/2019 12:52 AM, Michael Fulbright mike.fulbright@... [ap-gto] wrote:
> >
> >
> >
> >
> > If sources are available for the Alpaca driver it would be a possible option.
> >
> > Alternately I would just prefer adequate documentation to allow users to implement solutions to meet their
> > use cases.
> >
> > Is Alpaca even something that is realistic in the next year or two?
> >
> > Michael Fulbright
> >
> >
> >
> >
> > On 4/26/19 8:38 PM, 'Ray Gralak (Groups)' groups3@... [ap-gto] wrote:
> >
> >
> >
> >
> > Hello all,
> >
> > Of those users wishing for a non-Windows support for your mount, which platform would you prefer
> > Astro-Physics to devote resources?
> >
> > INDI or ASCOM Alpaca?
> >
> > INDI has been around for some time and runs on LINUX and MAC OSX and Windows. ASCOM
> > Alpaca is still in the early stages of development. There are no significant applications that work on LINUX
> or MACs,
> > and there may not be for some time.
> >
> > However, ASCOM Alpaca is modular as opposed to INDI's monolithic design. Once drivers are
> > available Alpaca devices can be standalone (over the network or wifi) or on another computer. I believe
> INDI only
> > works on the computer it is running unless the device has a network interface.
> >
> > There may be other advantages or disadvantages to INDI or ASCOM Alpaca. Please contribute your
> > knowledge or preferences if you are interested in this topic.
> >
> > -Ray Gralak
> > Author of APCC (Astro-Physics Command Center): http://www.astro-
> > physics.com/index.htm?products/accessories/software/apcc/apcc
> > Author of PEMPro V3: https://www.ccdware.com
> > Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver
> >
> >
> >
> >
> >
> >
>
>
>
>
>



Re: INDI or ASCOM Alpaca?

Michael Fulbright <mike.fulbright@...>
 

If newer firmwares support a better command for longer pulse requests then clearly you'd want to use it no?  At the moment that isn't even an option as it isn't documented

Having to send a command twice because the protocol is poorly designed is unfortunate I understand for older mounts.  It is not optimal but what can you do?

I've already set things up so for pre-V level firmwares there is a minimal functional legacy INDI driver.  I have no intention of working on it.  It is out there for anyone who wants to contribute. 

I understand AP doesn't have this much flexibility although I believe APCC does set a "you have to be this tall to ride" threshold for firmware level as well.  Which only makes sense.

I think you've swerved a bit into a specific example away from the larger picture.

How do you tell with protocol 'G' if the mount has been unparked and initialized?

How do you tell which firmware level the mount has?

How do you set a meridian delay?

Etc.

I've been through all this with the helpful feedback with Howard as there are things you need to do with the mount you simply can't with the available documentation.

I gave my feedback as you requested Ray. 

I'd really be interested in what Astro-Physics has to say.

Michael

On 4/27/19 3:24 PM, 'Ray Gralak (Groups)' groups3@... [ap-gto] wrote:
 

Hi Michael,

> Case in point - sending a "pulse guide" to the mount.

Okay, I think I can provide insight into this.

> The 'G' level documentation says the command is ':Mnxxx#' where 'n' is the direction
> and 'xxx' is the duration in milleseconds.

But that's not even the least common denominator. Rev D had no 'xxx'! :-) There are still some control boxes with that version in use. What's a driver author to do about that? :-)

> For longer pulses you have to do a convoluted sequence for changing the mount move
> speed to guide, then initiate and time a mount move and then terminate the move.

Convoluted? Dictionary Definition: "Extremely complex and difficult to follow".

Here are the steps:

1. Set Guide Speed
2. Start move and timer
3. When timer event occurs, send "stop move" twice.

The above is what the ASCOM driver does for early mounts and long duration moves.

BTW, a "Stop move" is sent twice in case the first stop failed. Pretty simple fail safe, right? It's worked for many years in the ASCOM driver.

That said, the above logic requires very basic programming skills so I am not sure why you think it is "convoluted"? Besides Astro-Physics didn't even invent that protocol. It is the generic Meade protocol.

> To make it more fun there are apparently no return codes for any of the steps you have to do nor
> a way to verify the mount is at the guide speed before you move it.

That's why you always change the speed and start the move right after each other. Regarding "no responses", that's the Meade protocol. But it has worked fine for 20 years.

> So on the off chance the change rate command failed you might move the mount for
> 2500ms at slew speed, for example.

I've not seen evidence of that happening, but you could send the "change rate" command twice. Also, you can send the change rate command followed by the start move all in one string. This virtually guarantees that if the rate is not accepted neither will the start of the move.

> Hopefully there has been progress in the protocol design so you can do this with a saner
> atomic operation.

Even if there was a complete redesign of the command protocol you can't expect the thousands of existing mounts with older control boxes to all upgrade! So, you *still* have to make due with all versions of the protocol.

And even Rev D, with simple start/stop moves, can be made to autoguide well with just a few common sense rules when sending commands to the mount. Can someone break that? Sure, but if you are the only driver/software talking to the mount you have control over what is sent so that shouldn't happen.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

> -----Original Message-----
> From: ap-gto@... [mailto:ap-gto@...]
> Sent: Saturday, April 27, 2019 11:48 AM
> To: ap-gto@...
> Subject: Re: [ap-gto] INDI or ASCOM Alpaca?
>
>
>
> 1.
>
> I think this is just good practice to provide documentation for high end devices. This used to be the default but in
> recent years more and more rare.
>
> I imagine most developers would take their chances on having _any_ information compared to the decade+ old
> protocol documentation that currently exists.
>
> Well they would except the protocol documentation doesn't seem to even exist any more - the two links a web
> search turns up:
>
> http://astro-physics.com/tech_support/mounts/protocol-G.pdf
>
> http://astro-physics.com/tech_support/mounts/command_lang.htm
>
> both give 404 errors.
>
> Fortunately I have a copied safely stored away and the date of the document is "Text modified: 07-04-06".
>
> Case in point - sending a "pulse guide" to the mount.
>
> The 'G' level documentation says the command is ':Mnxxx#' where 'n' is the direction and 'xxx' is the duration in
> milleseconds.
>
> For longer pulses you have to do a convoluted sequence for changing the mount move speed to guide, then initiate
> and time a mount move and then terminate the move.
>
> To make it more fun there are apparently no return codes for any of the steps you have to do nor a way to verify the
> mount is at the guide speed before you move it
>
> So on the off chance the change rate command failed you might move the mount for 2500ms at slew speed, for
> example.
>
> Hopefully there has been progress in the protocol design so you can do this with a saner atomic operation.
>
> I found by experimenting my 'V' level CP4 will actually accept up to 9999ms for a guide request but since this is not
> documented I am not going to release code to the public with it coded that way.
>
> I could ask Howard and he could confirm it but that doesn't really help the AP community as now the info is available
> but obfuscated in source code somewhere.
>
> Having adequate and up to date documentation should be the minimum hurdle when producing high end equipment.
> I would venture most low end mounts have better documentation available. I know the Explore Scientific PMC-Eight
> INDI driver I helped with gives documentation for the entire (admitted very simple) protocol API to developers.
>
> I believe it would be possible to make parts of the protocol required for decent operation of the mount available
> without spilling the secret sauce or undermining sales of APCC.
>
> 2.
>
> Here we get into the 'non-Windows' crowd which is statistically a minority across the general public and therefore
> more difficult to make a business case for. I hear rumors that most institutional users of AP mounts are
> predominately non-Windows but I have seen no firm studies to show this. Clearly AP would benefit in knowing this
> info as it could be more relevant to them than say someone who writes general purpose software.
>
> What I think is important is to have a minimum level of support for alternative environments. As long as the
> information is available for tools to be constructed by motivated individuals or business interests to construct a
> solution I don't know that I would expect AP to do more in terms of writing software on these environments.
>
> 3.
>
> I would just be happy with running these apps on alternative OS/architectures. The Raspberry Pi is such an under-
> powered platform I wouldn't waste time trying to get stuff running on it.
>
> I really am not sure developing and writing software for anything other than Windows is a good business case for
> AP. I would never suggest it as unless institutional users are demanding it I don't know demand is great enough.
>
> I suspect there are a large number of technically talented people with AP mount that could make some impressive
> things happen if given enough information. AP just needs to stoke the fire slightly.
>
> 4-6.
>
> I don't really know how to respond about Alpaca because as far as I know it is all theoretical.
>
> I don't personally see myself ever having one machine talk to another at the device control level over a network. It
> is an interesting theoretical possibility with INDI but for imaging I've found it too hindered by network traffic that I just
> run all things locally on a computer dedicated to the mount/camera at the mount.
>
> If Alpaca means 'ASCOM-like' drivers can be written so the source is more cross-platform compatible (you can
> recompile it on another arch) then that sounds like a good step. My understanding is the 'COM' part of ASCOM has
> been a bit of an albatross for awhile now that made this not possible.
>
> Final Thoughts
>
> I will fully admit I'm an outlier for these things. I enjoy developing code for my astro equipment as much as I enjoy
> using the equipment. If the software I have doesn't do it how I'd like it done I change it or write new code to do it.
>
> For this to be possible I just need enough knowledge of what is under the hood so I can tinker.
>
> But I suspect what I want for different reasons would actually help a wide swath of AP users who just want to avoid
> Microsoft in any way possible. That is not just a 'PC/Mac' thing any more - people can have many legitimate
> reasons to not deal with a particular computer vendor these days. I prefer to not get into whether a particular
> solution is 'best' or 'right' - it all comes back to personal choice on the user side and is it a legitimate business case
> on the supplier side.
>
> At least if the documentation is up to snuff the user has a recourse for a solution even if the supplier cannot justify
> constructing the solution from a business viability viewpoint.
>
> I appreciate AP considering the use cases of all users - hopefully we can move towards wider support of some
> fashion.
>
> Michael Fulbright
>
>
> On 4/27/19 1:07 PM, 'Ray Gralak (Groups)' groups3@... [ap-gto] wrote:
>
>
>
>
> So what do people hope will see happen with increased support for Alpaca or INDI?
>
> For example:
>
> 1. Just document the specs and let the LINUX and Mac developers figure it out?
>
> (I think developers may be disappointed with this because most of the cool features in APCC require a lot of
> work that will not be included in command specs and many features don't use any of the undocumented commands)
>
> 2. More MAC and LINUX applications?
>
> 3. Ability to run APCC and other apps on a Raspberry Pi 3 or other small low power computer?
>
> 4. Have the ability from ASCOM applications on Windows to talk to standalone Alpaca devices?
>
> 5. Have the ability from ASCOM applications on Windows to talk to devices on other computers running
> LINUX or Mac/OSX?
>
> 6. Other things?
>
> -Ray Gralak
> Author of APCC (Astro-Physics Command Center): http://www.astro-
> physics.com/index.htm?products/accessories/software/apcc/apcc
> Author of PEMPro V3: https://www.ccdware.com
> Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver
>
> > -----Original Message-----
> > From: ap-gto@... [mailto:ap-gto@...]
> > Sent: Friday, April 26, 2019 8:02 PM
> > To: ap-gto@...
> > Subject: Re: [ap-gto] INDI or ASCOM Alpaca?
> >
> >
> >
> > I agree, Michael, if the mount commands are fully documented, A-P can devote their resources to whatever
> they
> > see fit, and if something new pops up or A-P's choice doesn't fit their needs, then people will be able to
> write the
> > software that does what they need. Making information like that available fosters an environment where
> people can
> > create new innovative solutions. That's good for AP and the users.
> >
> > thomas
> >
> > On 4/27/2019 12:52 AM, Michael Fulbright mike.fulbright@... [ap-gto] wrote:
> >
> >
> >
> >
> > If sources are available for the Alpaca driver it would be a possible option.
> >
> > Alternately I would just prefer adequate documentation to allow users to implement solutions to meet their
> > use cases.
> >
> > Is Alpaca even something that is realistic in the next year or two?
> >
> > Michael Fulbright
> >
> >
> >
> >
> > On 4/26/19 8:38 PM, 'Ray Gralak (Groups)' groups3@... [ap-gto] wrote:
> >
> >
> >
> >
> > Hello all,
> >
> > Of those users wishing for a non-Windows support for your mount, which platform would you prefer
> > Astro-Physics to devote resources?
> >
> > INDI or ASCOM Alpaca?
> >
> > INDI has been around for some time and runs on LINUX and MAC OSX and Windows. ASCOM
> > Alpaca is still in the early stages of development. There are no significant applications that work on LINUX
> or MACs,
> > and there may not be for some time.
> >
> > However, ASCOM Alpaca is modular as opposed to INDI's monolithic design. Once drivers are
> > available Alpaca devices can be standalone (over the network or wifi) or on another computer. I believe
> INDI only
> > works on the computer it is running unless the device has a network interface.
> >
> > There may be other advantages or disadvantages to INDI or ASCOM Alpaca. Please contribute your
> > knowledge or preferences if you are interested in this topic.
> >
> > -Ray Gralak
> > Author of APCC (Astro-Physics Command Center): http://www.astro-
> > physics.com/index.htm?products/accessories/software/apcc/apcc
> > Author of PEMPro V3: https://www.ccdware.com
> > Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver
> >
> >
> >
> >
> >
> >
>
>
>
>
>



Re: INDI or ASCOM Alpaca?

Ray Gralak
 

I believe it would be possible to make parts of the protocol required for decent
operation of the mount available without spilling the secret sauce or undermining
sales of APCC.
I think you would be very disappointed if you think that having the complete protocol will "spoil the secret sauce" for APCC. Most of what APCC does requires a lot of logic that has nothing to do with the command protocol. Most of the calculations and features of APCC are in APCC, not the mount firmware.

For instance the mount firmware doesn't even have a notion of the park positions. That's all in the software.

That said, a few of the reasons the entire protocol has not been published are:

1) Another vendor once copied much of the command protocol to the point that they could even use the Astro-Physics V2 ASCOM driver until they created their own driver a few years later.

2) Along the same line some of the commands would give hints to other vendors how the encoders and limits and other features work in the firmware.

3) Some of the commands are "dangerous" and should only be used by Astro-Physics to reconfigure the control boxes. Accidental or experimental changes by a user causing their mount to not operate as it should would cause a significant number of support calls.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver


-----Original Message-----
From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
Sent: Saturday, April 27, 2019 11:48 AM
To: ap-gto@yahoogroups.com
Subject: Re: [ap-gto] INDI or ASCOM Alpaca?



1.

I think this is just good practice to provide documentation for high end devices. This used to be the default but in
recent years more and more rare.

I imagine most developers would take their chances on having _any_ information compared to the decade+ old
protocol documentation that currently exists.

Well they would except the protocol documentation doesn't seem to even exist any more - the two links a web
search turns up:

http://astro-physics.com/tech_support/mounts/protocol-G.pdf

http://astro-physics.com/tech_support/mounts/command_lang.htm

both give 404 errors.

Fortunately I have a copied safely stored away and the date of the document is "Text modified: 07-04-06".

Case in point - sending a "pulse guide" to the mount.

The 'G' level documentation says the command is ':Mnxxx#' where 'n' is the direction and 'xxx' is the duration in
milleseconds.

For longer pulses you have to do a convoluted sequence for changing the mount move speed to guide, then initiate
and time a mount move and then terminate the move.

To make it more fun there are apparently no return codes for any of the steps you have to do nor a way to verify the
mount is at the guide speed before you move it

So on the off chance the change rate command failed you might move the mount for 2500ms at slew speed, for
example.

Hopefully there has been progress in the protocol design so you can do this with a saner atomic operation.

I found by experimenting my 'V' level CP4 will actually accept up to 9999ms for a guide request but since this is not
documented I am not going to release code to the public with it coded that way.

I could ask Howard and he could confirm it but that doesn't really help the AP community as now the info is available
but obfuscated in source code somewhere.

Having adequate and up to date documentation should be the minimum hurdle when producing high end equipment.
I would venture most low end mounts have better documentation available. I know the Explore Scientific PMC-Eight
INDI driver I helped with gives documentation for the entire (admitted very simple) protocol API to developers.

I believe it would be possible to make parts of the protocol required for decent operation of the mount available
without spilling the secret sauce or undermining sales of APCC.

2.

Here we get into the 'non-Windows' crowd which is statistically a minority across the general public and therefore
more difficult to make a business case for. I hear rumors that most institutional users of AP mounts are
predominately non-Windows but I have seen no firm studies to show this. Clearly AP would benefit in knowing this
info as it could be more relevant to them than say someone who writes general purpose software.

What I think is important is to have a minimum level of support for alternative environments. As long as the
information is available for tools to be constructed by motivated individuals or business interests to construct a
solution I don't know that I would expect AP to do more in terms of writing software on these environments.

3.

I would just be happy with running these apps on alternative OS/architectures. The Raspberry Pi is such an under-
powered platform I wouldn't waste time trying to get stuff running on it.

I really am not sure developing and writing software for anything other than Windows is a good business case for
AP. I would never suggest it as unless institutional users are demanding it I don't know demand is great enough.

I suspect there are a large number of technically talented people with AP mount that could make some impressive
things happen if given enough information. AP just needs to stoke the fire slightly.

4-6.

I don't really know how to respond about Alpaca because as far as I know it is all theoretical.

I don't personally see myself ever having one machine talk to another at the device control level over a network. It
is an interesting theoretical possibility with INDI but for imaging I've found it too hindered by network traffic that I just
run all things locally on a computer dedicated to the mount/camera at the mount.

If Alpaca means 'ASCOM-like' drivers can be written so the source is more cross-platform compatible (you can
recompile it on another arch) then that sounds like a good step. My understanding is the 'COM' part of ASCOM has
been a bit of an albatross for awhile now that made this not possible.

Final Thoughts

I will fully admit I'm an outlier for these things. I enjoy developing code for my astro equipment as much as I enjoy
using the equipment. If the software I have doesn't do it how I'd like it done I change it or write new code to do it.

For this to be possible I just need enough knowledge of what is under the hood so I can tinker.

But I suspect what I want for different reasons would actually help a wide swath of AP users who just want to avoid
Microsoft in any way possible. That is not just a 'PC/Mac' thing any more - people can have many legitimate
reasons to not deal with a particular computer vendor these days. I prefer to not get into whether a particular
solution is 'best' or 'right' - it all comes back to personal choice on the user side and is it a legitimate business case
on the supplier side.

At least if the documentation is up to snuff the user has a recourse for a solution even if the supplier cannot justify
constructing the solution from a business viability viewpoint.

I appreciate AP considering the use cases of all users - hopefully we can move towards wider support of some
fashion.

Michael Fulbright


On 4/27/19 1:07 PM, 'Ray Gralak (Groups)' groups3@gralak.com [ap-gto] wrote:




So what do people hope will see happen with increased support for Alpaca or INDI?

For example:

1. Just document the specs and let the LINUX and Mac developers figure it out?

(I think developers may be disappointed with this because most of the cool features in APCC require a lot of
work that will not be included in command specs and many features don't use any of the undocumented commands)

2. More MAC and LINUX applications?

3. Ability to run APCC and other apps on a Raspberry Pi 3 or other small low power computer?

4. Have the ability from ASCOM applications on Windows to talk to standalone Alpaca devices?

5. Have the ability from ASCOM applications on Windows to talk to devices on other computers running
LINUX or Mac/OSX?

6. Other things?

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-
physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

> -----Original Message-----
> From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
> Sent: Friday, April 26, 2019 8:02 PM
> To: ap-gto@yahoogroups.com
> Subject: Re: [ap-gto] INDI or ASCOM Alpaca?
>
>
>
> I agree, Michael, if the mount commands are fully documented, A-P can devote their resources to whatever
they
> see fit, and if something new pops up or A-P's choice doesn't fit their needs, then people will be able to
write the
> software that does what they need. Making information like that available fosters an environment where
people can
> create new innovative solutions. That's good for AP and the users.
>
> thomas
>
> On 4/27/2019 12:52 AM, Michael Fulbright mike.fulbright@pobox.com [ap-gto] wrote:
>
>
>
>
> If sources are available for the Alpaca driver it would be a possible option.
>
> Alternately I would just prefer adequate documentation to allow users to implement solutions to meet their
> use cases.
>
> Is Alpaca even something that is realistic in the next year or two?
>
> Michael Fulbright
>
>
>
>
> On 4/26/19 8:38 PM, 'Ray Gralak (Groups)' groups3@gralak.com [ap-gto] wrote:
>
>
>
>
> Hello all,
>
> Of those users wishing for a non-Windows support for your mount, which platform would you prefer
> Astro-Physics to devote resources?
>
> INDI or ASCOM Alpaca?
>
> INDI has been around for some time and runs on LINUX and MAC OSX and Windows. ASCOM
> Alpaca is still in the early stages of development. There are no significant applications that work on LINUX
or MACs,
> and there may not be for some time.
>
> However, ASCOM Alpaca is modular as opposed to INDI's monolithic design. Once drivers are
> available Alpaca devices can be standalone (over the network or wifi) or on another computer. I believe
INDI only
> works on the computer it is running unless the device has a network interface.
>
> There may be other advantages or disadvantages to INDI or ASCOM Alpaca. Please contribute your
> knowledge or preferences if you are interested in this topic.
>
> -Ray Gralak
> Author of APCC (Astro-Physics Command Center): http://www.astro-
> physics.com/index.htm?products/accessories/software/apcc/apcc
> Author of PEMPro V3: https://www.ccdware.com
> Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver
>
>
>
>
>
>





Re: INDI or ASCOM Alpaca?

Ray Gralak
 

Hi Michael,

Case in point - sending a "pulse guide" to the mount.
Okay, I think I can provide insight into this.

The 'G' level documentation says the command is ':Mnxxx#' where 'n' is the direction
and 'xxx' is the duration in milleseconds.
But that's not even the least common denominator. Rev D had no 'xxx'! :-) There are still some control boxes with that version in use. What's a driver author to do about that? :-)

For longer pulses you have to do a convoluted sequence for changing the mount move
speed to guide, then initiate and time a mount move and then terminate the move.
Convoluted? Dictionary Definition: "Extremely complex and difficult to follow".

Here are the steps:

1. Set Guide Speed
2. Start move and timer
3. When timer event occurs, send "stop move" twice.

The above is what the ASCOM driver does for early mounts and long duration moves.

BTW, a "Stop move" is sent twice in case the first stop failed. Pretty simple fail safe, right? It's worked for many years in the ASCOM driver.

That said, the above logic requires very basic programming skills so I am not sure why you think it is "convoluted"? Besides Astro-Physics didn't even invent that protocol. It is the generic Meade protocol.

To make it more fun there are apparently no return codes for any of the steps you have to do nor
a way to verify the mount is at the guide speed before you move it.
That's why you always change the speed and start the move right after each other. Regarding "no responses", that's the Meade protocol. But it has worked fine for 20 years.

So on the off chance the change rate command failed you might move the mount for
2500ms at slew speed, for example.
I've not seen evidence of that happening, but you could send the "change rate" command twice. Also, you can send the change rate command followed by the start move all in one string. This virtually guarantees that if the rate is not accepted neither will the start of the move.

Hopefully there has been progress in the protocol design so you can do this with a saner
atomic operation.
Even if there was a complete redesign of the command protocol you can't expect the thousands of existing mounts with older control boxes to all upgrade! So, you *still* have to make due with all versions of the protocol.

And even Rev D, with simple start/stop moves, can be made to autoguide well with just a few common sense rules when sending commands to the mount. Can someone break that? Sure, but if you are the only driver/software talking to the mount you have control over what is sent so that shouldn't happen.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver


-----Original Message-----
From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
Sent: Saturday, April 27, 2019 11:48 AM
To: ap-gto@yahoogroups.com
Subject: Re: [ap-gto] INDI or ASCOM Alpaca?



1.

I think this is just good practice to provide documentation for high end devices. This used to be the default but in
recent years more and more rare.

I imagine most developers would take their chances on having _any_ information compared to the decade+ old
protocol documentation that currently exists.

Well they would except the protocol documentation doesn't seem to even exist any more - the two links a web
search turns up:

http://astro-physics.com/tech_support/mounts/protocol-G.pdf

http://astro-physics.com/tech_support/mounts/command_lang.htm

both give 404 errors.

Fortunately I have a copied safely stored away and the date of the document is "Text modified: 07-04-06".

Case in point - sending a "pulse guide" to the mount.

The 'G' level documentation says the command is ':Mnxxx#' where 'n' is the direction and 'xxx' is the duration in
milleseconds.

For longer pulses you have to do a convoluted sequence for changing the mount move speed to guide, then initiate
and time a mount move and then terminate the move.

To make it more fun there are apparently no return codes for any of the steps you have to do nor a way to verify the
mount is at the guide speed before you move it

So on the off chance the change rate command failed you might move the mount for 2500ms at slew speed, for
example.

Hopefully there has been progress in the protocol design so you can do this with a saner atomic operation.

I found by experimenting my 'V' level CP4 will actually accept up to 9999ms for a guide request but since this is not
documented I am not going to release code to the public with it coded that way.

I could ask Howard and he could confirm it but that doesn't really help the AP community as now the info is available
but obfuscated in source code somewhere.

Having adequate and up to date documentation should be the minimum hurdle when producing high end equipment.
I would venture most low end mounts have better documentation available. I know the Explore Scientific PMC-Eight
INDI driver I helped with gives documentation for the entire (admitted very simple) protocol API to developers.

I believe it would be possible to make parts of the protocol required for decent operation of the mount available
without spilling the secret sauce or undermining sales of APCC.

2.

Here we get into the 'non-Windows' crowd which is statistically a minority across the general public and therefore
more difficult to make a business case for. I hear rumors that most institutional users of AP mounts are
predominately non-Windows but I have seen no firm studies to show this. Clearly AP would benefit in knowing this
info as it could be more relevant to them than say someone who writes general purpose software.

What I think is important is to have a minimum level of support for alternative environments. As long as the
information is available for tools to be constructed by motivated individuals or business interests to construct a
solution I don't know that I would expect AP to do more in terms of writing software on these environments.

3.

I would just be happy with running these apps on alternative OS/architectures. The Raspberry Pi is such an under-
powered platform I wouldn't waste time trying to get stuff running on it.

I really am not sure developing and writing software for anything other than Windows is a good business case for
AP. I would never suggest it as unless institutional users are demanding it I don't know demand is great enough.

I suspect there are a large number of technically talented people with AP mount that could make some impressive
things happen if given enough information. AP just needs to stoke the fire slightly.

4-6.

I don't really know how to respond about Alpaca because as far as I know it is all theoretical.

I don't personally see myself ever having one machine talk to another at the device control level over a network. It
is an interesting theoretical possibility with INDI but for imaging I've found it too hindered by network traffic that I just
run all things locally on a computer dedicated to the mount/camera at the mount.

If Alpaca means 'ASCOM-like' drivers can be written so the source is more cross-platform compatible (you can
recompile it on another arch) then that sounds like a good step. My understanding is the 'COM' part of ASCOM has
been a bit of an albatross for awhile now that made this not possible.

Final Thoughts

I will fully admit I'm an outlier for these things. I enjoy developing code for my astro equipment as much as I enjoy
using the equipment. If the software I have doesn't do it how I'd like it done I change it or write new code to do it.

For this to be possible I just need enough knowledge of what is under the hood so I can tinker.

But I suspect what I want for different reasons would actually help a wide swath of AP users who just want to avoid
Microsoft in any way possible. That is not just a 'PC/Mac' thing any more - people can have many legitimate
reasons to not deal with a particular computer vendor these days. I prefer to not get into whether a particular
solution is 'best' or 'right' - it all comes back to personal choice on the user side and is it a legitimate business case
on the supplier side.

At least if the documentation is up to snuff the user has a recourse for a solution even if the supplier cannot justify
constructing the solution from a business viability viewpoint.

I appreciate AP considering the use cases of all users - hopefully we can move towards wider support of some
fashion.

Michael Fulbright


On 4/27/19 1:07 PM, 'Ray Gralak (Groups)' groups3@gralak.com [ap-gto] wrote:




So what do people hope will see happen with increased support for Alpaca or INDI?

For example:

1. Just document the specs and let the LINUX and Mac developers figure it out?

(I think developers may be disappointed with this because most of the cool features in APCC require a lot of
work that will not be included in command specs and many features don't use any of the undocumented commands)

2. More MAC and LINUX applications?

3. Ability to run APCC and other apps on a Raspberry Pi 3 or other small low power computer?

4. Have the ability from ASCOM applications on Windows to talk to standalone Alpaca devices?

5. Have the ability from ASCOM applications on Windows to talk to devices on other computers running
LINUX or Mac/OSX?

6. Other things?

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-
physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

> -----Original Message-----
> From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
> Sent: Friday, April 26, 2019 8:02 PM
> To: ap-gto@yahoogroups.com
> Subject: Re: [ap-gto] INDI or ASCOM Alpaca?
>
>
>
> I agree, Michael, if the mount commands are fully documented, A-P can devote their resources to whatever
they
> see fit, and if something new pops up or A-P's choice doesn't fit their needs, then people will be able to
write the
> software that does what they need. Making information like that available fosters an environment where
people can
> create new innovative solutions. That's good for AP and the users.
>
> thomas
>
> On 4/27/2019 12:52 AM, Michael Fulbright mike.fulbright@pobox.com [ap-gto] wrote:
>
>
>
>
> If sources are available for the Alpaca driver it would be a possible option.
>
> Alternately I would just prefer adequate documentation to allow users to implement solutions to meet their
> use cases.
>
> Is Alpaca even something that is realistic in the next year or two?
>
> Michael Fulbright
>
>
>
>
> On 4/26/19 8:38 PM, 'Ray Gralak (Groups)' groups3@gralak.com [ap-gto] wrote:
>
>
>
>
> Hello all,
>
> Of those users wishing for a non-Windows support for your mount, which platform would you prefer
> Astro-Physics to devote resources?
>
> INDI or ASCOM Alpaca?
>
> INDI has been around for some time and runs on LINUX and MAC OSX and Windows. ASCOM
> Alpaca is still in the early stages of development. There are no significant applications that work on LINUX
or MACs,
> and there may not be for some time.
>
> However, ASCOM Alpaca is modular as opposed to INDI's monolithic design. Once drivers are
> available Alpaca devices can be standalone (over the network or wifi) or on another computer. I believe
INDI only
> works on the computer it is running unless the device has a network interface.
>
> There may be other advantages or disadvantages to INDI or ASCOM Alpaca. Please contribute your
> knowledge or preferences if you are interested in this topic.
>
> -Ray Gralak
> Author of APCC (Astro-Physics Command Center): http://www.astro-
> physics.com/index.htm?products/accessories/software/apcc/apcc
> Author of PEMPro V3: https://www.ccdware.com
> Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver
>
>
>
>
>
>





Re: INDI or ASCOM Alpaca?

Michael Fulbright <mike.fulbright@...>
 

1.

I think this is just good practice to provide documentation for high end devices.  This used to be the default but in recent years more and more rare.

I imagine most developers would take their chances on having _any_ information compared to the decade+ old protocol documentation that currently exists.

Well they would except the protocol documentation doesn't seem to even exist any more - the two links a web search turns up:

        http://astro-physics.com/tech_support/mounts/protocol-G.pdf

        http://astro-physics.com/tech_support/mounts/command_lang.htm

both give 404 errors.

Fortunately I have a copied safely stored away and the date of the document is "Text modified: 07-04-06".

Case in point - sending a "pulse guide" to the mount.

The 'G' level documentation says the command is ':Mnxxx#' where 'n' is the direction and 'xxx' is the duration in milleseconds.

For longer pulses you have to do a convoluted sequence for changing the mount move speed to guide, then initiate and time a mount move and then terminate the move.

To make it more fun there are apparently no return codes for any of the steps you have to do nor a way to verify the mount is at the guide speed before you move it

So on the off chance the change rate command failed you might move the mount for 2500ms at slew speed, for example.

Hopefully there has been progress in the protocol design so you can do this with a saner atomic operation.

I found by experimenting my 'V' level CP4 will actually accept up to 9999ms for a guide request but since this is not documented I am not going to release code to the public with it coded that way.

I could ask Howard and he could confirm it but that doesn't really help the AP community as now the info is available but obfuscated in source code somewhere.

Having adequate and up to date documentation should be the minimum hurdle when producing high end equipment.  I would venture most low end mounts have better documentation available.  I know the Explore Scientific PMC-Eight INDI driver I helped with gives documentation for the entire (admitted very simple) protocol API to developers.

I believe it would be possible to make parts of the protocol required for decent operation of the mount available without spilling the secret sauce or undermining sales of APCC.

2.

Here we get into the 'non-Windows' crowd which is statistically a minority across the general public and therefore more difficult to make a business case for.  I hear rumors that most institutional users of AP mounts are predominately non-Windows but I have seen no firm studies to show this.  Clearly AP would benefit in knowing this info as it could be more relevant to them than say someone who writes general purpose software. 
 
What I think is important is to have a minimum level of support for alternative environments.  As long as the information is available for tools to be constructed by motivated individuals or business interests to construct a solution I don't know that I would expect AP to do more in terms of writing software on these environments.
 
3.

I would just be happy with running these apps on alternative OS/architectures.  The Raspberry Pi is such an under-powered platform I wouldn't waste time trying to get stuff running on it.

I really am not sure developing and writing software for anything other than Windows is a good business case for AP.  I would never suggest it as unless institutional users are demanding it I don't know demand is great enough.

I suspect there are a large number of technically talented people with AP mount that could make some impressive things happen if given enough information.  AP just needs to stoke the fire slightly.

4-6.

I don't really know how to respond about Alpaca because as far as I know it is all theoretical.

I don't personally see myself ever having one machine talk to another at the device control level over a network.  It is an interesting theoretical possibility with INDI but for imaging I've found it too hindered by network traffic that I just run all things locally on a computer dedicated to the mount/camera at the mount.

If Alpaca means 'ASCOM-like' drivers can be written so the source is more cross-platform compatible (you can recompile it on another arch) then that sounds like a good step.  My understanding is the 'COM' part of ASCOM has been a bit of an albatross for awhile now that made this not possible.

Final Thoughts

I will fully admit I'm an outlier for these things.  I enjoy developing code for my astro equipment as much as I enjoy using the equipment.  If the software I have doesn't do it how I'd like it done I change it or write new code to do it.

For this to be possible I just need enough knowledge of what is under the hood so I can tinker.

But I suspect what I want for different reasons would actually help a wide swath of AP users who just want to avoid Microsoft in any way possible.  That is not just a 'PC/Mac' thing any more - people can have many legitimate reasons to not deal with a particular computer vendor these days.  I prefer to not get into whether a particular solution is 'best' or 'right' - it all comes back to personal choice on the user side and is it a legitimate business case on the supplier side.

At least if the documentation is up to snuff the user has a recourse for a solution even if the supplier cannot justify constructing the solution from a business viability viewpoint.

I appreciate AP considering the use cases of all users - hopefully we can move towards wider support of some fashion.

Michael Fulbright

On 4/27/19 1:07 PM, 'Ray Gralak (Groups)' groups3@... [ap-gto] wrote:
 

So what do people hope will see happen with increased support for Alpaca or INDI?

For example:

1. Just document the specs and let the LINUX and Mac developers figure it out?

(I think developers may be disappointed with this because most of the cool features in APCC require a lot of work that will not be included in command specs and many features don't use any of the undocumented commands)

2. More MAC and LINUX applications?

3. Ability to run APCC and other apps on a Raspberry Pi 3 or other small low power computer?

4. Have the ability from ASCOM applications on Windows to talk to standalone Alpaca devices?

5. Have the ability from ASCOM applications on Windows to talk to devices on other computers running LINUX or Mac/OSX?

6. Other things?

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

> -----Original Message-----
> From: ap-gto@... [mailto:ap-gto@...]
> Sent: Friday, April 26, 2019 8:02 PM
> To: ap-gto@...
> Subject: Re: [ap-gto] INDI or ASCOM Alpaca?
>
>
>
> I agree, Michael, if the mount commands are fully documented, A-P can devote their resources to whatever they
> see fit, and if something new pops up or A-P's choice doesn't fit their needs, then people will be able to write the
> software that does what they need. Making information like that available fosters an environment where people can
> create new innovative solutions. That's good for AP and the users.
>
> thomas
>
> On 4/27/2019 12:52 AM, Michael Fulbright mike.fulbright@... [ap-gto] wrote:
>
>
>
>
> If sources are available for the Alpaca driver it would be a possible option.
>
> Alternately I would just prefer adequate documentation to allow users to implement solutions to meet their
> use cases.
>
> Is Alpaca even something that is realistic in the next year or two?
>
> Michael Fulbright
>
>
>
>
> On 4/26/19 8:38 PM, 'Ray Gralak (Groups)' groups3@... [ap-gto] wrote:
>
>
>
>
> Hello all,
>
> Of those users wishing for a non-Windows support for your mount, which platform would you prefer
> Astro-Physics to devote resources?
>
> INDI or ASCOM Alpaca?
>
> INDI has been around for some time and runs on LINUX and MAC OSX and Windows. ASCOM
> Alpaca is still in the early stages of development. There are no significant applications that work on LINUX or MACs,
> and there may not be for some time.
>
> However, ASCOM Alpaca is modular as opposed to INDI's monolithic design. Once drivers are
> available Alpaca devices can be standalone (over the network or wifi) or on another computer. I believe INDI only
> works on the computer it is running unless the device has a network interface.
>
> There may be other advantages or disadvantages to INDI or ASCOM Alpaca. Please contribute your
> knowledge or preferences if you are interested in this topic.
>
> -Ray Gralak
> Author of APCC (Astro-Physics Command Center): http://www.astro-
> physics.com/index.htm?products/accessories/software/apcc/apcc
> Author of PEMPro V3: https://www.ccdware.com
> Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver
>
>
>
>
>
>



New Owner Introduction and Question

Charles Thompson
 

Hi everyone, I was recently fortunate enough to purchase a lightly used AP900 CP2. It appears to have some upgrades including the fork/base and declination motor (maybe). I called Astro-Physics for some information on the mount and they were very helpful.  Any information on things to look for would be greatly appreciated for an instrument of this age. I purchased the AP grease kit so I can regrease and mesh the worms correctly. 

Last night I had the first chance to get the mount out under the stars for the first time!  I only had two problems. The first was when I had the mount slew to an object in the East the mount would point West instead!  I double checked my time zone, location and didn't have North South switch backwards. This was easily fixed with a plate solve and sync to the mount from Sequence Generator Pro but I don't know why it's backwards on the initial go-to.  Also, the guiding was very rough most of the night with PHD2 which I wasnt expecting. Some info on my setup is below. Thanks!

Location Nashville, TN area

*Polar aligned and unpark from level position 4
*AP900 CP2
*Serial to USB to laptop running V2 ASCOM and SGP
*127mm APO refractor
*80mm guidescope
*ASI1600MM Pro imaging camera
*ASI290MM mini guide camera
*HD tripod (for initial testing)

I'm sure there is some information I'm forgetting but wanted to introduce myself to the group and say thank you in advance!



Thanks,
Charles


Re: INDI or ASCOM Alpaca?

Ray Gralak
 

So what do people hope will see happen with increased support for Alpaca or INDI?

For example:

1. Just document the specs and let the LINUX and Mac developers figure it out?

(I think developers may be disappointed with this because most of the cool features in APCC require a lot of work that will not be included in command specs and many features don't use any of the undocumented commands)

2. More MAC and LINUX applications?

3. Ability to run APCC and other apps on a Raspberry Pi 3 or other small low power computer?

4. Have the ability from ASCOM applications on Windows to talk to standalone Alpaca devices?

5. Have the ability from ASCOM applications on Windows to talk to devices on other computers running LINUX or Mac/OSX?

6. Other things?

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

-----Original Message-----
From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
Sent: Friday, April 26, 2019 8:02 PM
To: ap-gto@yahoogroups.com
Subject: Re: [ap-gto] INDI or ASCOM Alpaca?



I agree, Michael, if the mount commands are fully documented, A-P can devote their resources to whatever they
see fit, and if something new pops up or A-P's choice doesn't fit their needs, then people will be able to write the
software that does what they need. Making information like that available fosters an environment where people can
create new innovative solutions. That's good for AP and the users.

thomas

On 4/27/2019 12:52 AM, Michael Fulbright mike.fulbright@pobox.com [ap-gto] wrote:




If sources are available for the Alpaca driver it would be a possible option.

Alternately I would just prefer adequate documentation to allow users to implement solutions to meet their
use cases.

Is Alpaca even something that is realistic in the next year or two?

Michael Fulbright




On 4/26/19 8:38 PM, 'Ray Gralak (Groups)' groups3@gralak.com [ap-gto] wrote:




Hello all,

Of those users wishing for a non-Windows support for your mount, which platform would you prefer
Astro-Physics to devote resources?

INDI or ASCOM Alpaca?

INDI has been around for some time and runs on LINUX and MAC OSX and Windows. ASCOM
Alpaca is still in the early stages of development. There are no significant applications that work on LINUX or MACs,
and there may not be for some time.

However, ASCOM Alpaca is modular as opposed to INDI's monolithic design. Once drivers are
available Alpaca devices can be standalone (over the network or wifi) or on another computer. I believe INDI only
works on the computer it is running unless the device has a network interface.

There may be other advantages or disadvantages to INDI or ASCOM Alpaca. Please contribute your
knowledge or preferences if you are interested in this topic.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-
physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver






Re: re greasing worm wheel on 1100GTO original gearbox.

W Hilmo
 

I actually worked as a baggage handler for an airline for a while, and my father was an airline pilot.

 

I am pretty sure that all of the Boeing and Airbus airplanes are fully pressurized (but not heated), even in the cargo holds.  The reason is that it’s easier structurally to pressurize the entire fuselage (except for areas that cannot be pressurized, like the landing gear bays), than it would be to have pressure bulkheads that isolate the cargo holds from the pressurized area.  For this reason, I would strongly suspect that the same is true for any modern jet aircraft, even from Embraer, Bombardier, etc.

 

As it said, it doesn’t affect your point about shipping grease, but it caught my attention because lots of people believe that the cargo areas are not pressurized, when they actually are.  If they weren’t pressurized, you could pretty much assume that any kinds of liquids in your checked bags (shampoo, toothpaste, etc.) would make one heck of a mess on every flight.

 

From: ap-gto@... [mailto:ap-gto@...]
Sent: Saturday, April 27, 2019 7:56 AM
To: ap-gto@...
Subject: Re: [ap-gto] Re: re greasing worm wheel on 1100GTO original gearbox.

 

 

Hi Wade,

 

    To answer your question, I Googled the question – “Are aircraft cargo holds pressurized? “, and got several answers, about temperature and pressure conditions in cargo. There are two cargo holds - one part right behind the crew cabin,  may indeed be made liveable, for pets, and live (lobsters) restaurant food shipments. The “aft cargo” hold isn’t likely to be – no need for the extra T & P conditioning load for “dead-weight” items. Meanwhile, sometimes “stowaways” survive such high altitude conditions when they stuff themselves into aircraft wheel wells.

 

    As for the “loosely capped” ASG-33 lube grease tubes, I wouldn’t want to risk travelling on a plane, not knowing if a dealer shipped this (Amazon purchase) product in the aft cargo, and whether the high altitude pressure drop causes outgassing and pops the lube cap. There probably are cargo fire extinguishers in there, if it should ignite. (Somewhat, kidding ?)

 

    Anyway, such products being shipped must surely require a signature, declaring that they are not hazardous, but then it is a matter of the shipper’s opinion.

    I’ve probably exhausted the case for lube shipping concerns here and I am confident AP takes the appropriate common sense measures and precautions,  to safely ship its special lube, where possible. So perhaps, we shouldn’t expect the lube product to be made generally available everywhere. Wonder if even the CONUS postal services or truck transports, have any special concerns or restrictions, handling such materials.

 

    As for where potentially combustible petro-chemicals might be “unknowingly” stowed, as cargo or luggage - Hard to predict, but surely hazardous or out-gassing  products wouldn’t share the same pressured and temperature controlled,  animals (liveable) forward cargo area. Here below, are two of the search results:

 

F.Y.I. – Joe

 

*****

are aircraft cargo holds pressurized?

The round shape of the fuselage outline is very efficient at withstanding pressure. Because of that, everything within the fuselage shape is pressurized. This includes the cargo hold below.

Only cargo holds located behind the aft pressure bulkhead would be unpressurized, and these are mainly found in smaller aircraft.Aug 21, 2014

***

Are “luggage compartments” on planes pressurized?

Yes, they are both pressurized and temp controlled, because of some of the "live" cargo they carry (pets, live animals for restaurant menus). Also, some of the larger wide-body aircraft have galley facilities in the cargo hold area that flight attendants have to access during flight.

***


Re: re greasing worm wheel on 1100GTO original gearbox.

Joe Zeglinski
 

Hi Wade,
 
    To answer your question, I Googled the question – “Are aircraft cargo holds pressurized? “, and got several answers, about temperature and pressure conditions in cargo. There are two cargo holds - one part right behind the crew cabin,  may indeed be made liveable, for pets, and live (lobsters) restaurant food shipments. The “aft cargo” hold isn’t likely to be – no need for the extra T & P conditioning load for “dead-weight” items. Meanwhile, sometimes “stowaways” survive such high altitude conditions when they stuff themselves into aircraft wheel wells.
 
    As for the “loosely capped” ASG-33 lube grease tubes, I wouldn’t want to risk travelling on a plane, not knowing if a dealer shipped this (Amazon purchase) product in the aft cargo, and whether the high altitude pressure drop causes outgassing and pops the lube cap. There probably are cargo fire extinguishers in there, if it should ignite. (Somewhat, kidding ?)
 
    Anyway, such products being shipped must surely require a signature, declaring that they are not hazardous, but then it is a matter of the shipper’s opinion.
    I’ve probably exhausted the case for lube shipping concerns here and I am confident AP takes the appropriate common sense measures and precautions,  to safely ship its special lube, where possible. So perhaps, we shouldn’t expect the lube product to be made generally available everywhere. Wonder if even the CONUS postal services or truck transports, have any special concerns or restrictions, handling such materials.
 
    As for where potentially combustible petro-chemicals might be “unknowingly” stowed, as cargo or luggage - Hard to predict, but surely hazardous or out-gassing  products wouldn’t share the same pressured and temperature controlled,  animals (liveable) forward cargo area. Here below, are two of the search results:
 
F.Y.I. – Joe
 
*****
are aircraft cargo holds pressurized?
The round shape of the fuselage outline is very efficient at withstanding pressure. Because of that, everything within the fuselage shape is pressurized. This includes the cargo hold below.
Only cargo holds located behind the aft pressure bulkhead would be unpressurized, and these are mainly found in smaller aircraft.Aug 21, 2014
***
Are “luggage compartments” on planes pressurized?
Yes, they are both pressurized and temp controlled, because of some of the "live" cargo they carry (pets, live animals for restaurant menus). Also, some of the larger wide-body aircraft have galley facilities in the cargo hold area that flight attendants have to access during flight.
***


Re: re greasing worm wheel on 1100GTO original gearbox.

Geert
 

It was sent to me in Belgium without problems whatsoever, it is only a small quantity of grease in a small plastic container.

 

Geert Vdbulcke

 

Van: ap-gto@...
Verzonden: zaterdag 27 april 2019 12:57
Aan: ap-gto@...
Onderwerp: RE: [ap-gto] Re: re greasing worm wheel on 1100GTO original gearbox.

 

 

At the risk of muddying the waters,   I also wonder,  if the “AP Special Mount Grease” formulation is even permitted to be shipped  overseas in air-cargo, given that it is potentially a fire hazard, possibly explosive canister in the high altitude unpressurized airplane cargo hold.

 

I agree that there might be shipping restrictions, and the rest of your points, but I am curious.  Which airplanes do you think have an unpressurized cargo hold?

 


Re: re greasing worm wheel on 1100GTO original gearbox.

Timo Inkinen
 

Well, Google is fine when you use it with site:*.co.uk or site:*.de (and so on) options for limiting the search to such domains only.
Currently unavailable.
We don't know when or if this item will be back in stock.
Derzeit nicht verfügbar.
Ob und wann dieser Artikel wieder vorrätig sein wird, ist unbekannt.

On the other hand you will then find these hits for the AeroShell 33 grease:

It woull also be nice to know, if there's some difference with AeroShell 33 in blue tubes...
Naming is the same for both products so I hope there's no difference in contents, because I have ordered the blue tube grease from Transair.co.uk now:
AeroShell Grease 33 - 400 Gram Cartridge
Code : 2833C

All in all, it's not that easy to pick up a suitable grease for my AP 1200 GTO mount outside US.


Re: re greasing worm wheel on 1100GTO original gearbox.

W Hilmo
 

At the risk of muddying the waters,   I also wonder,  if the “AP Special Mount Grease” formulation is even permitted to be shipped  overseas in air-cargo, given that it is potentially a fire hazard, possibly explosive canister in the high altitude unpressurized airplane cargo hold.

 

I agree that there might be shipping restrictions, and the rest of your points, but I am curious.  Which airplanes do you think have an unpressurized cargo hold?

 


Re: re greasing worm wheel on 1100GTO original gearbox.

Joe Zeglinski
 

Harry,
 
    It should be just fine, even if the AeroShell Grease-33 canister were stale-dated.
After all, the wear & tear on the AP mount’s worm gear isn’t nearly the same as on a jetliner’s massive landing gear retraction and wing flaps mechanisms, for which the grease is normally used.
 
    Let us know if the date on the Amazon-sold tube that finally arrives, actually is out-dated. Wouldn’t want others to go through the hassles of AP mount gearbox  removal etc. for lubrication with less than a perfectly stable grease.
 
    I recently learned a similar “Amazon Quality” lesson, when I bought a large box of hard to find, Full face (small centre hole) AVERY DVD labels. Turned out that the box of labels was VERY old unused stock, from some music company’s shelf, and the labels backing adhesive was out-dated – according to AVERY specs. They didn’t stick well to the media, messed up the Laser printer rollers.
I think there could be a lot of unscrupulous dealers out there, peddling left over junk, and hiding under the guise of Amazon’s presumably good reputation.
Caveat Emptor, as they say.
 
    At the risk of muddying the waters,   I also wonder,  if the “AP Special Mount Grease” formulation is even permitted to be shipped  overseas in air-cargo, given that it is potentially a fire hazard, possibly explosive canister in the high altitude unpressurized airplane cargo hold. Might be limited to only local  “CONUS -  courier truck-shipments”. That may be why the original poster can’t get this AP product in Italy, unless the unique AP formulation is mixed right there, on the AP dealer’s store premises, using locally obtainable “lube component” supplies.
 
    Hopefully, there is a solution.  Otherwise, AeroShell Grease-33 is certainly an AP-recommended, excellent alternative, and a lot easier to source and buy world-wide from a local ... airport supplies  service center.
 
Joe Z.

17361 - 17380 of 82432