Date   

Re: INDI AP driver

Dale Ghent
 

On Feb 22, 2018, at 3:46 PM, chris1011@aol.com [ap-gto] <ap-gto@yahoogroups.com> wrote:

They aren't getting the support they want so they create their own software but are kneecapped because AP keeps the protocol proprietary
That is not true. We do not keep it proprietary, only the internal servo software that controls the internal functions, not anything external.
Hey Roland,

I think the misunderstanding here stems partially from the latest documentation for the protocol on A-P's website being from 2006, documenting the protocol as it was through to the GTOCP3 rev. Q chips. This leaves the impression that any changes or features newer than that are not available for general consumption.

http://www.astro-physics.com/index.htm?tech_support/tech_support "Command Protocol" section.

For example, the retrieval and storing of PEM profiles is not explained, as are any of the new features that are going into the CP4. It's the lack of info on this kind stuff that limits the ability for non-Windows apps to gain parity with their Windows analogs.

/dale


Re: INDI AP driver

Ray Gralak
 

Alexander, I think you LINUX/INDI driver folks need to calm down a bit.

1) If you read my posts you would know that I *am* an advocate of cross platform development. 
2) I am not against LINUX.
3) It is NOT my place to "give up" any undocumented A-P mount commands.
4) A-P has very good reasons to not release the commands.
5) The AP ASCOM driver uses very few undocumented commands.
6) Using some of those undocumented commands could make your mount inoperable or erratic.
7) I am not against INDI either. It just seems like a better business decision to balance INDI vs ASCOM.

>Should we just stop developing new OS's since XP is very mature? 

Where did I say anything about dropping development?

>The software world changes so incredibly fast. INDI may 
>or may not be the future but open and cross platform software 
> certainly is. It is disheartening to see the maintainer of vendor's
> software not able to see the writing on the wall and not willing 
>to help with what's coming next.

Again, did you even read what I posted? I think .Net Core is the next
best cross-platform solution. It works on LINUX and Mac OS/X, and
is open source. It will help allow me and hundreds of other developers
with .Net applications to move our .Net applications cross platform.

>So how about spending time on being forward thinking and start helping INDI?

Did you miss the post where I asked Michael what features he
felt were missing from INDI driver? In fact that was the second time I asked,
and I still haven't received a response. 

As for any undocumented commands that is up to Astro-Physics. I have NO 
say in that matter at all.

-Ray 


---In ap-gto@..., <alexander.helms@...> wrote :

Windows XP is very mature. Should we just stop developing new OS's since XP is very mature? When 7 came out, way more people were using XP. XP was more stable, more mature, and had more users. I know this is a little facetious but my point is just because something is older and more mature doesn't make it intrinsically better. The software world changes so incredibly fast. INDI may or may not be the future but open and cross platform software certainly is. It is disheartening to see the maintainer of vendor's software not able to see the writing on the wall and not willing to help with what's coming next. Instead all I see is planting your feet in the ground and refusing to adapt. People want to use INDI and they want AP to support it. They aren't getting the support they want so they create their own software but are kneecapped because AP keeps the protocol proprietary. Like you said, ASCOM support is mature. So how about spending time on being forward thinking and start helping INDI?


Re: INDI AP driver

Roland Christen
 


They aren't getting the support they want so they create their own software but are kneecapped because AP keeps the protocol proprietary
That is not true. We do not keep it proprietary, only the internal servo software that controls the internal functions, not anything external.

Roland Christen


-----Original Message-----
From: alexander.helms@... [ap-gto]
To: ap-gto
Sent: Thu, Feb 22, 2018 12:54 pm
Subject: RE: [ap-gto] INDI AP driver



