INDI Library v1.9.9 Released (30 Nov 2022)

Bi-monthly INDI Library released with new drivers and bug fixes.

Driver OnStep (LX200 like) for INDI

  • Posts: 304
  • Thank you received: 24

I do not use guiding up until now, but maybe moving to it in the near future.

What I heard is that the internal guiding in Ekos is not the best. People have had better luck with PHD2. But what I want to try first is lin_guider, since it already has a prebuilt package in Ubuntu's repository (no need to compile PHD2, ...etc.)

But I need to get a guiding camera first ... The Rising Tech IMX224 camera on AliExpress seems like good value. But that is for later.
3 years 10 months ago #34528

Please Log in or Create an account to join the conversation.

  • Posts: 107
  • Thank you received: 4

I had bad luck als yesterday with the internal guider. It was not possible to get nice round stars. I did try a lot but there is still a lot of settings
and that cost a lot of time. (OnStep with Pulsguiding, Pole Polemaster aligned) At the end i used PHD on the mac better results but the program is not stable, So i like to get the internal guider to work. There for the questions to see what is used most.

Look Cool this Camera, I use a Lodestar, still happy with this guy,

By the way i installed PHD2 on my RaspPI3B this are the step
• sudo apt-add-repository ppa:pch/phd2 
• sudo apt-get update 
* sudo apt-get install phd2
3 years 10 months ago #34536

Please Log in or Create an account to join the conversation.

  • Posts: 155
  • Thank you received: 37
I find that with my 6" it depends on the Sky. It also has a self-made DEC worm, which isn't perfect.

In great sky PHD2 seems to work better. However, in passing-cloud skies Internal seems to work better. PHD2 goes crazy sometimes.

I added a fix (basically taking out a check) for the focuser if you use negative values.) I'm working on adding the few new things for the DC focuser support. (For the most part, it should be usable now, without being able to adjust power level control.)

On that, a question for people, since there are two ways I can do that: INDI has a variable power setting for focusers. However, the power level is stored in nvram. Which means a write anytime it's changed. I don't know how often that might be, so I'm tempted to completely bypass that, and have it be something that's NOT settable automatically via that mechanism. (So as to avoid killing the limited numbers of writes.) Thoughts?
3 years 9 months ago #35161

Please Log in or Create an account to join the conversation.

  • Posts: 332
  • Thank you received: 42
@ James,

Sorry I had to close the pull request for negative values on focuser since Indi assumes only positive.
I would suggest changing the focuser set-up intead of e.g. -25 .. + 25 to 0 .. 50.
For the time beeing better to stay as is.
By power level, do you mean the new feature added fo DC motors?
// :FP# Get focuser DC Motor Power Level (in %)
// :FPnnn# Set focuser DC Motor Power Level (in %)

In my understanding is that this parameter is controlling the DC motor minimum speed to avoid motor stall.
If so it is a tuning parameter and should not be changed once set for a given focuser.
If I am wrong and this parameter serves as speed control for the motore then I think it shpould never be written to the EEprom.

In both case this could be covered in InDi by just having a set point that is updated only on manual set.
3 years 9 months ago #35162

Please Log in or Create an account to join the conversation.

  • Posts: 257
  • Thank you received: 22
Quick side note on focusers. my DIY focusers use the Moonlite_focuser driver which has a way to enter an offset. I've used it quite a bit as my diy focuser uses a byjxxx gearhead stepper and requires quite a few thousand steps for complete travel even though it's connected to the 1:1 shaft. Because of this it is sometimes necessary to enter an arbitrary value in the middle of the range (i.e. 0-60000 =30000) to allow in and out travel. Might be worth perusing that code for interfacing tips.
3 years 9 months ago #35185

Please Log in or Create an account to join the conversation.

  • Posts: 332
  • Thank you received: 42
Just for reference, Jasem's statement about this : github.com/indilib/indi/pull/859

So if I understand well there is a "sync" command in Indi to say the focuser is at a certain value.
I don't see a way to sync in OnStep firmware, is there one except the "zero"?

