MirkoV wrote: Hello Thanks for pointing that out !!!
I downloaded the file again and .... the content is now changed (from few days ago) and I can see the ASI120MM-compatible.iic is there now
Interesting they did not change the zip file name
Anyway, I now flashed the firmware and I can now confirm that my 120MM now works and acquires images correctly!!!!
Looking toward good weather now.
Thanks all for your support
Best regards
Mirko
I would not get my hopes up too high. I also thought that the camera would be working fine after flashing it, I got images and celebrated victory.
Unfortunately, upon using it for real I found that it would periodically garble a frame, thus completely throwing off the guiding and destroying frame after frame.
I would suggest you get the 120MM-S (USB3 version). No problem with that at all now in almost 2 years of continuous use.
It will save you a lot of frustration.
Jo
Read More...
For the most part. That sawtooth pattern is - I think - the result of mechanical tension that builds up as the mount fails to move in DEC until the tension breaks and is released, resulting in the overshoot in the other direction. When you adjust the tension, feel every moving part and determine whether anything snags, has resistance, etc.
Frankly, from looking at the simple construction, I am amazed that the mount can perform as well as it does (most of the time now) for me.
Read More...
You have to take the DEC cover off, straighten the belt and then tighten it so it has no more than 3 mm slack when you press it down in the middle. Having the proper tension and it running straight is key.
Nonetheless, this remains finicky. For instance, I can now get outstanding DEC guiding with an RMS of 0.5" early in the evening, only to see it fall apart and disintegrate to >1" after the meridian flip. That shows the mechanical limitations of the mount.
You will have to get a feel for how much tension the belt should have and whether the axle is running tight, but without excessive resistance, etc. A real problem IMO is that the DEC motor is drawing about 40% less power than the RA motor, which results in it losing steps whenever there is too much resistance.
Also, make sure that the mount is perfectly balance in DEC and that there is no cable drag. With those weak motor, you have to strive to eliminate any potential mechanical interference.
Hope that helps,
Jo
Read More...
Perhaps a naive question, but how hard would it be to integrate Planetary Imager into Ekos?
That is a dynamite platform for planetary work with monochrome or a OSC camera. Unfortunately, with my feeble Linux skills I have so far not been able to compile it on the Pi4, although it ran on the original Pi3B+.
If that could be integrated into Ekos, it would be a mind-blowing addition to the system.
Jo
planetaryimager.gulinux.net/
Read More...
Thanks, Wouter, but I am confused now.
On Cloudy Nights you write: "....after resetting the alignment model in the CEM25P hand controller and disabling DST (and setting the UTC offset such that it compensates for DST manually), it works like a charm. Pointing using plate solving, meridian flip, parking all work very well."
Does that mean that parking does indeed also work in your hands with the CEM25P, not just for me, and that the problem is isolated to the GEM45?
Jo
Read More...
wvreeven wrote: Jo,
I know that you don’t and we have already compared our INDI config files which are exactly the same. Apart from that, I am not the only one who has parking issues with a CEM25 or GEM45 and to my best of knowledge there are many more people with issues than without (actually I think you’re the only one without).
FWIW I use the stable release and have had this issue since we started using this mount which is over a year now.
Wouter
Yes, I know we compared the config file and I know they did not explain the discrepancy. However, the fact that my mount parks reliably does indicate that this cannot be a systematic Kstars problem, but either has to be a misconfiguration either of an Ekos or Indi file, or, perhaps most likely, in the hand controller. I never used that for anything, except for setting the Zero, i.e. home position, which is also the parking position. That may be the reason why I am one of the few who do not have these parking issues.
I think it is possible to control the mount directly without the need to go through the hand controller, but I do not have the required cable for that. Do you - or anyone else having these problems - and have you tried that? That would help tremendously with trouble-shooting, as it would allow one to narrow the issue either to Indi/Ekos or the hand controller.
Read More...
wvreeven wrote: What about CEM25 and GEM45? Did the park behavior get improved for those as well? If yes then I can test with those mounts if you want.
Wouter,
At least with the CEM25P I have absolutely no problem with parking. Works like a charm at my end.
I wonder whether the problem is rooted in a misconfigured file somewhere. At least that is what I suspect my problem was when the refocusing on filter change no longer worked for me:
indilib.org/forum/ekos/8421-solved-refoc...ger-works.html#64997
Purging Nightly, reinstalling and a full upgrade restored normal behavior.
Jo
Read More...
After the purge, reinstallation of Nightly and full upgrade the problem seems to have disappeared. I don't know whether that was the result of an updated file in Nightly or a purge of a misconfigured one, but the system appears to be back to normal.
Thanks to Hy, Peter and Jasem for looking into it.
Jo
Read More...
Hooray, success (I hope)! I reinstalled Kstars and performed a full-upgrade. Now refocusing on filter change seems to work again in Nightly. At least the first change went smoothly as expected.
I am letting it run through the night, will recheck in the morning. Will also check whether this translates to independent builds as well.
I hope that settles it. This has been driving me crazy for the last 10 days or so.
Read More...
knro wrote: I just tested this and cannot reproduce any issues, it works reliably well. At least with simulators. How do your filter settings look like?
Focus module should also at least run once successfully before all of this, but I presume you already done that?
Here are my focus module settings:
The thing is, I tested Hy's latest guide module change in which capture is delayed until RMS < [a user definable value]. I still have that build on my Pi, and THAT build works. It unfailingly will refocus on filter change. So it's not like I am out of business, I have a fully functional Kstars I can use to take pictures. However, I can no longer update it.
When I switch now to ANY other build, either the installed Nightly, or any other recent build I have installed completely independently on my SSD in a separate folder, the refocusing on filter change will no longer work.
All the settings are retained when I switch between builds, so it's not like the focus module filter settings are suddenly deselected. It is just that they are being ignored.
Since nobody else has that problem, I suspect that has something to do with me running that other build, which may have changed SOME file that is used by the installed Nightly as well as any of the independent builds from source.
Question is, which file is that and how can I change it, if that were indeed the problem.
Sorry, grasping for straws here. And I LOVE all the changes Hy has made to Kstars, it is fun testing all of that, so please no one should look at this as criticism, just simple troubleshooting. I can always go back to a backup, not a big deal. But that would beat the purpose.
Jo
Read More...