Windows XP is very mature. Should we just stop developing new OS's since XP is very mature? When 7 came out, way more people were using XP. XP was more stable, more mature, and had more users. I know this is a little facetious but my point is just because something is older and more mature doesn't make it intrinsically better. The software world changes so incredibly fast. INDI may or may not be the future but open and cross platform software certainly is. It is disheartening to see the maintainer of vendor's software not able to see the writing on the wall and not willing to help with what's coming next. Instead all I see is planting your feet in the ground and refusing to adapt. People want to use INDI and they want AP to support it. They aren't getting the support they want so they create their own software but are kneecapped because AP keeps the protocol proprietary. Like you said, ASCOM support is mature. So how about spending time on being forward thinking and start helping INDI?


Re: Want to use APPM with TheSkyX

Ray Gralak
 

TheSkyX has a different set of settings for automated usage. You may have to dig down in the TheSkyX settings to find them, or try searching for "SkyX plate solve failure 655" in google, which should get you to the appropriate links at the Bisque.com website.

-Ray


Re: How to use TheSkyX Camera Add-on in APPM

Stuart Heggie <stuart.j.heggie@...>
 

This seems to me to be the classic “run once in administrative mode then close program and restart normally “. 

Stuart


On Thu, Feb 22, 2018 at 2:39 PM popkrab@... [ap-gto] <ap-gto@...> wrote:
 

I try to connect the camera using SkyX Camera Add-on in APPM Run tab. When I click Connect button, I got message below


Fail to connect to Camera: Cannot create ActiveX component.

And in "Plate Solve Setting" Tab. I choose "TheSkyX ImageLink " And click "Image Link Test". I got message below.

InitPlateSolveSettings failed: Failed to create TheSkyX.ImageLink: Cannot create ActiveX component.

I don't have any idea what to fix it. I try to find out using APCC Pro pdf manual. But there was no any detail about this.

Please suggest me what can I do.

Many Thanks

Pornchai POP



Re: Want to use APPM with TheSkyX

popkrab
 

Now ImageLink using TSX Camera Addon works. The problem is I have to input "Common Setting" for x-arcsec and y-arc-sec. Then I got success for plate solve. 

Thank you.
POP


---In ap-gto@..., <popkrab@...> wrote :

Hi

I run APPM and TSX as Administrator as you suggested. It works. I can connect to the camera. Then, I try to do platesolve using Image Link in "Plate Solve Setting" tab. Then I click "Image Link Test", I choose a .fit file that I have with fit header that contain ccd information and coordinate. (wcs). Then, I click "Solve" or "Blind Solve". No matter which button I clicked, I got message below

Plate Solving via SkyXPro ImageLink

RA/Dec = 05 34 24.34 / -04 49 23.15
Use FITS for Hints = True
X/ Y Scale = 1 / 1
AllSky = True

And then around 3-5 seconds, I got another message in pink border below

Solve Failed after 4.853 seconds: 

The astrometric solution failed. Error = 655.

I don't have any idea how to fix it. I don't understand why it caused this. Please suggest me what can I do.

Thank you very much.
POP


---In ap-gto@..., <popkrab@...> wrote :

Thank you very much Ray. Will do and let you know again.

Pop


Re: Want to use APPM with TheSkyX

popkrab
 

Hi

I run APPM and TSX as Administrator as you suggested. It works. I can connect to the camera. Then, I try to do platesolve using Image Link in "Plate Solve Setting" tab. Then I click "Image Link Test", I choose a .fit file that I have with fit header that contain ccd information and coordinate. (wcs). Then, I click "Solve" or "Blind Solve". No matter which button I clicked, I got message below

Plate Solving via SkyXPro ImageLink

RA/Dec = 05 34 24.34 / -04 49 23.15
Use FITS for Hints = True
X/ Y Scale = 1 / 1
AllSky = True

And then around 3-5 seconds, I got another message in pink border below

Solve Failed after 4.853 seconds: 

The astrometric solution failed. Error = 655.

I don't have any idea how to fix it. I don't understand why it caused this. Please suggest me what can I do.

Thank you very much.
POP


---In ap-gto@..., <popkrab@...> wrote :

Thank you very much Ray. Will do and let you know again.

