Greg replied to the topic 'Suggestions for Optec FocusLynx/Leo configuration' in the forum. 2 years ago

Hello Jasem,

You recently wrote:

knro wrote: Thanks!! It's done.


And many thanks to you...I did notice that, and have used
it successfully already.

However....

Interestingly (I did not realize this until I ran into it),
the function checkIfAbsoluteFocuser() in focuslynxbase.cpp
decides if a focuser is "absolute" by its name (I should have
looked for this, my fault). Currently, if it detects the string
"TCF" in the name, it is determined to be absolute (and
also if the name is equivalent to "FastFocus", but that is less
relevant).

The Optec Leo is an "absolute" focuser (and is temperature-
compensating), but because this is not determined correctly
by the driver, the driver presents the option "Sync Mandatory".
This should not be set for an absolute focuser, and therefore
(again currently) has to be manually disabled in order for the
Leo to work.

Therefore, if all concur**, I suggest a small change to the
checkIfAbsoluteFocuser() function. The line that determines
whether or the the focuser is "absolute" looks like this:

if (strstr(focusName, "TCF") || !strcmp(focusName, "FastFocus"))

I suggest that it be changed to this:

if (strstr(focusName, "TCF") || strstr(focusName, "Leo") || !strcmp(focusName, "FastFocus"))

and much less confusion will result when one of the two
the "Leo" focuser types is selected.

Greg


**I not having examined this in detail, though it does
work for me in my tests...

Read More...

Greg replied to the topic 'Help Required! Polar Alignment Experiment' in the forum. 2 years ago

Continuing all,

I recently wrote:

> I suppose I could test this by doing a *very* slight jog with the mount
> control before engaging the Polar Alignment routine -- is that even
> worth trying? (I'm obviously desperate for a solution :-) )

Well, I tried it last night, and -- it worked! I actually got quite a good
polar alignment (less than one arcminute from the pole) using the
westerly rotation and the non-diagonal (i.e., non-ONAG) parity of
the downloaded image. Testing the "flipped" parity case will have to
wait for another night.

Now, there was a nightly-build update in-between the time I wrote
the original problem statement and the test, so I can't say if something
changed in the driver, or if it was my tiny jog that did it. I ran out of
time for testing, otherwise I would have verified that.

Thanks to all who put some thought into this feature. I will post
further test results when I can (now that I *can* test it!).

Greg

Read More...

Greg replied to the topic 'Minor change to FocusLynx driver (Optec Leo support)' in the forum. 2 years ago

Hello again all,

Looks as if this item has been taken care of through another thread...
thanks for perusing!

Greg

Read More...

Greg replied to the topic 'Suggestions for Optec FocusLynx/Leo configuration' in the forum. 2 years ago

Hello Jasem,

Thanks for taking a look...in file focuslynxbase.cpp, the lynxModels
array is initialized with the focuser type codes for the Optec focusers.

Here are all of the lines in that file, with the two new ones I have
added ("Optec Leo" and "Optec Leo High Torque"):

lynxModels["Optec TCF-Lynx 2"] = "OA";
lynxModels["Optec TCF-Lynx 3"] = "OB";
lynxModels["Optec TCF-Lynx 2 with Extended Travel"] = "OC";
lynxModels["Optec Fast Focus Secondary Focuser"] = "OD";
lynxModels["Optec TCF-S Classic converted"] = "OE";
lynxModels["Optec TCF-S3 Classic converted"] = "OF";
// lynxModels["Optec Gemini (reserved for future use)"] = "OG";
lynxModels["Optec Leo"] = "OI"; // <-- this is the first added line --
lynxModels["Optec Leo High-Torque"] = "OJ"; // <-- this is the second added line --
lynxModels["FocusLynx QuickSync FT Hi-Speed"] = "FB";
lynxModels["FocusLynx QuickSync FT Hi-Torque"] = "FA";
// lynxModels["FocusLynx QuickSync SV (reserved for future use)"] = "FC";
lynxModels["DirectSync TEC with bipolar motor - higher speed"] = "FD";
lynxModels["FocusLynx QuickSync Long Travel Hi-Torque"] = "FE";
lynxModels["FocusLynx QuickSync Long Travel Hi-Speed"] = "FF";
lynxModels["FeatherTouch Motor PDMS"] = "FE";
lynxModels["FeatherTouch Motor Hi-Speed"] = "SO";
lynxModels["FeatherTouch Motor Hi-Torque"] = "SP";
lynxModels["Starlight Instruments - FTM with MicroTouch"] = "SQ";
lynxModels["Televue Focuser"] = "TA";

Thanks to Jeff and Daniel at Optec for supplying the two
new focuser type codes ("OI" and "OJ"). The focuser descriptions
are theirs, but could of course be made more consistent with the
others (e.g., "Optec Leo Hi-Speed" and "Optec Leo Hi_Torque").
That's stylistically up to you all, I guess. :-) The second character
of "OI" is the English capital letter "I", not an ell or a one.

Many thanks,

Greg

Read More...

Greg created a new topic ' Minor change to FocusLynx driver (Optec Leo support)' in the forum. 2 years ago

Hello all,

I was able to get things to work with the Optec Leo focuser/FocusLynx
combination by adding just two small entries to an array of focuser
definitions in the (very well-written) FocusLynx driver. The change
passed the autofocus test, as well as various manual motion tests.

Not being a full-fledged INDI developer, does anyone know how I
would go about sending this information to the development team,
short of a pull request? It's just two lines in focuslynxbase.cpp.
The source information for the changes comes from Daniel and
Jeff at Optec.

Thanks,

Greg

Read More...

Greg replied to the topic 'Suggestions for Optec FocusLynx/Leo configuration' in the forum. 2 years ago

Hello again all,

Well, I was able to get things to work by adding just two small entries
to an array of focuser definitions in the well-written FocusLynx
driver. I not being a full-fledged INDI developer, does anyone know
how I would go about sending this information to the development
team, short of a pull request? It's just two lines in focuslynxbase.cpp.

Greg

Read More...

Greg replied to the topic 'Help Required! Polar Alignment Experiment' in the forum. 2 years ago

Hello yet again,

I recently wrote:

> I don't know if this is significant at all, but I noticed when using
> the Mount Control that when the mount is "un-parked", the
> tracking status indicator in both the mount control ("Status: Tracking")
> and the Ekos mount screen (square tracking "ON" and "OFF" buttons)
> indicate that the mount is tracking, when in fact it is not. The motors
> remain off after the un-park, and the RA indicator continues to climb,
> as it does when tracking is off (which in fact it is).

After several tries of this, I noticed that the indicator on the mount
control does indeed go to the correct status ("Idle") for a brief moment
after the un-park is complete, before incorrectly going to "Tracking".

Curious.

All this perusal, of course, in the hope that (perhaps) because tracking
is not engaged after the park, then the RA is not being universally
updated after the "go west" or "go east" commands -- a completely
uninformed hypothesis. :-)

