Hy Murveit replied to the topic 'A better FITS viewer?' in the forum. 2 days ago

Now that I'm running on a Raspberry Pi 4 with more memory, I can compile and test KStars. So I thought I'd look and see if I could figure out why the fitsviewer was crashing so much.

The irony is, I haven't been able get it to crash amymore! I don't know if it is because of release v3.3.4 , or due to the fact I'm running on a Raspberry Pi 4b, or the fact I'm now using Raspbian with my RPi4, or that the computer has more memory (currently using the 2Gb version, though my 4Gb just came in).

I guess I can't complain--hopefully I'm not jinxing myself, and I'll continue to try and give the fitsviewer a workout, but for now all's well.


Hy Murveit replied to the topic 'PHD2/Ekos issue in v3.3.4 -- PHD2 not aborting in meridian flip' in the forum. 5 days ago


Thanks so much for looking into it.

TL;DR I found a new issue and resolved it and the old problem magically went away. Details below.

Last night, things got even wackier than before. I could only guide for several minutes before Ekos and PHD2 got out of sync. PHD2 would be nicely guiding, and Ekos thought that it wasn't guiding. That is, Ekos would display the active Drift Graphics and bulls-eye, updating them every few seconds, but the (Start) Guide button was enabled and the "Stop" (guiding) button was disabled -- as if there was no guider. It seems Ekos thought that PHD2 had stopped, but PHD2 was merrily going along on its way. I looked through the logs and discovered that PHD2 had sent a message to Ekos that settling had failed. PHD2 didn't quit, but apparently Ekos thought it did and reported that guiding was aborted. I don't really understand the settling issue, but I changed the parameters to 10s settling time and 2 pixels tolerance, and now all is running smoothly. No issues at all (same target as last night). Running all night and perfectly done meridian flip with a pause in guiding and a restart of guiding after the flip. Sorry, not sure what the settling parameters were before the change--though my hunch is 3s and 0.0 pixels tolerance.

Perhaps there's an issue with Ekos not knowing when PHD2 shuts down, or if PHD2 is just reporting something it can recover from.

Also, BTW, I too had the "issue" where Capture continued to take pictures after the mount had auto-parked. Not a deal-breaker, just throw those shots away, but it's odd behavior. I think that perhaps the guider failing was what was stopping the Capture, and when the guider "went away" nothing stopped it until it got a focuser error when the light got too bright.

Anyway, sorry for the bother,


Hy Murveit replied to the topic 'PHD2/Ekos issue in v3.3.4 -- PHD2 not aborting in meridian flip' in the forum. 6 days ago

I see I was a bit wrong in my analysis of the what went wrong, though there's still an issue, I believe.

In last night's log (when I was just using capture tab, not the scheduler), in fact Ekos did ask for PHD2 to abort guiding in the meridian flip:
[2019-08-13T02:47:20.234 PDT DEBG ][ org.kde.kstars.ekos.guide] - PHD2: request: "{\"id\":781,\"jsonrpc\":\"2.0\",\"method\":\"stop_capture\"}"
but never restarted it (there are no further PHD2: request lines in the log which ends at 9am.

In the previous night's log (when I was using the scheduler) Ekos both asked for PHD2 to stop during the meridian flip
[2019-08-12T02:47:20.513 PDT DEBG ][ org.kde.kstars.ekos.guide] - PHD2: request: "{\"id\":1002,\"jsonrpc\":\"2.0\",\"method\":\"stop_capture\"}"
and restarted it after the flip
[2019-08-12T02:49:02.842 PDT DEBG ][ org.kde.kstars.ekos.guide] - PHD2: request: "{\"id\":1003,\"jsonrpc\":\"2.0\",\"method\":\"guide\",\"params\":[{\"pixels\":1,\"time\":3,\"timeout\":120},false]}"

For comparison, I attached the properly running log (using scheduler) from the previous night).


Hy Murveit created a new topic ' PHD2/Ekos issue in v3.3.4 -- PHD2 not aborting in meridian flip' in the forum. 6 days ago

I believe this is a regression in v3.3.3 or v3.3.4.

Just switched to 3.3.4 from 3.3.2 and I first noticed that a capture tab job would continue after the guider failed.
Previously PHD2 failures (e.g. losing the guide star) would halt the capture job--which I believe is the correct behavior.

Last night, duing an automated meridian flip, PHD2 wasn't stopped by Ekos during the flip, and eventually failed because of the slewing etc.
Ekos should automatically stop PHD2's guiding during the flip, and restart it after.
Before my upgrade, this all worked well, but starting after my upgrade, the guider doesn't seem to be getting these "abort" messages, and the capture module doesn't seem to be noticing if PHD2 fails.

Attached is my log from last night. Notice that at around 2019-08-13T02:45 a meridian flip starts, but PHD2 goes on its merry way, eventually failing at 2019-08-13T02:47:21.812

I've also attached the PHD2 log



Hy Murveit replied to the topic 'AstroPi3 Scripts revised' in the forum. 7 days ago

I'm not saying that you can't image on the 3b+, I did for the last 6 months and it was fine, but I have to say that, for me, the RPi 4 for imaging is so much faster, I couldn't go back to a 3b+.
- image download speed (usb3) is much quicker (camera to sdcard)
- writing from sdcard to usbstick (usb3) is quicker, though, I just ordered a fast usb card,
and will try to write from camera directly to that, skipping a step.
- general responsiveness to the linux windowing environment is much better
- I think on my Pi3b+, PHD2 would occasionally max-out the cpu, causing occasional freezing. Not too often, but noticeable
- I'll bet the networking (e.g. running VNC and doing the encoding to send the screen image across the network) is quicker too (just saying, no real measurements) making everything feel much more snappy

