Wolfgang,
If I checkout your scheduler_enforce_guiding branch, will that supersede the master branch of the regular kstars repositiory?
Hy recently merged his new guiding and periodic error correction algorithm, I wanted to install that at the same time.
There is tons of new stuff since my last update, I just can't figure out what comes from your branch and what comes from master.
Steve, Wolfgang's repo checks out fine for me and the Pi is happily compiling. I just don't know what....
Jo
Read More...
That's a shame, Peter. From your description, that short must have been inside the 12 V socket.
Well, let's see what Pegasus Astro says. The part is not very expensive. You can get one for as little as $2 from Amazon.
smile.amazon.com/Detectorcatty-TB6612FNG...s=electronics&sr=1-8
So, if Pegasus Astro says they can't repair it or it would be very expensive to do so, you may want to have a go yourself. You just need a soldering iron with a very fine tip, a magnifying glass and a steady hand. Desolder the old controller, then use fine wires to connect the main board to the breakout board.
Alternatively, I would suggest putting your own autofocus controller together. This one works beautifully.
Read More...
Hoi Peter,
yes, that seems to show that the motor is fine. So it looks like this is a unipolar stepper. Red should be the common wire that splits the coils in half. So when putting one connector on the red wire, ALL the others should read 50 Ohms, right? If only 3 wires then read 50 Ohms and the fourth shows high resistance, then that would indicate that the coil is fried between those two connectors.
Anyway, the common wire could have a different color, I don't know, but one of them should show that behavior. Then the other wires should group into 2 pairs that show 100 Ohms. If so, then all parts of the coils are fine and you can eliminate the motor as the culprit. That leaves the stepper controller, arghhh!
In that case, it looks like the stepper controller is fried and you would have to contact Pegasus Astro to find out what to replace it with. The PDF you provided the link to does not say.
Can you post a picture of the stepper controller that allows one to read the label? From the specifications on the Pegasus web site it looks like this may be a DRV8825. If so, that is not an expensive part to replace especially if it is not soldered onto the board but connected through a socket. Since that is the part that would have to absorb the brunt of the surge generated by the short, it would make sense that it got fried.
Read More...
I would measure the resistance of the stepper coils first. If you fried a coil, resistance will be high. If the coils are intact, you should find low Ohm resistance (consult the spec sheet for the stepper to find out what the coil resistance should be ). It could also be the stepper controller (not sure what focuser you are using, self-built, commercial?). Is it Arduino driven? From what you are writing, it seems the microcontroller is still functional, otherwise Ekos would not recognize the focuser. So that's good news. If it is just the motor, that is easy to replace.
Can you share the wiring diagram?
Read More...
Hoi Peter,
I think missed steps is the most likely reason. Having just built a Moonlite compatible autofocuser using the MyFocuserPro blueprint, I had the opportunity to find out first hand. It depends on whether your focuser is using microstepping or not, which will also increase the likelihood of steps missed, and also the current limit that has been set on your focuser. If it is operating near torque limit, the chance of occasionally missed steps will increase. That may not be apparent when you just watch the focuser in action. I am still fine-tuning mine to minimize the number of steps missed on my focuser. You want the current limit set as low as possible, but high enough so missing steps are minimized. The higher the current limit, the higher the power consumption on the stepper, the noisier it operates and the hotter it gets until it seizes up entirely. Those are the trade-offs. Went through all of them.
Salü,
Jo
Read More...
What kind of autofocuser are you using? What is the setup of the stepper motor? When you say "smaller numbers", do you mean focusing inwards, i.e. against gravity?
My first guess is that your stepper is missing steps, due to current limitations and excess weight on the tube, so they need to be made up by gradually shifting the apparent focus position.
What speaks against that (and against your explanation) is that this seems to happen only with one filter. Those effects should be universal.
Are you sure only one filter is affected? If so, has it gotten loose in the filter wheel and is about to fall out? If the filter shifts position it might explain that, although I would not have thought that it would make that much of a difference.
Anyway, I think the troubleshooting has to concentrate on the fact that only one filter is affected (if that is indeed the case). Then see what is wrong with the light path affecting that particular filter only.
Read More...
I never used Kstars on a virtual machine, but Wouter (wvreeven) uses it on a Mac as well. He would be able to give more qualified advice.
Generally, I would suggest using an RPi4 running Ubuntu MATE 20.04. I have the best experience with that constellation. Painless since I went from Ubuntu 18.04 to 20.04. Run everything on the Pi4, control it via VNC from inside the house. Just works.
Read More...
I had the same problem Steve describes, but with the internal guider. I also never experienced it before. This is what happened:
[2020-06-24T23:51:46.172 CDT DEBG ][ org.kde.kstars.ekos.guide] - Received guide frame.
[2020-06-24T23:51:46.178 CDT DEBG ][ org.kde.kstars.ekos.guide] - Multistar: findTopStars 10
[2020-06-24T23:51:46.230 CDT DEBG ][ org.kde.kstars.fits] - SEP detected 0 stars.
[2020-06-24T23:51:46.230 CDT DEBG ][ org.kde.kstars.fits] - # #X #Y #Flux #Width #HFR
[2020-06-24T23:51:46.231 CDT DEBG ][ org.kde.kstars.ekos.guide] - # X Y Flux HFR sepSc SCORE SNR
[2020-06-24T23:51:46.231 CDT DEBG ][ org.kde.kstars.ekos.guide] - No suitable star detected.
[2020-06-24T23:51:46.231 CDT INFO ][ org.kde.kstars.ekos.guide] - "Failed to find any suitable guide stars. Aborting..."
[2020-06-24T23:51:46.234 CDT DEBG ][ org.kde.kstars.ekos.capture] - Guiding state changed from "Reacquiring" to "Idle"
[2020-06-24T23:51:46.235 CDT DEBG ][ org.kde.kstars.ekos.guide] - Stopping internal guider.
[2020-06-24T23:51:46.240 CDT DEBG ][ org.kde.kstars.indi] - iOptron CEM60 : "[DEBUG] CMD <:GLS#> "
[2020-06-24T23:51:46.241 CDT DEBG ][ org.kde.kstars.indi] - iOptron CEM60 : "[DEBUG] RES <-348454442028010901#> "
[2020-06-24T23:51:46.243 CDT DEBG ][ org.kde.kstars.indi] - iOptron CEM60 : "[DEBUG] CMD <:GEA#> "
[2020-06-24T23:51:46.243 CDT DEBG ][ org.kde.kstars.ekos.scheduler] - Guide State "Idle"
The scheduler was running unattended.
The guide star was lost, frames were dropped and then the guider was stopped.
However, the scheduler continued and captures also continued until the meridian flip occurred at ~ 4.15 AM. It looks like that completed fine, but then the capture sequence did not restart as the Capture module was probably waiting for the guider, which, however, had shut down hours earlier.
The scheduler finally terminated shortly before 5 AM when twilight triggered it and the mount parked normally.
Here the link to the (lengthy) log:
www.dropbox.com/s/slzkkb53h3sxj0i/log_18-37-16.txt?dl=0
I am only using the internal guider, so this problem is not PHD2 specific.
Read More...
The Polemaster works just fine on the Pi4. Use the internal polar alignment module and select QHY CCD as an auxiliary attachment. It will directly recognize the polemaster.
Then just use with the polar alignment module in the solver tab.
I do it all the time. No other software required. Works like a charm with Kstars as is.
Jo
Read More...