Yes, a Transaction class is certainly more elegant. If you'd like
to add it to my latest version (attached here), that would be a
very sophisticated addition.
There is no difference between this and my last posting, except
that your "bug fix" for the single-termination-character return is
included. I suggest starting with this only because it further
confines the TX calls, such that even the Transaction class
would not have to propagate much throughout the code.
This will have to be my last tested version for a while, since
I am sending my mount base back for repair, and the mount
maker requires that I send the Pulsar controller along with
it , no doubt for testing.
Your help has certainly made a much better product!
Many thanks again,
Thanks for the contributions! I had not noticed them before,
so I have included the "cleaned up" version of the code here.
I will take a look at your modifications, and attempt to incorporate
them (or just copy wholesale). Especially true for std::unique_lock,
which (as you know) is far better/safer than manipulating the mutex
directly. So, you may ignore the attached code (although it does
contain a bug fix for attempting to synchronize while the scope
is slewing, apparently a *very* bad thing for the controller!). I
*think* I also caught what you were referring to about calls
that do multiple receives, including resynchronize.
The UserRate stuff does not work with the firmware version I am
using either. I have tried to put comments in the code, until (if
ever) we can get an answer from the developer, or from another
means. Othewise, it's just too dangerous to use, since the
controller I have supports a rather invisible rate that is not rate
1, 2, or 3!
I will return a merged version soon,
Yes, good call! Less work to do at run-time, and more compact.
Those changes are copy/pasted in to the attached version, along
with the spaces, which I removed only because I was looking at
the Meade documentation. The spaces seem to work just as well
for my more recent firmware version.
I will attempt to pass on the information related to you describe to
Jasem, but (based on ancient memory) I also wonder if getSexComponents()
is as it is because support for a signed zero (also sometimes called
"dirty zero") has varied between compilers and compiler versions.
Maybe that's just not a factor any more, and things have become
standardized -- I don't really know. At least what we have in the
driver seems relatively "bullet proof" (which is why I used abs(d)).
There were two or three things I had hoped to add (e.g., UMode
Speed Limit, Pole Crossing direction, etc.), but Andras at GTD said
that, since the project is an old one, more information may not be
forthcoming from the developer. He did volunteer to post the
Delphi-based source to the Pulsar Commander, though, which
may have more information in it.
So, do you think we have a "release candidate" here, or would it be
better to wait for the Delphi source, in order to add the two or three
items, if they happen to be there? That may take a while, and those
features could be added later in another release, since what we have
at this point in version 1.2 seems like a valuable upgrade for other
Best regards, and thanks again,
Well, it's time for the most sheepish look I can muster.
It turns out that the -1 bug was not in the controller at all, but rather
in the driver code. I was doing a lazy thing, and taking the output
that was being logged to the INDI driver page as *the* output.
It turns out that the command actually being sent to the controller
was formatted incorrectly, which I discovered as I rolled up my
sleeves to do a lot more work...it was actually just a couple of
lines to change.
Then the great news is: the problem is fixed! (I sincerely hope).
It only remains for an expert such as yourself to try the attached
code, and let me know the results.
Now I will have to send my apologies to Andras Dan at GTD!
Very very grateful for your consistent input, and most thorough
Hooray, the units and display are correct for your controller for
the non-guide speeds!
Thanks so much for verifying that -- hopefully "set" commands
above 999 will also work. (Those are undocumented at this
point, based on the documents I have.)
On the -1 bug: I haven't tested this, but let's say (for the sake of
the discussion ) that the OTA does indeed end up pointing at
the wrong place, which is a likely outcome. I did a little experiment,
and for the controller commands (or hand controller button presses)
that *move* the position, they do move the position quite happily
into that "forbidden" band. I just can't use any command that
sends coordinates, or an Altitude position (I tried that also).
Please check my knowledge on this, but I *think* that all I have
available to me to correct the position would be the LX200 move
commands, which move in one of the cardinal directions at a
given pace. That pace is the currently-selected "slew" rate
(center, find, slew, goto).
The amount of time would be dependent on the system clock,
and therefore dependent upon the responsiveness of the
system to issuing tty commands at a given interval. This
is because, as far as I know, there is no command to move
for a given period of time (except for pulse guiding, which is
not universally available, and which operates only on the
current guide rate, which is much too slow for the correction).
So, if the target Dec position were in the "forbidden zone",
I would have to detect the end of that slew, then:
1) Pick a rate (e.g., the "find" rate), change it to a known value
(adjusted for distance) and calculate the amount of time necessary
to go twice the distance, or a bit less, to the celestial equator at
2) Start that southward motion;
3) At the end of that given time (say, an alert event), issue the
command to stop the motion;
4) Check the current Dec position, and if it is off, go through a
cycle at a slower rate (say, a guide rate) to correct the position.
For this, I *could* use the pulse guide facility if available, and if
not, just cycle for a reasonable time until reasonably close.
5) Return the find rate to its former value.
Even after all this, any command that is issued that specifies
a Dec or altitude position will undo all that good work!
Please let me know if I have completely missed some much
easier way to do this.
Nice to hear you got out under the stars! Sometimes the weather
is with us.
I contacted Andras Dan about the 0 to -1 bug. He said that he was
aware that the bug had existed, but thought that it had been solved.
I have not tested that bug under the stars, only "on the bench". As
far as I can tell, it is a bit difficult to tell exactly what objects exist
where you are pointed (short of plate solving). But, the coordinates
are easy to predict -- just take the negative declination, and make
it positive, and there you are!
As far as I can tell, there is no way that the scope could do otherwise
than just point where it is told to point, because the error is actually
in the controller -- it returns the wrong value to the controlling program,
which promptly tells the scope to slew to the wrong (positive) spot.
So, I have attached the source of the next version of the driver. I have
tried to make accommodation for the non-guiding values for the motion
speed indicators. If you have the time, give it a try, and see if it reflects
what you think you need. If it does not, then my detection method
probably needs a little work. But I do print the version string to the
console area of the INDI screen, so at least that should tell us
I do hope Andras can arrange for a fix for your controller. That -1
bug is just too egregious to let stand!
Let me know how the driver works out for you, and
More clear skies!