Pop


Re: How to use TheSkyX Camera Add-on in APPM

popkrab
 

I try to connect the camera using SkyX Camera Add-on in APPM Run tab. When I click Connect button, I got message below

Fail to connect to Camera: Cannot create ActiveX component.

And in "Plate Solve Setting" Tab. I choose "TheSkyX ImageLink " And click "Image Link Test". I got message below.

InitPlateSolveSettings failed: Failed to create TheSkyX.ImageLink: Cannot create ActiveX component.

I don't have any idea what to fix it. I try to find out using APCC Pro pdf manual. But there was no any detail about this.

Please suggest me what can I do.

Many Thanks

Pornchai POP



How to use TheSkyX Camera Add-on in APPM

popkrab
 

I am a new in APCC Pro which I intend to use with AP1100AE. In the Run tab, I want to use TheSkyX Camera Add-on as a camera. And Use ImageLink for PlateSolver. I have license for TSX with Tpoint and Camera Add-on which I got from my MyT mount. And I love the speed of ImageLink Plate Solver from TSX.


Please advise how to use TSX Camera Addon and ImageLink in APPM.


Thank you very much.

Best Regards,

Pornchai POP


Re: INDI AP driver

Alex Helms
 

Windows XP is very mature. Should we just stop developing new OS's since XP is very mature? When 7 came out, way more people were using XP. XP was more stable, more mature, and had more users. I know this is a little facetious but my point is just because something is older and more mature doesn't make it intrinsically better. The software world changes so incredibly fast. INDI may or may not be the future but open and cross platform software certainly is. It is disheartening to see the maintainer of vendor's software not able to see the writing on the wall and not willing to help with what's coming next. Instead all I see is planting your feet in the ground and refusing to adapt. People want to use INDI and they want AP to support it. They aren't getting the support they want so they create their own software but are kneecapped because AP keeps the protocol proprietary. Like you said, ASCOM support is mature. So how about spending time on being forward thinking and start helping INDI?


Re: When will Homing sensor ready?

Roland Christen
 

Yes, we have homing feature implemented in APCC for all mounts.

Rolando



-----Original Message-----
From: hmouse9@... [ap-gto]
To: ap-gto
Sent: Thu, Feb 22, 2018 1:10 am
Subject: [ap-gto] Re: When will Homing sensor ready?



Maybe this feature is already deprecated in face of APCC? Can someone from AP elaborate?


Re: INDI AP driver

Ray Gralak
 

Hi Michael,

You should be careful throwing out unsubstantiated comments like "almost
every
ASCOM driver is considerably more mature".

Based on what criteria or testing? I don't know we can make any claims
of that
nature without considerable work to back it up.
The reasoning is simple. ASCOM drivers for most of the major mounts have
been refined and updated for 15 years. They have been used by thousands of
users with hundreds of ASCOM applications. I am guessing that there are 100x
more separate ASCOM client applications than there are INDI client
applications.

You even wrote that you don't have complete confidence that your own INDI AP
driver should be used remotely:

Michael wrote:
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.
The AP V2 driver has been used locally and remotely with literally thousands
of users with all different firmware levels. It has been tested with every
AP controller and major firmware level change. It's probably been used with
hundreds of ASCOM client applications. Once and a while a bug is found but I
can say solidly that that the AP V2 driver can be used remotely with any of
those controllers.

And that's what I mean by "maturity". And I do not think this just applies
to the AP V2 driver. There may be a few exceptions, but most of the other
mount drivers are being used by many more ASCOM applications than INDI
applications. So, having been used and refined for a considerably longer
duration than INDI drivers I think makes the ASCOM drivers more mature by
definition.

-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:51 PM
To: ap-gto@yahoogroups.com
Subject: Re: [ap-gto] INDI AP driver



The future you are projecting with cross-platform ASCOM would be very
welcome as I
always like to have multiple options.

