discardedastro

From git and just doing make/make install is fine until you need to upgrade, update, or swap things out - keeping things installed as packages is much easier in the long run and it's only a few extra steps. Uninstalling after a "make install" is tricky! I'm running this headless and using my desktop PC to drive it - my intent is to put a full-time PC in my observatory when I get that built, but there'll be a server in there for the "main" INDI server driving the obsy, with the drivers accessed remotely on the Pi for imaging/scope/mount control. To be honest, with the Pi this fast and supporting dual monitors, it might just be a scattering of Pi4s - one as a desktop for control, one for the obsy, one for the scope!

Right - got my Pi4, sacrificed a spare USB-C supply so I could attach the USB-C port to the 5V feed from a 12V-to-5V step-down box, and hooked everything up. And it looks promising! I grabbed the libindi source and tried using the CI scripts to build the packages, which works, plus the make_deb_pkgs script in the 3rdparty folder. Basically you do the usual raft of dependency installs, then: # deps sudo apt install cdbs libcfitsio-dev libnova-dev libusb-1.0-0-dev libjpeg-dev libusb-dev libtiff5-dev libftdi1-dev fxload libkrb5-dev libcurl4-gnutls-dev libraw-dev libgphot o2-dev libgsl-dev dkms libboost-regex-dev libgps-dev libdc1394-22-dev python3-pip # personally I'd disable systemd's built-in ntp client and slap chrony in there, but this is wholly optional sudo timedatectl set-ntp false sudo nano -w /etc/chrony/chrony.conf # setup the UK pool, enjoy stratum 2 sudo systemctl start chrony sudo systemctl enable chrony # build cd indi-1.7.9 .circleci/build-deb-packages.sh cd 3rdparty nano -w make_deb_pkgs # edit DRV_LIST to include the packages you need - note for zwo you need asi-common as well as indi-asi ./make_deb_pkgs sudo dpkg -i *.deb sudo dpkg -i ../build/*.deb This probably isn't fantastic but it does work and keeps everything installed through dpkg, so any cock-ups can be reverted by simply removing the packages when the official release is out. I've also set up indi-web (just pip3 install indi-web and optionally drop in the systemd unit file from the indi-web repo) and it works fine. My only gotcha was GSC for indi_ccd_simulator - there's no packaging but you can get going with: mkdir /opt/gsc cd /opt/gsc wget -O bincats_GSC_1.2.tar.gz http://cdsarc.u-strasbg.fr/viz-bin/nph-Cat/tar.gz?bincats/GSC_1.2 tar -xvzf bincats_GSC_1.2.tar.gz cd src make mv gsc.exe gsc # there's Fun to be had with the GSCDAT env var not being set properly - so you might get away with this alone: sudo cp gsc /usr/local/bin/gsc sudo ln -s /opt/sc /usr/share/GSC # /usr/share/GSC is where gsc looks by default, so we just point it over to the catalogue # test by running "gsc -c 175.0+59.0 -r 10 -m 0 20 -n 3000" # otherwise, put the gsc binary in /usr/local/bin/gsc_bin, make a file /usr/local/bin/gsc which just has: #!/bin/sh GSCDAT=/opt/gsc /usr/local/bin/gsc_bin $@ # chmod +x and away you go - this avoids problems where GSCDAT doesn't get set right by things calling gsc within a shell within an app After this, a full simulator setup in indi-web looks to be working properly. I've also set up gpsd and that looks fine. I've hooked up everything except my guide camera (still on the scope outside) and mount (same) and written udev rules for the lot. Everything looks okay. Performance is great - building indi from scratch takes minutes. Very promising indeed.

An outstanding image - beautifully processed and clearly given a ton of time, light and care. Well done!

