Hello Camiel,

Ok, I will make some sort of change, but....

Check my calculations. The sidereal day is about 86164 seconds,
which means that, in order to go 360 degrees, the sidereal "rate"
in degrees/second is 360/86164, or ~0.0041781 degrees/second.

In order to go 7 degrees per second, you would have to travel
at ~1675x the sidereal rate. I don't see how this is related
exactly to the 9999 max value...if we call it 10000, then the
unit is 0.1675x sidereal. It seems rather strange, but if that's
it, then that's it.

If you have the time, please check the other speed designations
and their maxima. In other words, are the maximum values for
center, find, and slew also 9999?

My hand controller will not let me exceed the three-digits (999)
for any of the above speeds. For guiding, the unit on my
controller is 0.1x sidereal, and the input values allowed are 1-9.

At any rate, I will make the change for at least the goto speed,
and see if it works for you! If the other non-guiding speeds are
included in the range to 9999, I can change those also.

Many thanks again,

Gregory

Hi Gregory,

There is definitely a difference between the two controllers here. The same range of values is allowed for center, find and slew speeds.
In the documentation of the center speed, it says that '1 = 6x sidereal' (should this be 1/6x ?) while for guiding it says '9=sidereal'.
Anyways, with my setting of 5000 for the goto speed, the motion of the mount doesn't seem excessivly fast compared to other mounts I own.

Regards,
Camiel

Hi Gregory,
Since the weather turned out better than the forecast, I have been able to have a look at the -1 bug. It turns out
my Pulsar controller also has it. Both the hand controller and the INDI driver show an incorrect declination.
Since it is not dark (and clouded), I can't tell what the telescope is pointing actually at. Have you tested under the stars
what the actual motion of the scope is?
Regards,
Camiel

Hello Camiel,

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 values for the non-guiding 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
something.

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!

Regards,

Gregory

Hi Gregory,

The units for the non-guide speeds are reported correctly for my old Pulsar.
I hope to do some longer test runs under the stars soon but I think there are no major issues with the new driver.

Concerning the -1 bug, I can only think of two sources for this problem:
1. the conversion of the declination in string format as send with the slew command
to an internal (binary) format goes wrong, or
2. the conversion from this internal format back to the string that is displayed on
the hand controller and/or returned by the get position command contains an error.
In the first case the pointing is off, in the second case the pointing is correct.
In both cases a fix in the driver is possible although it will be somewhat simpler in the second case than in the first.
Since the bug is an old one, most Pulsar controllers will have it, so correcting it in the driver has the advantage that
every Pulsar user can profit.

Regards,
Camiel

Hello Camiel,

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
that rate;
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.

Regards,

Gregory

Hi Gregory,

So your test result indicates that we have the first of the two cases to workaround.
I'll do the same test with my controller.

There are three different types of movements that we can distinguish:
1. a motion from outside to inside the problematic declination range,
2. a motion within this range,
3. a motion out of this range.
The last one causes no problems of course.

To deal with the first one, we can issue a goto command just North or South of the range
depending on which is closer to the desired position and then apply the procedure that you describe.

For the second type of movement, we can use the same procedure for large movements. For small
movements, such as issued when kstars adjusts the telescope pointing based on astrometric data,
it may be better to use just move commands without goto.

Regards,
Camiel

Hello Camiel,

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
testing!!

Regards,

Gregory

Hi Gregory,

Good to hear that you found the cause of the bug. The driver code
is quite complex which doesn't help bug solving.

It looks like this evening there will be some gaps between the clouds
so that I'll hopefully be able to test the driver in an operational setting.

Regards,
Camiel

Hi Gregory,

There is just one small problem with the driver that I encountered: after the :Sr and :Sd commands,
and before the RA/Decl. are given, there should be a space. My old Pulsar controller needs it to properly
process the command. Furthermore, no more '-1 bug' for me either.

An alternative for your code which does not require hard-coding of the position of the + or - sign and allows
the format string to be a constant is:

bool setObjectDEC(const int fd, const double dec)
{
int d, m, s;
getSexComponents(dec, &d, &m, &s);
char full_cmd[32];
snprintf(full_cmd, sizeof(full_cmd), "#:Sd %c%02d:%02d:%02d#",( dec < 0.0 ? '-' : '+' ), abs(d), m, s);
char response;
return (confirmed(fd, full_cmd, response) && response == '1');
}

When I think about this, it seems that the bug is actually in the function getSexComponents().
It does not (or no longer?) return a signed zero value in the argument 'd'.
A quick 'grep' for it shows this function is used in many drivers. Maybe something to report to Yasem?

Regards,
Camiel

Hello Camiel,

Yes, good call! Less work to do at run-time, and more compact.
Those changes are copy/pasted into 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 getSexComponents()
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
Pulsar2 users.

Best regards, and thanks again,

Gregory

Hi Gregory,

I'll try the new code.

It would be useful if the solution for the sign problem in the driver could be moved to the getSexComponents() function.
This requires changes in many drivers but a this would be required anyways to fix this problem.

I think the driver is good enough to be released .

Next to adding a few more commands, a bit of code cleanup would be good as well. E.g., it would be better to get all
code involving the mutex localized by introducing a function sendOnly(). The low level send and receive functions could
then be hidden in a private scope. At the time, the serial port code of the standard LX200 driver didn't work well. It may be
worth to check whether this is still the case. If not, we could use the generic routines which saves some lines of code.

Regards,
Camiel