×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Driver OnStep (LX200 like) for INDI

  • Posts: 322
  • Thank you received: 31

Yes, when using my patch, it is left up to the user. Since the user has to go into the INDI control panel and select how many stars to align on,
they will also use the same number of stars when selecting them in Mount Model.



Agreed.



But that is added complexity. OnStep is fast evolving and there are already many board variants. If someone develops a new board (like I am doing), they will also need changes at the same time in INDI to make things work.

If we keep INDI board agnostic, it is better, since the board developer needs to worry about one side only (the board).

As you said, the :A?# can be queried for the maximum number of alignment stars, and that should suffice.
5 years 7 months ago #28438

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

  • Posts: 452
  • Thank you received: 71
@ Khalid,

I agree with you about OnStep Driver staying agnostic.

For detection I was more thinking about some additional features like presence of Temperature sensor, moisture .... that could be detected at init to enable/disable tabs for it in control panel like I do it for now with second focuser.
5 years 7 months ago #28439

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

  • Posts: 322
  • Thank you received: 31
That makes sense.
I have not heard of lots of people using these features within OnStep.
But if something is present, and readable over USB, then why not display a value for it? Maybe of use to someone.

Going back to the Mount Model, and the number of stars to use. In theory, we can modify Ekos to query OnStep via :A?# and automatically select the same number of stars. However, Ekos is not for OnStep only, and tens of other mounts run on it, so I am not not in favour of moving mount-specific complexities in the code and UI for Ekos.
5 years 7 months ago #28440

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

  • Posts: 161
  • Thank you received: 39
Ah, the stupid things overlooked on late cloudy nights. >_< I really need to review the alignment again.

We can alter the numbers in the switch based on that (an example of that is the focuser1 values) so detection of that should be easy.
The above would take care of that. As someone mentioned it's better to do the general case than a board by board.

Ideally, yes. Though I'd want to watch it. That's essentially what the mount model is going towards.

What I mean, is that there exists www.indilib.org/api/md_libs_indibase_ali...ent_white_paper.html However, I'm not sure if it's the same (It should be extendable to replicate what is in OnStep, or to use others and have OnStep be sort of a dumb interface (which are the options that Eqmod seems to use from looking at it.)) If you look at that page, you'll understand why I haven't done it yet. ;) (Especially, with my apparent reading skills lately :lol: .)

