×

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: 161
  • Thank you received: 39
I can't say I've seen that for Onstep, but I have for other things usually because I do a make && make install, instead of the full build process. (Cmake etc or make clean.)

I don't think I touched anything that hasn't been committed, or that would deal with connection.

Unfortunately, it'll probably be a bit before I can look at it. Feel free to back things out if it's crashing and I can look at it later. (Vacation, and my laptop picked now to have the battery fail. Stupid failure mode of degraded = permanantly won't do anything.) I have another tablet, but it is a tablet, so I'm not doing much coding on it. It is up to date, I think (I synced it when I left and didn't notice failure,) with my master though.

Thinking about it this morning while driving: If it's in your branch it's gotta be PEC. I don't think the align got pulled. Maybe the PEC status check?
5 years 8 months ago #27708

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

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

Not a hurry, I was out of the game too .... due to a nasty little animal .... a tick that infected me Lyme ... a pain in the ... brain I tell you :-)
I found the guilty merge, it is commit github.com/azwing/indi/commit/99a1850244...3b97c0686ebe59558fdd
4 days ago.
Now I can investigate deeper.
No it is definitively not coming from your changes.

Have nice hollidays

PS:
After investigation it is definitively not our code that make the driver to crash.
I checked the driver (version 1.3) in the Master and the same behavior.
When connection is clicked the driver crashes and Indi Log says

2018-07-22T20:57:27: Driver indi_lx200_OnStep: *** stack smashing detected ***: <unknown> terminated

So not only the development version crashes but also the stable one.
All this after commits of June 18th ...

Tomorrow is another day ... I try to sleep on it
Last edit: 5 years 8 months ago by Alain Zwingelstein.
5 years 8 months ago #27711

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

  • Posts: 452
  • Thank you received: 71
Investigation results this morning:
First thanks to avarakin for the git bisect idea, I learned something new.

So after some irterations here the results of git bisect on master at github.com/indilib/indi
=========================================================
root@alain:/home/alain/Development/master# git bisect bad
b3fe4b69dfe4e65f4d38c637027de0a7790d3196 is the first bad commit
commit b3fe4b69dfe4e65f4d38c637027de0a7790d3196
Author: Jasem Mutlaq <This email address is being protected from spambots. You need JavaScript enabled to view it.>
Date: Sun Jul 15 15:57:19 2018 +0300

Use the safer tty_nread_section to prever overflow

:040000 040000 9c5575ebfe8119938fa2401cc97a19409a0dff18 7020a299f7055d2ded759cb3152bf13976a965ca M libindi
=========================================================
Seems inline with what I already suspected on our fork github.com/azwing/indi

Now I can check what causes the troubble.
________________________________________
Last correct version is:
Stable version 1.3 on master : github.com/indilib/indi/commit/5981ae470...771cbbe0866b5c8d5467
Devel version 1.4 on Onstep fork: github.com/azwing/indi/commit/9571c3381a...419f67363258882506fd
5 years 8 months ago #27721

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

  • Posts: 257
  • Thank you received: 22
I saw this message when I was making my filter wheel firmware to emulate xagyl wheel. I renamed the version to show my changes and got the name too long. Some of the serial buffers cause that error if overflowed. @knro has it on his agenda to recode them one day and trap that. that info might give you guys a direction to look. I had a time finding the error until I realized it was really trying to say serial buffer overflow. It looked like it was in code but turned out to be induce by comms.
www.indilib.org/forum/ccds-dslrs/3109-in...ot-playing-nice.html
Last edit: 5 years 8 months ago by Ray Wells.
5 years 8 months ago #27725

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

Sorry folks if this commit caused any headaches, but it was necessary (and long overdue). Before we were open to buffer overflows from the serial devices. With tty_nread_section, it tries to find the stop char up until the size specified so there is no risk to overflow. The lx200driver currently caps that at 64, is there any responses from OnStep that exceeds this?
5 years 8 months ago #27727

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

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

I don't think we have response longer than 64 but since OnStep Firmware is really moving a lot could be.
I will try to check using debugger and serial sniffing so I hope to discover what the reason is for the crash.

thanks for the help
5 years 8 months ago #27736

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

  • Posts: 322
  • Thank you received: 31
Alain,

Too bad this Lyme disease. It is becoming prevalent here. Birds carry the infected ticks from the USA, and deposit them in vegetation, the people and pets walking among them get bitten and infected. It is hard to diagnose. Good that you got it diagnosed and treated.

As for OnStep, this is in Comamnd.ino (where all the USB commands happen).

static char reply[50];

So, there should be no replies larger than 50 characters.
5 years 8 months ago #27737

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

  • Posts: 174
  • Thank you received: 27
How about PEC data? Arent we moving it back and forth between device and client?
5 years 8 months ago #27740

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

  • Posts: 452
  • Thank you received: 71
Hi guys,

After some search and debug i have a working release on my PC.
Finally the problem was in the last changes (Align and PEC) where buffers variables are set 5, 10 or whatever.
I changes all buffer to RB_MAX_LEN 64 so that we are safe on this side and it works.

Some additional checks and I can push it tomorrow

The issue now is how to push a change to master where the same cahnges need to be done on the "stable V1.3" which is also impacted in one part.

So by the end the trouble was minor
The following user(s) said Thank You: Ray Wells
Last edit: 5 years 8 months ago by Alain Zwingelstein.
5 years 8 months ago #27744

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

  • Posts: 322
  • Thank you received: 31
Alain (and anyone reading this),

When you have the time, can you check the new feature in OnStep that enables the use of the "Mount Model" feature in Ekos?

Instructions on where to get the code, and steps to test are here:

www.indilib.org/forum/wish-list/1406-dri...html?start=216#27466
5 years 8 months ago #27745

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

  • Posts: 161
  • Thank you received: 39
PEC data will be fine. The commands return it one byte at a time.
5 years 8 months ago #27746

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

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

It was my intention when I said ... make some checks before pushing.
But unfortunately I cannot test with real hardware.
My mount is not set-up, the observatory suffered some delay and I am not in goog shape to go outside.
I will test with CCD Simulator, should make the job.
5 years 8 months ago #27756

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

Time to create page: 0.967 seconds