And it isn't too hard to write code to support multiple platforms - Cartes
du Ciel does
this already for example.

PHD2 is another example.

But since this promised ASCOM doesn't exist yet it really doesn't answer
the
requirements people have until this happens.

People have been waiting for a better part of a decade actually.

So for those people there is a valid alternative and we are all working on
making it
better.

You should be careful throwing out unsubstantiated comments like "almost
every
ASCOM driver is considerably more mature".

Based on what criteria or testing? I don't know we can make any claims
of that
nature without considerable work to back it up.

I also think the idea of having every ASCOM driver migrated to a new
platform is more
non-trivial than you are making it sound.

And why would you have to rewrite an entire application to use INDI?

Any properly written application will abstract these methods to minimize
the impact of
the actual implementation.

The best I can tell what you are trying to say is "If I have a decade
invested in a code
base that using Windows/ASCOM it would be best for me if everyone
continues using
Windows/ASCOM".

Michael Fulbright


On 2/21/2018 8:45 AM, 'Ray Gralak (Groups)' groups3@gralak.com [ap-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.

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: When will Homing sensor ready?

hmouse
 

Maybe this feature is already deprecated in face of APCC? Can someone from AP elaborate?


Re: INDI AP driver

Ray Gralak
 

Dale,

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.
And I'm sure that's fabulous for people who use .NET. For people who have
zero
interest in learning, writing or employing .NET, it does not matter at
all. If they wanted
to be Microsoft developers they would be Microsoft developers already, and
I'm pretty
sure if you polled them, they would have little to no interest in becoming
one.

And programmers are leaving LINUX for better waters, so you better hope that
.Net Core helps. :-)

Quoting: "Putting it in another way, the usage of GNU/Linux is declining
among the programmers."

https://fossbytes.com/os-x-windows-7-beat-linux-become-favorite-systems-used
-programmers/

grandstanding. It's astroturf. It
does the minimum to needed to even call itself open source.
.Net Core is open source. You can download, compile it, and change it for
your own use. Anyone with the appropriate skills can participate, but I am
absolutely would want that Microsoft to maintain control over the direction
of the project. After all, it is intended to make it easier for the
estimated 3-4 million .Net programmers to port their .Net applications cross
platform.

Ok, at this point I can't tell if you're purposefully trolling or not. I'm
going to assume
that you're not stupid, and I don't find your statement funny, so the only
remaining
possibility is that you must be trolling. If you're trolling, you've
completely gone off the
rails of decency and you've lost any authority in this conversation. Get
over yourself. I
definitely won't be looking for your products no matter how superior or
useful you or
anyone else think they may be.
Dale, I apologize if you my sense of humor was lost on you, but honestly I
think that some of your arguments are hopelessly out of date. And, I hope
that .Net core and the 3-4 million .Net programmers will help change the
trend in developers leaving 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:52 PM
To: ap-gto@yahoogroups.com
Subject: Re: [ap-gto] INDI AP driver





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

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. :-)
That's nice. I use vi as well. In fact, I use it pretty much exclusively
except for times
when TextMate on a Mac helps with dealing with someone's poorly-fomatted
code. It's
common (my emacs brethren included) and completely ordinary. I don't feel
the need
to look down on others because of this; and I don't appreciate solutions
being
prescribed to me for problems that don't exist, and "but what IDE can you
use" is
completely orthogonal to the concept and discussion of cross-platform.

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.
And I'm sure that's fabulous for people who use .NET. For people who have
zero
interest in learning, writing or employing .NET, it does not matter at
all. If they wanted
to be Microsoft developers they would be Microsoft developers already, and
I'm pretty
sure if you polled them, they would have little to no interest in becoming
one.

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.
That's not at all what I was getting at or what I said. It's
understandable that the bulk
of the developers and contributors for dotnetcore are MS employees. What I
pointed
out to you is that they're 100% MS employees - that dotnetcore is "open
source" in
that, yes, the source for it is open. It is *not* however a true "Open
Source" project,
because one still needs a MS employee badge to participate in dotnetcore
beyond
filing bugs or submitting patches for consideration. It's grandstanding.
It's astroturf. It
does the minimum to needed to even call itself open source.

