discardedastro

To be fair the full stack uses nowhere near 4GB of RAM in my experience, even with reasonably high-res imaging (I'm using a 183MM-PRO and 174MM guider), so you'd do fine with a Pi400. I went for an Argon ONE case which has a neat USB-to-SATA bottom plate for a 500G SATA SSD which I use as a cache volume (there's a daily rsync job that shoves everything to the real filestore when nothing's busy, which is 30TB usable of ZFS RAIDZ3 in the garage in a big Supermicro JBOD). Throwing a screen on at least so I can glance at it is something I've considered but I'm pretty tight on space - I think what I am going to do is pop it next to the TV so I can use a spare HDMI input there for monitoring at night. I find 1440p (which is what I use) works fine over VNC, but 4k would be a push; at that point the Pi will mostly be spending CPU cycles drawing KStars and encoding it!

The scope sits outside 24/7/365 under cover, but doesn't have permanent power, so by running KStars on the Pi indoors I have all the data accessible to transfer off to the NAS long after I've shut down the scope in the wee hours, and can hop on it at any point to fiddle with KStars etc on simulators and so on even if the scope's off. I much prefer Linux for stability and updates for KStars versus Windows, and since it's all the same platform (Arch) I can keep INDI etc on both devices updated in version lockstep. I used to use a Linux laptop for the indoors portion but having a dedicated device made more sense to me because that laptop sometimes ended up doing other bits and pieces, and the Pi's much more energy-efficient.

I'd definitely +1 KStars/Ekos and the Raspberry Pi route - I've had a Pi4 on the 'scope for a long while now and it works great. Personally, because I prefer to run KStars on something that's "always on" and INDIserver on the scope itself I have a second RPi4 sat in the house which runs a remote desktop via VNC for KStars/Ekos, and the Pi4 on the scope just runs indiweb/indiserver on start. Apply power to the scope, start up KStars/Ekos, hit connect and I can be imaging in minutes - it works really well. I plate solve on the Pi without issue (and at 0.5"/px, so at the "difficult" end of plate solving!) and use PHD2 as the guiding software. For the Pi on the scope I used a random metal project box from Maplin (RIP) with a bit of plastic offcut to provide a "platform" for the Pi and keep it off any metal (I covered the other surfaces in Kapton tape for good measure). The whole box has a velcro strip on the bottom to adhere to the scope's velcro hooks. I also use PHD2 for drift alignment - I haven't used Ekos for PA but find that a Polemaster for rough alignment and PHD2 for precise drift alignment works really well (to the point that the biggest ongoing issue I have is actually the ground moving under the telescope - really must sort a pier!) and it's very easy to do. By having the remote desktop Pi running KStars/Ekos I just VNC into that from either my desktop or a laptop or tablet and get the same "state" so I can view the same thing in alignment or imaging from either my laptop or desktop or even my phone which is great for keeping an eye on things but also makes for easy PA as I can take the laptop out if I have to do drift alignment which will take a while or just use my phone if I want to see if everything's OK sat on the sofa! In practice with the Pi4 you can do this "all in one" these days rather than having two Pis, but either way they're great hardware and more than up to all of the most complex AP requirements. The only thing I'd say on PA would be that if you need to do it quickly then a Polemaster is hard to beat for that "pretty good" alignment, assuming you have a modest laptop with you as a control surface. If you're setting up fresh every day it's a good route. If you're setting up once and leaving things in situ, then PHD2/KStars/Ekos is all you need.

Bought a scope in lockdown (my new 16" VX16 Dob) and am slowly adding to it now with a Nexus DSC, various black and green eyepieces, etc. Rational? I mean it's for looking at stars etc, it's not wholly rational to spend lots of cash on this, but... Now, there's all the other lockdown purchases - the modular synths, the fancy espresso machine, the alcohol - yeah, okay, none of this is rational... 😁

That's a great set of videos. Belt tension would make quite a bit of sense and I'll take a look at that for sure - it's about that time of year when I take the whole setup apart and inspect/clean/maintain it all anyway given we're now getting too bright to do anything much with DSOs! I've been doing alright in more recent times - I wonder how much those belts and the whole tensioning setup "walks" with temperature variation.

If you do the guiding setup right it can also (as @Space Oddities said) act as a polar alignment aid. PHD2 has great tools in this regard - a static polar alignment tool which can get you there or thereabouts, and a drift alignment tool for getting the alt/az set just right. This will actually be more accurate than a Polemaster etc in general though if you're shooting reasonably wide fields you don't need to get that close for long exposures - but if you want to shoot narrowband, it'd definitely be the way to go.

Have you considered tools for polar alignment? Either iPolar if the SGP supports it or a Polemaster. You should be able to get better exposure times out of the mount if properly aligned. Guiding won't help much if your PA is spot-on. PHD2 doesn't take much grunt so even a Raspberry Pi would do fine on that front if you wanted to go down that route. I'd definitely focus on getting your subframes "good" in terms of duration and stability before considering filters. An Optolong/IDAS LP filter will certainly help somewhat in 7 skies but not as much as longer exposures will!

Hi all, So I'm now the proud (and sore - it's heavy!) owner of an OOUK VX16 400mm Dobsonian, and am now learning how to use it and figuring out all the things I need to add on to make it really usable in my environment - but would appreciate some advice from other Dob owners! I managed to get a first light tonight - lots of cloud about so it was a bit hit and miss but I managed to collimate fairly well and look at some bright stars. Defocused, tube currents were very, very obvious - I'd kept it outside in a shed for half the day but it was still clearly a bit warm (the back of the mirror measured 5c compared to 0c ground temp on infrared). After about an hour it was down to temperature, but I was struggling with eyepieces dewing up. About half an hour later to warm up the eyepieces, the finderscope was completely dewed over, and both the primary and secondary had a degree of dew on them. The ambient temperature was about 1-2c with humidity around 70-80% by the met office and 50% by my local sensors. I also had some issues pointing the scope. I figure a RACI finder and/or Telrad would be worthwhile upgrades - the Explore Scientific RACI finder looks ideal - so will aim to upgrade those. The azimuth bearing seems very tight - it takes a lot of effort to get moving, so fine pointing adjustments are really hard. Thinking I may need to renew some bearing surfaces; I am using a few paving slabs as a base so it's got a fairly flat surface to rest on. Altitude I didn't quite get balanced right so need to shift that around a bit more and then can slacken the brake off. I called it a night and put the scope back in the shed - while I can move it around fairly well on the sack truck I bought for it, I'm definitely going to get it a Telegizmos 365 cover so I can leave it set up in situ for longer periods. We're in a fairly damp area - low lying, 25m from a small stream - so suffer quite a bit from dew. The mirror cell has a position for a 12V fan which I've now bought from OOUK, which I suspect will help quite a bit with both dewing of the primary and tube currents/cooldown - will fit this once it arrives and see if it helps. I'm also thinking that as a beginner in observational astronomy (imaging for a few years now) a digital setting circle is going to help a lot with finding my way around and building up confidence - is the Nexus DSC still the way to go? Do I need to consider dew heaters for either the eyepiece/tube, or secondary or primary? What else should I consider for dew control? Any tips on things to consider with finderscopes? Any other hints and tips for practical accessories for larger Dobs? Lots of questions - grateful for any advice!

It really is 🙂 I came in at the start of the Pentium era, though had a fair bit of time on Amstrad and friends prior, but no coding. i386 was my first chip - we've come a long way! If shipping all the image data around wasn't so prohibitive for most people I think there'd be a huge case for a render-farm style service for PixInsight and others; it's bursty, not something all users do all at once, so quite well suited to workload sharing. I did toy with the idea of using an AWS virtual desktop instance for PI (pay by the hour when you need it), but since I did my last PC upgrade I've not needed to consider it. And that's only because I've got a 1Gbps upstream from home, so pushing all the data to the cloud isn't a big deal - easily done in a few minutes for most jobs. Different story for typical rural/semirural ADSL/VDSL/DOCSIS!

True. The latest PI release with the quick subframe previewing has helped a lot in my workflow for that sort of thing, particularly noise reduction - but things like TGVDenoise, MureDenoise, and Deconvolution are still very processor intensive with poor previewability (and in the case of deconv particularly a lot of trial and error required on most images).

It's actually not quite as good - the platform doesn't extend far enough to fully support the base! It's a 3-in-one so you can lie it down and use it as a platform, and it has some other weird configurations I've not played with yet. 16" is quite a lot to lug around as one person, especially in a very non-flat garden, but I managed to set up a base for it with some spare paving stones and park it in the shed without dropping anything - I think a Telegizmos 365 cover is in this scope's future so it can sit out most of the time. That's an absolute beauty. Congratulations - that imaging rig is going to be very sorted!

Yep - I normally just have KStars sat on the graph view so I can keep an eye on things. Once I've finished writing this Rust INDI lib I'm hacking away at (or give up and fix some of the pure-Python ones) I do want to hook up a watchdog program that can alert me if imaging or the mount stops - I've had one too many kstars crashes on overnight imaging sessions!

FWIW, I'd consider myself PixInsight competent/familiar and WBPP confused the hell out of me - it relies on a lot of stuff in filenames etc which is pretty unobvious and the documentation isn't great! I'd strongly recommend starting out with the Inside PixInsight book and/or doing manual processing to get started. It'll be slower and less straightforward but it's a much easier way to learn the software than running straight into WBPP, in my view.

Quite likely, yep. For what it's worth I use KStars on a Pi remotely via VNC and it's plenty quick enough in my experience (I actually run VNC'd into a Pi4 sat in the house which is running KStars, with INDI running on another Pi4 which is strapped to the back of the telescope). This is with everything wired through a good 1Gbps network, though!

Yeah, excellent point - full frame I would argue demands a pretty high-end PC, realistically. Technically so long as you've got a reasonable amount of RAM you can get away with a lot, but practically it's really painful. I've got some images off a Nikon Z6 which is 6048x4024 natively and I think if I were doing an awful lot of that, I'd be looking at something Threadripper based with 64G or more RAM, especially for mosaics! The ASI183MM I'm using today is reasonably high resolution but since it's monochrome the resulting files aren't huge, and once you've got an LRGB master set the processing is generally quick stuff anyway. OSC is a different beast altogether.

You should be able to set this up on the imaging sequence by selecting upload to remote only and inputting the path there or in the camera settings under the Options tab, at least on recent-ish KStars. If you've got a reasonably fast (wired) network then you'll likely find it doesn't win you that much performance - I think KStars will still pull the image down from the remote end in order to show it and do any analysis (e.g. HFR for automatic focus triggers), so saving it locally isn't a big overhead.

The bats are decorative (we've got pipistrelles living in the outside of the house, so thematically accurate) and the BBC Club sign was rescued from Television Centre before it closed for good 🙂 Definitely looking forward to first light - which looks like it might be this evening, if I'm lucky!

Alright, so the postman didn't bring this, I had to go get it myself - but still worth a post I think! OOUK VX16 from @Commanderfish now being checked over, tweaked, and roughly collimated after a 2h drive up. Bit of play in the focuser to sort and the mirror cell wants a fan fitting, but otherwise good to go and a superb "little" scope I'm looking forward to trying out!

If you're on Uist then some friends up the north end of things have good internet - up on Berneray. BT did FTTC to the islands as part of their government-funded builds (though failed to actually connect it up till a few competitors started pointing out they hadn't actually delivered anything to people), but there's also a lot of fixed wireless stuff back to the mainland which is pretty quick! http://sealview.com/gettinghere.html Last time I was up there I wasn't really doing astro stuff, but knowing how populous it is (my friend had to go to Lewis to do their driving test because it's the only island with a roundabout) I can believe it's superb! Enjoy while you're there!

Do they work well in darkness without IR? I've got a fair few Reolinks and they're practically useless with their IR switched off, even if the manual exposure is maxed out.

Try this: sudo systemctl disable gpsd.sock To explain a little more - both gpsd.service and gpsd.sock are things provided by gpsd to systemd, which will ensure that all the dependencies for the service/socket are met. That includes, if you just disable the service, bringing it back to ensure the socket is available. If it's still booting up then try systemctl list-dependencies --reverse gpsd.service - this will tell you what is dependent on it and bringing it up.

Ah, around the focuser? I did consider that I had some light leakage from a nearby light and packed the gap between tube and focuser base (as mine had some gaps) with Sugru, and the opposing side of the tube is flocked, so maybe that's helping minimise ingress.

Seeing your image there I'm now realising that I'm probably actually seeing the same thing in my imaging. I'd noticed in some geometries - generally lower altitudes - I was picking up a bar across the image. Nowhere near as severe as that, though - it was only when I stacked things I picked it up, and I was able to generally correct it with some careful background correction, but the same basic artifact. I've only had it rarely and it wasn't the end of the world so I hadn't dug into it properly. I am using an IR cut filter (mostly just to have a parfocal filter with my RGB) as my L, so all of the filters I'm using are in some way filtering IR, which may explain the reduced intensity. I've been toying with the idea of something like the ASI120MM mounted side-on in a box with a Raspberry Pi, though I think these days the Pi high quality camera can also take long exposures and take a variety of fast C-mount lenses. Dropping IR entirely would seem the best approach.

Edit: Interesting, I can't post to this with some content... I don't suppose the LX200 will be returning GPS data in a format that gpsd can take advantage of anyway, so I'd disable it. If you want a GPS, then USB GPS devices that work with Linux can be had for <£20 on eBay or even Amazon et al. gpsd can be forced to look at a specific serial port and not autodetect with a startup parameter, normally configured in etc default gpsd. Otherwise systemctl disable gpsd would do the trick, so long as you've got an internet connection for time. For good time sync, gpsd can do basic clock control but you're much better off configuring ntpd or chrony to treat gpsd as a clock source as they'll do a much better job of regulating your clock. If you get a board-level GPS module or hat you can also configure chrony or ntpd to use the pulse-per-second input from a GPS module to properly discipline the clock, making your Pi a "stratum 1" reference with very good stability for very little money! https://thepihut.com/products/raspberry-pi-gps-hat This is probably the easiest solution to achieve that - it's a GPS module hat to drop onto a Pi, but also has an RTC, all the wiring needed for the PPS pin already done, and an external antenna port. The RTC means that even without a GPS fix or internet the Pi can get reasonably-close time quickly. Edit: OK, so the forums for some reason block paths like etc default gpsd.conf if you have / in them. Guessing some very overzealous web application firewall...

Yes: https://astronomy.tools/calculators/magnification However in practice sensible maximums are going to depend a lot on what you're observing!