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.
Time well spent.
I tried it with my working edition of Kstars (from 080819) and it opened okay. It was all white though. Hitting it with autostretch in the viewer showed some banding and stuff.
Then I tried to open it in my VM that has nearly the latest compile and it crashed to desktop with this error reported to dmesg:
``` kstars trap divide error ip:55de0d2813b3 sp:7ffdcc62a590 error:0 in kstars[55de0c771000+ff7000]```
Then I opened one of my fits files with Kstars fit viewer and it was fine.
You should file an issue at Kstars and be sure to include that file. I suspect it could have something to do with it being saturated and for some reason quite large.
Also, try opening kstars and loading an another file you know will open in another app.
Just a quick hit and run thought here. Try removing your XML files and replacing with defaults. When you downgrade the XML's keep you old settings. Hope it helps. That sucks bad on a good night. Been there...cried on Jasem's shoulder more than once.
I guided last night with an eq6-r and an asi120c-s on a converted finder scope. With the exception of a tight cable at one point, I was able to guide sub 1arcsec 600second exposures all night...and yes i'm stoked by that unusually good night.
With my new system I've found my tracking failures are almost always related to cable drag or polar misalignment. Also, I always clear any sync and tuning when I start each night as the mount tends to log erroneous settings from the previous setup if I don't. This could creep into tracking speeds on some mounts. I've found that I have better results by actually forcing the mount to be a bit west weighted(camera/focuser tilted west a bit) then shooting east, to help avoid bouncing on backlash. I tend to run my gains a bit high and I most recently switched my eq6r to 1.00x in settings and guiding.
Hope something here is of help to you.
Hi folks, just saw this in my emails.
I probably shouldn't recommend reading through all my ramblings but TL;DR and for what it's worth, I also tried my HP notebook with usb3 when I had this issue with identical results to my Odroid xu4 - also usb3. In fact the only way I found around the issue was to use usb2 ports on an rpi3b running Raspian, which is still in place on the mount as a result.
If you are needing the usb3 ports for high speed data forplanetary, one alternative answer is to use two different sbc's(odroid/rock64 etc.) and route one as guider and the other as main ccd using chained servers.
@Jasem! new clue, downgrading from usb3 helped!?
Hope this helps,