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.
Last night the skies were finally clear, but we had guests for dinner. I had never used the scheduler before, and this seemed the perfect time for it.
I have no focuser (yet), and the mount was polar aligned the previous night, so all it had to do was unpark, slew/plate-solve/track, guide, capture and park.
I came home 30 minutes before my guests arrived, wrote the capture and scheduling files, and pushed play. I checked it out late that night after everyone had left...
It worked perfectly! Thanks so much for the very nice software.
Here are a few questions I have regarding the experience:
- I just had one capture job, so I set the scheduler to run the job at 8:30pm, about 90 minutes after sunset. Is there a "start when it gets dark" kind of option?
- I wasn't sure if I was supposed to connect to Indi or not after I pressed play in the scheduler (at 5:30pm 3 hours before the job was to really start). In the end, I chose not to manually connect to Indi, and it worked fine. Should it also have worked if I had left it connected? Hopefully it would work either way.
- I use Phd2 to guide. I started up Phd2 manually when I pushed play on the scheduler at 5:30pm (though it was obviously unconnected to the guide camera, since indi was not running). Is that the normal mode of operation? I suppose I could have written a script to start Phd2, but it seems easier this way.
- The scheduler required me to enter the RA and DEC of my target before it was happy with my job, even though I had entered a fits file to tell it where the target was. Since I didn't know the RA/DEC, I needed to start up the plate solver, solve my fits file, and feed that info into the text boxes. Seems like that's an unnecessary step (e.g. the scheduler could have done that too, or could have just solved it when it ran at 8:30). Is there a way to avoid that?
- I'd like to issue a command that states: "No matter what's happening, shut down and park at 4am" or something like that. The Mount tab has that functionality, but it clearly states not do use that functionality when using the scheduler. How can I make sure my telescope parks before sunrise?
I recently noticed that Kstars 3.1.1 was released (saw it on the Stellarmate Facebook page, something I don't normally check out, but Google happened to point me there). I upgraded the software on my Intel Stick / Ubuntu 18.04 machine to the lastest Kstars/Ekos/Indi releases, and, voila -- the QHY driver no longer crashes on startup!
Thanks Jasem! I most likely won't have the chance to fully test for a couple days, but this is a big improvement.
Thanks. Can't wait 'till mine arrives.
I have a follow-up. My main use case is that I shoot a monochrome (ZWO ASI 1600) and need to re-focus whenever changing filters, certainly from Ha to OIII, or Red to Blue. However, I don't notice anything in the capture tab that says "run the focuser when changing filters".
Is there some such functionality to force a focus eval on filter swap that I haven't noticed?
Is it that "autofocus if HFR > XXX" button--does it evaluate the focus after every shot and automatically decide when to re-focus? Is that the way to go?
Can you insist that Ekos runs the focuser at a certain time?
I imagine focusing is a bit time consuming, and you wouldn't want to refocus frequently, so, practically speaking, how do you use your focuser with ekos and the focus tab?
How well do the filter offset settings work--i.e. can those numbers be learned easily enough, and do they stay constant?
My Astromik filters are supposedly parfocal, but when I noticed that they needed focus adjustments, I was told, yes the filters are parfocal, but different light colors will focus at different distances through my OTA. Bottom line, seems to me, that, practically speaking it doesn't matter if they filters are technically parfocal or not--when used with the rest of my optics I'll need to refocus.
For what it's worth, tonight I tried compiling indi-1.7.6 from source on the stick to see if that would work.
I got it all to compile, and kstars/ekos/indi and my asi-1600 camera ran, but indi_qhy_ccd continued to crash.
I believe 64 bit.
This is the ISO I installed:
And this is the computer:
I tried to run with the new build that was supposed to come out today, but couldn't find it.
Just verifying that it's not ready yet.
sudo apt-get update
sudo apt-get upgrade
but no new version of kstars, etc. Still 2/27 3.1 release.
I tried the indinightly, and did get Build: 2019-03-07T12:48:11Z but that also crashed on startup.
This is what qhy versions I seem to be running, it's the same in the standard nightly release:
Selected version '2.1~201901131630~ubuntu18.04.1' (INDI Stable Builds:18.04/bionic [amd64]) for 'indi-qhy'
Both the standard release (which was the same as last time, and the new nightly crash right away.
As a reminder, I'm running Ubuntu 18.04 on an Intel Stick (Atom CPU).
I've been using dd to backup and restore SD cards, and I've seen, e.g. 30minutes to save a 32Gb SD card to disk and 2-3 hours to write a 32Gb SD card from disk. I've also noticed that when I download an Ubuntu .iso, Etcher can write that to an SD card in a minute (though it's true that the dd backups are 32Gb, and the Ubuntu .iso files are a few GB). Still, the write speed of Etcher seems an order of magnitude faster--though it won't write these dd backups. Any idea why Etcher is so much faster at writing SD cards, and is there a way to get dd to write that fast, or get Etcher to write these dd backups?