Hello developers,

I recently acquired a Pulsar2 controller from Gemini Telescope Design, and set out to use it under INDI.

I realized that the existing driver was missing several aspects available with the new Pulsar2, so I
set out to add them, and fix a couple of long-standing issues with the existing driver. I forked a branch
from master, and made changes, and am about to check them in.

It did turn out to be more changes that I imagined it would be, so my question is: since the Pulsar2
driver is part of the "core" driver set, perhaps this should become an experimental version? On the
other hand, there were some serious problems in the 2016 version, so perhaps it's just as well to
submit a pull request, and let the community test it out? I have never done this for the INDI project,
so I am a bit at a loss as to how to proceed.

Gregory

Hi Gregory,

I have a Pulsar (original model) which supports the same commands as Pulsar2. Although the weather is not to great here the coming week I could do some tests with the updated driver.
Can I access the driver somewhere?

Best regards,
Camiel

Hello Camiel,

Are you not the creator of the original version? I am quite happy that
you decided to respond!

Since you are a developer, and presumably have the capability of building
a new version of indi_lx200generic, I would be happy to send/email you the
source (just two files, lx200pulsar2.cpp and lx200pulsar2.h). The bugs I
found mostly had to do with motion control, and were straightforward to repair.

It would be great if you could comment on and fix anything I have missed
or broken. Some things were changed simply in the course of testing,
minor name changes, etc. Mostly there were additions of the Pulsar2
features that were "documented".

In my version of the firmware, there looks to be a bad bug, where
calculations of negative declination/altitude in the one-degree-wide
band just under the celestial equator are returned by the controller
as positive. (For example, setting a value of -0.5 degrees returns
a value of +0.5 degrees). It's as if the firmware is saying that the
boundary between the northern and southern hemisphere begins
at the -1 point, rather than zero. So, perhaps somewhere, the
code is using <= (-1) rather than < 0. I don't have access to
the firmware code, so I cannot verify this.

At any rate, I will attempt to attach the files here. There is still
some debug output in the code, please ignore that, it will be
removed in a final version. Feel free to make changes and
send them back!

Thanks again for responding,

Gregory

Hi Gregory,

Today I deed some simple tests with the new driver such as slewing, (un)parking, N/S/E/W motion controls,
and enabling/disabling pole crossing, PEC, and refr. correction. All this worked fine so far. Of course an extensive
test is only possible when I get clear skies but the weather forecast is not very good for the coming week.

Here are a few comments/suggestions/questions:
1. Defaults for several numerical parameters are different from those obtained from the Pulsar controller. My personal taste is
that values from the Pulsar should always be used as the default so that values in the controller can only be changed when
the user explicitly edits and sets a new value.
2. Maybe it is better to make a separate tab (e.g., 'Advanced Setup') for parameters like currents, ramp, reduction and rotation direction.
I never change these parameters after setting up the controller for my equipment. Do you use them a lot? I also noted that when I set
current values via the hand controller, a 'Please wait ...' message is being displayed and only after several seconds the change is made.
Do you see this with Pulsar2 as well? This seems to be different from what happens when changing these parameters via the driver.
3. To me it is not clear what 'On Set' is supposed to do. I can't find anything that resembles this parameter in the documentation that I have.
Is it something specific to Pulsar2?
4. In the source code I noted that poll_mtx is never used. Can it be removed?

Regards,
Camiel

Hello Camiel,

Thanks so much for the feedback! I can't begin to tell you how valuable it is.

All excellent suggestions, I will get to work on most if not all.

1) Default values really should be as you say -- I will dig into how to do that, and make sure it happens.

2) I would also prefer a separate tab, as you say. I did not realize I *could* add a new, arbitrary tab,
but I will research that. I do not use the setup parameters frequently at all, so this would be a great
alternative to cluttering the "standard" tabs.

On the point about the hand controller, on the Pulsar2 hand controller that I received (I assume
it is the latest, sans joystick), I have never seen a "Please wait..." message displayed. Some
changes produce a kind of "reset", but that does not seem related. When parking, there is a
sort of cryptic message that appears (something like 18-6.6 MIN), before a "Going HOME..."
message appears, and that does persist until the parking operation is complete.

3) "On Set" confused me also, but I took a look at the code, and realized that 'On Set' meant "on
the setting of coordinates", so it is related to the input directly underneath the item. So, on entry
of coordinates (RA/Dec), you can choose to a) Track from those coordinates, b) Slew to those
coordinates, or c) Sync to those coordinates. I think it is more of a driver convenience, rather
than anything directly to do with the Pulsar2. I did not implement this (it's at a higher level in
the object hierarchy), so I left it as-is.

The polling mutex was just another experiment to try and find out where that tty timeout is
coming from. It happens as a result of doing a series of commands each polling period.
Mostly that works, but occasionally (as you know) it fails, and a "resynchronize" is done.
The commands are "is slewing", get RA, get Dec, and get OTA side-of-pier. At first, I
thought it was only the get-side-of-pier that was causing a problem, but actually, any one
of the "polled" commands can cause the timeout to happen. Maybe the Pulsar2 just
cannot keep up with four commands every second, I don't know. I will remove the
mutex, since in testing, it did no good.

If you have a moment, I wonder if you could check something else. I *think* I have
found a bug in the controller such that, if a Declination value between zero and minus
one (-1) is submitted as a go-to (or parameter) value, a *positive* value is returned
instead. This makes it impossible for KStars to "go to" any object in the one-degree
band between zero and (-1) degrees declination. The RA value is correct, but the
Dec value is returned as positive by the controller. This may not happen in your
firmware, but it is definitely happening in the Pulsar2 controller I am using (it has
the latest firmware version publicly available, Version 5.73a 2019.04.26),

