Date   

Re: INDI AP driver

Ray Gralak
 

A lot of us don't depend on IDEs - a lot of us aren't even interested in
producing GUI
applications. If I want to make a CLI for a telescope control system, or a
web
interface, or anything like that - I want to be able to do those things
and have a menu
of appropriate languages to choose from to implement these ideas. If that
means PHP
bindings to a INDI client library, then great. If that means Python or Go
bindings to a
client library, then so be it.

I'll repeat it again: The world does not revolve around GUI apps and
Windows
platforms. Your world might, but not everyone subscribes to your view and
there is a
pent-up desire for the ability to operate outside that world.
An IDE isn't just used for developing GUI apps on Windows. Don't you use
Eclipse on LINUX? (I have). There are many other IDE's for LINUX, but they
are not used just to create apps with a GUI. Of course, if you want to use
an editor like vi, then more power to you. I use vi sometimes too. :-)

The INDI project is evident of this. Ever wonder why the progenitors of
INDI didn't
instead put their efforts into ASCOM?
Because it wouldn't have made sense since COM interop doesn't exist on LINUX
and cross-platform .Net didn't exist at the time.

That said, because of .Net Core I think that many of those Microsoft
developers will start targeting LINUX and Mac/OSX. I think this is a good
thing, whether you believe it or not. In fact, .Net Core on LINUX might be
one of the best things that could have happened to LINUX.

Have you looked at the donetcore github PRs and group members and seen who
they
are? Spoiler alert: it's pretty much all Microsoft or dotnet Foundation
employees.

I can't even believe you wrote that. Of course they are! I would think you
would WANT people from Microsoft developing .Net Core, since .Net originated
with Microsoft.

3. How about another *free* software application from Microsoft, "Code".
It
is available for Windows, Mac, and LINUX and supports numerous
languages:

Again, one should not require IDEs to produce code.
I guess one could walk to work instead of driving too. Microsoft Code is
more of an editor on steroids than an IDE. You should check it out, but no
one is stopping you from using vi if that makes you feel more like a real
programmer.

-Ray Gralak
Author of APCC (Astro-Physics Command Center):
http://www.astro-physics.com/index.htm?products/accessories/software/apcc/ap
cc
Author of PEMPro: http://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: http://www.gralak.com/apdriver
Author of PulseGuide: http://www.pulseguide.com
Author of Sigma: http://www.gralak.com/sigma


-----Original Message-----
From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
Sent: Wednesday, February 21, 2018 11:50 AM
To: ap-gto@yahoogroups.com
Subject: Re: [ap-gto] INDI AP driver





On Feb 21, 2018, at 10:21 AM, 'Ray Gralak (Groups)' groups3@gralak.com
[ap-gto]
<ap-gto@yahoogroups.com> wrote:

And this is a perfect example of one of the big reasons why people do
not
wish to get
involuntarily hitched to anything in the Microsoft world.
Dale, I think your anti-Microsoft sentiment is showing. :-)

1. Microsoft is giving out the best IDE in the world for free to most
small
businesses and independent developers/tinkerers. And the Community
edition
is free to universities.
A lot of us don't depend on IDEs - a lot of us aren't even interested in
producing GUI
applications. If I want to make a CLI for a telescope control system, or a
web
interface, or anything like that - I want to be able to do those things
and have a menu
of appropriate languages to choose from to implement these ideas. If that
means PHP
bindings to a INDI client library, then great. If that means Python or Go
bindings to a
client library, then so be it.

I'll repeat it again: The world does not revolve around GUI apps and
Windows
platforms. Your world might, but not everyone subscribes to your view and
there is a
pent-up desire for the ability to operate outside that world.

The INDI project is evident of this. Ever wonder why the progenitors of
INDI didn't
instead put their efforts into ASCOM? It's because of the continued
hang-up ASCOM
has with existing too up-stack, and too insular on its platform would make
it tortuously
inflexible in trying to bring to on others - and there would be real
trade-offs. Obviously,
they determined it was easier to create a new system than to change the
existing one.
The last paragraph of their "Intended Audience" succinctly conveys their
desire:

http://indilib.org/develop/developer-manual/87-intended-audience.html

2. Microsoft has also made .Net open source and a version of it cross
platform It's here whether you like it or not.
Have you looked at the donetcore github PRs and group members and seen who
they
are? Spoiler alert: it's pretty much all Microsoft or dotnet Foundation
employees.

This is what I call "Github Grandstanding". It's when a company
open-sources a
product (or worse, a subset of a complete product) but they don't actually
grant the
opportunity for the greater community to participate in any reviewer,
committer, or
architecture roles - ergo, any meaningful stewardship roles. While the
code is open-
sourced in the most basic definition, it's a Potemkin village - a place
where you can
look, but not touch. At the end of the day, its direction, features, and
capabilities are
deliberated in Redmond, WA conference rooms and not openly. This is
universally
considered to be unhealthy in the long-term for any truly open source
project. This is
what you're proposing to base a portable ASCOM on, with Microsoft's
continued
devotion to their platform being something it depends on into the unseen
future.

3. How about another *free* software application from Microsoft, "Code".
It
is available for Windows, Mac, and LINUX and supports numerous
languages:

Again, one should not require IDEs to produce code.

/dale






Re: INDI AP driver

Michael Fulbright <mike.fulbright@...>
 

Gabe,

  I would say compared to a year ago the current INDI driver is on much better footing that before!  If you have a spare machine or laptop I'd recommend giving it a shot.  You don't need as beefy a machine as Windows requires for a good user experience.

  When I first tried the INDI driver I could unpark and slew around so that was promising.

  But then trying to sync the mount was a problem - it was using the old low precision LX200 commands! 

  So when plate solving and iteratively slewing to a target you were off quite a bit if you expect the typical few arcsecond resolution we achieve in imaging.

  So I started with fixing that problem.

  Then I found others which I have fixed since:

    - the driver didn't properly control  slew rates - FIXED
    - pulse guiding didn't work - FIXED
    - couldn't enable/disable PEM - FIXED
    - Poor control of park positions - FIXED
    - No ability to use meridian delay - FIXED
    - mount initialization was crude and required user intervention each time - FIXED

  Combined with EKOS (kstars imaging module) and PHD2 you have a software solution comparable in many ways to SGP.

  My experience with the INDI developers has been overall positive and they are responsive to suggestions and attending to bug reports.  Much better than most software vendors I deal with!

  The main area I don't have much experience with is unattended automated imaging.  I have moderate light pollution and only image one narrow band filter per night and with my East horizon blocked I just use meridian delay and have the scope run through a sequence without a meridian flip.  My carbon fiber Newtonian rarely needs refocusing (night temps stabilize quickly here) so I usually only refocus manually a couple of times during the night.

   So where I could use some help is for people to test automated runs (while supervising the mount initially at least) and give me feedback.

   To you point about developing software under Linux - that was one of my primary reasons moving to INDI.

   I like writing astroimaging utilities and mostly in Python and I find the environment under Linux much more appealing.

   Using chroot's or containers I can build entire imaging software stacks in a "blob" and have multiple of these stacks on the same machine so I can do several development projects in parallel.  And if I want to setup another machine I just move the blob over and I have my entire imaging environment ready to go.

   The idea of having to duplicate my old Windows imaging stack on a new machine (where you can't just ghost the drive) just gives me the shivers.

   Add in my refusal to ever load Win10 on any machine there just doesn't seem to be much of a software horizon for Windows for me past when Win7 loses maintenance in 2020.   Until Microsoft puts a true opt-out mechanism for their telemetry in their non-Enterprise offerings that is a complete non-starter for me and many people I work with.

    I have no idea how you would run simultaneous parallel software stacks (drivers and software) of different versions for testing under Windows.  Presumably it is possible but under Linux that is a standard practice these days.

Michael Fulbright

On 2/21/2018 12:09 AM, gshaughnessy@... [ap-gto] wrote:


 

Add me to the list of having used Indi, and waiting for better support.  I'm one of those academics that are set in their ways who uses linux and have been a linux user for 15 years.  However, when it came to getting my imaging rig running with reliable automation, I switched for the purposes of imaging and bought a PC stick.  I currently use SGP and APCC on my PC stick things run quite well.  I don't regret doing it since I see the PC stick as another device that is used as a tool.  I did try Indi and Ekos a few years ago when confronted with getting an automated setup and found it to be not yet rock solid.  


That said though, when it does become rock solid, I'll move over in a heartbeat.  Perhaps that time is now.  I've heard it's made great strides recently.  I have a lot more experience in linux and have coded my own sensors and devices that I'd like to poll for sky and environmental conditions.  I know how to do that in linux / python and have the whole project already mapped out.  Doing that in Windows would take too much time and doesn't fit well w/ my expertise.  

Not to get too off-topic, but I might be able to add some perspective to academics preferring linux.  In addition to the security of linux, it's easier when I was starting out to write and compile programs with the gcc/gfortran compilers, which was completely free and available online.  I could be wrong, but I don't recall any well supported and free compilers available under windows.  

Gabe
 


Re: INDI AP driver

Dale Ghent
 

On Feb 21, 2018, at 10:21 AM, 'Ray Gralak (Groups)' groups3@gralak.com [ap-gto] <ap-gto@yahoogroups.com> wrote:

And this is a perfect example of one of the big reasons why people do not
wish to get
involuntarily hitched to anything in the Microsoft world.
Dale, I think your anti-Microsoft sentiment is showing. :-)

