×

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: 452
  • Thank you received: 71
Serge I am happy it works with your setup.
Unfortunately I don't have all this equipment and extensive testing is not easy on simulation so I thank you a lot for your efforts.

Now I think it would be good to include the changes into Indi's Master.
I will check how to do that.
The following user(s) said Thank You: Ray Wells
2 years 8 months ago #73631

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

  • Posts: 257
  • Thank you received: 22
2 years 7 months ago #73691

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

  • Posts: 161
  • Thank you received: 39
Given your changes, I'd like you to look at the own-goto branch as it now has the changes so there should be NO status set from base classes. So it should be only update by our update, and should be consistently reported, and avoid the TrackState IDLE after a park.

I apologize for being quiet, and stepping on your toes about it, but I think it's actually a better solution. Unfortunately a lot of that delay was me upgrading and various changes. (Mostly related to me compiling things outside the package manager, and forgetting, plus resolving what turned out to be insofar as I can tell, a bit error on my SSD. (I don't think I've knowingly encountered that ever on a HDD, but might have if it's in data that's not processed by computer.)

The one change that I don't have in that branch is the Focuser hiding, but that seems to be pretty simple to add back in.

Unfortunately, KStars/Ekos does not pull directly from TrackState, so that didn't resolve the mount model issue. However, digging into it, it relies on EqNP's status as part of the Update using the TrackState. I've added updating that to the section after TrackState, so that should always be good as well. So finally solved? (Maybe.)

So far in my testing, That has eliminated all IDLE states when it's not actually idle except the very initial connect, and so far all instances of the Mount Model taking an instant photo. (Using an OnStep board, and CCD simulator, so that's limited testing and of course things are supposed to be not conducive to testing in the real world for a bit. ) So I think all of that is fixed, but not 100%. I do know in one case with TrackStateSP, there's something lower down that wants to modify it if slewing, so I had that only update if SCOPE_TRACKING to be on.

Anyway, Sorry for going quiet, now trying to catch up on some more things. (So I may be quiet again for a few days.)
2 years 7 months ago #73694

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

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

we have an Old Story from Mr "Jean de La Fontaine" called the Haze and the Turtle.
So going slow and safe is also my view, otherwise I would have pushed to Indi Directly.
We can wait for pushing to Master for two reasons:
- Lamba use most probably do notice nothing because they do not use advanced features
- Advanced users can test your or my branch and test it if they want.

I will have a look on yout updated Own-Goto soon
2 years 7 months ago #73718

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

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

First test of your onw-goto is promising.
Everything worked fine.
I continue testing and review your code

2021-07-20T18:17:10 Shutdown complete.
2021-07-20T18:17:10 Ekos stopped.
2021-07-20T18:17:09 INDI devices disconnected.
2021-07-20T18:17:06 Dome parked.
2021-07-20T18:16:49 Parking dome...
2021-07-20T18:16:48 Mount parked.
2021-07-20T18:16:47 Warning: mount park operation timed out on last attempt.
......... a lot of waiting since meridian flip before parking
2021-07-20T18:14:53 Warning: mount park operation timed out on last attempt.
2021-07-20T18:14:52 Parking mount in progress...
2021-07-20T18:14:52 Warning: mount park operation timed out on attempt 4/5. Restarting operation...
2021-07-20T18:14:51 Parking mount in progress...
2021-07-20T18:14:51 Warning: mount park operation timed out on attempt 3/5. Restarting operation...
2021-07-20T18:14:50 Parking mount in progress...
2021-07-20T18:14:50 Warning: mount park operation timed out on attempt 2/5. Restarting operation...
2021-07-20T18:14:49 Parking mount in progress...
2021-07-20T18:14:49 Warning: mount park operation timed out on attempt 1/5. Restarting operation...
2021-07-20T18:13:48 Parking mount in progress...
2021-07-20T18:13:47 No jobs left in the scheduler queue.
2021-07-20T18:13:46 Job 'Navi' is complete.
2021-07-20T18:13:25 Job 'Navi' capture is in progress...
2021-07-20T18:13:25 Job 'Navi' slew is complete.
2021-07-20T18:10:17 Job 'Navi' is slewing to target.
2021-07-20T18:10:14 Mount unparked.
2021-07-20T18:10:12 Dome unparked.
2021-07-20T18:10:06 Unparking dome...
2021-07-20T18:10:05 INDI devices connected.
2021-07-20T18:10:05 Ekos started.
2021-07-20T18:10:00 Scheduler started.
Last edit: 2 years 7 months ago by Alain Zwingelstein.
2 years 7 months ago #73726

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

  • Posts: 59
  • Thank you received: 1
Hello,
I just tested with my setup.
I am unable to unpark the mount.
With the azwing driver the position of the mount on the map is correct and I can unpark the mount.
With the james-lan driver, the position of the mount on the map is wrong and I cannot unpark the mount.
I deleted the xml files just in case.
I will find out where it can come from.
2 years 7 months ago #73732
Attachments:

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

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

