×

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: 257
  • Thank you received: 22
The QHY could be using up all your USB bandwidth, especially after a lockup. Sometimes a setting will result in an error and cause the driver to get stupid. Once the ASI camera driver goes unstable for whatever reason (drive full is one) indiserver does some very strange things and I have to restart it using SSH to the Odroid, so the qhy code using the same backbone may have done the same to you.

My Mega has been doing a pretty good job of keeping up with things lately, but again, I'm on older code now. not sure this helps but I figured it couldn't hurt to have some comparison data. I haven't updated the indi driver in a week or two as I promised myself I'd just do astronomy for a while once I got things going well enough. I backed up the working version so I should be able to test latest before you guys issue a pull next go if you like, unless aliens move into a parking orbit or I have that rare 4/5 stable clear night. I'm on Beta still and attempts to switch to the newer code have gone poorly, but I've not had any lag issues beyond the usual self induced problems of connecting to the wrong port and crashing the driver or having to disconnect to remove a camera while tweaking the light train, thereby crashing the whole works on reconnect...and other "normal" stuff like that.
I noticed a recent addition of a polling system and I haven't seen any docs on it yet. That might be something to check on the Indi side, And also the ZWO cameras(despite being usb3 units) can cause lag problems throughout the system when run on usb2 ports - not sure if the QHY suffers the same issues but worth mentioning. I keep them both(178mm/120c-s) throttled to 40 even on the Odroid's usb3 ports which seems to avoid trouble pretty well and is more than enough for DSO long exposure anyway as even framing shots are 2-3 seconds.
37mb! Some parsing may be needed. yikes!
5 years 10 months ago #25826

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

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

I see you're busy testing and observing ... happy you.
I was digging and digging :-) for the foundation ot my fixed obeservatory (attachement)
This is the reason why I was quiet (in fact I was dead ... to much for my old bones :-)

Blueshawk, there is nothing on the fire currently with the driver.
James fixed the Focuser so it is usable with Ekos.
I am trying to clean up the code in the meantime and hope I cann soon test all on the fixed station.

Clear Skyes ...
.
5 years 10 months ago #25837
Attachments:

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

  • Posts: 257
  • Thank you received: 22
@Azwing Yep! After I got that crazy buffer problem fixed I was able to just "do" astronomy for a while, mostly fiddling with all my toys and trying to come up with a flat light train for the 6 inch f4 newt. I dislike digging. I dug holes for some tomatoes last week and threw my shoulder out hitting roots with a maddock.
That pier looks great! You might check out the facebook group I'm in called "Home observatories and DIY projects(guess which one I am :P) that has a ton of good observatory info and nice and informative community. We'd love to see how things go on that project. Tell em Ray sent you so they'll know you mean business! ;)
I also made a nifty guidescope from parts costing me 0$ I'm pretty stoked about and got my focuser issues sorted too. Other than that it's just been hardware issues for the last bit, a broken belt tensioner, Declination lash, a loose pulley and a stripped worm adjustment bolt to name a few show stoppers during the brief clear period we had.
The tapping in the cg4 was apparently done by overworked 12yr old chinese girls as they are all loose in the threads from wobbly bit work. I've had to retap a couple already and should have just done them all but space and time constraints...

I may eventually try the newer onstep code to get back on the testing train, but I'm considering doing a more stable fork for those of us already built and working with older code and the Arduino Mega. Alternately, I may go talk to Howard Dutton and try to test for them to help keep the mega sections viable as the teensy code evolves as I'm pretty sure the issues I found were related to this. I am enjoying the break from the madness though. :D

One thing to keep an eye out for: I've not been able to verify this bug due to the belt issues etc. but there may be a bug in the "home" routine when in the southwest quadrant, I've found it had gone inverted and tried to circle under. It could have been a crashed or unstable situation so I've not got any real data, just wanted to get it out there in case somebody else catches it doing this.
5 years 10 months ago #25839

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

  • Posts: 161
  • Thank you received: 39