1. Microsoft is giving out the best IDE in the world for free to most small
businesses and independent developers/tinkerers. And the Community edition
is free to universities.
A lot of us don't depend on IDEs - a lot of us aren't even interested in producing GUI applications. If I want to make a CLI for a telescope control system, or a web interface, or anything like that - I want to be able to do those things and have a menu of appropriate languages to choose from to implement these ideas. If that means PHP bindings to a INDI client library, then great. If that means Python or Go bindings to a client library, then so be it.

I'll repeat it again: The world does not revolve around GUI apps and Windows platforms. Your world might, but not everyone subscribes to your view and there is a pent-up desire for the ability to operate outside that world.

The INDI project is evident of this. Ever wonder why the progenitors of INDI didn't instead put their efforts into ASCOM? It's because of the continued hang-up ASCOM has with existing too up-stack, and too insular on its platform would make it tortuously inflexible in trying to bring to on others - and there would be real trade-offs. Obviously, they determined it was easier to create a new system than to change the existing one. The last paragraph of their "Intended Audience" succinctly conveys their desire:

http://indilib.org/develop/developer-manual/87-intended-audience.html

2. Microsoft has also made .Net open source and a version of it cross
platform It's here whether you like it or not.
Have you looked at the donetcore github PRs and group members and seen who they are? Spoiler alert: it's pretty much all Microsoft or dotnet Foundation employees.

This is what I call "Github Grandstanding". It's when a company open-sources a product (or worse, a subset of a complete product) but they don't actually grant the opportunity for the greater community to participate in any reviewer, committer, or architecture roles - ergo, any meaningful stewardship roles. While the code is open-sourced in the most basic definition, it's a Potemkin village - a place where you can look, but not touch. At the end of the day, its direction, features, and capabilities are deliberated in Redmond, WA conference rooms and not openly. This is universally considered to be unhealthy in the long-term for any truly open source project. This is what you're proposing to base a portable ASCOM on, with Microsoft's continued devotion to their platform being something it depends on into the unseen future.

3. How about another *free* software application from Microsoft, "Code". It
is available for Windows, Mac, and LINUX and supports numerous languages:
Again, one should not require IDEs to produce code.

/dale


Re: Intersection of the RA and Dec axis on AP 1100 GTO

Mlooker
 

Where the RA and Dec intersect.

For dome geometry you need to be fairly precise so 'anywhere near the middle of the mount' may not cut it.


On 2/20/2018 11:06 PM, dvuolhhr6nx4a532a3phnju3zs6lzvlgxdl2wzaf@... [ap-gto] wrote:
??

I'm trying to set up my Slave settings for dome rotation and it asks to do all the measurements from the "centre of the RA and Dec Axis".


Where would that be on the AP 1100 GTO? Anywhere near the middle of the mount would be fine?




Re: Intersection of the RA and Dec axis on AP 1100 GTO

Roland Christen
 

On our website under technical Support:

http://www.astro-physics.com/tech_support/mounts/latitude-dimension-calc.xls


-----Original Message-----
From: dvuolhhr6nx4a532a3phnju3zs6lzvlgxdl2wzaf@... [ap-gto] To: ap-gto
Sent: Wed, Feb 21, 2018 3:57 am
Subject: [ap-gto] Intersection of the RA and Dec axis on AP 1100 GTO



I'm trying to set up my Slave settings for dome rotation and it asks to do all the measurements from the "centre of the RA and Dec Axis".

Where would that be on the AP 1100 GTO? Anywhere near the middle of the mount would be fine?




Re: INDI AP driver

Michael Fulbright <mike.fulbright@...>
 

I wanted to challenge one recurring idea mentioned in this thread - that
the INDI driver supporting AP mount needs to stabilize.

The current driver (versus when I started around May 2017) is very
stable in my experience.

Since fixing the major problems I found in the existing driver I've
taken 200+ hours of imaging data with it - many times 8+ hours/night. 
I've had no down time due to the driver.  Or other INDI drivers (I use
the Moonlite focuser, SX Lodestar, ASI CCD and ASI filter wheel as well
as the joystick drivers).

My caveat in this qualification is I am always near my mount when I'm
using it.  I run everything from inside with VNC but when I meridian
flip or park I always go outside to watch the mount.  I am very paranoid
about open loop systems with command protocols with no checksums!  This
is of course borderline irrational but that is how I felt under Windows/ASCOM as well.   When I have a chance to build a hardware
failsafe to prevent pier collisions I might change my position.

With that understanding - I am not comfortable saying the current driver
would be appropriate for remote systems that are unattended.   I haven't
run mine that way so I can't honestly extrapolate to how it would work
in other people's situations.

I am sure I'm being very overly cautious as I haven't seen anything with
the current driver to lead me to think it wouldn't work OK but I want
people to understand they are using new software and it could only
benefit from testing.

But for someone who is setting up each night and imaging (or doing
visual!) and basically hanging around the mount and keeping an eye on
things I don't see any difference in reliability using the INDI driver
versus the ASCOM solution I had been using previously.

And I can use my $30 wireless  gamepad to move the scope around now as a
bonus.

Michael Fulbright


Re: INDI AP driver

Roland Christen
 


For A-P, the GTOCP protocol isn't published in full
There are some internal commands that are not published, but they should not be accessed by anyone because they do control functions inside the servo. Changing them by outside users can disrupt proper operation of the mount.

Rolando


-----Original Message-----
From: Dale Ghent daleg@... [ap-gto]
To: ap-gto
Sent: Wed, Feb 21, 2018 9:50 am
Subject: Re: [ap-gto] INDI AP driver



> On Feb 21, 2018, at 8:45 AM, 'Ray Gralak (Groups)' groups3@... [ap-gto] gto@...> wrote:
>
> Hi Chris,
>
>>> The real question is this... how many people are not going to purchase
> an
>>> A-P mount because A-P doesn't provide in-house INDI drivers?
>>> (I may be wrong, but I think that number is really low.)
>>
>> So I guess that Software Bisque, 10-Micron and a few others are
> frantically
>> building turnkey Linux solutions for their mounts because they are just
>> silly, foolish people?
>
> There's a subtle difference here that I think some are missing:
>
> I said "INDI drivers", not LINUX!!!
>
> I think LINUX should be targeted, but the question is INDI or a future ASCOM
> cross platform API.
>
> The primary amateur Astronomy market has been developed with ASCOM for a
> long time. And because the ASCOM platform developers chose .Net for the
> client library interfaces, most Astronomy based Windows applications have
> been developed with .Net for the last decade. I think it would significantly
> increasing the chances that .Net/ASCOM developers would bring their Windows
> apps cross platform if they could use a framework like Xamarin with a cross
> platform ASCOM API. The advantage of this solution is that they wouldn't
> have to rewrite their entire application.

