Still having the same issue. I believe the error lies in the setStandardProcedure call. If I replace the procedure inside of lx200driver.cpp with the following code, it works. BTW, this is code from tango13 that he shared yesterday!

int setStandardProcedure(int fd, const char * data)
{
char bool_return[2];
int error_type;
int nbytes_write=0, nbytes_read=0;

DEBUGFDEVICE(lx200Name, DBG_SCOPE, "CMD <%s>", data);

if ( (error_type = tty_write_string(fd, data, &nbytes_write)) != TTY_OK)
return error_type;

usleep(10000);
tcflush(fd, TCOFLUSH);
usleep(30000);
error_type = tty_read(fd, bool_return, 1, LX200_TIMEOUT, &nbytes_read);

usleep(10000);
tcflush(fd, TCOFLUSH);
usleep(30000);


if (nbytes_read < 1)
return error_type;

if (bool_return[0] == '0')
{
DEBUGFDEVICE(lx200Name, DBG_SCOPE, "CMD <%s> failed.", data);
return -1;
}

DEBUGFDEVICE(lx200Name, DBG_SCOPE, "CMD <%s> successful.", data);

return 0;

}

--Jon

The problem could be a wrong syntax of the St command.
In the log file I see:
SCOPE 38.238694 sec : CMD <:St +42:46:60#>
ERROR 43.243943 sec : Error setting site latitude coordinates
but I believe the :St command syntax is sDD*MM:SS#

But it could possibly also be the extra usleep that I added, if I remember correctly without it not even the correct :St command worked

I tried the command with the * and it still fails....I believe your code fixes the issue. It looks like it slows things down long enough to allow the proper transfer.

--Jon

Slewing around a bit in kStars I notice that it throws a lot of 'object below horizon' messages when the object is not below the horizon. The slew still occurs fine. Nothing major I don't think but I do wonder why it's doing it.
Next step is to add in the motion control again as those do not work with this latest effort. S
Still, overall, this is great. I can't wait to get a clear night to setup and give it a real whirl!

--Jon

The modifications do not make sense. The TCOFLUSH just discards data, and the tty_read already waits for 5 seconds before it gives up. Try to remove line by line of what was added until it fails, reduce it to a minimum.

knro;
I played quite a bit with this code to try and understand what was going on here. The only other combination of the code tango13 used that still works is removing the usleep commands from both sides of the output flush and leaving the sleeps before and after the input flush. I even tried less duration (< 10000) on the usleep and it still fails. I also tried increasing the lx200_timeout to 10 seconds and that didn't work either.
I believe you are correct that it doesn't make sense if the tcflush command works as we think it should. In reality, i believe tcflush never really clearly defines when the input is flushed, especially if we are still receiving input while it is flushing. It can take a very long time if that is the case. Telling the stream to stop talking (usleep) completely allows the input to be flushed. It is a crude fix but is easier than trying to pull all of the input out one by one until we know it is empty.
Just offfering my limited understanding of things......

--Jon

Dear All, I read there's still a few features of the ZEQ25 driver that needs tweaking but I wanted to thank you all for pushing this through. Special thanks to jonkjon for reigniting the fire and for tango13 for adding supporting code and ideas. Thanks also to knro who never ceases to amaze me in how much effort he has contributed to libindi community.

I've now updated/upgraded libindi,

sudo apt-add-repository ppa:mutlaqja/ppa
sudo apt-get update
sudo apt-get upgrade

selected ZEQ25 driver via the device wizard and connected to port /dev/ttyACM0 with immediate connection. I noticed the popup "Please wait while KStars tries to connect to your telescope" is still active in the background but I'm now checking how it slews and tracks indoors waiting for my next night with clear skies. So far so good.

Thanks again!
yabby

Thanks for the kind words yabby. Yes, you are right about knro. I don't when he sleeps.....
I do have a question. I would like to test out my version of the driver on a raspberry pi. I have everything installed and connecting but the driver on the pi is still giving the latitude/longitude error. I assume that's because knro hasn't posted the version with the fix we discussed as it may not be stable for him. Is there some way to copy over the executable from the vm using scp or something to replace the driver on the pi with my own version for testing?

--Jon

Thanks yabby, that's the beauty of open source...
And kudos to knro from me too for his great work and willingness to help.

Jon, to keep things simple I installed on my RPi all the tools necessary to compile the libindi code, then I keep two copies of the svn repository (one original, the other with my mods) and depending on what code I want to test I compile and install one of the two repos.

Ciao,
Piero

I copied the libindi folder over to the pi and ran "cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Debug ." just fine. I needed to change the path in the cmake cache file though.

Is there something other than:
sudo apt-get install libnova-dev libcfitsio3-dev libusb-1.0-0-dev zlib1g-dev subversion libgsl0-dev build-essential cmake git libjpeg-dev

I need for compiling?
I am getting this error when running sudo make install:
"<strong>No rule to make target '/usr/lib/x86_64-linux-gnu/libnova.so', needed by 'libindi.so.1.1.0</strong>'"obviously because those folders don't exist on the pi....

SOLVED:: Should've just deleted the cmake cache text file.....
--Jon

Now, I'm running into this on the pi while running sudo make install on libindi:

/home/pi/libindi/drivers/telescope/skywatcherAPI.cpp: In member function ‘void SkywatcherAPI::PrepareForSlewing(SkywatcherAPI::AXISID, double)’:
/home/pi/libindi/drivers/telescope/skywatcherAPI.cpp:464:13: error: ‘sleep_for’ is not a member of ‘std::this_thread’

I am running gcc 4.7 so not sure if that's the problem or not. Not sure how to get to any higher version although 4.9 is installed but I can't compile with that.

SOLVED: ranto get to gcc-4.9 compiler which was installed already but not set as default.

--Jon

FYI, the indi for raspberry package is being build every day so no need to compile anything . You need PI Jessie, Wheezy is no longer supported.