Date   

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
 

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





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@... [mailto:ap-gto@...]
Sent: Wednesday, February 21, 2018 5:52 PM
To: ap-gto@...
Subject: Re: [ap-gto] INDI AP driver





On Feb 21, 2018, at 3:39 PM, 'Ray Gralak (Groups)' groups3@...
[ap-gto]
<ap-gto@...> 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@... [ap-gto] <ap-gto@...> 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@... [ap-gto] <ap-gto@...> 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@... [mailto:ap-gto@...]
Sent: Wednesday, February 21, 2018 10:07 AM
To: ap-gto@...
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
>
>
>
>



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@... [mailto:ap-gto@...]
Sent: Wednesday, February 21, 2018 11:50 AM
To: ap-gto@...
Subject: Re: [ap-gto] INDI AP driver





On Feb 21, 2018, at 10:21 AM, 'Ray Gralak (Groups)' groups3@...
[ap-gto]
<ap-gto@...> 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@... [ap-gto] <ap-gto@...> 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