Should be able to just swap out the %appdata%\eqmod_sim folder - there may be specific files in there that relate to the mount model specifically (haven't got a copy to hand)

I've got a bunch of Eaton 9130 units here which are full double-conversion units and have configurable bypass thresholds - basically if the incoming mains is within a voltage +frequency range it'll bypass in all internal fault conditions, but if there's an ongoing brownout or other mains fault it will hang on till it's out of internal power and then cut the power fully rather than let half-arsed AC in. This is generally hugely preferable - it's not pretty when some AC-DC supplies set up for 230-240V suddenly get 100 or 50. The Eaton units are powering a bunch of computers (desktops, servers, disk arrays) and telecoms infrastructure (switches, routers, WiFi APs, etc). None of that tends to like weird voltages. At $dayjob I've got an estate of a few hundred telecoms sites which are all -48VDC consumers - those just have rectifiers which are immensely tolerant of incoming AC being all over the shop and will do their best to produce some DC for recharging or powering of kit, but even those will give up in the end! To protect against rectifier faults, there's lots of rectifier modules, each rated for a couple of kW or so, so losing one doesn't mean the end of the world. The trick with all of this is having enough monitoring in place that you get notified when something goes badly wrong, so manual intervention can happen (for work, that means dispatching someone with a generator - at home, much the same!) For 12V stuff, double-conversion or just having a 12V charger attached to a bunch of 12V batteries (double-conversion by another name) is perfectly sensible and very reliable. It's when you need 230V for something where the components and electronics get fiddly - inverters are much more fickle and prone to faults.

Not as such - but you can get an "erecting prism", which will do that (and fix left-to-right, too). But I've never used one - mostly seem to be pitched at terrestrial use rather than astronomy.

Seems to be working well - I took the opportunity to finally break out Photoshop and tidy up one of my Ricoh Theta S photos for where I plan to put my observatory for use in Stellarium. The user guide (unpublished? https://github.com/Stellarium/stellarium/blob/master/guide/ch_landscapes.tex ) has some good guidance. Seems to work well!

Hi all, I've been working up a design based on a 4.8x3m footprint - I'm not short of space, I have to go through planning permission anyway (conservation area), and I want a reasonable amount of room for a 19" server rack and some storage along with a compact desk in the warm room. Having laid this out with a 1.1m distance from my pier centre to the nearest wall, which looked about right, I'm now wondering A) if this is actually enough given my scope/mount (a 200PDS on an EQ6-R), B: if it'll be good enough for future use, and C) if I could actually get away with more than one mount in the space and therefore should put more than one pier in, or otherwise isolate the pad generally to give me the flexibility. Does anyone have some numbers for working scope radii (for imaging)? I'm still keen to have the option to use the "big" scope for solo visual use, and I might go to a long FL frac in future or upgrade to a larger Newtonian. My current layout (incl shuttering) is attached.

From a little while back now...

Depends on the Canon, and the lenses - it's not a given by any means. You'll definitely lose a lot of the intelligence in electronic lenses, autofocus won't work, and you won't be able to use VR stabilisation. I do prefer Canon's software approach.

If you plan to use it for non-AP and you have lenses, then your answer is the Nikon - reusing glass nearly always makes the decision for you. If you're just using it for AP, the Canon is preferable because of the software support. As others have said you can't use the D3500 with any software to control it during capture sessions. If your definition of AP is mostly widefield with in-build camera features and a simple tracker, though, then either will be fine.

Yep - I'll fiddle around a bit when I get some skies to work with. It's very snug at present.

So, yes, OAG is always going to be better than a guidescope. However, I have a guidescope, camera, etc which all works fine - except for the differential flexure... I was using a set of Primaluce Lab guidescope rings. They're pretty bad. Through filing off all the plastic tips on the screws, and slathering everything in Loctite, I managed to overcome some of the failings but they still basically aren't made well - the threads are loose, the screws don't fit well in the threads, the tips flex, and so on. I've got an ADM dovetail and clamps, which are perfect. No change needed there. So figured, hey, I know a guy with a collection of CNC machines who needs more projects - and hacked together a CAD design that looked like this: https://myhub.autodesk360.com/ue29fa843/g/shares/SHabee1QT1a327cf2b7a5a22a1be63168b5b He cut those for me the other week and after a bit of sanding to bring them into final dimensions I have a very tight fitting set of guidescope rings: Time will tell if these actually fix my differential flexure problem adequately - I only fitted them today - but they feel much more secure. I'm a little concerned about pinching the optics but for a guidescope stable but slightly defocused is preferable to wobbly, so I've erred on the side of caution so far - can always take them off and sand them back another few tenths of a mm. My other thought was to take them back half a mm and line with some fine felt or plastic, but I didn't think this would actually help the stability side of things. One more thing - he's now played around with the design a bit more (beyond just replacing my captive nuts with cut threads) and is considering making more if anyone wants any, so drop me a PM if you do. The finish on these wasn't great, but he reckons he's got a better way of doing them in future which will give a nicer finish.

They do seem to have that covered by virtue of being in very low orbits - they'll deorbit within 3-5 years without any power/fuel (i.e. fault conditions), and with power/fuel will actively deorbit at end of life. But the impact on AP is worrying. Various people suggesting they'll only be visible in astro twilight due to the low orbit, but yeah. Going to be interesting to see how that develops, given the first 60 made quite a stir - 12000 is going to start looking very busy indeed. I wonder if someone could simulate it.

I'd +1 the 7nm Baader, they're a great starting point and don't have major issues with halos/reflection in my limited experience. Baader are a lovely midpoint in most things brand-wise - good enough to be effective and useful in almost all their products, even if they're not the best of the best, whereas others in the same price point often end up going for features or spec over functionality. I'd only look at Astrodon or other high high end brands once I had everything else in my system perfect, really - you'll get much better bang for your buck with a flattener, or mount improvements, etc - or accessories like dew heaters if you don't have those already.

The hitec won't show you how bright the background sky is if it's clear, no, or at least not appreciably I wouldn't have thought.

Cloud sensors and SQMs measure different things. Basically, your SQM measures visual brightness of the sky - your background noise, so to speak, for visual imaging. The cloud sensors, on the other hand, generally measure the temperature of the sky - the infrared brightness, effectively. This is because clouds reflect IR from the warm ground, and so warm skies are cloudy skies; you can relate sky warmth to cloud cover pretty accurately with a good sensor. So cloud sensors tend to be used exclusively with automation or monitoring systems. If the clouds roll in, stop the session and close the observatory roof, that sort of thing. SQMs on the other hand are telling you how good your skies look, assuming they're clear. So you generally need both if you want to do long-term monitoring (to let you discard the data with clouds in and average only over clear nights). For a practical "is it worth setting everything up" answer, an SQM might be helpful but I'd put more faith in a weather app - all these things do is tell you about now!

Only just saw this - thank you very much indeed! Lots of absolutely stunning competition.

With a Polemaster and careful alignment (EQMOD or using SynScan 3-star alignment) I've managed 120s, but touch-and-go on a 1000mm FL. On the ES you should manage much better. Guided should be <0.6-0.7" fairly consistently with good guiding input. It'd be worth doing PPEC training before you throw it back, and I'd heartily recommend a Polemaster if you're doing semi-frequent alignment.

Oh, absolutely - I'm a long-term Linux user and contributor to various FOSS projects. I've already fixed a bug in the Arch packaging for the astrometry.net solver which was causing KStars to pick --nofits2fits when it shouldn't...

Not well explained ? So indiserver running on the box doing all the hardware interface stuff is fine and great, and works well. What I basically want is the equivalent for Ekos - the alignment, focusing, guiding, etc state of "where am I pointing/what am I imaging" and observatory control. Ekos is great but complicated, and if KStars crashes I lose all the state in it. Plus I have no way to remotely get at it other than VNC. Ideally I'd have two Ekos clients seeing the same state so I can have a KStars/Ekos session on my PC in the house and see the same sequencing etc information as I would on an KStars/Ekos session out by the scope on the PC. Going to spend an afternoon faffing with udev to get everything static and that should make life a whole bunch nicer, either way!

Coming late to the party, but thought I'd chip in with my experiences. I'm a long-time Linux user but started my AP journey on Windows with Sharpcap and then SGP. I run both OSes on desktops daily (Linux at work, Windows+Linux at home). I lost my Windows box I was using for AP so ended up setting up my work laptop with KStars/Ekos/INDI as an interim fix; having said that I'm actually very happy with it all (with one or two exceptions) and don't have any plans to run back to Windows at present. I'm using Arch Linux on my box, which is a rolling release very close to upstream - has the benefit of being on the bleeding edge, and the downside of being on the bleeding edge. I'm using an EQMod EQ6-R Pro mount, ASI183MM-PRO imaging camera, ASI120MC guide camera, a ZWO EFW, HitecAstro DC focuser, and MBox "weather station". My main gripes so far are with device connectivity/discovery - getting everything recognised and tying up each driver with the right tty device is a bit of a nightmare every evening. I'm going to see what I can do with udev rules to at least get all my USB devices assigned to their tty filenames consistently, and then I can configure everything to use those static assignments. I also have issues with gpsd eating other USB devices even though I've told it not to. KStars has crashed a couple of times, usually while focusing - this is most frustrating, but it's infrequent enough. PHD2 works much better than the inbuilt Ekos guider, so it's worth setting that up, and pretty painless once done. The local astrometry.net solver works great; had some problems getting final fine alignment to work which I think is mostly down to the EQMod driver's n-stars alignment and some weirdness when that gets a lot of solves/syncs in the same small area. My focuser is pretty awful (stock Skywatcher with DC focuser) so can't really use autofocus, but the manual focus options and framing lets me manually drive close enough. I'll replace the focuser and motor soon so I can use the autofocus module. Overall quite happy with the whole ecosystem. While I'm running it all on my laptop at the moment I intend to move to a distributed setup once I get the obsy together, with a server near to the scope for indiserver, and a server/desktop in the warm room for KStars/Ekos to run on. At the moment I just VNC into the laptop from indoors, shove the files across onto a NAS and then take them onto my workstation for processing (though the laptop's beefy enough to run PI so sometimes I'll process directly on that). The one bit that doesn't quite sit right with me is control/state - I don't like having a desktop application/GUI managing all the state about my capture session and observatory. I'd much rather have a server manage all of that (and do so in a careful, robust fashion) and keep the GUI complexity out of it. Then again, INDI is an open protocol, so maybe I'll have a stab at something...

Well, thanks for all the advice - this dark frame I took on the scope! Not a shred of light leakage visible to my eyes, so I think that's done the trick (by and large). All my lights from the night appear to be free of any light leak style artefacts, too, so the flocking appears to have helped too. I ran without the dew shield tonight to give myself the worst odds, too. One 60s luminance exposure, M33:

So far it's been OK - I've kept it out for a full year now more or less. I cap it all off at the end of the night and use FLO's desiccant 2" cap to help reduce the moisture levels in the tube. I've noticed no issues thus far. I had the mirror out as part of modifying the tube to add flocking and it looked pretty good - gave it a fingertip/water soak and distilled water rinse and it looks good as new. I'm more worried about the mount than the tube, really, but that also seems OK so far. The Telegizmos cover is pretty decent. I've got space for a RORO so that's planned when I've saved up enough for it!

I haven't yet put the camera on and taken any dark frames, but thought I'd share my mod to the scope - I had RazorLabs laser cut a circle of 5mm acrylic with slightly oversized holes (not quite oversized enough if anything) for the collimation knobs, and tight holes for the locking screws. This lets the locking screws (which don't do much if anything anyway for the mirror stability as far as I can tell) hold the plate in place securely while adding nearly no length to the tube. Total cost was about £25. I drew it up in Fusion360, exported to DXF, cleaned up in Inkscape and shipped it off. I've attached the SVG if anyone wants it - it's to RazorLabs' guidelines for cutting and fits a 200mm scope, other sizes will need adjustment. The plate completely covers the whole end of the scope with no gaps, so should work pretty well at keeping the light out. It won't help tube cool-down particularly, but I'm mostly keeping the tube outside at the moment under a Telegizmos cover so that's less a concern. I did wonder about putting some slots and mounting holes for a fan in, but figured I'd want a slightly more complex mounting arrangement to stop light leaking in through the fan itself (some indirect paths and offsets, which would involve a couple of bits of acrylic and some antireflective paint) so left it for this iteration. Once I get a bit more time I'll get it back indoors or drag the camera out in the daytime and see if I can take dark frames that are as good as the ones with the cap on the camera! tubecap.svg