×

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
----

Not until I solve this, as the code I have is apparently different.
---
I think I found it. Git clone gets beta even if you change to Alpha branch the url is the same on the website. Thats a nice trap to fall into. to save time, I'll proceed withe the zip file instead.
---
That was it. It took the patch that time. Now I know I have the rest of the correct code(alpha). I noticed they moved the pin configuration file, in case anyone missed it.
Last edit: 5 years 7 months ago by Ray Wells.
5 years 7 months ago #29021

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

  • Posts: 322
  • Thank you received: 31
This should work:
git checkout Alpha

Then copy your Config.xxx.h, and my Command.ino, and you are now with the latest Alpha with the plate solving patch applied.
git diff Command.ino
will give you the changes, in case you want to review them.
5 years 7 months ago #29022

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

  • Posts: 257
  • Thank you received: 22
Okay thanks.The freshly downloaded zip is working but I'll do git checkout alpha next time. I knew there was some way, but had forgotten about that command.
I also had to move my pins.classic.h into the new src/pins folder since mine is a one off mega layout that predates the pcb's they have now and is built on a breadboard shield.

Next problem... EnableStepperDrivers(); not declared in this scope. Seems like Azwing mentioned something... That's where I am atm. Scope is set up and I saw bright Vega overhead.

That got it. I had autostart tracking on, which is disused and broken. I've had trouble in the past getting tracking to start with anything other than the phone app. Hopefully this will be fixed now. Going out to sit on a wet chair with the bugs.
Last edit: 5 years 7 months ago by Ray Wells.
5 years 7 months ago #29024

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

  • Posts: 257
  • Thank you received: 22
Set current alpha command.ino to verify operation of current system in mount.

Enabled full verbose logging in ekos.

Tracking now starts okay using indi
slewed to deneb.
Manual plate solve worked and synced. Slew to solved position was reasonably accurate. Normal operation.

bug 1. If unit unparked but tracking not started. Incorrect error given on slew to target command:
2018-08-29T01:32:54: [ERROR] Object below the minimum elevation limit.
2018-08-29T01:32:54: [ERROR] Error Slewing to JNow RA 20:42:05 - DEC 45:20:53
2018-08-29T01:31:45: [INFO] Mount is unparked.

bug 2. PEC still claims recording, still pops back on if off button pressed. I realize it's not doing anything but it's misleading.


Iinstalled alignment patched command.ino and downloaded to mega.

coords not set in firmware after update:
indi would not set them, longitude error. used phone app to set site coords.

Slewed to deneb and checked focus.
Manual plate solve captured and solved but resulted in a loss of ra/dec position. showing all zeros. then captured but could not solved based on previous 00:00:00 coords
patch breaks manual plate solve.

A manual sync after solving by hand also failed to update, and appears to have crashed the mount.

no logs found after. nice... I wonder where they went? Logging was enabled but I have nothing to show for it? wtf!?
I'll have to redo the whole thing another night as it's time for bed for a 6am start.

****Meanwhile a check of the sync call in OnStep command is needed. I think it never returned from a routine, causing blocking in the mount.

@KNRO -- Unrelated: Kstars is eating memory whenever temporary captures are made ASI drivers/focus module. leaving it looping adds up quickly. Conky reports high memory usage from Kstars. This eventually causes slowdowns and I have to kill it all and restart. I can already hear you telling me to upgrade my 16.04lts system. --my notebook doesn't do it with xubuntu 18.04lts
5 years 7 months ago #29026

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

  • Posts: 322
  • Thank you received: 31

That is odd. Latitude and longitude should be set in EEPROM, and recalled from there if they are not sent from KStars. When I am using KStars, I always choose 'KStars updates mount' and that way, longitude, latitude, UTC offset, date and time are all sent at the beginning of sessions. But regardless, if you don't do that, OnStep should remember the last latitude and longitude you used.


That is odd. Are you using the current master of KStars, or azwing's fork?
There was a problem in the last stable version where INDI would not get back returned data because of the buffer size change (RB_MAX_LEN thing). The fix is in the current master (not the PPA builds yet).

Perhaps that is related?
5 years 6 months ago #29043

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

  • Posts: 257
  • Thank you received: 22
--I had the same thought this morning.I'm using Azwings fork, but maybe there's an error there.
-- I think a bit is set to load "first run" defaults when you download to the arduino, or it was at one time anyway..or it was in my servo software, can't remember.
--! I had a thought on this. It might due to a negative longitude stored in OnStep defaults. If so, maybe the indi driver reads that and gives an error instead of updating somehow? Anyway, the phone app fixed it in eeprom so I'm able to move on and we can tackle that possible bug later.

I need to get those logs working first, then I'll look into the indiserver, and by then it will be dark and we'll try again!
Fingers crossed everybody!