People already make apps that use both or either ASCOM and INDI. Again, you're making suppositions about complexity that are best left up to the people who are making their apps to decide.

"Cross-Platform" in 2018 does not mean "my app works on chosen OSes", as is the case with Ximarian.

It means "the software is effectively language AND OS-agnostic" and is portable, without too much fuss, between OSes which subscribe to a minimum standard. In INDI's case, it has two options of here: One can port or use its client or server portions without too much fuss across any reasonably modern, POSIX-compliant OS, or one can be so bold as to implement its published wire protocol in whatever environment the person sees fit. If one wanted to implement a INDI client library in JOVIAL on PowerPC, go knock yourself out. This is an extreme example, but it presses home the point.

> Logically, if the same API calls (ASCOM) are used then I think those
> applications would require less rewriting and debugging of logic than if the
> applications were rewritten to use the INDI API.

You're acting like the only apps that will ever exist are ones that are already written and thus absolutely require the crutch of language and API continuity.

> Plus, almost every ASCOM driver is considerably more mature than its
> equivalent INDI driver. I think that porting the ASCOM drivers cross
> platform would bring a lot of maturity that the INDI driver's will not be
> able to match for years. To me, that is not an insignificant detail.

Quantify maturity. For A-P, the GTOCP protocol isn't published in full and only a chosen few have access to it in order to do things such as maintain the ASCOM driver for it. *Of Course* Michael's work on the A-P INDI driver is going to be limited by his lack of access and thus it won't even be as featureful as its ASCOM analog due to this basic fact.

Also, we're talking about what are serial protocol drivers. These aren't complex beasts at all, and you're being a bit over the top if you're trying to make them out to be like they're some complex monstrosity that is like wine and the code magically gets better as it ages. Either purposefully or accidentally, you're trying to spread FUD here where it's completely uncalled for. Stop it. You are not being a steward of A-P products if you want to go down that unobjective and selfish route.

/dale







------------------------------------
Posted by: Dale Ghent <daleg@...>
------------------------------------

To UNSUBSCRIBE, or for general information on the ap-gto list
see http://groups.yahoo.com/group/ap-gto
------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ap-gto/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/ap-gto/join
(Yahoo! ID required)

<*> To change settings via email:
ap-gto-digest@...
ap-gto-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
ap-gto-unsubscribe@...

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/


Re: INDI AP driver

Michael Mulcahy
 

I must say this has been an interesting thread which shows the considerable software expertise of folks in the forum.  As a programmer in another age I can appreciate and understand the issues being discussed.

 

I have imaged for about 8 years and operate an automated system using a windows laptop and the usual tools – Maxim, FocusMax, SkyX and CCDAutopilot.  This system delivers images 98 percent of the time and when it doesn’t it is usually a USB problem.  

 

So I ask why would I change this and move to a theoretically better architecture with new hardware and a steep learning curve?  How would Linux with INDI drivers make my imaging world better?  What would it do that I can’t do now.

 

I would rather capture data and process images than experiment with new software.  Until there are real benefits from a new architecture the “business case” for a change is just not there for me.

 

Mike Mulcahy


Re: INDI AP driver

Roland Christen
 


I might have second thoughts against the Mach1 if a different yet attractive and adequately capable mount was also well-supported under INDI, with bonus points if the mount's maker also took an active interest in supporting software development for it.
What mount would that be?

Rolando


-----Original Message-----
From: Dale Ghent daleg@... [ap-gto]
To: ap-gto Sent: Wed, Feb 21, 2018 3:31 am
Subject: Re: [ap-gto] INDI AP driver



> On Feb 18, 2018, at 2:53 PM, Michael Fulbright mike.fulbright@... [ap-gto] gto@...> wrote:
>
> My use case is probably unique - I love developing software and so working on the AP INDI driver lets me pursue two things I love doing - programming and imaging.

First, thank you for doing this. Being an occasional OSS contributor myself, I can understand your drive. I didn't get into NIC driver programming because some boss tasked me with it; I got into it because I had new hardware that needed a driver for the OS I use and it coincided with me wanting to know how it all worked inside the kernel, on the chip registers, in the DMA transactions - the whole shebang. Some blood, sweat, and tears later, and I had support for my NIC working well and passing code review and community testing. It also introduced me to chip errata, which can be real horror stories.

> In addition to the benefit of avoiding Windows, the multi-platform support of INDI is a good play to help those people with Macs out as well, not to speak of the ocean of ARM based boards and computers which are becoming more attractive as lightweight imaging platforms.

I would love nothing more than to be able to frisbee the HP laptop and only Windows computer I own, which exists solely to run astro software, into the trash bin and replace it with a low-power ARM or Atom-based industrial design (checkout the UPboard baseboards and housings, for example) in a true client-server setup. No more long USB cables. No more remote desktops. Something that won't crap out the moment it gets a micron of dew on it or hotter than 40C. A solution worthy of this decade.

> I don't think AP needs to go to the point of actually monetarily supporting INDI beyond perhaps providing hardware in cases people are trying to debug certain problems.

A-P doesn't even really need to provide hardware. A sufficient modern stance would be for A-P to assist the community in developing a fully-featured INDI driver for GTOCP by publishing its protocol(s). As long as there's someone/some people willing to implement their spec and the community to support it with testing, that's really all A-P needs to do. Doing so would be to both the astronomy community’s benefit as well as their own:

1) More software on more platforms can be made to *reliably* interop with A-P mounts with feature parity found elsewhere.

2) Users or potential users are no longer limited to a very narrow choice of platform and hardware to operate the mounts, reducing or even eliminating the need for costly bespoke solutions.

3) Longevity of GTOCP hardware is ensured - contemporary software can be made to talk to GTOCP hardware for as long as there is operable GTOCP hardware available - hardware which I hope will outlive us all.

Otherwise, I feel like we're living the 90's all over again. I remember hardware vendors routinely balking at releasing chip datasheets so that non-Windows drivers could be developed for their hardware. A vendor that was open about their hardware or proactively assisted the community in writing drivers or software for their hardware without requiring NDAs or cleanroom coding was a newsworthy occurrence. Eventually, the industry as a whole realized that the train was going to leave the station with or without them, so they started falling all over themselves to provide freely usable documentation, even contributing code themselves or directly sponsoring the work. Nowadays, it's normal to see Linux and even FreeBSD drivers for hardware appear before their Windows counterparts... a complete 180 from even 15 years ago when it was normal to have to laboriously reverse engineer hardware in order to make a driver for it, often under a legal grey area due to the DMCA (section 1201, specifically).

The point is, we've seen this movie before. We know the ways in which it can end. Hardware makers eventually realized that they're really just in the hardware business, and the more people who can use their hardware, the better for them. Their secret to success wasn't in their closely-held protocols, registers, pinouts or DMA setups - rather, their secret was in the overall quality of their product, its reliability, the support behind it, and the the ability for users to use their imagination and adapt it to their requirements rather than the other way around. The hardware makers who refused to realize this became more concerned with being acquired for any IP they owned because, suddenly, no one was interested in buying their black box hardware.

> The driver at the moment is working well and more than anything just needs more sets of eyes trying it out and verifying its operation. My hope would be the driver will not require much work beyond bug fixing as time goes on unless AP releases something new that requires new code.
>
> I must end with saying the support I've received from Howard has been exemplary.

This is good to hear. I sincerely hope A-P can help and support your efforts even more going into the future. I, as a A-P mount owner and customer, would love it, as I would be afforded a wider array of options to choose from and can potentially gain more capability through these expanded options. I'd love to see the day when a science mission can publish time-sensitive targets through a web API, and something as simple as a Python script can get that target information by polling that API, check the weather, open the observatory shutter, acquire and interrogate said target, and then shut everything down when the session is over. No Windows .NET programming knowledge prerequisite, no manual point-and-drool interface or wonky runtime needed - just knowledge of a scripting language that is now commonly taught in high schools, potentially running out of cron. One can dream.