MS still wears the pants in that relationship, and the future direction of
dotnetcore is
still very much dependent on MS's own whims. They can just as easily pull
development back inside and defund their Dotnet Foundation that'll be
that. If
dotnetcore's license allows forking, then that might be one savior, but
then you're
going to be stuck with 2 or more divergent implementations and that will
happen only
if there are sufficient numbers of non-MS employees to carry that burden -
which it
looks like they exist. This not what one can call publically-stewarded,
survivable
software, and this is exactly the kind of stuff that the OSS community has
sought to
avoid for the past 30 or more years.

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.
Ok, at this point I can't tell if you're purposefully trolling or not. I'm
going to assume
that you're not stupid, and I don't find your statement funny, so the only
remaining
possibility is that you must be trolling. If you're trolling, you've
completely gone off the
rails of decency and you've lost any authority in this conversation. Get
over yourself. I
definitely won't be looking for your products no matter how superior or
useful you or
anyone else think they may be.

I sincerely hope that Roland, Howard, and the team at Astro-Physics
continue to put
their support behind INDI, Michael and other any other application
developers who are
looking to make A-P products first-class citizens on *any* platform;
otherwise we're
going to be stuck in a ASCOM-on-Windows/.NET-on-x86 monoculture that
completely
misses the point, and this would be a sad state of affairs in the world of
astronomy
technology.

/dale




Re: INDI AP driver

Dale Ghent
 

On Feb 21, 2018, at 11:46 AM, mike@mulcahys.us [ap-gto] <ap-gto@yahoogroups.com> wrote:

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, no one is asking you to change. If ASCOM on Windows is what you have and what you like, then you should stick with it. It'll continue to be there for you and you can disregard everything else to your heart's content.

INDI is not going to make your mount track more precisely. It's not going to reduce the hot pixel count in your exposures. It's not going to reduce the sky glow from nearby cities, and it's not going to increase your OTA's contrast. It's another software stack that can exist on a range of OSes and computer architectures and is far easier to program to using a variety of different programming languages, from C to commonly-taught scripting languages. Yes, it's very geeky reasoning, but it is very attractive for people who want to exercise better control and use of their equipment using the skills they already have. For these needs, ASCOM and its confinement to Windows and .NET make it too burdensome and too inflexible.

/dale


Re: INDI AP driver

Dale Ghent
 

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

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. :-)
That's nice. I use vi as well. In fact, I use it pretty much exclusively except for times when TextMate on a Mac helps with dealing with someone's poorly-fomatted code. It's common (my emacs brethren included) and completely ordinary. I don't feel the need to look down on others because of this; and I don't appreciate solutions being prescribed to me for problems that don't exist, and "but what IDE can you use" is completely orthogonal to the concept and discussion of cross-platform.

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.
And I'm sure that's fabulous for people who use .NET. For people who have zero interest in learning, writing or employing .NET, it does not matter at all. If they wanted to be Microsoft developers they would be Microsoft developers already, and I'm pretty sure if you polled them, they would have little to no interest in becoming one.

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.
That's not at all what I was getting at or what I said. It's understandable that the bulk of the developers and contributors for dotnetcore are MS employees. What I pointed out to you is that they're 100% MS employees - that dotnetcore is "open source" in that, yes, the source for it is open. It is *not* however a true "Open Source" project, because one still needs a MS employee badge to participate in dotnetcore beyond filing bugs or submitting patches for consideration. It's grandstanding. It's astroturf. It does the minimum to needed to even call itself open source.