Strange, I just made a test to reproduce your observation.
When I start Kstars and then Ekos I see the telescope where it should be and I have no problem with unparking.
Which xml files are you speaking about?
2 years 7 months ago #73734

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

  • Posts: 59
  • Thank you received: 1
It's ~/.indi/OnStep_config.xml

My park position is 0° alt and 0° az (telescope horizontal).
For the two drivers, in the mount tab, position is bad before unpark. But the reticle is good with your driver and not in  the james driver.
It's very strange...
Same issue with Skychart (Cartes du ciel): Position is ok with your driver, not ok with james driver.

PS: I use:
merge = refs/heads/own-goto
 
Last edit: 2 years 7 months ago by Serge CLAUS.
2 years 7 months ago #73740
Attachments:

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

  • Posts: 161
  • Thank you received: 39
I'm confused: The only reason it shouldn't update are common to both as far as I can see from a diff. Either it should get a location in UpdateScopePosition, or it should fail in both cases, as that code is at the very front, do you have any: Error reading RA/DEC. messages?

I'd very much like to get a debug log if you don't mind, because I can't seem to reproduce what you have.

I do discover some odd behaviour with parking on a (fake) alt-az mount, namely that it seems sometimes to goto after an unpark?! (To where it was before the park.) Never have seen that on an EQ. I'm looking at it, but a log would be great to try to figure it out. I do seem to recall that as being something a while back though that I'd very occasionally encounter on startup?
Last edit: 2 years 7 months ago by james_lan.
2 years 7 months ago #73743

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

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

I could reproduce your strange behavior.
After OnStep ColdStart and if Telescope was Parked I receive the Status "nNPH" which is At Home and Parked.
I checked OnStep response on :GR# and :GD# and effectively the coordinates are wrong RA=0 DE=0
After unparking whatver I do it in a terminal or from Kstars I get the right Parking RA/DE

So it is definitively not related to the driver.

Have a try to connect with my driver after OnStep Coldstart
2 years 7 months ago #73833

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

  • Posts: 6
  • Thank you received: 1
Dear Alain, I've the Problem that I can't connect to my OnStep STM32F303 via KStars.
My System is a raspi 4 8G and I#M running Astroberry with KStars 3.5.4 and the last indi driver 1.9.1.

Since my last Update of Astroberry the System never worked again. My soft skills are limited.
My mount always stuck at DE=0 when I try to connect with Ekos and will not point to Polaris (Park Position).
I then have no possibility to control the mount.
In the indi tabs the indicator always become yellow and dont execute a command as it was previously the case.
The mount OnStep-Status tabs were left empty.  The firmware figures were shown.
I cannot start an align procedure through indi.

What I discovered is that the traffic through my /dev/ttyUSB0 sends continuously the following messages what seems to be very strange.

/dev/ttyUSB0
44 48 2D 4F 41 47 2C 33 23                         DH-OAG,3#
/dev/pts/2
3A 47 58 59 31 23                                  :GXY1#
/dev/ttyUSB0
44 48 2D 4F 41 47 2C 33 23                         DH-OAG,3#
/dev/pts/2
3A 47 58 59 31 23                                  :GXY1#
/dev/ttyUSB0
44 48 2D 4F 41 47 2C 33 23                         DH-OAG,3#
/dev/pts/2
3A 47 58 59 31 23                                  :GXY1#
/dev/ttyUSB0
44 48 2D 4F 41 47 2C 33 23                         DH-OAG,3#
/dev/pts/2
...
...
...


I have set up in my Onstep config.h file some features like a DewHeater function called "DH-OHG".
Do you think that there is a problem with the OnStep firmware and a miscommunication with the indi driver that causes the failure?
I cannot understand why Onstep is sending those figures over the USB port, also because the Heater was switched off.

Perhaps I should ask Howard or Khalid if they know what could be the Problem.

All the best and thanks to your help and work since years as I read.
Joe

OnStep Firmware is 4.24g   
Hardware : STM32 Bluepill with upgraded STM32F303 chip

File Attachment:

File Name: Config.h.txt
File Size:26 KB
Last edit: 2 years 7 months ago by Joe. Reason: Forgot to mention that I use your last Indi-driver, Azwing github: github.com/azwing/indi
2 years 7 months ago #73967
Attachments:

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

  • Posts: 161
  • Thank you received: 39
Yes, that's related to the dew heater, and the new detection of features.
The gxy1 call should return the feature name and type.


It appears to be looping, but I'm not in front of the computer to look at the code. (Quickly looking at azwing's repo, I don't see anything that I would think could cause it, except repeated calls to update properties?) For a temporary solution, you might try removing that feature?
The following user(s) said Thank You: Joe
2 years 7 months ago #73968

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

Time to create page: 0.862 seconds