Thanks for doing that Markku!
How did you train your PEC? With the top button in the indi eqmod pec tab?
I was just running with RA PEC? Did you have both RA and DEC? (As I recall, it didn't allow me to train DEC).
I'll try again the next free night.
Just double checking: I am saying that (a) I started guiding, and (b) turned on PPEC RA training, and it ran for a 10-15 minutes, and then said it trained successfully.
Then, later, I turned on guiding again (mount is definitely tracking--I just double checked) and yet it will not let me turn on RA PPEC.
So, I could not turn it on though it was definitely moving/guiding.
Is it somehow possible that it didn't train the PEC successfully, even though it said it did when I turned on the training?
I noticed while guiding that I have significant periodic error with RA on my Orion Atlas Pro. I though, perhaps it made sense to try the periodic error correction feature--though I'm not experienced with it (perhaps I'm confused on how to use it). I did the following.
I started up Indi and Ekos, pointed at Dubhe and started (Phd2) guiding. I went to Indi Control Panel --> EQMod Mount and turned on RA PPEC Training. It went yellow for about 14 minutes and then said RA PPEC training completed, and the light turned off (went grey). I assumed this meant it was successful. I then stopped guiding, set up my target (M13), clicked on Indi Control Panel --> EQMod Mount --> Turn RA PPEC to "on". I then started guiding. At this point Indi (in the EQMod Tab log) said: "Turning RA PPEC off while guiding. Turn on RA PPEC after guiding."
So , I'm confused. Can I not use PPEC while guiding? I had hoped that was the point--to improve guiding, or rather make guiding easier, by removing the periodic error component. How should this be used?
Thanks for the release Jasem!
FWIW, I 'apt-get upgraded' , started up kstars, made sure I was running 3.2.2, and played with the fits viewer. It crashed (the viewer, Ekos & KStars all went down) after a few minutes of messing around with a few files in the fits viewer.
I'd love to show you some log of it, and I was logging most things (see the attached picture of the logging window) and I have attached the log too, but I don't believe you'll find it very imformative.
If there's some way you'd like me to help you debug it, please let me know.
Running on a Raspberry Pi 3B+ with StellarmateOS.
I originally meant to write this note about a bug I saw trying to plate solve near the meridian (see the PS below).
I had logging turned on for all Ekos modules, see the attached logging.png image (and it was checked many days ago and restarted many times).
In the log I've attached, you'll see there is only one line from the align module, even though it did a plate solve a couple of times, and it ran through many iterations of those solves.
Did I do something wrong, or is there not a way to log that module?
Further, I would have liked to just cut-and-paste the output from the log portion of the alignment tab, but I couldn't figure out a way to cut/paste that text.
There was no copy or any menu popped up with a right click. I'm running this on a Raspberry Pi, StellarmateOS, over VNC.
How do you cut/paste from those Ekos windows?
Running the latest version of StellarMateOS (Kstars 3.2) on a RPi.
PS The original bug I was trying to report, but the attached log won' be of much use, unfortunately, would have shown that at about 21:41 local time (pacific) I tried to have the align module plate solve the Leo Triplet. I didn't realize, but it was about 1 minute before Meridian at the time. What it did was it slewed to just before it would have had to flip, found it was within 1 33' of the target, then slewed to the other side of the meridian, took a picture, found it was within 2 42' of the target, took another pic, again found it was within 2 42', and repeated picture taking and being within 2 42' until it ran out of iterations. (Perhaps the issue was related to changing sides of the meridian during an alignment sequence?) I suspect this had to do with that, so I parked it, waited 10 minutes, and it had no problems slewing, plate solving and getting within 10" of the target in a few iterations. I'd like to document this more carefully next time I see it happen, if this information isn't sufficient to debug it, please let me know if/how I might turn on the logging. Thanks.
I watched the meridian flip again tonight, and this night, no issue.
If you look at the text below from the Capture logging on the capture tab, you can see that there's a 50s gap between downloading the last image and completing the meridian flip slew.
2019-04-27T22:11:21 Capturing 240.000-second Green image...
2019-04-27T22:11:18 Post meridian flip calibration completed successfully.
2019-04-27T22:11:04 Performing post flip re-calibration and guiding...
2019-04-27T22:11:04 Post flip re-alignment completed successfully.
2019-04-27T22:09:41 Performing post flip re-alignment...
2019-04-27T22:09:41 Telescope completed the meridian flip.
2019-04-27T22:08:51 Received image 5 out of 8.
2019-04-27T22:04:46 Capturing 240.000-second Green image...
2019-04-27T22:04:45 Received image 4 out of 8.
and looking at the indi control panel for the mount agrees with this timing (again, indi in GMT, capture in local time):
2019-04-28T05:10:09: [INFO] Align Pointset: added point 4 alt = 62.9796 az = 181.9
2019-04-28T05:09:39: [INFO] Telescope slew is complete. Tracking TRACK_SIDEREAL...
2019-04-28T05:09:39: [INFO] Iterative Goto (2): RA diff = 1.15 arcsecs DE diff = 0.05 arcsecs
2019-04-28T05:09:38: [INFO] Iterative goto (1): slew mount to RA increment = 4799, DE increment = 0
2019-04-28T05:09:38: [INFO] Iterative Goto (1): RA diff = 44.89 arcsecs DE diff = 0.05 arcsecs
2019-04-28T05:09:25: [INFO] Align: current point is 3
2019-04-28T05:08:56: [INFO] Align: current point is 0
2019-04-28T05:08:53: [INFO] Slewing to RA: 11:20:51 - DEC: 13:07:57
2019-04-28T05:08:53: [INFO] Slewing mount: RA increment = -4607252, DE increment = 4005547
2019-04-28T05:08:52: [INFO] Setting Eqmod Goto RA=11.2904 DE=11.7667 (target RA=11.3475 DE=13.1324)
2019-04-28T05:08:52: [INFO] Aligned Eqmod Goto RA=11.2904 DE=11.7667 (target RA=11.3475 DE=13.1324)
2019-04-28T05:08:52: [INFO] GOTO ALign Nearest: delta RA = -0.057081, delta DEC = -1.365656
2019-04-28T05:08:52: [INFO] Starting Goto RA=11.3475 DE=13.1324 (current RA=11.2921 DE=11.7666)
2019-04-28T04:20:33: [INFO] Device configuration saved.
Not sure why yesterday was problematic and today was OK.
Some kind of threading issue?
I was watching a meridian flip last night and noticed some odd behavior. Bottom line, it looked like the capture & align modules thought the mount was done slewing for the meridian flip, but the mount was still moving, perhaps had just started moving, and thus the picture taken was full of star trails, and not solvable. Fortunately the align was retried after motion was completed, the alignment picture re-taken, and all worked out. I have logs and screen shots to help, though some details seem missing. Details below.
1) I had many logs enabled, and I have the log file for the evening attached (see the file log_20-30-29.txt). Look at 2019-04-27T00:22:20.58 in the log and note the meridian flip starting about 00:22:20, and the flip should take 5-10 seconds of slewing .
2) You can see my screenshot attached "screen_logging.png" to see what's logging is enabled. Please let me know if I should have had more things enabled.
3) IndiMount.png, shows the output of the Indi Eqmod driver. First note that the times displayed are GMT (all the other logs and screenshots show local time), so 07:22:20 on that page corresponds to 00:22:20 on all other pages. At that time, you can see the mount goto command and the slew starting at 00:22:20. As I said, it has to take several seconds.
4) Capture.png shows the meridian flip starting at 00:22:20, and then at the same second, it says: "Telescope completed the meridian flip", and also, same second it says "Performing post-flip realignment".
5) Align.png. At the top of the page you can see at 00:22:22 "Changing filter to LPR", 00:22:24 "Changing focus", 00:22:25 "Capturing image". This is being done to take the plate solving image (plate solving fails) which is taken while the mount is still slewing.
Sorry, I don't have the star-streaked failed alignment image. 00:22:25 would be too soon to start the capture of the first alignment image if the meridian flip started at 00:22:20, but it did because of the reported/immediate "telescope completed the meridian flip" at 00:22:20.
Please let me know if I can get you more info.
I've been using PhD2 as the guider. That's just because some friends recommended it. I'm not saying that the ekos guider wouldn't also work.
Not sure what to say about bandwidth. The raspberry pi 3B+ comes with USB2. I wish it had come with USB 3, so it's a little slower downloading. Takes several seconds for a full resolution image to download. I can live with that. It is more of an issue if you tried to do things like polar alignment with the pi. I've been using a polarmate with a laptop for that setup. I mean you probably could polar-align on the pi, but the real-time feedback would be a little slower.
I've run the focus module on full frame mode, and it does work as well.
For me, the main speed issue for the pi was adjusting parameters for plate solving.
Feel free to ask here or message privately if you have any further questions.
To clarify, I do run Indi, KStars and EKOS all on a single Raspberry Pi 3B+. It seems to work fine for me. I do use a powered hub for the USB devices, and I separately power my Raspberry Pi. In retrospect, not sure why I power it that way--probably mistrust for the hub. My imaging camera is the ZWO ASI 1600mm pro.
I happily recommend this system to my friends, while saying it's much simpler to start with the already put together stellarmateOS. I'm sure a more expensive computer would run the system faster, but what this setup does is more than adequate for me.
I second that. I run pretty much everything on the Pi, with the Mac just being a monitor/keyboard/mouse via VNC.
It's certainly do-able and not that slow (you need to adjust plate solving params to bin and downsample by a factor of 3 or so, but that's fine).
I started by partly running on the mac, and that was less reliable IMHO--no worries now about the mac sleeping, losing connection, etc.
As an added bonus, you could even, once your session was setup and started, just use a vnc client on your phone or tablet to monitor things, and at that point close the macbook altogether.
I agree with Guido that it seems not possible to view unstretched after stretching, but I agree with the others, that this stretching does not seem to affect the raw data--when I download these images, they are not stretched. In fact I view with PixInsight, instead of fits-viewer (after transfering a couple FITs files from my Pi to my mac) just for just this reason.
I doubt fixing this would require a totally re-done fits viewer, but would be a nice feature in a future release.
I'd add a 4th request: My fits viewer crashes if I play with it much. Not sure what causes the crash, but it brings down KStars/Ekos with it. Therefore, I rarely do much with it for fear it will crash and end my imaging session. This has been the case for as long as I've been running Ekos on the Pi (all releases since Fall 2018). I view the recent image with fits-viewer, and from time to time might zoom in if I'm focusing manually, but other than that, my work-around is to stay away from it during an imaging session.
I guess I should enable to fits viewer logs and somehow cause a crash (wouldn't be hard) and send it in. I assume I'm not the only one seeing these crashes, though.
FWIW, I just had a crash. It's daytime, but I just booted up the Pi and upgraded to KStars 3.2 on my stellarmateOS Raspberry Pi. I wanted to see if it became more reliable with release 3.2. I had no devices connected. Once installed, I connected via the simulators profile, took a simulator image in the capture tab (that was the only way I could start the fits viewer--hitting the toggle fits viewer button on kstars didn't start it). The I file-->opened a couple fits files on my local disk and started playing with them (looking at stats and histograms and such) and sure enough the view and kstars/ekos/indi all crashed in a few minutes.
I guess this is a naive question, but here goes:
I saw that Ubuntu 18.04 (server) was released for the RPi 3B+ wiki.ubuntu.com/ARM/RaspberryPi so I went and downloaded/installed/booted one for armhf, added a desktop (xubuntu) and then did the usual things to install Indi/KStars/Ekos and Phd2 (e.g. sudo apt-get install indi-full kstars-bleeding kstars-bleeding-dbg indi-dbg, and so on). In a straight-forward way (including a lot of googling), I was able to get to a system that seemed to work a lot like my stellarmate (e.g. wifi x11vpn etc). It was running the same release as my stellarmate (can't remember exactly, I think March 10 compile of 3.1 or 3.1.1).
I tried it for an evening imaging session, though, and two things were very disappointing.
1) The vpn was off somehow (repeated characters, much slower) -- ok, this is not related to this forum,
2) sometimes when opening certain windows (e.g. clicking on various ekos and phd2 buttons) the vpn connection would just die, but when I re-connected, the menu was there and I could continue.
3) ekos/kstars crashed 2 or 3 times during the evening--it was not reliable at all. My standard Ubuntu Mate 16.04 Stellarmate on the same Indi/Ekos release is quite stable now with my equipment.
It was using the same physical Raspberry Pi. I just swapped the SD Card with the new software.
I then swapped back in the old SD Card, and things worked well again.
My naive question is, why does the standard release not work well on U18.04? Is it the case that the standard release is complied with Ubuntu 16.04 and if you're running 18.04, it gives you the 16.04 build which somehow doesn't match well? If so, is there a list of which OSs would work and which don't? Are there multiple builds for different OS targets, and if so, should 'apt-get' find the appropriate one automatically?
PS If someone wants to look into this further, and would like some logs to be of help, let me know what you want logged and how I get you those logs.
Focus was NOT checked in the scheduler.
I was hoping to set it up such that it didn't try to autofocus, but that it did move the focus according to the filter offsets setup in the capture module.
For the most part, it did do that, except through the meridian flip.
Just got a moonlight focuser, and started working with it and the scheduler.
I decided not to have the scheduler do the main focus, I setup the focus myself (I still don't "trust" the auto focusing
So, I setup the schedule module with checkmarks for track, align, and guide, but not focus.
Still, I expected the system to honor the filter focus offsets in the capture tab (and it mostly did).
I started the scheduler with two jobs. On my first one, things worked as expected until a meridian flip.
That is, a red filter was first-up, and the capture module moved the focus +80 steps to focus, as expected.
Then, after 7 captures, an automated meridian flip swapped in the my LPR filter for the post-flip plate-solving.
Then the capture module moved back to the Red filter to finish it's Red sequence.
Unfortunately, the way it looks, it moved focus to LPR's offset for the plate solve, but did not move it back to the Red offset when the camera-module continued with its Red sequence,
so the remaining red shots were out-of-focus. It did seem to get back in focus the for Green sequence which followed the Red.
Let me know if this doesn't make sense, or if somehow you'd like me to get you more detail.
I'd love to re-create this for you, but the meridian flip is a bit of a tricky thing to recreate.