I bought my Mach1GTO from A-P 8 or so years ago because it was the best hardware for my personal budget, and I still have no doubt that I made the right call. Back then, INDI was embryonic and the only real go-to solution (pun intended) for well-integrated control naturally involved ASCOM on Windows.. However, time and progress march ever onwards, and here we are today. If I were instead considering buying my mount today rather than 8 years ago, I might have second thoughts against the Mach1 if a different yet attractive and adequately capable mount was also well-supported under INDI, with bonus points if the mount's maker also took an active interest in supporting software development for it.

Thanks again,
/dale




------------------------------------
Posted by: Dale Ghent <daleg@...>
------------------------------------

To UNSUBSCRIBE, or for general information on the ap-gto list
see http://groups.yahoo.com/group/ap-gto
------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ap-gto/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/ap-gto/join
(Yahoo! ID required)

<*> To change settings via email:
ap-gto-digest@...
ap-gto-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
ap-gto-unsubscribe@...

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/


Re: INDI AP driver

Ray Gralak
 

Dale,

People already make apps that use both or either ASCOM and INDI. Again,
you're
making suppositions about complexity that are best left up to the people
who are
making their apps to decide.
OK, but I *am* one of the people that make the applications. And I've been
involved with ASCOM at the client and driver level almost since ASCOM
started.

Quantify maturity.
By maturity I mean testing against thousands of users with all levels of
mount firmware and the driver doesn't crash and works as expected.


For A-P, the GTOCP protocol isn't published in full and only a
chosen few have access to it in order to do things such as maintain the
ASCOM
driver for it. *Of Course* Michael's work on the A-P INDI driver is going
to be limited
by his lack of access and thus it won't even be as featureful as its ASCOM
analog
due to this basic fact.
I think this is another misconception... there are not many unpublished
commands used or needed by the driver. It must be able to function with the
lowest firmware as well as the latest. It definitely does not use very many
undocumented commands. Most of the functionality is not in the driver, but
in the applications that use the driver.

So, can you or anyone else state functionality they believe is missing in
the INDI driver that is in the AP V2 ASCOM driver?

-Ray Gralak
Author of APCC (Astro-Physics Command Center):
http://www.astro-physics.com/index.htm?products/accessories/software/apcc/ap
cc
Author of PEMPro: http://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: http://www.gralak.com/apdriver
Author of PulseGuide: http://www.pulseguide.com
Author of Sigma: http://www.gralak.com/sigma


-----Original Message-----
From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
Sent: Wednesday, February 21, 2018 7:35 AM
To: ap-gto@yahoogroups.com
Subject: Re: [ap-gto] INDI AP driver





On Feb 21, 2018, at 8:45 AM, 'Ray Gralak (Groups)' groups3@gralak.com
[ap-gto]
<ap-gto@yahoogroups.com> wrote:

Hi Chris,

The real question is this... how many people are not going to purchase
an
A-P mount because A-P doesn't provide in-house INDI drivers?
(I may be wrong, but I think that number is really low.)
So I guess that Software Bisque, 10-Micron and a few others are
frantically
building turnkey Linux solutions for their mounts because they are just
silly, foolish people?
There's a subtle difference here that I think some are missing:

I said "INDI drivers", not LINUX!!!

I think LINUX should be targeted, but the question is INDI or a future
ASCOM
cross platform API.

The primary amateur Astronomy market has been developed with ASCOM for a
long time. And because the ASCOM platform developers chose .Net for the
client library interfaces, most Astronomy based Windows applications
have
been developed with .Net for the last decade. I think it would
significantly
increasing the chances that .Net/ASCOM developers would bring their
Windows
apps cross platform if they could use a framework like Xamarin with a
cross
platform ASCOM API. The advantage of this solution is that they wouldn't
have to rewrite their entire application.
People already make apps that use both or either ASCOM and INDI. Again,
you're
making suppositions about complexity that are best left up to the people
who are
making their apps to decide.

"Cross-Platform" in 2018 does not mean "my app works on <these> chosen
OSes",
as is the case with Ximarian.

It means "the software is effectively language AND OS-agnostic" and is
portable,
without too much fuss, between OSes which subscribe to a minimum standard.
In
INDI's case, it has two options of here: One can port or use its client or
server portions
without too much fuss across any reasonably modern, POSIX-compliant OS, or
one
can be so bold as to implement its published wire protocol in whatever
environment
the person sees fit. If one wanted to implement a INDI client library in
JOVIAL on
PowerPC, go knock yourself out. This is an extreme example, but it presses
home the
point.

Logically, if the same API calls (ASCOM) are used then I think those
applications would require less rewriting and debugging of logic than if
the
applications were rewritten to use the INDI API.
You're acting like the only apps that will ever exist are ones that are
already written
and thus absolutely require the crutch of language and API continuity.

Plus, almost every ASCOM driver is considerably more mature than its
equivalent INDI driver. I think that porting the ASCOM drivers cross
platform would bring a lot of maturity that the INDI driver's will not
be
able to match for years. To me, that is not an insignificant detail.
Quantify maturity. For A-P, the GTOCP protocol isn't published in full and
only a
chosen few have access to it in order to do things such as maintain the
ASCOM
driver for it. *Of Course* Michael's work on the A-P INDI driver is going
to be limited
by his lack of access and thus it won't even be as featureful as its ASCOM
analog
due to this basic fact.

Also, we're talking about what are serial protocol drivers. These aren't
complex beasts
at all, and you're being a bit over the top if you're trying to make them
out to be like
they're some complex monstrosity that is like wine and the code magically
gets better
as it ages. Either purposefully or accidentally, you're trying to spread
FUD here where
it's completely uncalled for. Stop it. You are not being a steward of A-P
products if you
want to go down that unobjective and selfish route.

/dale






Re: INDI AP driver

Dale Ghent
 

On Feb 21, 2018, at 8:45 AM, 'Ray Gralak (Groups)' groups3@gralak.com [ap-gto] <ap-gto@yahoogroups.com> wrote:

Hi Chris,

The real question is this... how many people are not going to purchase
an
A-P mount because A-P doesn't provide in-house INDI drivers?
(I may be wrong, but I think that number is really low.)
So I guess that Software Bisque, 10-Micron and a few others are
frantically
building turnkey Linux solutions for their mounts because they are just
silly, foolish people?
There's a subtle difference here that I think some are missing:

I said "INDI drivers", not LINUX!!!

I think LINUX should be targeted, but the question is INDI or a future ASCOM
cross platform API.

The primary amateur Astronomy market has been developed with ASCOM for a
long time. And because the ASCOM platform developers chose .Net for the
client library interfaces, most Astronomy based Windows applications have
been developed with .Net for the last decade. I think it would significantly
increasing the chances that .Net/ASCOM developers would bring their Windows
apps cross platform if they could use a framework like Xamarin with a cross
platform ASCOM API. The advantage of this solution is that they wouldn't
have to rewrite their entire application.
People already make apps that use both or either ASCOM and INDI. Again, you're making suppositions about complexity that are best left up to the people who are making their apps to decide.

"Cross-Platform" in 2018 does not mean "my app works on <these> chosen OSes", as is the case with Ximarian.

It means "the software is effectively language AND OS-agnostic" and is portable, without too much fuss, between OSes which subscribe to a minimum standard. In INDI's case, it has two options of here: One can port or use its client or server portions without too much fuss across any reasonably modern, POSIX-compliant OS, or one can be so bold as to implement its published wire protocol in whatever environment the person sees fit. If one wanted to implement a INDI client library in JOVIAL on PowerPC, go knock yourself out. This is an extreme example, but it presses home the point.

Logically, if the same API calls (ASCOM) are used then I think those
applications would require less rewriting and debugging of logic than if the
applications were rewritten to use the INDI API.
You're acting like the only apps that will ever exist are ones that are already written and thus absolutely require the crutch of language and API continuity.

Plus, almost every ASCOM driver is considerably more mature than its
equivalent INDI driver. I think that porting the ASCOM drivers cross
platform would bring a lot of maturity that the INDI driver's will not be
able to match for years. To me, that is not an insignificant detail.
Quantify maturity. For A-P, the GTOCP protocol isn't published in full and only a chosen few have access to it in order to do things such as maintain the ASCOM driver for it. *Of Course* Michael's work on the A-P INDI driver is going to be limited by his lack of access and thus it won't even be as featureful as its ASCOM analog due to this basic fact.

