Come and join our community. Expand your network and get to know new people!
I'll test the new version and let you know the result.
Glad it wasn't just me!
I've just pulled Jasem's latest commits from the extractor branch and built it.
With the simulators it's now working. I'll update the kstars instance on my RPi tomorrow and test it with my Losmandy mount and camera simulator. I'm doing that anyway trying to run to ground my meridian flip issues, which I think I have licked (yay!)
Not sure when Jasem is going to merge that branch into the official nightlies.
I have not been able to get the scheduler going either. Latest build as of this evening. Nightly does not work either. Starts, but never proceeds to unpark the mount and hangs on IDLE.
This is with a CEM25P.
There is a lot more going on, though. I am currently using just the capture module after solving a previous nights image and slewing to that target. Exposures are working fine, tracking is working fine, guiding is working fine, but the mount tab thinks that there is no target defined and it think the mount is parked.
Beautiful night here, but I missed it. I found that using the SynScan WiFi HOTSPOT for anything other than sending and receiving motion controls is well beyond the design capabilities of the HOTSPOT. It can connect multiple hosts and will route traffic on its local net, but the data travel at the "speed of smell." A fairly unpleasant smell at that.
I decided instead to add a WiFi router to my telescope kit. A small one, but with some ethernet ports with which to interconnect the Pi3 and Pi4 and a 5G connection to my laptop. My home network is also 5G, but it drops rather dramatically as you move away from the router. Meanwhile, the changes made a staggering difference in image transfer speed. I had considered using VNC to avoid sending all that data over the network, but I don't think I need worry about that now. I typically setup less than 20 feet from the scope, so the bandwidth is...well...as I should have done it in the first place.
I have separated the cameras on the two Pi's. Besides USB collisions, I was having network throughput problems. Now that the bandwidth is solved, I may as well just leave the two Pi computers in the kit....in case you wondered.
Yes, a Transaction class is certainly more elegant. If you'd like
to add it to my latest version (attached here), that would be a
very sophisticated addition.
There is no difference between this and my last posting, except
that your "bug fix" for the single-termination-character return is
included. I suggest starting with this only because it further
confines the TX calls, such that even the Transaction class
would not have to propagate much throughout the code.
This will have to be my last tested version for a while, since
I am sending my mount base back for repair, and the mount
maker requires that I send the Pulsar controller along with
it , no doubt for testing.
Your help has certainly made a much better product!
Many thanks again,
Quick observation, sorry if you went over this already. It looks like you have the guiding deviation selected on the capture module. What do you have it set too? It seems like every time you go to dither the threshold you have set for guiding deviation is exceeded. This in turn will deactivate guiding and I believe also dithering since it is in the same module.
Go into your capture module, what is the guiding deviation set at?(Its on the bottom right and has a checkbox)
Does this not calculate atmospheric refraction vs altitude in a linear relationship? Surely that is not the reality, as the atmosphere is more substantial at lower altitudes Especially below 30°.
ZOMG I can hardly believe it. I had noticed that Kevin recommends putting in a delay value to improve torque, but I thought "Jeez, this thing is slow enough already" and "It moves the knob just fine, no need to putz with that".
Well, imagine my surprise when I put in a value for that and the pulley started whirling around at speeds never before seen!
If there's backlash, it's less than a step, which means less than 0.03mm focus-tube linear movement by my measurements.
Think I probably got it now. Sigh. Thanks again for all the help. I'll let you know the next time I can see stars how it actually goes.
hy wrote: Right. I agree (mostly--just quibbling about nirvana with what Jo has said..
Certainly, I'll search to activate the debug logs.
1. After a lot of tries and settings changes, I've pressed reset to default (guide-->option tab) and after a while, RMS went to 1-1.5.
2. SkyGuiderPro, so only RA
3. I've read about it and I have to try it.
4. My captures are great (for my taste), but I am trying to combat the walking noise, that's why I need it.
The thing is that I have also Stellarmate OS and with exactly the same settings dithering is working fine even with the max 10px. So I'm trying to understand why is it different.
Thanks guys. [Gals. Folks. Whatever. I may live in Madison but I'm old. I'm still learning this stuff the hard way: Having an ambiguously-gendered kid will do that for you!]
OK, now I think I understand what's going on with the algorithm; it's actually pretty much like what I thought it would be. And given that my backlash is something like 90 steps, and the linear algorithm moves out, then in, several times that at least every time it does a run, you'd think it would Just Work. Maybe there's another source of ugly of which I'm unaware.
I should definitely increase the tolerance, thanks for that suggestion. It's painful to watch it achieve really good focus, then move away from that to establish the other side of the curve, and then never manage to find that point again, poor thing! I think what I might need to do is bring a micrometer and actually measure where the focusing tube at these points on the curve. I tried to keep track of it on the fly by doing all the arithmetic in my head but that worked about as well as you'd expect for a tired old fart in the dark and cold.
If only I could work on this any time I wanted! I've even thought about poking a pinhole in a piece of cardboard, hanging that on the fence with a light behind it, and pointing the scope out the window at it. Who knows, it could work. Of course now it's not just cloudy but RAINING, so it would have to be something waterproof...
I'd be happy to look if you posted a log (enable debug logging for guiding), and also your guidelog (parallel directory to the logs directory).
But before you do, here's a few questions:
1) Does it guide well without dithering? This is showing quite large guiding error. See if you can get it to guide under 2 pixels rms (really ideally under 1 or lower). I'd like to see good guiding before attempting dithering.
2) Why 1-axis? Why not guide in DEC?
3) Can you run PHD2, and in particular their guide analyze or whatever it's called and see if that comes up with some warning? [There is no such analysis tool for KStars at this point.]
4) Of course, as always, the most important question is, how are your captures?
Right. I agree (mostly--just quibbling about nirvana with what Jo has said.
To rephrase, there is no explicit backlash compensation in Linear, but rather the algorithm tries to set itself up in a situation without backlash.
It does this by first moving far "out", then moving back "in" by quite a bit, in hopes that the inward motion eats up all the backlash.
It then tries to sample a v-curve, moving "in" by step size, sampling the HFR, moving in again ... eventually find where the bottom of that curve is
(by moving past the minimum and noticing the HFR has started to increase). It really doesn't care what the absolution position is, just the value of
the HFR at the bottom of the V. It then performs its 2nd pass, whose goal is to find the minimum again and stop there (at whatever
absolution position, doesn't matter). It does that 2nd pass by again moving back out quite a bit, and again reversing to inward, moving quite a bit to
again hopefully eat up all the backlash. Hopefully, the position it finds itself in at that point is outside the minimum HFR position.
It then performs its 2nd inward sweep, iterating the following: moving in my 1/2 step size, measuring an HFR, and deciding if its done.
It's done if the measured HFR is close enough to the minimum HFR from the 1st pass (and its no longer decreasing).
It may decide that something went wrong, and instead of going off to nirvana, repeating the backward/forward motion.
It always terminates after 30 steps.
It's not perfect, but can often overcome backlash.
It is converted to lx mod sc2 and rs232 works fine under win10 and does not want to work on linux (no RTS / DTR control)
What you are describing is the result of excessive backlash. The linear algorithm assumes there is none and that is what the step calculations are based on.
Wait, what? Did you not previously write:
Linear focus is the way to go. Nails perfect focus every time and inherently compensates for backlash.
One of these things is not like the other Hy's answer up the stream also seems to indicate that the algorithm is designed to minimize the effects of backlash.
I mean, "excessive" I might certainly buy, since a step size of 100 makes a visible focuser tube displacement but can be nearly eaten by backlash.
So, as nearly as I can tell, the backlash is actually in the motor; there's really nothing I can do about that without replacing it. Although I recognize that geartrain backlash in a commercial motor seems unlikely compared to my laughably crude setup displaying, shall we say, idiosyncrasies...still, when I reverse direction the thing gronks for a couple seconds and only then does the shaft start to turn. A subsequent move in the same axis makes the gronking and turning simultaneous.
When I ordered the timing pulley they sent me one with a bore about triple the size of what I'd asked for; coming up with a crude bushing for that left me with a setup that certainly might be susceptible to backlash, although as I noted that doesn't appear to be happening. I've ordered another, we'll see what arrives in a week or two on the slow boat from China.
I expect such a PR to be accepted for the 3rd-party repo yes.
The SPC900 does not do long exposure, unless it has had a special long exposure modification, if it has it will have two cables on it and will then work, I would guess that your camera has not had this mod, so it won’t work in this mode....
I found spc900nc and wanted to use it as a guide camera with astroberry 2.0.3, no problem with image but I can't make it long with FT232RL converter, can't send RTS / DTR signal. Astroberry mounts usb0-OnStep and usb1-Lx ports, but no response to the port. SPC900Nc-LX works fine in WIN10 and PHD2 and can control RTS / DTR. Anyone had such a case or know what the problem is? greetings