After the k50 failed to bulb, but we had gotten some pentax models working, I helped some with GPhoto testing for the eos-m1 that I've never gotten to tether. It's trapped out pretty well in that camera to the point of not even being able to use an arduino IR trigger I made while connected to the camera card. If you connect usb it fails to fire even locally. I read that some newer models were fairing a bit better but haven't checked in for a while. Development for models is usually done through Libgphoto2 issues tracker at github so you might get info doing a search there and reading the development threads.
OH yep. Missed that one. Glad you got it going.
Quick pass attempt to help. You might make a new thread for this to get more folks to see it.
Make sure you close the arduino IDE before trying to connect. it likes to hold the port open once opened. Make sure you are attaching the usb port it's on. Turn off scanning as handshake attemps can dork other ports until you get the order correct. I have the best results when I make a udev rule that identifies the arduino by vender code or serial#(if not 0). There's some info on that in the tutorials somewhere. I remember it does handshake on the 3.1.5 so if you get that from If in serial monitor then it should go, at least that far. Good luck!
ar2star2 wrote: Ray, have you tried the MyFocuserPro2 driver it uses Arduino, has backlash compensation a recent Indi driver was written by Alan. I’ve tried it on an MyFocuserPro2 I built a while back for use on ASCOM I just updated the firmware to version v291 and it works I believe there may be a version v292 by now there’s a long thread on here about it
Thanks I'll check that out. I looked at it once long a go but found the code difficult to follow and went a different route. I'm a bit more experienced now so maybe I can bend it to my hardware needs now. Sounds like they continued development as well so if nothing else that new driver might have the protocol I can use. Jasem also mentions another full opensource driver in that thread I'll check out too.
Thank you for the input. I could do that but then I would also have to write my own driver which would largely be redundant given the number and complexity of current ones.
To reiterate the OP...
What I'm after is to see if anyone has already made an arduino focuser serial using a different protocol with a backlash feature that already has a working driver in the system.]/B]
I've been using a DIY arduino driven focuser to drive motors on several different scopes for some time now but have recently decided I need backlash control for the one using a small gearhead stepper, while still being able to turn it to 0 for the belt driven ones. I recently did a complete rewrite of my arduino code using the accelstepper library and added backlash compensation, but it's emulating the moonlite protocol which has no backlash feature itself (according to the release paper circulating). So... preamble completed, on with my question!
If I change to a different protocol which one would be the easiest to match with an indi driver that does have backlash compensation?
and if so, can I get a copy of the protocol used?
Also, does anyone have arduino focuser code that emulates a different protocol from moonlite and that has working backlash controls via the indidriver?
All the ones I've found in searches are using moonlite, but it never hurts to ask.
I did a text search of the indi-focus drivers code and found several that have it mentioned and am going through looking at indi code to try to decide which one to switch to but many of them are very complicated.
I can second this for Linux users!
Having an opensource solution that works has catapulted my foray into the world of remote astronomy,EAA and AP more than any single feature. I would also add that approachable and understanding developers make it even better. Almost every time I interact with opensource developers they are enthusiastic or even excited to have feedback or to help with confusion, of which I've had my share of with this system.
I always tell people: "devs run on hugs..so go give them one."
Cheers and clear skies!
I just thought I'd drop a quick note on a recent problem I had and just solved.
I'm using indiserver on an rpi3b at the mount(usb connected eq6r), networked to a pc in the house running kstars on ubuntu based linux. Last week I had a great night and left the rig running making darks and bias frames while I slept a the remaining few hours, then wound up leaving it on all day. When I went to restart that evening I figured I better reboot everything, and then I discovered that the mount position was reporting incorrectly and would not sync properly, and even headed the wrong way on screen while guiding. The next day I used the hand controller(not normally installed/used) to reset the mount but this had no effect. I tried various things to narrow down the problem and after much head scratching I tracked the problem to the Kstars version being out of sync with the version with Indilib on the mount rpi. I updated the pi and it works fine now.
Hope that helps anyone else that has this weirdness happen.