Also, we're talking about what are serial protocol drivers. These aren't complex beasts at all, and you're being a bit over the top if you're trying to make them out to be like they're some complex monstrosity that is like wine and the code magically gets better as it ages. Either purposefully or accidentally, you're trying to spread FUD here where it's completely uncalled for. Stop it. You are not being a steward of A-P products if you want to go down that unobjective and selfish route.

/dale


Re: INDI AP driver

Ray Gralak
 

And this is a perfect example of one of the big reasons why people do not
wish to get
involuntarily hitched to anything in the Microsoft world.
Dale, I think your anti-Microsoft sentiment is showing. :-)

1. Microsoft is giving out the best IDE in the world for free to most small
businesses and independent developers/tinkerers. And the Community edition
is free to universities.

2. Microsoft has also made .Net open source and a version of it cross
platform It's here whether you like it or not.

3. How about another *free* software application from Microsoft, "Code". It
is available for Windows, Mac, and LINUX and supports numerous languages:

https://code.visualstudio.com/

-Ray Gralak
Author of APCC (Astro-Physics Command Center):
http://www.astro-physics.com/index.htm?products/accessories/software/apcc/ap
cc
Author of PEMPro: http://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: http://www.gralak.com/apdriver
Author of PulseGuide: http://www.pulseguide.com
Author of Sigma: http://www.gralak.com/sigma


-----Original Message-----
From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
Sent: Wednesday, February 21, 2018 6:59 AM
To: ap-gto@yahoogroups.com
Subject: Re: [ap-gto] INDI AP driver





On Feb 21, 2018, at 8:33 AM, 'Ray Gralak (Groups)' groups3@gralak.com
[ap-gto]
<ap-gto@yahoogroups.com> wrote:

Hi Gabe,

Not to get too off-topic, but I might be able to add some perspective
to academics
preferring linux. In addition to the security of linux, it's easier
when I was starting
out to write and compile programs with the gcc/gfortran compilers,
which was
completely free and available online. I could be wrong, but I don't
recall any well
supported and free compilers available under windows.
Microsoft has two choices: Visual Studio Express, and Visual Studio 2017
Community, the latter even has a Mac OS/X version.

The Community edition is more comprehensive, but you can't use it on
enterprise
(>250 PCs or $1M revenue).

The Express editions can be used in enterprise environments but they are
not as
functional as the Community edition.

And this is a perfect example of one of the big reasons why people do not
wish to get
involuntarily hitched to anything in the Microsoft world.

/dale






Re: INDI AP driver

Zac Kruger <z@...>
 

There are a lot more than Microsoft offerings at this point for Windows, and there have been for quite some time (15+ years).

LLVM + Clang started as a research project at my university (University of Illinois) and is arguably the best compiler infrastructure for all operating systems at this point.  And I say that as a Visual Studio / MonoDevelop guy



On Wed, Feb 21, 2018 at 7:58 AM, Dale Ghent daleg@... [ap-gto] <ap-gto@...> wrote:
 



> On Feb 21, 2018, at 8:33 AM, 'Ray Gralak (Groups)' groups3@... [ap-gto] <ap-gto@...> wrote:
>
> Hi Gabe,
>
>> Not to get too off-topic, but I might be able to add some perspective to academics
>> preferring linux. In addition to the security of linux, it's easier when I was starting
>> out to write and compile programs with the gcc/gfortran compilers, which was
>> completely free and available online. I could be wrong, but I don't recall any well
>> supported and free compilers available under windows.
>
> Microsoft has two choices: Visual Studio Express, and Visual Studio 2017 Community, the latter even has a Mac OS/X version.
>
> The Community edition is more comprehensive, but you can't use it on enterprise (>250 PCs or $1M revenue).
>
> The Express editions can be used in enterprise environments but they are not as functional as the Community edition.

And this is a perfect example of one of the big reasons why people do not wish to get involuntarily hitched to anything in the Microsoft world.

/dale

[Non-text portions of this message have been removed]



Re: INDI AP driver

Ray Gralak
 

And for those that think .Net has no place on LINUX:

https://opensource.com/article/17/11/net-linux

-Ray Gralak
Author of APCC (Astro-Physics Command Center):
http://www.astro-physics.com/index.htm?products/accessories/software/apcc/ap
cc
Author of PEMPro: http://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: http://www.gralak.com/apdriver
Author of PulseGuide: http://www.pulseguide.com
Author of Sigma: http://www.gralak.com/sigma

-----Original Message-----
From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
Sent: Wednesday, February 21, 2018 5:46 AM
To: ap-gto@yahoogroups.com
Subject: RE: [ap-gto] INDI AP driver



Hi Chris,

The real question is this... how many people are not going to purchase
an
A-P mount because A-P doesn't provide in-house INDI drivers?
(I may be wrong, but I think that number is really low.)
So I guess that Software Bisque, 10-Micron and a few others are
frantically
building turnkey Linux solutions for their mounts because they are just
silly, foolish people?
There's a subtle difference here that I think some are missing:

I said "INDI drivers", not LINUX!!!

I think LINUX should be targeted, but the question is INDI or a future
ASCOM
cross platform API.

The primary amateur Astronomy market has been developed with ASCOM for a
long time. And because the ASCOM platform developers chose .Net for the
client library interfaces, most Astronomy based Windows applications have
been developed with .Net for the last decade. I think it would
significantly
increasing the chances that .Net/ASCOM developers would bring their
Windows
apps cross platform if they could use a framework like Xamarin with a
cross
platform ASCOM API. The advantage of this solution is that they wouldn't
have to rewrite their entire application.

Logically, if the same API calls (ASCOM) are used then I think those
applications would require less rewriting and debugging of logic than if
the
applications were rewritten to use the INDI API.

Plus, almost every ASCOM driver is considerably more mature than its
equivalent INDI driver. I think that porting the ASCOM drivers cross
platform would bring a lot of maturity that the INDI driver's will not be
able to match for years. To me, that is not an insignificant detail.

-Ray Gralak
Author of APCC (Astro-Physics Command Center):
http://www.astro-physics.com/index.htm?products/accessories/software/apcc/ap
cc
Author of PEMPro: http://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: http://www.gralak.com/apdriver
Author of PulseGuide: http://www.pulseguide.com
Author of Sigma: http://www.gralak.com/sigma

-----Original Message-----
From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
Sent: Wednesday, February 21, 2018 12:37 AM
To: ap-gto@yahoogroups.com
Subject: RE: [ap-gto] INDI AP driver





Hi Michael,
Sorry, I'm going to play devil's advocate here for a second... :-)
- cross platform support - Mac and Linux users are people too :)
The real question is this... how many people are not going to purchase
an
A-P mount because A-P doesn't provide in-house INDI drivers?
(I may be wrong, but I think that number is really low.)
We'll never know, will we?

So I guess that Software Bisque, 10-Micron and a few others are
frantically
building turnkey Linux solutions for their mounts because they are just
silly, foolish people?

-Chris

---
This email has been checked for viruses by AVG.
http://www.avg.com






Re: INDI AP driver

Dale Ghent
 

On Feb 21, 2018, at 8:33 AM, 'Ray Gralak (Groups)' groups3@gralak.com [ap-gto] <ap-gto@yahoogroups.com> wrote:

Hi Gabe,

Not to get too off-topic, but I might be able to add some perspective to academics
preferring linux. In addition to the security of linux, it's easier when I was starting
out to write and compile programs with the gcc/gfortran compilers, which was
completely free and available online. I could be wrong, but I don't recall any well
supported and free compilers available under windows.
Microsoft has two choices: Visual Studio Express, and Visual Studio 2017 Community, the latter even has a Mac OS/X version.

The Community edition is more comprehensive, but you can't use it on enterprise (>250 PCs or $1M revenue).

The Express editions can be used in enterprise environments but they are not as functional as the Community edition.
And this is a perfect example of one of the big reasons why people do not wish to get involuntarily hitched to anything in the Microsoft world.

