Thank you for the commands. I've looked at the code of the driver and at a first glance it doesn't do anything fancy. The driver just passes the position to the device as it is so it should just work. And the result of position query suggests that it indeed works fine, so #QP! is equal to #GT! Just the physical rotation direction of the motor is wrong.

So I think that there is either a reverse switch missing somewhere or the driver needs weird commands (like negative positions) when reversed. Maybe I will attach Wireshark to my Windows/Sesto Senso setup later to see what the driver is doing there.

My intial look comes up with the same. I am just about to read out the current values using the Sesto software.
After we initialise it via INDI it must ge getting its absolute position set to something very high otherwise the GT command would focus out

Reversing wont help as it look like that function is is not implemented.
bool SestoSenso::ReverseFocuser(bool enable)
{
INDI_UNUSED(enable);
return true;
}

Need to setup a VM to build it I think. Then I can add extra output to work out what it is doing.

Update:

I have setup a USB monitor on the StellarMate. The GT command looks fine. I will run a trace now from startup to shutdown and see if I can see whats going on.

Not sure if this is really progress but I now have the same issue using the Sesto Windows application.
I set zero as a reference, tell it to goto 1000 and it focusses in!
Reversing the direction makes no difference.

I have been monitoring the USB traffic on both INDI and the Sesto software and the commands being sent and responses coming back are OK but the direction is wrong. I am starting to suspect the firmware but I need to dig a little deeper before I draw any conclusions.

I think I am going to flash the firmware, calibrate and then try with Indi and record all the USB traffic.

This is odd, I have had it working perfectly with Indi and with the Sesto software but I have also had the "reverse" behaviour in both.
For once I hope it stays cloudy tonight!

Dear all,

thank you for advancing this matter!

I have similar issus with my Sesto Senso. Therefore I started a while ago this topic: www.indilib.org/forum/ekos/4641-sesto-senso-in-ekos.html#35281. In the meantime I tried a lot, Jasem did some Team-Viewer-Sessions etc. Result was that it still does not work (my one always focusses in and does not stop at the desired position; it can only be stopped manually), but it seems that the INDI-Driver works correct. Because of this Jasem and I get in contact with PrimaLuceLab. So they know about the problem, but (at the moment) they don't have an idea what the reason for the problem is. I hope that they will jump in now and and help to solve this issue.

In addition to the aforementioned, I noticed the following

1.
The INDI-Driver seems to not read out the correct maximum position of the Sesto Senso. In my case it is (depending on the respective calibration with the PrimaLuceLab Software) somewhat about 80.000. The value displayed in the INDI-Control-Panel is somewhat above 2.000.000 (!).

2.
When the Sesto Senso is focussing in / has manually stopped in the INDI-Control-Panel next to firmeware is not displayed "2.1" (which is the actual firmware / the firmware I have installed) but wired characters (something like "x&%!"). After reconnecting the Sesto Senso "2.1" is shown again.

3.
The Sesto Senso works under ASCOM, but after using it in Ekos I have the reinstall the firmware and recalibrate it. Otherwise it will not work under ASCOM.

4.
It seems that for some users the Sesto Senso works with INDI. My impression is that only Sesto Senso users who have firmware 2.1 installed have the described issues. But I am not sure at this point.

I hope this helps. Please tell me if I could do something to assist in this matter (I am not a programmer / software guy).

Best

Nils

Thanks for the extra info.

The more I look into it the more it looks like an error in the Sesto firmware.
I think I have the error now consistently in the Sesto app so I can now hassle them.

@Jasem. Can you send an email to PrimaLuceLab stating that I am investigating this? They seem to need this before they will give me any info.

Does anyone with 2.1 of the firmware have it working correctly?
When I get back I will also try with a much smaller range. I have a feeling that it could be a problem with signed/unsigned variables. I will try with a max under the 64K and see if that changes anything.

Cheers

Rishi

I've tried to take INDI out of the equation for a while and communicated with the focuser just with a terminal (screen in my case).

After a fresh boot without INDI the focuser behaves the same as we've seen it here in the thread: #GT10000! moves inward.

I've recalibrated the focuser again under Windows and reconnected it to the Raspi. When I sent a #GT10000! then the tube moved outward as it should.

Now I started INDI and the focuser moves inward again. Not just in INDI but also in the terminal.

It seems like INDI is doing something that the firmware of the Sesto Senso doesn't like at all.

Thats great info.
The only command Indi sends out (except for requests for status) is '#SM;0096746!'
The response is `SM;96746! which seems good.

Maybe the Sesto firmware has an issue with the Set Max command?

When the Sesto software calibrates it uses the #SM! command to set to the current position so it does not use the #SM;XXXXXXX! command.
Maybe it doesn't like he leading zero's or the whole command.
Now I need to setup a build environment to see if changing/removing the command makes any difference.

Good progress everyone! I agree that the next step involves process by elimination. So eliminate the startup INDI Driver commands and see which one causes the focuser to go haywire and then report our findings to PrimaLuca.

I have setup a dev environment with Ubuntu and everything builds (great instructions!).
Now to start the process of elimination.

I have made a change and rebuilt the indi_sestosenso shared library.
I copied the shared library to /usr/bin on the Stellarmate but now it does not recognise it when I try and start up Ekos.

I guess this is not the correct procedure. What is the minimum I need to do in order to make changes and test?

you can't copy x86-64 binary to armhf.

Why don't you build on StellarMate? just use the same procedures.

Thanks, got too used to Windows recently, forgot it was a different processor!