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.

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

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?

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

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?

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

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.

@ 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

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.

.

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

Now that I looked in the log, the alignment using plate solving is working as intended.

Before :CM#, there are Sr and Sd commands (set RA, set Dec), and the results from :A?# increment the number of 'stars' aligned on, from 413, to 423 to 433.

The first digit, 4, is the maximum number of alignment stars (because this is an Arduino Mega), and the second digit is the number of star aligned on, and the third digit is the number of stars that are intended to align on.

Once the second and third digit are equal, alignment is complete.

You mentioned that it is not plate solving (too fast or something). That is separate issue, but at least coordinates are returned and are used in Sr, Sd, then CM syncs.

Thanks for testing this. It confirms what I found testing indoors.

Hi Folks,
I have the following issue.

Connecting the indi_lx200_OnStep driver that came with kstars the following error arises
#2018-09-02T16:13:38: [WARNING] Communication with /dev/ttyACM0 @ 9600 failed. Starting Auto Search...

There is no /dev/USB0 as suggested by default. So the determination of the /dev/ttyACM0 works (scan).
But i am not possible to establish a connection

Using MaxPCB (V1.12), libindi V1.7.x

May be you have a solution for this?
Regards,
Gerrit