/dale


Re: INDI AP driver

Ray Gralak
 

Hi Chris,

The real question is this... how many people are not going to purchase
an
A-P mount because A-P doesn't provide in-house INDI drivers?
(I may be wrong, but I think that number is really low.)
So I guess that Software Bisque, 10-Micron and a few others are
frantically
building turnkey Linux solutions for their mounts because they are just
silly, foolish people?
There's a subtle difference here that I think some are missing:

I said "INDI drivers", not LINUX!!!

I think LINUX should be targeted, but the question is INDI or a future ASCOM
cross platform API.

The primary amateur Astronomy market has been developed with ASCOM for a
long time. And because the ASCOM platform developers chose .Net for the
client library interfaces, most Astronomy based Windows applications have
been developed with .Net for the last decade. I think it would significantly
increase the chances that .Net/ASCOM developers would bring their Windows
apps cross platform if they could use a framework like Xamarin with a cross
platform ASCOM API. The advantage of this solution is that they wouldn't
have to rewrite their entire application.

Logically, if the same API calls (ASCOM) are used then I think those
applications would require less rewriting and debugging of logic than if the
applications were rewritten to use the INDI API.

Plus, almost every ASCOM driver is considerably more mature than its
equivalent INDI driver. I think that porting the ASCOM drivers cross
platform would bring a lot of maturity that the INDI driver's will not be
able to match for years. To me, that is not an insignificant detail.

-Ray Gralak
Author of APCC (Astro-Physics Command Center):
http://www.astro-physics.com/index.htm?products/accessories/software/apcc/ap
cc
Author of PEMPro: http://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: http://www.gralak.com/apdriver
Author of PulseGuide: http://www.pulseguide.com
Author of Sigma: http://www.gralak.com/sigma


-----Original Message-----
From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
Sent: Wednesday, February 21, 2018 12:37 AM
To: ap-gto@yahoogroups.com
Subject: RE: [ap-gto] INDI AP driver





Hi Michael,
Sorry, I'm going to play devil's advocate here for a second... :-)
- cross platform support - Mac and Linux users are people too :)
The real question is this... how many people are not going to purchase
an
A-P mount because A-P doesn't provide in-house INDI drivers?
(I may be wrong, but I think that number is really low.)
We'll never know, will we?

So I guess that Software Bisque, 10-Micron and a few others are
frantically
building turnkey Linux solutions for their mounts because they are just
silly, foolish people?

-Chris

---
This email has been checked for viruses by AVG.
http://www.avg.com




Re: INDI AP driver

Andrew Barton
 

I’m a "want to use INDI". I do most of my desktop work on a Mac and Linux. Windows is only in my life to support my astrophotography gear and I would love to get to the point where I can ditch it. I am not set on INDI. A cross platform ASCOM would likely work for me as well.

About once a year I survey the astrophotography landscape to determine if I can make the move. One interesting new development for me is PixInsight’s inclusion of some INDI tools. 

Regards,

Andy
--
Andrew Barton
520.289.3064

On Feb 18, 2018, at 8:34 AM, 'Ray Gralak (Groups)' groups3@... [ap-gto] <ap-gto@...> wrote:

 
OK, so the count so far is:

1 is using INDI regularly.
1 has used it, but is waiting for better support.
2 will be using it soon.
5 want to use it .

Anyone else?

So, besides people hating Windows for various reasons, what problem(s) do people believe are solved by using INDI (and LINUX in general)?

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

> -----Original Message-----
> From: ap-gto@... [mailto:ap-gto@...]
> Sent: Saturday, February 17, 2018 9:21 PM
> To: ap-gto@...
> Subject: Re: [ap-gto] INDI AP driver
>
>
>
> Then you should ask Bob to support INDI.
>
>
>
>
> ________________________________
>
> From: ap-gto@... <ap-gto@...> on behalf of
> 'Steven Reilly' sreilly24590@... [ap-gto] <ap-gto@...>
> Sent: Saturday, February 17, 2018 8:33 PM
> To: ap-gto@...
> Subject: RE: [ap-gto] INDI AP driver
>
>
>
> Can’t speak for SGP but many of us use ACP/Expert.
>
>
>
> Steve
>
>
>
>
>
> From: ap-gto@... [mailto:ap-gto@...]
> Sent: Saturday, February 17, 2018 11:30 PM
> To: ap-gto@...
> Subject: Re: [ap-gto] INDI AP driver
>
>
>
>
>
> What is the hot imaging software to use these days? SGP. What will be the first
> Windows imaging platform to support both INDI and ASCOM at the same time?
> SGP. APCC was updated to work with what, other than MaximDL and CCDSoft?
> SGP.
>
>
>
> Who has an in house supported driver for INDI, from Premium Mount Makers?
> Software Bisque (via SkyX For RPi)
>
>
>
> Who needs one? Astro-Physics and 10 Micron.
>
>
>
> Who should most certainly not be last to the table here? Astro-Physics.. 😊
>
>
>
> ________________________________
>
> From: ap-gto@... <ap-gto@...> on behalf of
> Hemant Hariyani hemanthariyani@... [ap-gto] > gto@...>
> Sent: Saturday, February 17, 2018 8:12 PM
> To: ap-gto@...
> Subject: Re: [ap-gto] INDI AP driver
>
>
>
>
>
> Will be using it very soon!
>
>
>
> Regards
>
> Hemant
>
>
>
>
>
> On Sat, Feb 17, 2018 at 9:30 PM, 'Ray Gralak (Groups)' groups3@... [ap-
> gto] <ap-gto@...> wrote:
>
>
>
> A show of hands...
>
> How many people here are actively using the astro-physics INDI driver?
>
> -Ray Gralak
> Author of APCC (Astro-Physics Command Center):
> http://www.astro-
> physics.com/index.htm?products/accessories/software/apcc/ap
> cc
> Author of PEMPro: http://www.ccdware.com
> Author of Astro-Physics V2 ASCOM Driver: http://www.gralak.com/apdriver
> <http://www.gralak.com/apdriver>
> Author of PulseGuide: http://www.pulseguide.com
> Author of Sigma: http://www.gralak.com/sigma
>
>
>
>



Re: INDI AP driver

Ray Gralak
 

Hi Chris,

The real question is this... how many people are not going to purchase
an
A-P mount because A-P doesn't provide in-house INDI drivers?
(I may be wrong, but I think that number is really low.)
So I guess that Software Bisque, 10-Micron and a few others are
frantically
building turnkey Linux solutions for their mounts because they are just
silly, foolish people?
There's a subtle difference here that I think some are missing:

I said "INDI drivers", not LINUX!!!

I think LINUX should be targeted, but the question is INDI or a future ASCOM
cross platform API.

The primary amateur Astronomy market has been developed with ASCOM for a
long time. And because the ASCOM platform developers chose .Net for the
client library interfaces, most Astronomy based Windows applications have
been developed with .Net for the last decade. I think it would significantly
increasing the chances that .Net/ASCOM developers would bring their Windows
apps cross platform if they could use a framework like Xamarin with a cross
platform ASCOM API. The advantage of this solution is that they wouldn't
have to rewrite their entire application.

Logically, if the same API calls (ASCOM) are used then I think those
applications would require less rewriting and debugging of logic than if the
applications were rewritten to use the INDI API.

Plus, almost every ASCOM driver is considerably more mature than its
equivalent INDI driver. I think that porting the ASCOM drivers cross
platform would bring a lot of maturity that the INDI driver's will not be
able to match for years. To me, that is not an insignificant detail.

-Ray Gralak
Author of APCC (Astro-Physics Command Center):
http://www.astro-physics.com/index.htm?products/accessories/software/apcc/ap
cc
Author of PEMPro: http://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: http://www.gralak.com/apdriver
Author of PulseGuide: http://www.pulseguide.com
Author of Sigma: http://www.gralak.com/sigma


-----Original Message-----
From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
Sent: Wednesday, February 21, 2018 12:37 AM
To: ap-gto@yahoogroups.com
Subject: RE: [ap-gto] INDI AP driver