As far as temp sensors, unfortunately, there's not a good interface to tie into. I was looking at that for images and recording it, because my CCD doesn't have a temp sensor (or at least none of them expose that functionality that I'm aware of.) Unfortunately, Ekos as just reading the CCD's temperature. Which is something that would require a fair bit of work to deal with, to add throughout several things. Displaying it would be great though.
5 years 7 months ago #28442

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

  • Posts: 452
  • Thank you received: 71
@James,

Since yesterday after last git pull I cannot compile anymore a working Indi.

Whatever I start ends up with "undefined symbol: _ZN4INDI9Telescope13ISSnoopDeviceEP8xml_ele_" error

3rdparty driver even do not compile and show "CMakeFiles/indi_eqmod_telescope.dir/eqmod.cpp.o:(.data.rel.ro._ZTV5EQMod[_ZTV5EQMod]+0x78): undefined reference to `INDI::Telescope::ISSnoopDevice(xml_ele_*)'" at compilation

Do you have same issue?

I wonder what I am doing wrong

============ After deeper verification ... I had some old files from previous builds not de-installed
I allways clean up previous builds with xargs rm < install_manifest.txt but something went wrong ... I'm really get old :-)
Last edit: 5 years 7 months ago by Alain Zwingelstein.
5 years 7 months ago #28480

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

You're not doing anything wrong. The code was updated to fix a C-language compliance issue

So update libindi and sudo make install and it should be good.
5 years 7 months ago #28482

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

  • Posts: 452
  • Thank you received: 71
Thank you Jasem,

I finaly got to compile libindi.
all the 3rdparty drivers also except "indi-rtlsdr" (I suppose dependency for libdspau issue)
I will continue to search ...
================
A the end I don't know if I made something wrong or not but fact is that I had an old version of "libdspau.so" an "libdspau.so.1" in my /usr/lib/ directory.
After removal full compilation worked again.

Not that I need all the 3rdparty drivers, but I hate when something does not work ...
Last edit: 5 years 7 months ago by Alain Zwingelstein.
5 years 7 months ago #28483

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

  • Posts: 322
  • Thank you received: 31
I upgraded today to the latest stable KStars and INDI.

The good news is that the driver no longer crashes, after the fixes for the tty_nread changes. So slewing is normal, ...etc.

The bad news: One problem: when starting an Align (1 star or 3 star), the 'Align Process' line does not change to the value returned from :A?#. It still says 'Manual Alignment Process Idle', instead of the return value from said USB command.

OnStep itself is not the problem. When I disconnect INDI and connect from the command line using picocom, then use the Android app to start an Align, and issue a :A?#, I get back 613#. So the OnStep side of things are normal. It is the INDI driver that does not read and/or report the result of :A?# correctly.
Last edit: 5 years 7 months ago by Khalid.
5 years 7 months ago #28743

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

  • Posts: 452
  • Thank you received: 71
@ Khalid,

I think something is broken in the driver code.
I am not in position to test it but for sure it has someting to do with refresh of Align variables
I believe the OSAlignOn variable is reset somewhere (could not see where).
I did this conditional to minimize polling but think it is not necessary.
Have same issue in version 1.4 and fixed it by discarding test

===================== lx200_OnStep.cpp ======================
// Update OnStep Status TAB
IDSetText(&OnstepStatTP, "==> Update OnsTep Status");
if (OSAlignOn) //don't Poll if no Aligning
{
if(!GetAlignStatus()) LOG_WARN("Fail Align Command");
}
==================================================
5 years 7 months ago #28780

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

  • Posts: 452
  • Thank you received: 71
@ Khalid,

I checked the last version of stable and can reproduce what you notice about align.
Sine I discovered the same issue in the development version I did suspect my code but the fact that Stable has the same issue make me think that something in Indi changed and affected the behavior.

Here my notes after debugging:
To maintain some status I use global variables defined as part of "class LX200_OnStep" in lx200_OnStep.h
The strange thing is that these variables are reinitialized each time a function from Indi is called as if there would be declared again and again ????
I checked older versions with the same code and this did work.
Moving the variables declaration out of the class did solve this issue but I still do not understand the problem so nothing is solved.

I suspect my coding approach is wrong and I missunderstand something in Indi.
Any idea?

these variables are
char OSStat[20];
char OldOSStat[20];

char OSAlignStat[10];
char oldOSAlignStat[10];
bool OSAlignProcess=false;
bool OSAlignFlag=false;
bool OSAlignOn=false;

char OSPier[2];
char OldOSPier[2];
5 years 7 months ago #28842

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

  • Posts: 452
  • Thank you received: 71
Finally I found that the variables were overwriten via overflow by Indi, so all of them should be sie of RB_MAX_LEN.

Just move definition of RB_MAX_LEN into header instead of cpp

char OSStat[RB_MAX_LEN];
char OldOSStat[RB_MAX_LEN];

char OSAlignStat[RB_MAX_LEN];
char oldOSAlignStat[RB_MAX_LEN];
bool OSAlignProcess=false;
bool OSAlignFlag=false;
bool OSAlignOn=false;

char OSPier[RB_MAX_LEN];
char OldOSPier[RB_MAX_LEN];
5 years 7 months ago #28843

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

  • Posts: 322
  • Thank you received: 31
Thanks for finding the root cause.

So, will you create a pull request for the fix against master, or should I do that?
5 years 7 months ago #28863

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

Time to create page: 0.581 seconds