My entire stack runs on the Raspberry Pi, and I just use a laptop for the VNC monitor/keyboard/mouse.


Hy Murveit replied to the topic 'RaspberryPi 4 my version of full install indi/kstars' in the forum. 7 days ago

My Flirc case came in, and I've been using that the last few days.
Very happy with it. flirc.tv/more/raspberry-pi-4-case
It's $11.40. No fan, but the entire case is a heat sink.
The pi runs much cooler now.



Hy Murveit replied to the topic 'RaspberryPi 4 my version of full install indi/kstars' in the forum. 2 weeks ago

@Rlancaste, OK, I'll bite: How do you like that Fay Tun WiFi usb adapter in your picture?
Clearly the Pi's internal WiFi is pretty mediocre, and I've been using a travel router, but something like that would be more convenient...
Anything special to get it to work on the Pi?
Seems to get a pretty high percentage of 1-star ratings on amazon


Hy Murveit replied to the topic 'RaspberryPi 4 my version of full install indi/kstars' in the forum. 2 weeks ago

What case is that, can you send a link?
Is there any kind of cooling involved (fan? heat sink?)
My Pi4 sure runs hot.

What is that arm on the back, an antenna?
What did you have to adapt for the Pi4?



Hy Murveit replied to the topic 'RaspberryPi 4 my version of full install indi/kstars' in the forum. 2 weeks ago

Do you know the specific git command to do this?
I'm not too familiar with Git, and kstars development, but I did a little googling and came up with the following:

> git clone github.com/indilib/indi.git
> cd indi
> git tag

I assume tag v1.8.0 is the tag for indi 1.8.0

Then, I assume this is how to get the released indi source:

cd indi
git checkout v1.8.0
// then go ahead and compile indi in this directory

However, for kstars, things seem more complicated:

// Get kstars
git clone git://anongit.kde.org/kstars
cd kstars
// Find all the tags
git tag

It doesn't look like any of these are the current tags, if they still use tags. e.g.

> git log --tags --simplify-by-decoration --pretty="format:%ai %d"
2018-08-15 21:09:17 +0300 (tag: v2.9.8)
2018-07-25 21:38:14 +0300 (tag: v2.9.7)
2018-04-23 00:20:55 +0300 (tag: v2.9.5)
2018-04-08 10:06:21 +0300 (tag: v2.9.4)
2018-02-26 17:27:08 +0300 (tag: v2.9.3)
2018-01-28 09:57:47 +0300 (tag: v2.9.2)
2018-01-10 08:45:17 +0300 (tag: v2.9.1)
2018-01-09 16:22:27 +0300 (tag: v2.9.0)
2017-12-16 00:51:54 +0300 (tag: v2.8.9)
2017-11-19 15:33:38 +0300 (tag: v2.8.8, origin/2.8)

there is nothing for 2019.
Any ideas how to get kstars release source via git?

I guess the alternative is to use
or some other release from download.kde.org/stable/kstars/
and skip git altogether.

Is that the recommended approach?


Hy Murveit replied to the topic 'Modify default for meridian flip HA value' in the forum. 2 weeks ago

Thanks Wouter.

Yes, this was my understanding of how things work. However, you say:
" If the meridian flip actually happens depends on the mount and the meridian flip setting of the mount."
But what is that setting? I cannot find such a setting in the Indi driver, and when I look in the Atlas Pro mount manual, the best I could find is this:
nimax-img.de/Produktdownloads/51933_2_AnleitungSynscanEN.pdf (see page 13, section 5.6)

To set the meridian flip mode, go to Setup\Flipping Mode.

  • Scroll to Auto Flipping and press ENTER to let the hand
    control decide automatically whether to perform a meridian
  • Scroll to Force Flipping and press ENTER to force the
    mount to perform a meridian flipping for the next GoTo
    object only.
  • Scroll to No Flipping and press ENTER to prevent the
    mount from performing a meridian flipĀ¬ for the next GoTo
    object only

So there is some control via the handset, but not exactly control over when the mount will decided to change sides.
It does imply, though, that ekos/Indi could send a command to the mount to force flipping on the next goto, which would make the overall system much more reliable (only one system keeping track, unstead of needing to coordinate HA parameters).

In my case, I think I've found that setting "Flip if HA>0.2h" in the Ekos mount tab fixes my issue.



Hy Murveit created a new topic ' Modify default for meridian flip HA value' in the forum. 2 weeks ago

I had several unsuccessful meridian flips this past week (ekos said it was starting a meridian flip, it re-aligned, re-started guiding, restarted captures successfully, but I found that the OTA stayed on the same side of the mount). I was not running in the scheduler, but rather with a job within the capture tab. Luckily, I checked my mount the first time this happened and caught the issue before anything "crashed". I was careful after that and always checked to see if it had flipped.

To solve this, I took a shot in the dark and changed the test for meridian flip in the mount tab to "HA > 0.2" and then watched two more meridian flips, and all worked great.

[Previously, when the meridian flip checkbox was in the capture module,I believe the default for flipping was for the HA greater than a small positive value.
The default now (in the mount tab) seems to be HA = 0.]

My guess is that because of some slight sloppiness (probably on my part re time or lat/lon or some-such) the mount decided not flip sides on the slew issued for the meridian flip, since it thought the OTA was still on the correct side of the mount. I'm guessing that defaulting to HA > 0.2 or something similar would fix that. Also, I think it would a rare case where going 10 minutes past the meridian would be harmful, and a much more common harm could be caused by missing the meridian flip altogether as had happened to me.


PS My setting for HA > 0.2 doesn't seem to stick on reboots. Can I get Ekos to remember this setting in my mount tab?