Thanks, I will be in touch and submitting changes soon,

Gregory

Hi Gregory.

I'll check the '-1 bug' as soon as the weather permits. I'll have to open my observatory to check this but this will have to wait until the weather permits.

Ad 2. Maybe this is a difference between Pulsar and Pulsar2. I get the wait message when changing currents only. When the currents change I here short knock from the mount.
I don't get this when setting the currents from the driver. I'll check whether changing currents from the driver has an effect on Pulsar . When parking I get the same going home message.

I also use the Pulsar software when I am working under Windows. That program seems to have some connection problem too since it sometimes is not able to detect that a slew has ended.
I can imagine that a serial port buffer overflow occurs in the contoller.

Regards,
Camiel

Hello Camiel,

Thanks for the willingness to check on that potential firmware bug!
Oh the other hand, maybe there is nothing worth imaging in the band
between 0 degrees and -1 degrees declination, and the controller is
just trying to tell us that

I do most of my testing with the Pulsar2 just connected to the computer,
no mount at all connected. It seems to respond correctly, even without
a load to drive. Of course, all of my time under the stars is using the
new versions as I create them!

If there are some tty/serial shortcomings with the controller, I would
expect Windows to have a couple of problems also. And, just
intuitively, I would expect to see some differences between our
firmware versions.

Thanks so much for your suggestions, I have tried to implement them
in the new version attached to this message. If you are still willing,
give it a try, and let me know if it comes closer to what you would
like to see.

If I recall correctly, I do get a *very* quiet knock from the mount when
particular changes are made -- changing the RA rotation direction,
or the reduction parameter. Again IIRC, I do hear this even when
changing those parameters through the driver. However, I don't
recall hearing anything when the current values are changed
(tracking, stopping, goto).

Since I have recently been experimenting with changing the RA
reduction parameter, I was hoping to use the driver to do this.
However, the command to do this is documented only to use
integral values from 100 to 6000. The hand controller accepts
tenths and hundreds of these values, so for example, I could
set the RA reduction parameter to 482.34, which resembles
a "floating point" number. The "set" command simply documents
values from 100 to 6000, and returns them that way, so I can
only work with integral values. This must be a shortcoming in
the protocol, but if so, I will have to continue using the hand
controller to do these experiments. (If you wish to know, the
published specification from GTD for this value seems too
"fast" for the mount, and causes a runaway western excursion.)

Also, there seem to be a few operations that have no
corresponding commands in the protocol, or if they do,
they are not documented. For example, there should be
a command to change the pole-crossing direction (north
or south), but I cannot find it.

Thanks again, this is far beyond what I hoped would happen,
and you have already improved the driver very much with
your suggestions. Let me know if you are able to build a
new version, and how it looks and works for you.

Best regards,

Gregory

Hi Gregory,

I'll try the new version. It looks now like the weather will improve by the end of this week so I hope to be able to do a real-life test run soon.

The RA reduction problem reminds me of some tests that I did years ago. The tests consisted of sending equal numbers of east and westward guiding pulses
of equal length to the mount. Instead of ending up at the same RA position as one would expect, there was a shift in RA that increased with increasing
number of iterations. How did you detect this reduction problem?

Regards,
Camiel

Hi Gregory,
A quick inspection turned up a small problem: I have the goto speed set to 5000 which is shown correctly in the left text field in the advanced setup tab but is shown as 999.99 in the right text field.
Everything else looks fine.
Camiel

Hello Camiel,

You recently wrote:

Ah, that was a clever way to discover the potentially incorrect reduction setting...

In my case, I have been attempting do so some deep-sky imaging using the
Pulsar2 controller and a friction-drive mount. Some tests of unguided
performance (with careful polar alignment) showed a strong tendency to drift
in RA, about 8-9 arc-seconds over about 90 seconds. Attempting to guide
in this situation produced a cyclical behavior, as the drift continually forced
corrections in one direction in RA. Recent experiments in adjusting the
reduction parameter seemed to alleviate this particular problem.

Unfortunately, I could not use the driver to make the incremental changes
during the test, because of the problem I had mentioned before, i.e., the
controller protocol seems not to be able to accept the "fractional" parts
of the reduction parameter, only integral values. The necessary changes
required smaller increments, so I used the hand controller.

I suppose the problem could be in the mechanical calculation of the
parameter (less likely), or perhaps in the implementation in the controller.
At any rate, adjusting slowly, and watching the (unguided) PHD2 graph,
was how I arrived at what seems to be a better parameter value.

Gregory

Hello Camiel,

You recently wrote:

Uh oh, I was afraid something like this might happen

In the documentation for the protocol "extensions", the command
for setting the goto speed (and in fact, all of the non-guide speeds
such as center, find, and slew) looks like this:

goto speed 1-999,1-999#

So the *highest* value supported is 999 (that's 999x sidereal). I
also checked the hand controller, and it limits input to 999 as well.

If your value is set to 5000, your controller may be using different
units In that case, I may have to detect a firmware version, and
change the min/max limits (and incidentally the button labels) on
those parameters.

Or, is your mount/motor/controller combination actually capable of
5000x sidereal? That would mean that your OTA could whip across
the entire sky in a little less than 10 seconds! I don't think
my mount/motor combination could exceed about 480x sidereal,
so I currently have it set to 400x sidereal. If that is the case, let me
know, and I can detect the firmware version, or some other indicator,
and simply change the limits.

Thanks again for the very thorough evaluation,

Gregory

Hi Gregory,
In the manual of the controller dated Dec. 14, 2006, Pulsar v2.59, max goto speed is listed as 9999 which should correspond to 7 degrees/second.
Maybe that changed from Pulsar to Pulsar2? Or is a difference between setting via the handcontroller and the LX200 style commands?
Regards,
Camiel