MS still wears the pants in that relationship, and the future direction of dotnetcore is still very much dependent on MS's own whims. They can just as easily pull development back inside and defund their Dotnet Foundation that'll be that. If dotnetcore's license allows forking, then that might be one savior, but then you're going to be stuck with 2 or more divergent implementations and that will happen only if there are sufficient numbers of non-MS employees to carry that burden - which it looks like they exist. This not what one can call publically-stewarded, survivable software, and this is exactly the kind of stuff that the OSS community has sought to avoid for the past 30 or more years.

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.
Ok, at this point I can't tell if you're purposefully trolling or not. I'm going to assume that you're not stupid, and I don't find your statement funny, so the only remaining possibility is that you must be trolling. If you're trolling, you've completely gone off the rails of decency and you've lost any authority in this conversation. Get over yourself. I definitely won't be looking for your products no matter how superior or useful you or anyone else think they may be.

I sincerely hope that Roland, Howard, and the team at Astro-Physics continue to put their support behind INDI, Michael and other any other application developers who are looking to make A-P products first-class citizens on *any* platform; otherwise we're going to be stuck in a ASCOM-on-Windows/.NET-on-x86 monoculture that completely misses the point, and this would be a sad state of affairs in the world of astronomy technology.

/dale


Re: INDI AP driver

Ray Gralak
 

Hi Michael,

OK, is there anything missing in the INDI driver that is in the ASCOM driver
that you need help with?

-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 10:07 AM
To: ap-gto@yahoogroups.com
Subject: Re: [ap-gto] INDI AP driver

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



------------------------------------

------------------------------------

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

Yahoo Groups Links



Re: INDI AP driver

Michael Fulbright <mike.fulbright@...>
 

For your use case with your requirements I don't think you would benefit from changing anything.  

But there are use cases where your solution does not meet the requirements and for those INDI offers an alternative.

It really is about individual choice and the ability to pick the option best suited for you.

Michael

On 2/21/2018 11:46 AM, mike@... [ap-gto] wrote:
 

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



PEC clarification and possible feature idea

Robert Berta
 

I have a 900 CP 3 and also a new 1100 mount with CP 4....one for home observatory and the other for travel. I use the same hand controller for both so that means loading the PEC run appropriate for each mount from my computer before use IF I want to use the CP 4 box with both mounts.


I assume the PEC run is  stored in the control box.?  If so different PEC would be stored in the control box used with that mount. so just turning on PEC would be all you need to do.


But if you use the same CP4 box with both mounts you  need to install the appropriate PEC for each mount which can be saved on a laptop. .


So if I am correct it seems it would be handy to be able to store the PEC files in the hand controller so you could upload the appropriate one to the mount.  I know that feature isn't the way it works now....but that might be a useful feature down the road.


Re: INDI AP driver

Michael Fulbright <mike.fulbright@...>
 

The future you are projecting with cross-platform ASCOM would be very welcome as I always like to have multiple options.

And it isn't too hard to write code to support multiple platforms - Cartes du Ciel does this already for example.

PHD2 is another example.

But since this promised ASCOM doesn't exist yet it really doesn't answer the requirements people have until this happens.

People have been waiting for a better part of a decade actually.

So for those people there is a valid alternative and we are all working on making it better.

You should be careful throwing out unsubstantiated comments like "almost every ASCOM driver is considerably more mature".

Based on what criteria or testing?   I don't know we can make any claims of that nature without considerable work to back it up.

I also think the idea of having every ASCOM driver migrated to a new platform is more non-trivial than you are making it sound.

And why would you have to rewrite an entire application to use INDI?

Any properly written application will abstract these methods to minimize the impact of the actual implementation.

The best I can tell what you are trying to say is "If I have a decade invested in a code base that using Windows/ASCOM it would be best for me if everyone continues using Windows/ASCOM".

Michael Fulbright

On 2/21/2018 8:45 AM, 'Ray Gralak (Groups)' groups3@... [ap-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.

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@... [mailto:ap-gto@...]
> Sent: Wednesday, February 21, 2018 12:37 AM
> To: ap-gto@...
> 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
>
>
>
>