Just a note on the focuser. You do not design a "GUI" in INDI per se, but rather have to follow the existing INDI Focuser interface & functions, and it will define the appropriate properties accordingly.

Jasem,

Language abuse on my side! thank you to follow our discussion and to steer us in right direction when we go the wrong way.

I fact the compliance with Indi focuser interface is my concern, I don't want to change the code ending up in non compliance.
there are some different point of view for example concerning on how to save focus points (one would use firmware , I would like to use Indi approach)
I whant to clarify this before doing anything else.

Right. A question: If you look at the LX200 generic, which does not implement the focuserinterface, that's not the right way to do it? (I'm basing my focuser stuff off of gphoto)

I ran into a problem with AbortSP being reused a lot of places, and posted in the development forum. (While I'm sure there's a way to solve it via C++ inheritence, there doesn't look like a nice clean way aside from renaming.) indilib.org/forum/development/3224-variable-reuse-abortsp.html

One problem we run into with OnStep is that it can support two focusers. Is there a good way to handle that? (I'm less focused on that than getting one focuser working with Ekos, so if something like the current not-using-focuserinterface is used, that's fine with me for now.)

Alright, so the entirely untested on telescopes (I have a mega I test on, that's how I found, and confirmed in the code the if using :FS or :FR that :FQ does nothing.

So very glad it wasn't on the telescope.

If you want to fix that, in OnStep, Command.ino change the FQ to handle it by adding the bolded parts:
// :FQ# Stop the focuser
// Returns: Nothing
if (command[1]=='Q') {
amountMoveAxis4.fixed=0;
targetAxis4.part.m=posAxis4;
targetAxis4.part.f=0;
quietReply=true;
} else

Here is the branch. Note that the testing is limited, but if you want to play with it. It currently has both, the prior focusing code, AND that of the FocuserInterface (ONLY working on Focuser1 (As above not sure of the right way to do a focuser2, and this will show if it can focus or not(similar to gphoto showing my digital camera when it can't focus the telescope (It could through a lens))
github.com/james-lan/indi/tree/focuserchange

(Now, to actually fix the focuser physically on mine!)

So, that issue with FQ not working was already fixed in OnStep Alpha. I found a similar issue with the FT, which I'm using in my branch for checking to see if the move is done. Howard already put it into the OnStep Alpha. So use that with my test branch.

It at least with the CCD simulator (and it's randomness) Ekos will autofocus. (Untested on real hardware, more than the mega I uses for testing.)

Known issues currently:
Values for min/max are not upated in Ekos unless , it pulls them in on UpdateFocuser... but doesn't update Ekos until you disconnect/Reconnect OnStep.

My thoughts for the best way for this to work:
OnStep configuration set to 1 step per 'micron', min set to 0, max set to wherever makes sense.

The max rate when using FR/FS is set by the MaxRateAxis4 and how many steps. So the speed controls don't matter, and I took them out with the latest commit.

James,

I see you make nice progress in your development.
Just for information, I checked with Howard about the presets. He is thinking to use EEprom to save presets in frimaware (most probably adding some new commands). As far I saw till now in Indi presets are saved on driver side. May be recheck with Howard before starting coding on this part.
As soon I have some time (spring is comming and somebody keeps me busy on other tasks I will test your code in real.
That's all promising improvements and will add a new brick to the Driver.
Don't kow you follow the posts in This email address is being protected from spambots. You need JavaScript enabled to view it., it seems interest for Indi is growing also there.

Bon courage

James,

lucky me, it is raining like deluge so I could take some time to test your code.
From a focuser point of things are ok.
Ekos does not recognize that there is a focuser. How did you setup Ekos to detect OnStep Focuser?

Thanks

I follow the onstep list.

As far as it is. make sure you are on on focuserchange branch, rather than my master branch. I haven't merged it in to master yet.

That explains this

I wil try it.

Just for indo, did not comile, you need to commenbt out SetFocuserSpeed in header file.
But it works

I fixed that and committed it a while back.

Finally, had a time where I could get out and do some testing. Unfortunately with light clouds, allowing some work for a while.The autofocus works (Subject to the backlash of the device), but a few times, it would decide to just start taking several exposures with the camera. I don't think that's a problem with the OnStep driver, but I'm not sure if it's Ekos, or the gphoto driver. So I'll look at merging it to my master and on up. As well as removing Focuser 1 separate controls from the interface. (Still don't know the best way to do a second fouser)

Also got the tracking mostly right. One thing I encountered, while fighting with the above, was that OnStep would shift to a custom tracking rate if disconnected, without the Arduino being reset. Then I'd have star trails, setting it to Sidreal worked correctly. That one probably is something to look at. (From a brief double check of the LX200 and scan of lx200 driver source, I don't think that there's any way to query that.) Not that it's the cause of my problems, but it looks like the sidreal tracking calculation is very slightly off ( f=(trackingTimerRateAxis1*1.00273790935)*60.0; Per wikipedia Should be (1.00273737909+(5.9006*10**(-11)*(0.18)))-(5.9*10**-15*(0.18)**2) = 1.0027373790910774 Not that that an error on the order of 10^-7 should be significant, especially compared to other sources of error. I'll mention it on the list. ) Digging into that, (very slight error aside) I see no reason for that odd star trail behaviour *at all*, that there shouldn't be anything sent on connection the screws it up that I can see. Nor should OnStep do anything on connect.

However, I am about to fall asleep on the keyboard, so I'll look at it after sleeping, when I'm less likely to make mistakes. (Probably something stupid on my part with the tracking.)

Woot on the testing! I found that if I save the params after setting stuff like that it tends to stay put better on reconnect, so that may be something to check. I have also noticed that the frequency doesn't default to anything until you update it with the button in some instances, which might be related, though I've had so much bad weather I can't remember if we fixed it yet.
re: dual focusers. How about making it change the focuser along with the camera as a setting somehow. It would take some coordinated efforts but seems like the way to go since we can change cams and even (filters now) in Ekos the focus page.
[followup: There is a device field in ekos/focus, and it may be possible to get it to recognize something more than "OnStep", or some way to register and label the second device.]

My ARM related stack smashing detected issue with my filter wheel has turned out to be a real problem. Keep an eye out for it in the indiserver output if you are using an Rpi or Odroid and get bizarre results.. Apparently any threat of a full buffer gets it upset. I made an issue at master git for it but the problem is rare and I think something in my arduino code could be triggering it somehow. It's at issue 539 if anyone is interested in trying to duplicate the problem.
github.com/indilib/indi/issues/539

Hi,

Weather: Seems we all are in the same situation. Howard solved it on April 1st by adding a sort of cloud remover in the code
Weather is completly crazy, rain, wind clouds hot then cold again.
Even my observatory project is stopped, my foundation hole transformed in a mud lake ... and at the end I got the flue

Tracking Rate: Concerning the connect and OnStep using a custom tracking instead of Sideral seems strange.
At connection the only comands sent are the one related to location, time and date and confirmed by sniffing the communication.
It is true that the tracking frequency is only updated when a set is issued, but the filed is not the actual tracking frequency of Onstep nbut the last setiing, an it is confiusing I agree. The tracking speed setting is not handled by OnStep driver but uses Indi standard way of doing.
There could be a way to update with the ":GT#" command but with limitation if I believe the code herunder.
=============== OnStep code
// :GT# Get tracking rate
// Returns: dd.ddddd# (OnStep returns more decimal places than LX200 standard)
// Returns the tracking rate if siderealTracking, 0.0 otherwise
===============
I don't see any way to check which tracking is actual in OnStep (Sidereal, Solar, Lunar or Custom)
How did you notice you are on Custom Tracking after connect?

Second Focuser: May be it is possible to declare a second Focuser so that Indi would be aware of the second Focuser but I have no clue on how to do that ... I am still not understanding C++