I suppose I could test this by doing a *very* slight jog with the mount
control before engaging the Polar Alignment routine -- is that even
worth trying? (I'm obviously desperate for a solution :-) )

Greg

Read More...

Greg replied to the topic 'Help Required! Polar Alignment Experiment' in the forum. 2 years ago

Hello again,

I don't know if this is significant at all, but I noticed when using
the Mount Control that when the mount is "un-parked", the
tracking status indicator in both the mount control ("Status: Tracking")
and the Ekos mount screen (square tracking "ON" and "OFF" buttons)
indicate that the mount is tracking, when in fact it is not. The motors
remain off after the un-park, and the RA indicator continues to climb,
as it does when tracking is off (which it in fact is).

If I do a mount motion (in this case, pressing the east or west buttons
on the Mount Control), then tracking is *truly* engaged, and the
previous two indicators are unchanged, and have suddenly become
correct. But they are *incorrect* immediately after the un-park
operation.

Greg

Read More...

Greg replied to the topic 'Help Required! Polar Alignment Experiment' in the forum. 2 years ago

Hello Jasem,

If I understand the task correctly, his was an easy "indoor"
test to conduct, so I just set up the mount, connected, and
made sure that I could "park" it in the homed position
(A-P calls this "park 3", which is the typical position of
counterweights down, pointed to the north pole). For my
location and time, this currently gave an RA reading of
02:57:19 (DEC 89:57:06).

I then brought up the Mount Control dialog and "un-parked"
the mount. Since it was not tracking, this started the RA
to increase each second by about a second.

I then clicked and held the "west" button for about three
seconds at 600x. This gave me an RA of about 02:28:41
(decreasing, as you would expect for the westerly direction).
This also started tracking.

I then pressed the "east" button for about six seconds at
600x. This gave me an RA of about 03:19:11 (increasing,
as you would expect for the easterly direction).

The declination did not change during these tests.

Unfortunately, I will probably not have clear skies to test
and collect logs under the stars for about three days (also
will miss the lunar eclipse tonight, if the forecast is accurate. :-) ).

Greg

Read More...