Hy Murveit replied to the topic 'fits viewer: auto-stretch failure' in the forum. 2 days ago

My new code/UI that allows you to modify the automatic stretch is now available. You can 'git pull' it from the main KStars git repository, and I imagine it will be in the nightly builds soon.
Hopefully the UI will be obvious when looking at the FitsViewer (there are now sliders and buttons on the bottom of the window).


Hy Murveit replied to the topic 'Meridian flip interrupted on EQMOD mount - Alignment Module?' in the forum. 4 days ago

BTW, I checked, and I'm actually using "Flip if HA > 0.2h" for my Orion Atlas Pro mount.
Again, make sure your OTA/Camera can safely go this far past the meridian without hitting anything.


Hy Murveit replied to the topic 'Meridian flip interrupted on EQMOD mount - Alignment Module?' in the forum. 5 days ago

Here's how I would interpret your log:

In the case where the meridian flip failed (ie took only 3 seconds),
when EKOS determined it was time for a meridian flip, it sent a slew command to the mount.
It was "hoping" the mount would switch to the other side of the pier (which normally takes a minute and a half) but the mount decided to
stay on the same side of the pier and only took a few seconds to finish its slew to a very nearby coordinate. That is, I believe it was probably
not interrupted, but rather it probably just finished quickly. Once the slew was complete the normal post-meridian-flip-slew alignment process started up.

To try and fix your situation, I'd try setting the meridian flip threshold to >0.1hour or maybe even a little more and seeing if you have more luck
(assuming that would be safe--e.g. the camera/telescope would not hit tripod, and so on). Going that much further past the meridian might
cause it to go to the other side of the pier.

If that doesn't work, or perhaps even before trying that, another, less likely possibility, is that your mount somehow has the wrong time, or geographic
coordinates, etc so that it doesn't have the same meridian in mind as your software. You can test that by commanding it to point to some star e.g. 15 degrees
east of the meridian, and another one 15 degrees west of the meridian and making sure picks the appropriate (different) side of the pier for both stars.
Make sure you have your finger near the stop-the-slew button just in case it really is off.

I've had (and solved) both of the above issues in the past 6 months! Moving to .1h definitely improved my meridian flips.


PS Please be civil, I'm certain Rob was genuinely trying to help you and not being dismissive.


Hy Murveit replied to the topic 'AstroPi3 Scripts revised' in the forum. 1 week ago

FWIW, in my experience I can compile Indi and KStars on my 4Gb RPi4 no problem. It's certainly not as quick as compiling them on my mac laptop, but it works for me and is usable for me. I've done it as well on a 2Gb RPi4, and the difference is noticeable, but still works OK. I would not recommend compiling these programs on a 1Gb machine (last year I tried and gave up on my Rpi3b+, I guess you can get lucky, but...).
You certainly want to run parallel make (e.g. 'make -j 6 kstars') on the 4Gb RPi.

I'm not on top of swap space for linux, but I checked my Raspbian RPi4 4Gb just now, and I had the 100Mb setting you mentioned active in /etc/ dphys-swapfile. However, running 'free -h' or 'top' shows that I currently have 4Gb swap, not 100Mb. I guess this is due to running zram en.wikipedia.org/wiki/Zram (something I didn't actively setup, but I guess I'm using, as I checked and it is in my /etc/rc.local file, and visible with '/etc/swapon -s'.

(I don't use Astroberry, just raw Raspbian with Rob's script).


Alfred thanked Hy Murveit in topic Fits viewer freezes 2 weeks ago

gehelem thanked Hy Murveit in topic Fits viewer freezes 2 weeks ago

Hy Murveit replied to the topic 'Astrohat - An open hardware RPi Hat for astronomy equipment' in the forum. 2 weeks ago

If the goal is to power everything through this, I'd worry about the current draw of a mount while slewing. I'm pretty sure I've seen my Atlas Pro draw 4 or 5A, but just for a short while.

USB outputs might be nice, but I suppose one could just connect a powered USB hub to this hat.


Hy Murveit replied to the topic 'Limits to protect the mount from bending over backwards' in the forum. 2 weeks ago

Here is the log

It is gzipped to 12Mb but the log is 250Mb ungzipped because there's a new log line from indi that seems to print out a lot.

Again, bottom line is that when PHD2 stopped, capture stopped, and then there was no meridian flip.
Without a meridian flip, and with the mount continuing to track, it eventually went too far past vertical and bumped into the tripod leg.

I would love to have a limit, similar to parking, that stops the mount once it bends too far back.



Hy Murveit replied to the topic 'Limits to protect the mount from bending over backwards' in the forum. 2 weeks ago

It did try to park at 5:30am, but by then it had long been in contact with the tripod legs.
It thought it was parked, but in reality it wasn't in park position, probably because the camera attached to the refractor on the mount was in contact with the tripod.

Yes, a shorter telescope would reduce this issue.



Hy Murveit created a new topic ' Limits to protect the mount from bending over backwards' in the forum. 2 weeks ago

Last night, the following occurred.
I was shooting Orion, started while my scope was pointing on the east side of the meridian.
I ran a capture sequence job intending to shoot all night. No scheduler. Was guiding (using PHD2). I set the mount module to park at ~5:30 am. I did not have mount limits set nor enable limits checked.
The plan was it would capture with various filters until ~2am, then it would meridian flip and continue until 5am or so. I went to bed.
I have done this many nights successfully (including the previous night).

Unfortunately, a cloud must have passed by at 1:30am, causing PHD2 to abort guiding. Capture aborted too because of that. Without capture running, the meridian flip did not happen.
The mount kept tracking and unfortunately the camera eventually bumped into the tripod legs, which is the way I found it in the morning.
Fortunately, I don't believe I damaged anything.

My question is: What should I have done to prevent this?
I suppose suspect #1 is mount limits. I have never done that, probably because I never really understood how to set that up.
I want the scope to be able to point beyond vertical (because i have meridian flip set to +0.2 hours--otherwise I find my mount (Orion Atlas Pro) does not reliably switch pier sides when the meridian flip comes along.
Would mount limits have saved me, and yet worked properly and allowed the flip if a cloud didn't come by? How do I set them up? Can the limits be set "beyond vertical"?

Should we have a simpler interface --e.g. there is an "enable limits" checkbox in the mount tab, but it controls altitude and thus only goes to 90-degrees. I think I want something different--e.g. when my scope "bent over backwards" last night, its altitude was still below 90-degrees. Should we have simple max for that that could be enabled to protect our mounts in situations like what occurred last night? and what is the word for bending-over-backwards?