[2018-05-11T21:56:03.775 CDT DEBG ][ org.kde.kstars.indi] - ISD:Telescope sending coords RA: "15h 35m 12s" ( 15.5868 ) DE: " 67° 02' 27\"" ( 67.0409 )
[2018-05-11T21:56:05.524 CDT DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:FI#> "
[2018-05-11T21:56:10.537 CDT DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] <setObjectRA> "
[2018-05-11T21:56:10.997 CDT DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:Sr 15:35:12#> "
[2018-05-11T21:56:10.997 CDT DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:Sr 15:35:12#> successful. "
[2018-05-11T21:56:10.997 CDT DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] <setObjectDEC> "
[2018-05-11T21:56:10.997 CDT DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:Sd +67:02:27#> "
[2018-05-11T21:56:10.997 CDT DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:Sd +67:02:27#> successful. "
[2018-05-11T21:56:10.997 CDT DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] <Slew> "
[2018-05-11T21:56:10.998 CDT DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:MS#> "
[2018-05-11T21:56:10.998 CDT DEBG ][ org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] RES <0> "
[2018-05-11T21:56:10.999 CDT INFO ][ org.kde.kstars.indi] - LX200 OnStep : "[INFO] Slewing to RA: 15:35:12 - DEC: 67:02:27 "

Ok, so I got a short log. (The one prior to this was 20 seconds) Showing the delay I'm talking about. Note the 7 second discrepancy between being commanded to and actually moving. Ekos shows 'Slewing' in the main window, but there's no motion. So I'm not sure if it's a Kstars/Ekos issue, a driver issue or an OnStep issue. (I just updated to 18.04 Ubuntu, but everything should have been updated.) I'd say it wasn't OnStep, given the log, but I've only seen it so far on OnStep Alpha. If anyone else wants to take a look. (This is my 2nd OnStep Mega mount)

I'm on 2.9.5 (latest per ppa repository) I just upgraded to the 18.04 version (vs the 17.10, same version)

Indi is current, or at least current as of the last time I pulled from it. I'm gonna try to clean everything and build a new version making sure there's nothing left around.

Ok, looking more carefully, it looks like :FI# if FOCUSER1_OFF is on, gets a 5 second delay from OnStep (or lx200_OnStep.cpp) as does :FM# so that's something to go back and look at, or report. Sometimes typing things out gets you to the solution faster...

That problem (repeated delay) would have only occurred for me (or azwing. depending on the branch) because I removed the :FA# check, to force it on. Well, each command was coming up against the timeout, resulting in a 5 second delay. (#FG, #FI, #FM #FT). (It's defined as 3, but in my logs is always 5 seconds.) Adding an :FA check around the focuser updates didn't work initially. I looked at onstep and realized it wouldn't reply if the focusers weren't on at all. Added code below and it worked, and of course performing that check once (as was done previously is better).

Code to add to command.ino
#ifndef FOCUSER1_ON
if (command[0]=='F') {
// :FA# Active?
// Return: 0 on failure
// 1 on success
if (command[1]=='A') { // Not present so return 0 always.
reply[0]='0';
quietReply=true;
}
} else
#endif

#ifndef FOCUSER2_ON
if (command[0]=='f') {
// :fA# Active?
// Return: 0 on failure
// 1 on success
if (command[1]=='A') { // Not present so return 0 always.
reply[0]='0';
quietReply=true;
}
} else
#endif



----


However, it was/is a cause of freeze on connection, that I recall, so there's almost no connection delay from hitting 'Connect' to it working. I've sent an email to the OnStep list with this. It's alpha, but once that continues down, everyone should see an improvement on connect.

This stream of consciousness has been a bug fix for me, due to a self-inflicted bug that resulted in a fix for everyone else. ;)
5 years 10 months ago #25967
Attachments:

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

  • Posts: 60
  • Thank you received: 1
Hello

I can't see the integrated OnStep focuser in kstars.
I have the last versions of kstars and indi.
The focuser works fine with indi control panel but it's not visible in Ekos (i can't choose it).

Thanks
5 years 10 months ago #25976

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

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

The current version (1.3) of the Onstep Dirver does not imùplement focuser in a way that Ekos can see it.

Our Indi fork github.com/azwing/indi does (based on James Lan's work github.com/james-lan/indi ) but is still experimental and needs some clean up and rework to support the second Focuser. lokk also at Blueshawk's feedback
Before releasing a version 1.4 better to wait for more return from testing.

This takes a bit of time especially because I am not in position to test in field for the time beeing.
5 years 10 months ago #25978

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

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

What if the :fA# / :FA# commends are issued only during initialisation, and then make polling conditional to the result?
I think so we can setup the Focuser is present and leave it out if not.
Sorry, I am still full busy with my Observatory construction so that the driver dev suffers a bit.

Regards
5 years 10 months ago #25982

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

  • Posts: 257
  • Thank you received: 22
I think both adding the conditional in OnStep and in the init and tab setup in the driver both make perfect sense. OnStep needs to reply with usable info if the user isn't going to add the focuser(such as my case) so that drivers, ascom or indi for instance can decide if they need to list it. Serial polling is a fixed rate so it wouldn't normally have an effect on timing or parsing of commands unless it happened too fast to read them all in.
...which reminds me, does anyone know where we can get info on this new polling timer that has appeared in the latest ekos release? I've left it alone for the most part but if it's intended to throttle calls it might need to be faster with smaller intervals per tab..but if it is as I described above, it may just need to be long enough to ensure busy command requests don't get truncated. I guess the question is, could more performance or stability result from tweaking?
5 years 10 months ago #25992

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

  • Posts: 257
  • Thank you received: 22
Something for the todo list:
It would be nice to have buttons for these like the phone app has.

// :T+# Master sidereal clock faster by 0.1 Hertz (I use a fifth of the LX200 standard, stored in EEPROM)
// :T-# Master sidereal clock slower by 0.1 Hertz (stored in EEPROM)
// :TR# Master sidereal clock reset (to calculated sidereal rate, stored in EEPROM)

I moved the mount out front to protect it from a student driver. :P A side effect is having a blue tooth connection at my desk, which resulted in finding this nice toy. No two gear sets are exactly alike, especially considering the DIY aspect of the driver, and mine is no exception. Great for fine tuning unguided tracking speed.
If I get time I'll try to get this going, as it's a pretty simple call response and I can use another for a skeleton to hack at it. But don't let that stop anyone from picking it up. :)

Found something interesting. the custom tracking rates do work.
"2018-05-15T00:43:58: [WARNING] Custom tracking rates is not supported."
Should really issue a "tracking off" wait a turn, then change them, then restore tracking to original state. Or at least say so instead of the misleading error message. If you turn tracking off manually and it will take the tracking change.
I still like the phone app's .1hz push buttons for fine tuning. Checking Onstep code, it does remember the frequency you settle on unless it gets reset, also currently happening. Someday maybe we'll get a way to serially adjust actual ratio variables in eprom.
Last edit: 5 years 10 months ago by Ray Wells. Reason: I changed something.
5 years 10 months ago #26007

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

  • Posts: 161
  • Thank you received: 39
Blueshawk: Added to my fork, However, I seem to have broken the focuserinterface (Works from within the INDI control panel) so unless you are manually focusing, I wouldn't use it.
5 years 9 months ago #26487

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

  • Posts: 161
  • Thank you received: 39
BlueShawk: I fixed the focuser in my master. (Implementing sanity checks is only good if you implement good sanity checks. Checking if it's below the min isn't great. Oops!)

Azwing: Made a pull request, so you can merge it in.

One thing to note: When looking through the onstep code itself, there's no way to verify it that I can tell, as the variable it alters is used for the calculation of the sidreal rate, which everything is reported relative to.
The following user(s) said Thank You: Alain Zwingelstein
5 years 9 months ago #26501

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

  • Posts: 257
  • Thank you received: 22
Haven't had a chance to try that yet. Summer nights are so short. I'll wait till I get a look to see how it's going. No promises but i'm hoping the storms cleared things enough for me to get an hour before bed to try for Jupiter with the GRS showing. I'll start earlier and update the drivers in the Odroid(currently in the field but unplugged) from Azwing's git.
Last edit: 5 years 9 months ago by Ray Wells.
5 years 9 months ago #26510

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

Time to create page: 1.208 seconds