Hi Michael,
Sorry, I'm going to play devil's advocate here for a second... :-)
- cross platform support - Mac and Linux users are people too :)
The real question is this... how many people are not going to purchase
an
A-P mount because A-P doesn't provide in-house INDI drivers?
(I may be wrong, but I think that number is really low.)
We'll never know, will we?

So I guess that Software Bisque, 10-Micron and a few others are
frantically
building turnkey Linux solutions for their mounts because they are just
silly, foolish people?

-Chris

---
This email has been checked for viruses by AVG.
http://www.avg.com




Re: INDI AP driver

Ray Gralak
 

Hi Gabe,

Not to get too off-topic, but I might be able to add some perspective to academics
preferring linux. In addition to the security of linux, it's easier when I was starting
out to write and compile programs with the gcc/gfortran compilers, which was
completely free and available online. I could be wrong, but I don't recall any well
supported and free compilers available under windows.
Microsoft has two choices: Visual Studio Express, and Visual Studio 2017 Community, the latter even has a Mac OS/X version.

The Community edition is more comprehensive, but you can't use it on enterprise (>250 PCs or $1M revenue).

The Express editions can be used in enterprise environments but they are not as functional as the Community edition.

https://www.visualstudio.com/vs/community/

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


-----Original Message-----
From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
Sent: Tuesday, February 20, 2018 9:09 PM
To: ap-gto@yahoogroups.com
Subject: RE: [ap-gto] INDI AP driver



Add me to the list of having used Indi, and waiting for better support. I'm one of
those academics that are set in their ways who uses linux and have been a linux
user for 15 years. However, when it came to getting my imaging rig running with
reliable automation, I switched for the purposes of imaging and bought a PC stick.
I currently use SGP and APCC on my PC stick things run quite well. I don't regret
doing it since I see the PC stick as another device that is used as a tool. I did try
Indi and Ekos a few years ago when confronted with getting an automated setup
and found it to be not yet rock solid.

That said though, when it does become rock solid, I'll move over in a heartbeat.
Perhaps that time is now. I've heard it's made great strides recently. I have a lot
more experience in linux and have coded my own sensors and devices that I'd like
to poll for sky and environmental conditions. I know how to do that in linux / python
and have the whole project already mapped out. Doing that in Windows would
take too much time and doesn't fit well w/ my expertise.


Not to get too off-topic, but I might be able to add some perspective to academics
preferring linux. In addition to the security of linux, it's easier when I was starting
out to write and compile programs with the gcc/gfortran compilers, which was
completely free and available online. I could be wrong, but I don't recall any well
supported and free compilers available under windows.


Gabe



Re: INDI AP driver

Christopher Erickson
 

Now you're just being deliberately obtuse and ornery. (grin)


-Christopher Erickson
Observatory engineer
Summit Kinetics
Waikoloa, HI 96738
www.summitkinetics.com

-----Original Message-----
From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
Sent: Sunday, February 18, 2018 5:25 PM
To: ap-gto@yahoogroups.com
Subject: RE: [ap-gto] INDI AP driver

needed windows. I told them that a non-Windows solution would be about
$50,000 more. That's what they chose and that is what we are building.


What more can I say.
But... you just write in another post:

I can build a Linux observatory solution for a fraction of the cost of
a Windows solution
$50K more for a non-Windows solution... you must have used Mac's, right? :-))

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


-----Original Message-----
From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
Sent: Sunday, February 18, 2018 4:43 PM
To: ap-gto@yahoogroups.com
Subject: RE: [ap-gto] INDI AP driver



The UH88 observatory was looking for a new Observatory Control System. I
proposed an ASCOM solution with a Sidereal Technologies Servo Controller II
combined with a servo amplifier. I planned to create several microcontroller
interfaces to the focuser, dome and other systems so the custom systems would
emulate common commercial systems. They refused to accept any solution that
needed windows. I told them that a non-Windows solution would be about $50,000
more. That's what they chose and that is what we are building.


What more can I say.

-Christopher Erickson
Observatory engineer
Waikoloa, HI 96738
www.summitkinetics.com


On Feb 18, 2018 1:45 PM, "'Ray Gralak (Groups)' groups3@gralak.com [ap-gto]"
<ap-gto@yahoogroups.com> wrote:


> Part of that is certainly arrogant human bias but another part of that is
better
> reliability, better security, lower hardware costs and significantly-lower
software
> licensing costs. I can build a Linux observatory solution for a fraction of
the cost of
> a Windows solution. And with a web-based GUI that can be operated from
any
> remote computer with a web browser.

I think this is a special case. These users don't personally own their
equipment and don't have to natively use the operating system (and maybe they
don't even know how).

However, it does make for a good business case for AP to potentially sell
some more mounts to academia.

Would you think this same customer type would care if the platform was
some form of cross-platform ASCOM on LINUX?

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-
physics.com/index.htm?products/accessories/software/apcc/apcc
<http://www.astro-
physics.com/index.htm?products/accessories/software/apcc/apcc>
Author of PEMPro: http://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: http://www.gralak.com/apdriver
Author of PulseGuide: http://www.pulseguide.com
Author of Sigma: http://www.gralak.com/sigma