If I follow Blueshaw, an offset of max/2 would solve this issue.
Just for info, here my focuser set-up (than explains why I don't need the negative value or offset)
#define MinAxis4 0.0 // minimum allowed Axis4 position in millimeters, default = -25.0
#define MaxAxis4 38.0 // maximum allowed Axis4 position in millimeters, default = 25.0
and whith this set-up I have 38000 steps to travel these 38mm with 0 fully retracted. (48 step motor, and approx 20,8/1 gear)
When I start I set the focuser mechanically to zero (0), initialize the focuser to Zero and from then travel to approx half travel where my focus usually is and I'm done.

May be James has some ideas.
3 years 9 months ago #35189

Please Log in or Create an account to join the conversation.

  • Posts: 332
  • Thank you received: 42

After some review in Onstep firmware I think there is no way to sync the focuser in a arbitrary position without modifying Onstep firmware.
All the Onstep Focuser1 commands are here (Driver supported):
// :FA# Active?
// :FAn# Select focuser 1 or 2
// :F+# Move focuser in (toward objective)
// :F-# Move focuser out (away from objective)

// :FQ# Stop the focuser
// :FG# Get focuser current position (in microns)
// :FI# Get full in position (in microns)
// :FM# Get max position (in microns)
// :FT# get status
// :FZ# Set focuser position as zero
// :FH# Set focuser position as half-travel

// :FF# Set focuser for fast motion (1mm/s)
// :FP# Get focuser DC Motor Power Level (in %)
// :FPnnn# Set focuser DC Motor Power Level (in %)
// :Fp# Check for focuser pseudo absolute mode
// :FRsnnn# Set focuser target position relative (in microns)
// :FS# Set focuser for slow motion (0.01mm/s)
// :FSsnnn# Set focuser target position (in microns)
// :Fn# Movement rate, 1=finest, 2=0.01mm/second, 3=0.1mm/second, 4=1mm/second
Set an arbitrary position without moving the focuser:
With OnStep we can only set to 0 (:FZ) or half-travel (:FH) but not any other position.
If we would want to add SyncFocuser Onstep firmware should be modified.
Should we ask to Howard for a change?

Use relative negative movements: // :FSsnnn# Set focuser target position (in microns)
As per Jasem's answer this would break Indi/Ekos since all setpoints for movement / position are defined as (unint), see Focuser Interface
I would be possible to calculate an offset if the returned range (:FI and :FM return values ) is -25000 to + 25000 and present a 0 to 50000 to Indi but this would create even more confusion.
I still don't see a solution here.

Set focuser Speed:
This could be supported by SetFocuserSpeed I presume provided we override the function to deduce the :Fn# arguments (1, 2, 3, 4) from a 0/100% saying 0-25 = 1, 26 to 50= 2 51 to 75=3 and 76 to 100=4 for example.
3 years 9 months ago #35217

Please Log in or Create an account to join the conversation.

  • Posts: 155
  • Thank you received: 37
The major issue comes in when someone, like me, goes, I'll set min/max to +/- 50000 Which seems reasonable.

:FH and :FZ both initialize to 0, which requires human intervention/uploading the firmware. I can probably shift it (now that I've realized it's IMO unwisely uint), but that means any problems with OnStep, will have a different number than is in the hardware.

I'll as noted in the pull request submit an issue, followed by a pull request, to change it from uint32, to int32, because the restriction seems contrary to the INDI protocol (the one focuser actually shows a negative position.) I'm going to be honest, after looking through 13 of the 21 drivers that do absolute focusing, yikes. I have found exactly one that uses unsigned for how it deals with the uint32_t. Well, 3 I guess if you count Hex. There's no reason at all for it to be a positive number at all. I suspect it was just how some focusers work, and it got based off of that.

Nothing so far that I've looked at uses more than 20 bits. There would only be a few driver changes required. Also, as far as I can tell, OnStep has greater ability to handle ranges, but with the timing, heh! But at 1 millisecond (default is 8 ) 20 bits of change would take 17+ minutes. (Depending on hardware it may use a 4-byte float/double, or an 8-byte double) Anything above that I think is kinda silly, unless you've got some amazing measuring equipment and are down in the nanometer range. (SEMs for telescope alignment?)

Ironically, at least one I looked at briefly last night (not in the 13 I've looked at), there was one also work with negative numbers via treating the uint as int, and enforcing the greater than 0 will actually break that one.
Last edit: 3 years 9 months ago by james_lan. Reason: Auto smileys are annoying.
3 years 9 months ago #35246

Please Log in or Create an account to join the conversation.

  • Posts: 332
  • Thank you received: 42

I remember when I started testing my stepper focuser with Onstep (before I had a self built DC type), I started with default settings (-25 .. + 25) and it was working with Indi but I changed during tests because I never was able to set my origin so I chose to use 0 .. 38 instead. (Just to say the reason was not software, just simple mechanical fact)

By the way, what means IMO?

Nevertheless, there must be an objective reason why Howard did set the default to -25 .. +25, so we should find a solution.
So I decided to change my set-up again to relative (-19 .. +19) to fit with my 38mm stroke to be in position to test this with Indi again

Seems we have other issues too. I made many tests yeasterday and dis the mistake to upgrade OnStep to last Alpha.
At a fist glace everything seemed working fine and then I discovered that Speed adjust :FS# :FF# and :Fn# do not work anymore.

I asked also on Onstep Forum wait and see
Last edit: 3 years 9 months ago by Alain Zwingelstein.
3 years 9 months ago #35251

Please Log in or Create an account to join the conversation.

  • Posts: 257
  • Thank you received: 22
IMO ~= à mon avis :D
We all value your opinion greatly @James_Lan. I read through the git discussion also.
Sync - (I knew it had a name ;-P)

tl;dr I think it's more of a machine thing than a program thing.

Very interesting discussion. One side effect of programming in short pants(opensource) is that it can be like herding cats when so many different bits of hardware come together. I'm not surprised there's already a negative going focus driver as it does seem likely to happen in normal use due to system startup favoring 0 unless an offset specifically loaded, but it tends to leave you with an unknown index. Some focuser developers may not have been working with repeatable indexes in mind, especially the DC motor ones.
In industrial robots, we "home" a traverse/arm/spindle etc. to get a calibrated position. "home" is always a 0 or 0,0 and locked to physical encoder indexes or mechanical/hall effect limit switches. Only robots that zero at a midpoint use negative numbers. Our gem mounts are one example of the latter, and we all know how picky alignment is from that variable location(viva la platesolving). Onstep is ahead of the curve on this btw, having inputs available for homing switches; nice touch Howard.
I see Jasem's point about setting this arbitrary home position(all the way in) at 0 because this means your known locations are always going to be "out/positive" from there. This gives you a repeatable and locked "home" point with which to base your movements and then all offsets are positive from there.

@KNRO: Storing the previous session's focus position to XML might be a nice option.

Hope this makes it easier. :D
3 years 9 months ago #35271

Please Log in or Create an account to join the conversation.

  • Posts: 332
  • Thank you received: 42
@ Blueshawk,

Thanks for your input ... especially for the IMO :-) ... I have really problems with acronyms also in French!

More seriously, I asked also Howard about the -/+ and the here the answer .

There is also support in the interface to store settings to file, just a matter of thinking about what needs to be stored.
I really would like to work on both sides, Firmware modification to allow Sync, Reverse, Speed control as well as stting saving.
But to reach the goal I must be sure both Sides are happy whith the modifications.
Seems on Howward side there is agrreement on that.

A propos Focuser speed control, did somebody experience with that?
3 years 9 months ago #35276

Please Log in or Create an account to join the conversation.

  • Posts: 155
  • Thank you received: 37
Posted the suggested change here as an issue: github.com/indilib/indi/issues/866 (And I'm about 50% done with the pull request)

The takeaway from reading through all the things that implement focuserinterface and the focuserinterface is that, 20 bits is all that's used aside from OnStep and OnFocus and to go through that, even at 1 step/millisecond and 20 bits is a 17 minute focus!

Also, everything communicates with the mount as if it's already a signed integer, fixing it to actually act like the documentation would be more issues than the reverse. (gcc, which is almost certainly the compiler used for INDI, will let you call printf(%d) with an unsigned integer, not give you a warning, and output it as a signed integer, which is part of why everything works for me. Actually, based on a quick look, so will Microsoft's compiler. There is only a single driver that actually treats it with the proper %u, and that's only for warnings not for output to the focuser.)

Internally, focuserinterface actually uses signed integers in it's calculations.

Most drivers also represent it internally as well, and I'd say that aside from one using an unsigned short (16-bit), and a few using uint32_t, most use signed doubles. Our current implementation relies alone on the FocuserInterface, and the INDI number variables are doubles. (Frankly I see a lot of unnecessary code in many many drivers. ie, lots of bounds checking, and because I looked at other drivers initially, I did that too.)

FocuserInterface also needs to have support for more than 1 focuser, but that's a separate issue. (And it should be pretty simple to handle, now that I've gone through things.) There's also the rotator interface, which can be used for OnStep.


As far as speed control: That isn't something that's going to matter for Absolute positioning.

A brief overview as to why that exists, and why I ignored it:

LX200 was designed when there were only DC motors, so you'd have a speed + time + direction. You can see this still reflected in www.indilib.org/api/classINDI_1_1FocuserInterface.html with MoveFocuser, which gives you reasonable control over DC, and you REALLY need to be able to control the speed for fine vs coarse focusing. The methodology aside from computers was a hand controller with a few speeds and buttons for each direction.

This translates into the LX200 commands, which were the only ones for a while: In, Out, Halt, Fast, Slow, %speed www.meade.com/support/LX200CommandSet.pdf Looking at the newer protocol specification, www.meade.com/support/TelescopeProtocol_2010-10.pdf added some more like time for pulse and such.

However, OnStep uses steppers, with given positions. So instead of trying to use the above, there are more useful commands, where we can tell the focuser go to position X, and barring mechanical or electrical interference/problems it will. There's no need to go at 1mm go for 5 ms In/Out. When you can go: Make 2 steps. It is limited by the rate specified per axis (default is 8ms/step at least on Megas, probably lower on others) (Ok, it's actually defined as micrometers theoretically, along with a conversion factor between steps and physical motion. I personally just set that to 1 micrometer/step, as trying to calculate that on at least one of my setups was probably inaccurate and would require disassembly of the focuser (again). I'd say that's the best method, unless for some reason you know the proper physical conversion and want it to be stored like in the FITS header, I don't see much of a point.)

So I have left speed out of the implementation, because IMO it's useless for anything from within INDI. It might not be for a hand controller (I know some people have SHCs with focusing. Frankly there I'd use absolute.) Frankly, if allowed, I wouldn't have done anything with MoveFocuser, if it weren't a required function. (I used relative movement, ignoring speed, and using the duration as ticks) same as MoveRelFocuser). Relative moves update the Abs position in OnStep, so there's no issue.

So unless you have a reason to want to implement focuser speeds (and I honestly can't think of any good reason, unless you want compatibility with really old lx200 software, but that wouldn't be going through INDI) I would just ignore them completely.
3 years 9 months ago #35378

Please Log in or Create an account to join the conversation.

Time to create page: 0.862 seconds