I haven't done pec in mine, maybe Azwing has something? Any small quadrature encoder should provide the needed signals. The little red lion ones work very well and are small and lightweight. I've seen them in industry for decades. They count steps and log however many steps vs. the encoder count. Any lost steps are then added back to the system. I've not missed them however. As long as you have enough torque available for the microstep level (steps per step/sqr2=trq ...I think) it won't miss them. There is no real benefit to more than 16s/s unless you need it to make up for gear ratios. Also watch out for some motors notching to the main magnetic step points as this can override the microsteps and lead to some nasty tracking hops. We had a really good discussion on steppers in another thread on this forum when I was trying to design my lightweight mount, converting a Celestron Omni cg-4 to goto for ap.
This might get you to the right one sorry in advance if it's not. www.indilib.org/forum/mounts/2213-rpi-di...control-upgrade.html
@azwing...really? it was the ",4"
I have no Pec on my mounts.
I tested Pec some years ago with both optical detectors and hall effect chips.
Both were working but I still would put my choice on optical.
With hall I couldn't have a good reproduceability over time, may be my magnet was not well positioned.
With optical sensor the slit on the index is quite the same all the time.
This is only my experience, many people even use reed relays.
I included some additional controls in the driver.
in the Site Management TAB:
- Backlash settings
- Tracking Compensation
in the Site Management TAB
- Homing (Cold start and Homing
Also some bugs sorted out for the Status refresh which is now operational I think
I still have a problem with parking but I think I found the problem:
When having backlash set to a value greater than zero (0) parking constantly fails
When Backlash is set to zero no perking issue anymore.
I posted to Howard to have an advice, but I definitively think it is OnStep related, not Indi Driver
I could runn in paralell three instances of OnStep:
- One Teensy and One Mega2560 with Alpha Software
- One Mega 2560 with Beta Software
Just received confirmation by Howard for the Parking Issue.
Not yet working but at least I am able to manage it working between 0 and 15 for RA /DEC Backlash
Anyhow not so important for the moment.
The Backlash code seems to be active only for Parking, and as long the mount is not fixed nobody cares about parking accuracy.
to be followed .
Ah. That makes sense as it would help find the same spot each time to simplify later startup. I hope to have a dome one day.
I noticed something odd while trying to get guiding up and running. I guess backlash only effecting park means I'll have to nail down that sloppy dec bearing after all.
After using my phone to get started and do a one star alignment the speed controls are now working well. The pad goto worked after syncing but for some reason I had to use the right click menu in kstars to sync. I had less trouble getting the site correct put after syncing the time first and the initial goto was correct the first try and only needed centering.
The sync button in the mount control pad just showed slewing and did not sync. It did however do a goto properly after syncing with the alternate method.
- AH! solved it. The camera was hogging the usb. I'll lower the bandwidth limits on both of them. --limitation of the Rpi3 I think. an odroid-XU4 is in the works to get usb3 ports.
That unparked status is a problem. it showed up again after a goto. The pad is reporting errors still but the right click will move. I suspect this is related somehow to your troubles.
2018-02-06T00:38:15: [INFO] OnStep Unparked...
2018-02-06T00:38:07: [INFO] OnStep Unparked...
2018-02-06T00:38:06: [INFO] Slewing to RA: 6:31:37 - DEC: 4:59:47
pretty much any move is showing it. I think it may have been messing other things up too. "Lost in space" would describe my evening.
If you keep reading my messy southern prose you'll be an english pro in no time!
honestly I do not test using ekos so I did not check the PAD, I have to try this out.
I experienced the same bottleneck things, my computer has only one USBport and when I hooked a powered switch on it I got even more problems.
Hope we can get a patch for this Parking problem.
You are right I have this parking message showing up all the time, some debugs to remove or an if contition to set in the code.
Basically I poll check OnStep status vi :GU# and if no change return, maybe there is still something to refine here.
English Pro ... my wife "graduated in English" always laughs when she reads my English so I have no chance
Some testing with Ekos:
1) Ekos Telescope Tab
- Track On/Off works fine
- Driver information about Aperture, Focal Length, Config works
- MinAlt / Max Alt are inline with OnStep settings
1) Mount Control PAD
- Sync effectively does not work as our intuition would expect (I expect that sync would work all the time when an object is reached and tracking)
Looks like sync does work only after a target has been given using the searh tool (the magnification glass).
Tryed to select an object and sync works.
My opinion there is something with Ekos on this side, may be we can ask Jasem.
- Speed (1x, 2x, 3x, 4x) control works and is synchronized with Indi Control Panel
- All direction Arrows trigger the right movements
- Park and UnPark work
A propos Parking ...
I succeeded to eliminate the nasty debug messages "Parked ...", was in the ReadTelescopeStatus() where I had to if out some actionsl
çà me donne du courage pour la suite ... encourages me for the future
I think the next goal should be the Alignment process.
I would like to have this process driven by some pop-ups but I have no clue how to make po-ups work in Indi
Time to read a little bit the manual
As a famous french author said, I am a writer but nobody reads me!
The reporter: But what type of literature do you write?
He answered, I am User Manual writer!
I also found/in agreement:
Aperture and focal length do work, as well as when used in guiding.
Unpark started motors but not tracking.
Track on/off did work to starting tracking.
Speed changes work great now.
pad sync seems to describe lots of problems I've had with it.
***Park failed to follow meridian flip(possible firmware problem) details below.
When I tried to park from a southwest target last night the RA went the wrong way home and I didn't find out till I went out to retrieve the mount. I found it had tried to make its way home via china which is not healthy for it.. Nothing was broken that I saw though some cables were a bit tight. I'll do a function check before I put it outside next time.
On mine unpark appeared to work but tracking stayed off. The tracking button in control panel kept turning back off but did eventually work, possibly due to usb or cpu loading.
When I unparked with the phone sidereal tracking started right away. While most EQ mounts would be fine with it, folks might not want a big scope sitting on its parking yoke support to start tracking immediately. Maybe a check box option could be offered to start or not start tracking on unpark. Tracking and parking are currently on different pages. Consolidating (un)park, tracking modes, tracking on off, home, reset home and reset park onto one tab might help the startup flow a bit.
On alignment, Ekos has a couple nifty methods already with one star via goto/center/sync, plate solving sync and centering via astrometry.com, a polar alignment aid, and a multi target mount tuning routine I haven't tried yet. The OnStep arduino code has a section marked experimental for multi point mount tuning as well. It may be possible to interface the Ekos routine with the mount one I haven't tried any of that beyond just a quick look as yet.
Unrelated: I've actually had some issues getting guiding and plate solving to work in recent builds. I need to try PHD2 guiding to see if it is related to a report made recently or there really is something wonky(maybe translates to déréglé?) on my mount.
I think you do just fine on English, much better than I would into French even with an online translator. My older son is fairly fluent but lives three states away. You're certainly getting farther on the programming than I would have at this point.
Pakring / Unparking:
- normally, an this is what I have here, unpark returns to the tracking state before parking
- I use a patch for parking that is not yet released by Howard, but seems oit fixed the issue of "parking failed"
- the idea with the checkbox looks fine to me => todo list
Considering your China tour, I remember when I started to build my first mout I spent months to design the gear considering 360° until I discovered (the hot water again) that it makes no sense to have a look to China.
In the same stupid trap when I wrote my first µsteps driver in assembler, I deleopped from scratch a Sinus Cosinus calculation to have the right values, only after dbugging this crazy soft I realized that using a table would reduce the code drastically but also spare me headakes and nightmares
Sometimes it is better to stop and to sleep!
Alignment, alignment, alignment ...a "Leitmotiv" (In german a driving motivation if not an obsession) yes this is really a thing I should start to think about.
For now I stay with the user driven method via messages but the Indi alignment subsystem lokks really nice, I used it with Eqmod.
Issue a pull request to Jasem to include the actual code in the Master?
and continue testing in the fork.
What is your thinking?