ps. If anybody sees a different version of this post it's returned from the ether on its own...I lost it a while ago..poof!
Last edit: 5 years 6 months ago by Ray Wells.
5 years 6 months ago #29051

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

  • Posts: 257
  • Thank you received: 22
oh hey! I found them. I was looking in .indi/logs and just found them in /home/hawk/.local/share/kstars/logs/2018-08-28 instead! Who wants a read through?

File Attachment:

File Name: log_21-14-20.txt
File Size:945 KB

File Attachment:

File Name: log_21-30-50.txt
File Size:365 KB

File Attachment:

File Name: log_22-14-57.txt
File Size:1,684 KB

File Attachment:

File Name: log_22-38-05.txt
File Size:1,289 KB

File Attachment:

File Name: log_22-51-48.txt
File Size:729 KB
Last edit: 5 years 6 months ago by Ray Wells. Reason: attachments failed to fire...
5 years 6 months ago #29052

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

  • Posts: 322
  • Thank you received: 31
There are too many variables in your setup.

If it was me doing it, I would do it as follows:

1. On the OnStep side:

a) Download Alpha,
b) patch it with the plate solve align patch
c) Compile it, and upload it to the Mega
d) Using the WiFi, set the longitude, latitude, UTC offset, date and time.

2. On the INDI site:

a) Download the current master (NOT azwing's fork)
b) Compile it. That way you get the buffer fixes and guarantee that the results returned from USB commands are valid.

Test the Plate Solve Align as follows:

1. In INDI click on 3-Stars. Tracking should start.
2. In KStars, select Mount Model, and choose 3 stars that are far apart and visible in your location.
3. Start the Mount Model tool.

Check the screen where KStars display the delta errors (the difference between where the object is, and where it was supposed to be).
5 years 6 months ago #29053

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

  • Posts: 257
  • Thank you received: 22
This log follows your instructions including changing to "master" which I decided must mean Indi git since all git repositories have a master branch. There are a couple extra slews I did at the end and a plate solve to see if it did anything. Since you never set a baseline I had none to go by and....
Observations: As before... it went too fast to be solving on my computer, even locally.

I will not do this again until changes are made.

I wrote a test procedure based on my experience using this equipment and 25 years writing test procedures for industrial electronics repair but I won't bore you with it. Too many variables.

File Attachment:

File Name: log_20-33-31.txt
File Size:2,461 KB
5 years 6 months ago #29055
Attachments:

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

  • Posts: 452
  • Thank you received: 71
@ Blueshawk.
Thanks for your efforts.

I had a look in your last logs.
Seems that from an alignment point of view things behave correct:
====================
I see and Align request ":A3#"
then a lot of align status ":A?" answered by <413> meaning first star out of 3 is in process
then after :CM" (sync most probably from Ekos after plate solvind"
followed by align status ":A?" answered by <423> meaning second star out of 3 is in process ==> so Sync does what is expected
===============

I really need to speed up my work to complete my set-up to be able to test this in real situation.
Just ordered a "blue pill". I want to build a testing patform, hope this will arrive soon.

I like your approach with testing protocol, this is the right way I would like to go for testing when everythinbg is set-up.

What concerns current Git version, it is tested to work on bench but not in real situation, but form an align point of view, it should behave as version 1.3.

The only differences are the new alignment tab and PEC which both need rework.

Regards
The following user(s) said Thank You: Ray Wells
5 years 6 months ago #29057

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

  • Posts: 257
  • Thank you received: 22
Thanks Alain.
I could also try Azwing/master against the Onstep change sometime without too much effort. I'll leave things as they are for the moment and play with it more, but no more double shifts for a while.

I'm not sure this is the right way to go. It relies on changes to code outside the scope of the driver which could leave it broken at a later date, as well as having implications for legacy user and non indi users of OnStep. We could also try a side branch with James's in driver version sometime after I lick my wounds a bit.
5 years 6 months ago #29064

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

  • Posts: 452
  • Thank you received: 71
.

=> I agree it is not the way to go. I tried to setup two branches, "OnStepTest" and OnStep1.3", thinking I can keep;
-Master as the in Progress but tested version
-OnStepTest as the testing version
-OnStep1.3 as the stable vesion

It works in my local git, I can switch from one to the other with "fgit checkout OnStepxxxx" but I cannot use fixes on version 1.3 to pull requests in main master.
Git is most probably very powerfull but I am not able to use it in the right way I guess.

Concerning Legacy ... this is the reason why I don't want to release any changes before everything is tested against a stable version of OnStep Firrmware.
Seems the cat bites his tail here :-) but soon or later we will manage.

Rome was not built in one day !
5 years 6 months ago #29072

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

Time to create page: 0.306 seconds