> -----Original Message-----
> From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com]
> Sent: Sunday, February 18, 2018 3:14 PM
> To: ap-gto@yahoogroups.com
> Subject: Re: [ap-gto] INDI AP driver
>
>
>
> I have a large number of academic clients that absolutely refuse to let me
build
> obsevatories or other scientific facilities for them that use any Windows
computers
> or Windows software.
>
> Part of that is certainly arrogant human bias but another part of that is
better
> reliability, better security, lower hardware costs and significantly-lower
software
> licensing costs. I can build a Linux observatory solution for a fraction of
the cost of
> a Windows solution. And with a web-based GUI that can be operated from
any
> remote computer with a web browser.
>
> And the best part of a turnkey Linux solution is that my clients won't ever
have to
> deal with a Linux prompt themselves.
>
> I hope this helps.
>
>
> -Christopher Erickson
> Observatory engineer
> Waikoloa, HI 96738
> www.summitkinetics.com
>
>
> On Feb 18, 2018 12:21 PM, "Michael Fulbright mike.fulbright@pobox.com
[ap-gto]"
> <ap-gto@yahoogroups.com> wrote:
>
>
>
>
> You are asking two separate questions.
>
> 1) "Why use INDI at all?"
>
> 2) "Why would a technically challenged person what to use INDI over
> ASCOM/Windows?"
>
> I would suggest for #2 that there is no compelling reason if they get
> ASCOM/Windows working with their hardware and are able to afford the
> associated software required.
>
> There are several reasons for #1 - just a few:
>
> - cross platform support - Mac and Linux users are people too :)
> - client/server architecture
> - vendor independence for hardware support that is subscription free
> - free software, as in free beer, as well as freedom for the user to work
on or
> have someone else work on software and distribute changes
>
> None of these really apply to ASCOM.
>
> I think it would also be short-sighted to underestimate the large
groundswell
> of animosity towards Windows and Microsoft and the desire for many
users to get
> away from it. I think the lack of Windows 10 uptake is a good indicator.. It
has
> been over two years since it was released and it is only now reaching the
same
> number of active machines as Windows 7.
>
> But really the question should not be so much WHY people are
wanting to
> use INDI as much as ARE people wanting to use it and if so what can AP
do to
> assist their customers.
>
> Michael Fulbright
>
>
>
>
>
> On 2/18/2018 4:35 PM, 'Ray Gralak (Groups)' groups3@gralak.com
[ap-gto]
> wrote:
>
>
>
>
> Hi Bill,
>
> Resending again....
>
> > I don't hate Windows. I want to run my rig on a raspberry pi 3,
and
> prefer the client
> > server model of INDI.
>
> The AP V2 ASCOM driver is an out of process local server, thus it
> provides a true client/server model.
>
> That said, what problem does running on a raspberry Pi 3, or INDI
> client/server model solve for you that can't be done on a
Windows/ASCOM
> platform?
>
> BTW, I have nothing against LINUX. I have years of experience
> developing software on LINUX, but I haven't seen a good argument for
INDI
> except that ASCOM doesn't work on LINUX.
>
> ASCOM is far more mature, far better support, far better device
> selection, and client software available. I can see that technical types
want to roll
> their own code but what does INDI+LINUX provide that is more compelling
than
> ASCOM to the average non-technical user?
>
> -Ray Gralak
> Author of APCC (Astro-Physics Command Center):
http://www.astro-
> physics.com/index.htm?products/accessories/software/apcc/apcc
<http://physics.com/index.htm?products/accessories/software/apcc/apcc>
> <http://www.astro-
> physics.com/index.htm?products/accessories/software/apcc/apcc
<http://physics.com/index.htm?products/accessories/software/apcc/apcc> >
> Author of PEMPro: http://www.ccdware.com
> Author of Astro-Physics V2 ASCOM Driver:
> http://www.gralak.com/apdriver
> Author of PulseGuide: http://www.pulseguide.com
> Author of Sigma: http://www.gralak.com/sigma
>
> > -----Original Message-----
> > From: ap-gto@yahoogroups.com [mailto:ap-
> gto@yahoogroups.com]
> > Sent: Sunday, February 18, 2018 10:07 AM
> > To: ap-gto@yahoogroups.com
> > Subject: Re: [ap-gto] INDI AP driver
> >
> >
> >
> > I don't hate Windows. I want to run my rig on a raspberry pi 3,
and
> prefer the client
> > server model of INDI.
> >
> >
> >
> >
> >
> > ________________________________
> >
> > From: ap-gto@yahoogroups.com <ap-gto@yahoogroups..com>
> <mailto:ap-gto@yahoogroups.com> on behalf of 'Ray
> > Gralak (Groups)' groups3@gralak.com [ap-gto] <ap-
> gto@yahoogroups..com> <mailto:ap-gto@yahoogroups.com>
> > Sent: Sunday, February 18, 2018 9:28:46 AM
> > To: ap-gto@yahoogroups.com
> > Subject: RE: [ap-gto] INDI AP driver
> >
> >
> >
> > Resending this... I guess Yahoo is stalling posts again??
> > ---------------
> >
> > OK, so the count so far is:
> >
> > 1 is using INDI regularly.
> > 1 has used it, but is waiting for better support.
> > 2 will be using it soon.
> > 5 want to use it .
> >
> > Anyone else?
> >
> > So, besides people hating Windows for various reasons, what
> problem(s) do
> > people believe are solved by using INDI (and LINUX in
general)?
> >
> > -Ray Gralak
> > Author of APCC (Astro-Physics Command Center):
> http://www.astro-
> >
physics.com/index.htm?products/accessories/software/apcc/apcc
<http://physics.com/index.htm?products/accessories/software/apcc/apcc>
> <http://physics.com/index.htm?products/accessories/software/apcc/apcc
<http://physics.com/index.htm?products/accessories/software/apcc/apcc> >
> > Author of PEMPro: http://www.ccdware.com
> > Author of Astro-Physics V2 ASCOM Driver:
> http://www.gralak.com/apdriver
> > Author of PulseGuide: http://www.pulseguide.com
> > Author of Sigma: http://www.gralak.com/sigma
> >
> > > -----Original Message-----
> > > From: ap-gto@yahoogroups.com [mailto:ap-
> gto@yahoogroups.com]
> > > Sent: Saturday, February 17, 2018 9:21 PM
> > > To: ap-gto@yahoogroups.com
> > > Subject: Re: [ap-gto] INDI AP driver
> > >
> > >
> > >
> > > Then you should ask Bob to support INDI.
> > >
> > >
> > >
> > >
> > > ________________________________
> > >
> > > From: ap-gto@yahoogroups.com <ap-
gto@yahoogroups..com>
> <mailto:ap-gto@yahoogroups.com> on behalf of
> > > 'Steven Reilly' sreilly24590@centurylink.net [ap-gto] <ap-
> > gto@yahoogroups.com>
> > > Sent: Saturday, February 17, 2018 8:33 PM
> > > To: ap-gto@yahoogroups.com
> > > Subject: RE: [ap-gto] INDI AP driver
> > >
> > >
> > >
> > > Can’t speak for SGP but many of us use ACP/Expert.
> > >
> > >
> > >
> > > Steve
> > >
> > >
> > >
> > >
> > >
> > > From: ap-gto@yahoogroups.com [mailto:ap-
> gto@yahoogroups.com]
> > > Sent: Saturday, February 17, 2018 11:30 PM
> > > To: ap-gto@yahoogroups.com
> > > Subject: Re: [ap-gto] INDI AP driver
> > >
> > >
> > >
> > >
> > >
> > > What is the hot imaging software to use these days? SGP.
What
> will be the first
> > > Windows imaging platform to support both INDI and ASCOM
at
> the same time?
> > > SGP. APCC was updated to work with what, other than
MaximDL
> and CCDSoft?
> > > SGP.
> > >
> > >
> > >
> > > Who has an in house supported driver for INDI, from Premium
> Mount Makers?
> > > Software Bisque (via SkyX For RPi)
> > >
> > >
> > >
> > > Who needs one? Astro-Physics and 10 Micron.
> > >
> > >
> > >
> > > Who should most certainly not be last to the table here? Astro-
> Physics.. 😊
> > >
> > >
> > >
> > > ________________________________
> > >
> > > From: ap-gto@yahoogroups.com <ap-
gto@yahoogroups..com>
> <mailto:ap-gto@yahoogroups.com> on behalf of
> > > Hemant Hariyani hemanthariyani@gmail.com [ap-gto] <ap-
> > > gto@yahoogroups.com>
> > > Sent: Saturday, February 17, 2018 8:12 PM
> > > To: ap-gto@yahoogroups.com
> > > Subject: Re: [ap-gto] INDI AP driver
> > >
> > >
> > >
> > >
> > >
> > > Will be using it very soon!
> > >
> > >
> > >
> > > Regards
> > >
> > > Hemant
> > >
> > >
> > >
> > >
> > >
> > > On Sat, Feb 17, 2018 at 9:30 PM, 'Ray Gralak (Groups)'
> groups3@gralak.com
> > [ap-
> > > gto] <ap-gto@yahoogroups.com> <mailto:ap-
> gto@yahoogroups.com> wrote:
> > >
> > >
> > >
> > > A show of hands...
> > >
> > > How many people here are actively using the astro-physics
INDI
> driver?
> > >
> > > -Ray Gralak
> > > Author of APCC (Astro-Physics Command Center):
> > > http://www.astro-
> > >
physics.com/index.htm?products/accessories/software/apcc/ap
<http://physics.com/index.htm?products/accessories/software/apcc/ap>
> <http://physics.com/index.htm?products/accessories/software/apcc/ap
<http://physics.com/index.htm?products/accessories/software/apcc/ap> >
> > > cc
> > > Author of PEMPro: http://www.ccdware.com
> > > Author of Astro-Physics V2 ASCOM Driver:
> http://www.gralak.com/apdriver
> > > <http://www.gralak.com/apdriver
<http://www.gralak.com/apdriver> >
> <http://www.gralak.com/apdriver <http://www.gralak.com/apdriver> >
> > > Author of PulseGuide: http://www.pulseguide.com
> > > Author of Sigma: http://www.gralak.com/sigma
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>
>
>
>



------------------------------------
Posted by: "Ray Gralak &#92;(Groups&#92;)" <groups3@gralak.com>
------------------------------------

To UNSUBSCRIBE, or for general information on the ap-gto list
see http://groups.yahoo.com/group/ap-gto
<http://groups.yahoo.com/group/ap-gto>
------------------------------------

Yahoo Groups Links


(Yahoo! ID required)

fullfeatured@yahoogroups.com>







------------------------------------
Posted by: "Ray Gralak &#92;(Groups&#92;)" <groups3@gralak.com>
------------------------------------

To UNSUBSCRIBE, or for general information on the ap-gto list
see http://groups.yahoo.com/group/ap-gto
------------------------------------

Yahoo Groups Links




---
This email has been checked for viruses by AVG.
http://www.avg.com