Using cached pyindi-client-0.2.7.tar.gz (5.5 kB)
And clear the cache in your .local/cache directory, it seems pip may have some issue here when I only change minor/minor version number (0.2.7 to 0.2.7.a for instance).
I never used ascom vspec, I suppose it uses the variable rate setting capability of eqmod mounts (maybe other mounts?). You may do the same in indi at the telescope class level (this is not limited to indi-eqmod). The only problem would be to retrieve the worm position between restarts, I don't remember if there is an access to the worm indexer in the skywatcher protocol for instance. And how ascom vspec may do that.
Concerning guiding software I am totally ignorant.
npindi is basically a python rewrite of some indi base class in addition to the indi client qt classes used in kstars. That are those "kstars" qt classes which need some work if you want to stay in sync.
With current pawel's work the indi base class may also need some rewriting. Now, as long as the INDI xml format remains unchanged, npindi should continue to work whatever implementation is used in C++.
If you only need a basic client (I suppose you only need to translate INDI messages into JSON format and send that through a webservice), you may only keep or start from the npindi base class. In your case you may even suppress the receiving thread if your client has nothing else to do. Mmmh, maybe should you also listen to your app...
@HADES Thanks for giving such a clear explanation.
The driver only exposes the hardware PPEC implementation. And this one kills guide pulses as it overloads axis speed at constant interval using speed values stored in microcontroller eeprom (after training).
As long as you have continuous axis speed setting in a driver, PEC is better (and in a simple manner) performed using a software implementation. That may be done at the INDI telescope class level, but I wonder if guiding software should not be aware of this PEC correction. It seems it is best if they do the whole thing.
@pawel Thanks for helping, I really can't make new pyindi-client versions as updates are commited in the indi-core master branch. IMO this may not be the best way, as you may have to add code because of swig limitations, code that you are going to suppress on the next indi-core release as you want to keep it as simple as possiblle.
I made pyindi-client years ago, just to see if this was achievable at low cost (I remember I started with using another wrapping tool, SIP). And I was unaware that it was used in subsequent projects since then.
I've proposed to @pawel to include pyindi-client directly in indi-core. I just can't support it alone.
@dolguldur and @GuLinux Don't wait a support for npindi. Really too large.
@dedicateastro The docs for pyindi-client are the C++ docs for IndiClient. No more, no less (almost). I don't want to write a documentation on how to design an indi client.
Don't forget that when you polar align, you're pointing near the celestial pole by definition, and there, RA visually corresponds to a rotation of your scope around its optical axis. You could be 12h00 shifted in RA at the pole, Polaris will still be in your FOV, simply it will be on the wrong side of the celestial pole. Polaris being only 45 arc minutes from the pole, you should be very precise when you make your alignment (depends on the magnification of your polar scope). Your 20 minutes error is only a 5 degrees error **in rotation** of Polaris around the pole. Maybe half the diameter of Polaris itself as you see it through the polar scope (just an estimate). And if you simply spent 5 minutes between the time you set the RA angle of Polaris in your polarscope and the time you finish your alignment, you're 5 minutes away.
Not sure where your 20 minutes error comes from, as you did not find the AlignData file, that may be a plate solve/sync near the pole. Here too depending on the resolution of your imager and the quad star the astrometry solver finds in your image, you may get high error in RA when you sync near the celestial pole.
Anyway the problem with the meridian flip not occurring is a software issue, it seems that INDI/Ekos/client devs have to discuss this point and decide the correct way to go for mount drivers which can sync.
In your situation you may simply set a flip HA 1.00 hour past the meridian, just check your setup allows for that (it depends on the declination of your target though, your latitude, your pier...). That way you may live with a 20 minutes alignment error, the meridian flip will occur 1h00 past the celestial meridian.
To be honest you are not the first to report this problem and I already tried to explain why meridian flip may not occur (regarding indi-eqmod at least, I don't know for other drivers which are using alignment).
Eventually there may be some misunderstandings between developers. Here is my understanding:
Meridian flip is used in order to keep down the counterweights of the mount, avoiding your equipment to hurt the pier. If your mount is perfectly aligned, the mount meridian coincides with the celestial meridian, and a meridian flip should occur when the mount crosses this unique meridian. Now suppose you turn the pier of your mount 45 degrees to the west. The mount is misaligned with deltaRA = 3.00 hours and the alignment system will correct that for you and track your target as desired. At that point, if the driver performs a flip when the target crosses the celestial meridian, this will result in a counterweight up position, as the target is still 3.00 hours before the mount meridian. And that's not what you want in order to preserve your equipment. That's why indi-eqmod may not perform a meridian flip if the corresponding goto is still before the mount meridian.
To sum up a meridian flip is related to the mount coordinate system and should occur at the mount meridian, never at the celestial meridian. And that may be before the celestial meridian when the pier is shifted to the east.
@jpaana Thanks for answering, I have not thought to that case. I don't know the precision you get when using a high quality mount in a fixed observatory and how alignment may still be relevant in such a case.
@vineyard The mount driver does not have a 'meridian flip' command. It only offers track, slew and goto (and sync, guide). When tracking or slewing, it runs as long as it is told to run, even if it crosses the meridian (it may stop if you have set/enable limits).
You may make three turns in RA if you like. Concerning gotos, it always performs a goto with counterweight down at the given target (unless it is told to do counterweight up, there is a property switch you may set before issuing your goto).
That way, client/user may image passing the meridian without performing a flip if its setup allows it. Or it may start a session east of meridian without performing a flip if it starts counterweight up.
You have nothing to fix in your case. If you repeat your last test (start tracking east of meridian counterweight down, no alignment), just wait the target pass the meridian, then manually issue a goto in kstars to the same target, the mount should flip.
As I previously said, the problem seems to be that the client (Ekos) is using celestial coordinate to issue the goto performing the flip. It should use the true telescope coordinate, or wait for the side of pier property to toggle (the driver uses true telescope coordinate to compute this value, unless someone changed that).