Lx200 serial fix and and update on my version.

[Blueshawk]

I know it's been way too long but I thought I would drop you a line and share something I figured out that I'm pretty sure you can use(below)...but first a long overdue update!
I did end up getting different gearheads 515:1 that on my slo-mo shafts worked out to about 20rpm at sidereal time. They lope terribly though due to the low commutator segment count but it only shows up at extreme magnification. I may be changing to geared steppers at some point. I've tried a few things to reduce speed errors and experimented with the PID library, which you can find in my git, though the code for it is a bit scattered, mostly in the main setup section and in Axis. Be careful with pulls as our control systems are very different now, but it may be fun to play with in your "spare" time. I'm not sure it's really helped anything though and more testing/comparison is needed. Now that I have the rpi3/indi/ekos wifi remote working(though still mighty unstable) I'm planning to disable much of the ui and see if it improves system response times. Cameras are still an issue in my system since so many no longer handle tethering well and I may break down and spend (way too much) money for a cmos or ccd dedicated AP camera.

I noticed you started work on a custom indilib driver. I've also been working on this but was aiming to use existing drivers if possible to reduce development time and so I can try other clients as they become available. After testing several drivers I found only lx200basic would connect but was very limited in control. Since everything seemed to line up I joined the Indilib forum and asked for help. Jasem said lx200basic has no motion controls, and suggested I use lx200generic or one of the other drivers. After trying generic which also failed to connect just like the others, I got the source of indilib and set out to find out why it wasn't working. After some time and major league class hopping I found myself in the libs folder in inditelescope.cpp looking at the "ACK" response init routine. after some fiddling I realized that lx200basic didn't ask for a response to ACK! This meant the ack response must not be working and fixing that might solve a bunch of connection problems! Here's what I found.
The ACK is actually a control character 06 and isn't sent in a command frame :xx#
in LX200serialhandler.cpp the lines:

if(serialBuffer[1]=='A'&&serialBuffer[2]=='C'&&serialBuffer[3]=='K') {
SerialSend("G#"); // respond to ack with mount type (G=GEM)
}

are in serialcommand() which isn't called unless there is a # found in the buffer.

So I moved the code to the buffer section, (before the framing check) and changed it to include the ACK more like the crlf control chars like this:

---

while (Serial.available() > 0) {
serialBuffer[serialBuffer_count] = Serial.read();
if(serialBuffer[serialBuffer_count]==10) {
return;
}
if(serialBuffer[serialBuffer_count]==13) {
return; // ignore CR LF
}
--> if(serialBuffer[serialBuffer_count]==06) {
SerialSend("P"); // respond to ack with mount type P for Polar
}

---

I included some extra code to make it easier to find the location.

I also found out that the response to ack should be P for GEM type mounts.

---

From the LX200command.pdf - now missing from the Meade website.

ACK - Alignment Query
ACK <0x06> Query of alignment mounting mode.
Returns:
A
If scope in AltAz Mode
L
If scope in Land Mode
P
If scope in Polar Mode

---

I haven't tried all the drivers to see what they mght offer but lx200generic has some nifty looking buttons to push and I was able to get my mount to move from within ekos and show up on a preview of a picam I set up for guiding last night...from my living room! I had previously gotten it to work in Stellarium but that had no move/joystick contrls and I had to use the wii one at the mount, which can get a bit chilly here in the mountains, especially when the winds blows up off the river at -4c.
I've also had issues with meridian flip and other goto motion control problems, mostly(I think) due to the encoders being behind the motors on my system. I ended up making an encoder mask definition that allows reversing the quadrature at compile time without having to resolder wires. I'll be restesting the goto soon to see if the new indi setup handles it better than Stellarium did.

Cheers!

Ray Wells
https://github.com/Blueshawk/arduino_cgem_driver

[mwvent]

Hi Ray!

I do not know how but I somehow knocked this message as read without noticing it many moons ago and it was a pleasure to see how well this is coming along.

I am afraid to say my project has completely flopped now sitting in the back of the shed unused since I moved house. It is a crying shame that I am not developing it but a wonder to see your project and the amazing astrophotos you have taken, I guess was what I hoped to do with mine! I think when my daughter is a bit older and life is a bit less chaotic I will be resuming from the point you have got to rather than where I left of you have made much progress on this!

[Blueshawk]

I wondered but didn't want to be a bother. :P
tldr: new motors coming, focuser, possible software changes because steppers.

Thanks, and good to hear from you! My code at github is way out of date at the moment as I keep breaking things and fixing them differently. Seems like I fix one thing and break something else every time I work on it. I'll try to get my most recent code updated so you can gleen it for ideas should you get inspired(or sleep), and I'll be glad to explain what I did...and maybe why if I can remember. I Since I wrote that I tried a thing called PDF (psuedo derivative feedback) after getting the guys who wrote the pid library to play with the math a bit to make it emulate what spacecraft use. Then I discovered that some of the instability was actually caused by uneven timing in the loop and installed an interrupt timer to drive the motors that works pretty good.
I just ordered stepper motors, pulleys and timing belt gears for a major overhaul after last spring's bouncing planets despite my efforts to get in front of motor errors due to motor lope - you were right about the gearing. Even 515:1 wasn't enough to overcome twitchy tracking - though the timing change helped quite a bit. I put it off long enough, fiddling and fiddling but in the end decided something had to change, and much discussion and research lead me to belts and steppers. I also plan to try adapting to the also developing Onstep arduino code to see how that goes just for kicks - and it uses the stepper library already. I've been reading through it and it has some cool stuff I want to try and some mind boggling math bits using slightly cryptic and nifty C functions. Keep a search engine handy if you dive into that stuff.
If you do get get back into it, be sure to go through my stuff very carefully when integrating anything because some of my hardware is different...but you already knew about some of that. For example, at one point I turned off the ds1307 clock byte code because I realized the newer model ds3231 I used would be used if I did, which helped functionality a bit. Future efforts might convert to the http://playground.arduino.cc/Code/EEPROMWriteAnything library that makes it really easy to stuff a rom full of setup variables and constants.
The pid loop and timer interrupt driven mount routine might be worth a try. I had trouble figuring out classes at first so some things are a bit messy. You will find the setup for pid in the main setup.
Other projects in the works now that the craziness of the eclipse is over are motorized auto focus using indilib, cheap little geared stepper motors, o-rings(soon to be belts) and bits of RBrown's moonlite focuser code, a motorized filter wheel and eventually active peltier cooling for the asi178 camera, which caused about 3 months of rain when I got it.

Good luck clear skies and congrats on the kid!
Ray

[mwvent]

No never a bother its great to see how things are coming along - I will be enjoy seeing what you do on this next just keep posting! Wonderful job 👍