Thank you gentlemen! I just got back into town only to find you all have been hard at work..... This is a great enhancement for remote observing.... Bruce

Last night I could do a check with the accuracy of Autohoming in INDI
It works well but it seems to differ quite a lot compared to the HC for some reason.



In this image the darker zone is the Autohome with the HC, and the rest of the image is Autohome with INDI.
If the position would be exactly the same compared to HC and INDI Autohome then all the image would be dark and with stars.
The difference is 384pix in X-axis and 224pix in Y-axis and my setup have 1.32pix/arcsec according to astrometry.



I this image I did 2 Autohomings and added the images together so everything seems to fall in place here.

So, I wonder why there is such a difference when comparing HC and INDI ??
But anyway, if something really bad happens, just do a Autohome and resolve a image and you are ready to go again, but I'm not sure if it's wise to save that calibration after Autohome..?? maybe I'll push my luck some time and try just that..

Jean-Luc, what do you think abut the difference ??
I read in EQ8 forum that somebody there wrote that the Autohome sensor is not good enough and might be unreliable??
If I had another EQ8 I'd take it apart and take a look how it's implemented.. but it's too much money to buy another just for that.

Br,
/Markku

You say the difference is between indi and hc variants of auto-home. How many runs did you do with the hc, to check for consistency ? I suspect if you do successive runs with the hc, you will see the same kind of variance between runs, and if that's the case, the issue is more about accuracy of the encoders than the code implementation.

I'm not sure how many times I've done that, but every time I changed filters, cleaning cameras, changing cables or done anything at the obsy that might have altered the scope.. It's a lot of times, and it always end up at the same position, and so do INDI after maybe 6-8 tries yesterday.. but a different position.
I don't doubt Jean-Luc's coding, just wondering why there is a difference.

Thanks for testing and posting your results.
Do you think I am right in saying that the first image seems to show an equal difference in RA and DEC between HC and INDI ? As if both motors made an equal number of steps in excess. I am not sure if the break steps used in INDI with the S command are sufficient to stop the mount in this case. In case of INDI gotos I use a relative step increment/decrement with a fixed number of break steps and that seems to work. Here I use the absolute goto S command and an absolute break step command (U if I remember). So I will first check that point.
The second image shows that the home position is always the same with INDI Autohome as the trailings are aligned, is this right ? I'm not sure of what you meant in your last post ("after 6-8 tries"). If it is not always the same that would be quite useless. Looking at the code (and as far as I can understand) the indexer is plugged to an int input of the PIC µprocessor and triggered with a low to high transition. The int routine simply saves the current microstep number. And the q command gets its value. So as long as the mount uses the same direction in HC autohome and INDI autohome their values should be the same. May you check that HC and INDI autohome use the same direction for their successive moves, starting from the same (or almost) position ?
By the way I will soon commit the code as it seems that there are no big mistakes in the current implementation.

if it always ends up in the same position with the indi variant, and always the same with the HC variant, but the two are different positions, then I can think of a few ways this can happen.

As Jean-luc suggests, it could be as simple as arriving at the index from the left in one case, and from the right in the other case, with the difference being the size of the index mark. Another thought that comes to mind, is the difference between a rising edge, vs falling edge detect. If they are both arriving from the same side, but one is triggering on 'arrived at index', while the other is triggering on 'past the index', you would get the same effect, ie two identical routines but using different sides of the index mark as the 'we are here' spot.

Thank's gerryr, that crossed my mind too after some thinking

It might be so even if the Y-axis is roughly the twice of X-axis, but it could look like that because the image is not square..??

In the logfile:
:G201=
:S249F090=
:M249CF8F=
:J2=
the :S1 and :S2 commands are used, but I don't know what the :M2 command does, and I couldn’t find a :U2 command in the logfile.

Yes, that is correct, the 500second images are taken on 2 Autohomings number 6 and 7 during my tests, I wasn't very clear about that, and then I did a last test number 8 before shutting down.

So probably the PIC catches the value fast enough, so there should be no problem.

Ok, might be that the direction is not the same for both HC and INDI at the time the position is taken,
So to try to figure it out I have a couple of new videos.. My friend went to my obsy and used the HC.

HC Autohome:


INDI Autohome:

Thanks maxer for the videos. I've tried to understand what's going on as I've corrected my test board so it supports now highspeed slews and gotos. But I have the same problem as you had before, i.e. the mount performs a complete turn in RA when it slews back 10 degrees at the end before slewing in home position. Actually the home index has been reset to 0xFFFFFF (not 0x000000 as it should) so 0xFFFFFF becomes the home index. It seems to work for the other axis as when I simulate the home index by grounding the corresponding pin, the PIC controller catches that position.
Concerning the difference between HC and INDI Autohome, I 've thought to add some constant corresponding to the indexer half width. I've also looked at the log you posted in the previous thread, and saw in the second example, a difference between the values of the indexers and the ones at the end of the autohome sequence. In the first example these values are the same. So I am a little stuck for now.
By the way I have made the commit so other people may be able to test further.
Concerning the M command, it sets a break step increment value, I thought it was a relative value as I use it in standard gotos (move +10000 steps, start breaking 1000 steps before). In your log it is used as an absolute break step value (start breaking at this step index value). Is this log from the HC ?
Anyway I don't think the break step values could be the reason for the difference between HC and INDI Autohome as every highspeed gotos I've tested stop at the desired step value. I now display these values at the end of the autohome sequence so it could be easy to check.

So if your tests shows the same behaviour in some situations then it seems to work as expected even if it seems to be erratic and a bit buggy.
Could it be that the HC always assumes it already knows the position and sets the position as soon as it knows the homeposition is passed ?? (just a guess..) that would explain why the digits is the same all the time.
Yes, there is a difference, now I have a new logfile with 3 runs from different positions and I can see the difference there too, file attached.
Ok, I begin to understand how the M command works then, it makes sense to slow down before stopping, probably that is the reason the mount sounds like a musical instrument
The 2 latest logfiles is only from INDI, only the first is from sniffing between the HC and mount.
Great to get the driver from PPA, hope to get more users to test and see if the results differ.
Thank you again for looking into this.

Gentlemen,
I appreciate all the hard work going into this issue and eagerly waiting for something to be pushed out. Sorry, I'm not a unix expert and hesitant to compile code. Any idea when it will start showing up?? I don't see anything in my latest update on EQMOD INDI. Thanks again for your support.... Bruce

Hi Bruce,
As far as I can see it's in the sources and also in PPA.
"indi-eqmod 2016-03-05 geehalel [r2694] indi-eqmod: Autohome (TEST) for EQ8/AZ-EQ6"

Hmmm.. took a look again and found that It's not there for Utopic ?? but all other recent distros..
Maybe Jasem can take a look at it.

If you like to compile from source.

svn checkout svn.code.sf.net/p/indi/code/trunk indi-code
cd indi-code
cd 3rdparty
mkdir indi-eqmod_build
cd indi-eqmod_build
cmake -DCMAKE_INSTALL_PREFIX=/usr . ../indi-eqmod
make
sudo make install

During 'make' you will get some warnings but that's ok.
/Markku

Thanks Max,
I will see what I can do given your instructions. I am running Ubuntu-mate 15.1, I think that is wiley. I see the normal park and unpark button but no home button under main control tab. Is is located somewhere else??.... Bruce