discardedastro

OK, question for the mechanical wizards... I've been getting (for a few weeks now, but given sky availability, maybe longer) some odd calibration results and associated warnings in PHD2 about orthogonality of axes. Some calibration results (all from one night) are shown below: These are obviously not "quite" at a right angle to each other. Guiding appears to be working okay though in some cases room for improvement. My question is - is this likely to be mechanical (or should I be looking at e.g. my OAG?) and if so where should I start for diagnostics? I did go through the SW backlash adjustment many moons ago and I'm now thinking maybe I need to repeat the exercise, at least on the declination axis. PHD2_GuideLog_2021-02-25_184927.txt PHD2_GuideLog_2021-02-26_193641.txt PHD2_GuideLog_2021-02-27_181257.txt

There's been occasional bugs with KStar's meridian flip stuff getting stuck in the wrong state. Is this with indi_eqmod? I'd recommend grabbing whatever logs you have (and if you can reproduce the fault, do so with debug logging enabled for the mount etc before you start and connect devices) and filing a bug with the KStars team at https://invent.kde.org/education/kstars/-/issues Shouldn't really matter what side the saddle bolts sit on, though bolts on the left are I believe "correct".

Pretty much all astro software is hard to use - it's just degrees of difficulty! If you're just looking to start using as a basic "visual" setup I'd start with something Windows based like SharpCap and EQMod. They're very simple, will let you leverage experience with Windows drivers etc to get you going while you understand the mount/telescope/camera side of things, so are a good entry point (and low cost!). Active USB cables to feed a hub might be OK but I'd want to use a powered hub and run mains/12V out to the hub to avoid it trying to bus power stuff off a long extension lead (which will itself be drawing some of that USB power budget for itself). One of those cheap "dry box" things and an extension lead and you're sorted. In the grand scheme of things ASCOM and USB is going to be around for a long while but INDI is basically the only game in town for networked astrophotography stuff and widely supported by vendors now, so getting on board with a Raspberry Pi on your mount/scope will put you in better stead for more sophisticated stuff down the line when remotely operating with a PC distant from the scope. KStars/Ekos is also incredibly powerful for the startling cost of free (do buy Jasem a coffee if you enjoy using it, though). I use two Pis - one as a "desktop" indoors and one on the scope - using INDI on the scope and KStars/Ekos on the desktop to run it all. But you can use an existing laptop for the indoor end as easily! As soon as you start tinkering with imaging there's a bunch of other things you'll undoubtedly want to have available on your upgrade path - motor focusing being the big one of course - and eventually you're going to need more USB ports. Daisy-chaining etc can work, but is expensive and quite clunky - and much less reliable.

Given this is for solar, I would really recommend that you don't take chances and instead stick to the well-known brands like Baader. The price difference really isn't that significant and it's your ability to see you're safeguarding. From a quick check they're almost the same price as the Baader stuff from FLO.

Welcome! Straight in at the deep end, it looks like! I won't comment on telescope/camera selection - there are others who can cover that much better than I. Piggybacking is fine but does usually put you into quite an expensive category of mount - think Mesu, CEM120, Losmandy, 10micron etc, £3-4k and up - if your scopes have "reasonable" aperture. Consider if you'll be doing both year-round or sticking to planetary/lunar in brighter months or not, e.g. swapping scopes every 6 months rather than piggybacking. I'd strongly recommend getting some of the software and e.g. motor focus, guide stuff as soon as you can so you can learn this stuff better before planning for the obsy version. These are often heavily reusable bits (dependent on budget for future scopes, of course). If you're going to use KStars/Ekos that's free but has a learning curve. SGP et al also have learning curves of their own and are ££. Get some, try others, set up your current setup and see if you can get "everything but the dome" running. Learning that is going to take you months (especially with this cloud) and will help inform what you do for a final setup in terms of scopes, software, focusers, etc etc etc. Walk before you try and run a marathon and avoid some expensive mistakes; you can do this stuff with your current setup plus a cheap camera, guidescope/camera setup, focus motor, and an eqmod cable. That gets you to electronic viewing without a dome etc with your existing scope. That'll give you a bit of a feel for it - both to see if it actually scratches that itch appropriately and to give you a feel for the important things. Getting a Pulsar dome in and powered is a good chunk of the battle towards ease of operation for sure. You'd want a good solid pier, also, and plenty of concrete in the pad (most builders hear "pad" and start thinking how thin they can get away with - you can either do a deep dig for the pier and isolate it, or just make the whole pad good and thick to ensure a good, vibration-insensitive base). Once you know what your payload weight will be you can pick a mount - but that means picking (roughly) the sort of telescopes you'd be mounting, and adding a good buffer for cameras, guidescope (if required), and on-tube equipment like focusers, dew heaters, etc. Lots and lots to think about, in any case!

It does help, but I've since aded a tilt adjuster to the train. Haven't adjusted tilt with it yet, but at some point I'll get around to it! I'll also add here - in case it's handy - that TeleVue helpfully confirmed on Twitter that with the T2 adapter fitted, there is exactly 55mm from the top surface of the T2 adapter to the focal plane.

I've been doing RDC protected 4-gang onto a 12V PSU (a Nevada linear one) for years without issue, so that works. With a reasonably large box the PSU can sit in the box - just think cooling, esp with the linear PSUs. However, with a good battery, you can indeed just plug that in - and a USB hub looking for 12V will also be fine off a 13.8V battery input, "12V" in consumer gear almost universally means 12-ish-or-what-a-12V-battery-spits-out-V. I use a silicone cable from Lynx Astro to go to a cigarette lighter socket on the PSU or an adaptor to a battery via crocodile clips.

High efficiency just means not-terribly-lossy - it has no real bearing on this (other than being another part that's losing you efficiency and liable to fail). Boost-buck converters don't really fix undervolt issues; I've got some scope graphs somewhere, but broadly speaking these sorts of converters tend to completely blackout when they get overloaded or the input voltage drops too low, and you end up with short transients down to <2-3V or "choppy" power. The right way to avoid undervoltage issues is a suitably dimensioned battery or power supply. The overall price will be the same and you end up with fewer parts to go wrong, mis-wire, etc!

Single supply is fine. I will say those boxes branded "NVVV" are trying to rip off MeanWell (branded MW in a quite stylised fashion on their units), who are a well-regarded manufacturer of SMPS. I'd stick to the real ones, e.g. https://uk.rs-online.com/web/p/embedded-switch-mode-power-supplies-smps/7059857/ - a little more dear, but you don't want a dodgy PSU blowing up all your kit when it decides to short the incoming AC across the DC outputs... Any of those encapsulated/skeleton PSUs will indeed need boxing up, but that's very doable - just consider heat dissipation (you may want to think about hot airflow around your scope in an obsy - SMPS are obviously much better in this regard than linear supplies, but something to think about nonetheless)

Pretty sure the obstruction will be larger - the oversized secondary to avoid vignetting was a definite feature of the DS models. Back focus on the 200PDS at least is plentiful but with a decent extension tube (the Tele Vue ones are great, but others are available - just do upgrade from the Sky-Watcher one!) that's no issue really, and if you swap the focuser for something a bit nicer or put e.g. Baader Clicklock on the focuser that takes up a good amount of backfocus anyway, and you'll probably want a coma corrector eventually which will take up a bit more...

Right - but binning 3x3 the same images and creating copies then stacking doesn't actually put the different offset pixel data into each of those created subframes, right? ImageJ plugin would be good to see if for no other reason than reference, certainly. There is definitely scope for reuse if I ever decide to swap the 200P setup for something a bit more considered - it's a good camera, just needs to be paired with something a bit better suited to it and an 80mm frac would certainly fit the bill. That's a lovely shot.

That makes some sense practically (though I'm still trying to get my head around the maths of it - basically the same logic as binning, right?) - and I agree I'm unusefully oversampled. I'm not sure how I'd go about making that work, though, in terms of actually generating those subsampled subframes from my current data. I'm predominantly using PixInsight at the moment for my processing, but I could probably hack something together to generate this with astropy.

Hi all, So I've now "finished" my 200PDS rig - it's the best-corrected I can make it with a Paracorr, collimated nicely (though I do want to get a Catseye autocollimator to "check"), and the imaging train works well with good guiding. The 183MM-PRO is a nice camera that's worked well for me for a long while now. I'm only interested in AP for this rig - I'm treating visual as a separate set of requirements involving a large Dob at some point. Trouble is, especially with the mild Barlow effect of the Paracorr, this is a pretty narrow-view scope now. The AFOV is about 40x26 arcminutes, meaning that targets really have to be quite small to frame nicely. I've dabbled with larger targets doing mosaics, which naturally results in really nice high resolution images but is a lot of work and with the cloud we're having that's quite frustrating, e.g. the WIP image below: But other targets, even "small" ones like the Iris Nebula, can be hard to frame without losing a lot of context (in the case of the Iris, dust clouds): So now I'm thinking - should I modify the rig (somehow) to get a larger AFOV, or do I just need to start picking on a different class of targets than my usual galaxies etc? Smaller objects like M82 rapidly start to fall into the "seeing limited" category for detail. I'm already essentially imaging at 0.42"/px which is definitely oversampled. I could swap the 200P for something faster with a shorter FL; or I could go for a larger sensor, though I'd probably have to upgrade/replace a lot of my optical train north of the Paracorr and that'll get expensive quick (plus full-frame is expensive anyway); lots of options. Interested in what people would suggest!

Might be gin here rather than wine, but I recognise that vibe! I was wondering about a VX12 or 14 as a visual counterpart to my imaging rig (a 200P Sky-Watcher) but am erring towards a frac (either a cheap Bresser or a low-end Tak) at the moment just for portability and ease of setup; not having to collimate after moving etc is a definite appeal, but then I'm limiting myself to fairly bright targets with reduced aperture, so swings and roundabouts... I've got a E350 estate which would be big enough to move a VX14 should I go to a dark sky site, but definitely worth considering the size etc - I know a lot of the truss based dobs fold down and can save a lot of room when transporting which can be a huge plus. The 200P is much smaller (a full 50cm shorter) and a bit of a faff to move around - I've taken it to one or two sites and the combined pain of setting it up and collimating it (and the weight) is a lot of work.

Just a night and a bit of data inbetween fixing observatory issues, and not perfect by any means - I tried a new process using WBPP in PixInsight and definitely didn't get as good a result. Framing-wise the Iris isn't ideal for my setup but it does get some nice detail near the central star. Shot on the 200PDS with my usual setup - Paracorr, ASI183MM-Pro, EFW with Baader filters, ASI174MM and ZWO OAG on an EQ6-R Pro. INDI/KStars/Ekos for capture, and PixInsight for processing. I couldn't find good "background" bottom right which I think limited the options for DBE - it's a tricky one! Seeing was also pretty meh.

I think so long as the screws are replaced (potentially with shorter equivalents) you'd be fine. You just want to stop debris getting in.

I should add that the telescope has a Pi 4 on it (mounted in a little case on the tube of the 200P with velcro tape) running INDIserver which is the "other half" of the equation - this has been running flawlessly for a couple of years. I used to run Windows/APT and then SGP back in the day but kept coming back to Linux for the remote management and monitoring. RDP is definitely better than VNC, which is the big "win" over Linux for remote operations, but everything else I really do prefer Linux. Ekos/KStars has come a very long way over the years, too.

So, for a good long while - going on 3-4 years - I've been using a spare laptop as my observing control PC for imaging. However, if I ever get around to an observatory I'll need something full-time and the laptop takes up a lot of space to have out all the time. I figured I could do pretty well with the Pi4 so set about making an ideal "Obsy in a box" setup. This comprises: Pi4 8G - 4G probably more than enough but best to futureproof ArgonONE case - an excellent, passively-cooled (but fan-assisted, i2c controlled) aluminium case, with... ArgonONE M.2 SATA to USB adapter - a nice way to expose a SATA (not NVMe!) M.2 disk to a Pi in a neat case WD Blue 500G SATA M.2 drive - for storage without write-cycling the uSD card to death 2.5A 5V adapter to power it all via USB-C This all packages very neatly into a box that lives in my "comms cupboard" next to the network switches/routers. The Pi is networked into the core on 1GE copper, which gives it a nice fast path to the storage array (a 16-disk 30TB ZFS RAIDZ3 in the garage) that acts as primary archival storage for the imagery. I didn't go down the Astroberry etc pre-made stacks as I like to run "current" versions of software (though stable) and Arch is very flexible and lightweight, enabling a very small footprint. Software-wise I wanted fully headless but to run KStars/Ekos natively for remote control of the Pi on the 'scope running INDI. This turned out to be pretty straightforward: Arch Linux - I've been using Arch for many years now and it's a rolling release with a great community of INDI/astro users so excellent KStars etc support following the main release cycle TigerVNC, set up as per https://wiki.archlinux.org/index.php/TigerVNC#Running_vncserver_for_virtual_(headless)_sessions KStars/Ekos - I copied my ~/.indi and ~/.local/share/kstars folders across which got all my main configuration, and just had to rebuild the phd2 darks library LXDE as a lightweight desktop environment - GNOME was a non-starter This gets me a user-bound VNC virtual desktop that performs well enough to be usable interactively at 2560x1440px. VNC is definitely the bottleneck when looking at interactive media like KStars full screen - actually encoding the frames to ship over the LAN takes up a bunch of time and isn't thread/CPU-bound so not sure what's going on there. But when using KStars et al windowed, as above, it works pretty smoothly and responsively. I use the SATA disk as local capture storage for KStars/Ekos, and then I use rsync to push this across during daylight hours to the storage array, from where I can pull it down for PixInsight. All KStars/Ekos functions and PHD2 perform beautifully and promptly, and there's no threat of CPU-bound performance snags - running an imaging session I have a load average of ~1.2 and only 1.4G of RAM in use (though a good 3G of RAM is acting as a file cache, which undoubtedly helps things like plate solving etc). All in all it's working remarkably well and has completely replaced my laptop in a tiny footprint! Very pleased with the result and shall work now on monitoring and some status displays around the house.

Does look good - I've had the cheap Skywatcher one for a while and as a more ahem rotund gentleman of ample proportion, find the clamps slipping rather alarmingly when the pipes get a bit dewy and wet. Something with fixed positions appeals a lot! That's a lovely setup overall.

I have an Ethernet cable certifier at the office and a favourite hobby is seeing how hilariously badly flat Ethernet "Gigabit ready!" cables fail against the standard for even Cat5e. Vast majority of them aren't even differential pairs, they're just four wires shorted together, or so close in RF terms the certifier can't tell them apart... Definitely recycle 'em if you ask me - life's too short for bad cables!

So, an interesting occurrence today - I fired up the telescope and upon trying to connect to everything realised I was not finding the main camera. The USB2 filter wheel is plugged into the hub on the camera, and this was being discovered occasionally by INDI. Looking through my system logs I kept hitting log messages like this: Feb 18 18:57:44 raspberrypi kernel: usb usb2-port2: Cannot enable. Maybe the USB cable is bad? Feb 18 18:57:49 raspberrypi kernel: usb usb2-port2: Cannot enable. Maybe the USB cable is bad? Eventually I took the kernel's advice to heart, grabbed a spare USB3 hub and the required cables (lacking a suitably long USB3 A-B lead) to bodge a short A-B lead to the camera from the Pi on the scope, and swapped the flat USB cable out. Instantly fixed and back to normal. No visible damage or issue with the contacts; it's been sat out under cover for a couple of years. This was the ZWO-provided flat cable which comes with the camera. Long story short - flat cables, from Ethernet to USB, continue to be The Devil and should not be allowed near your rig! Replacement cable of the right length on the way, and I'll replace the USB2 flat cable to the EFW too.

The mount will draw as much current as it needs from any source between 11 and 16V. Most 12V stuff regulates that voltage down to 5V or 3.3V for any internal electronics (since 12V microcontrollers etc basically don't exist), so will tolerate a wider range of input voltages than precisely 12V. 12V is generally taken to include the range of voltages a 12V lead-acid battery or charger will normally supply, which will be somewhere between 11 and 15V. Normal "float" levels for a charged 12V battery are around 13.8V, which is why many "12V" supplies actually target this with their output to accommodate the usual voltage sag as increasing current is drawn. Generally any 12V device will be absolutely fine running at 13.8V.

Doesn't look problematic if it's consistent - I'd check a range of samples and try a few different methods for covering it and exposure times.

I'd avoid the no-name stuff from Amazon. Pretty dubious in terms of what you're getting. The challenge with your budget is that when imaging with a prime lens/bigger sensor like you've got there the cost will normally be much higher than 1.25" filters etc - filter cost broadly scales as a function of coated area! I'd save your money, wait a bit, and get an IDAS D1 or D2 in EOS body-mount format (though check the 550d can take these): https://www.firstlightoptics.com/light-pollution-reduction-imaging/idas-body-mounted-filters-for-canon-eos-aps-c-and-rp.html These will be much much better filters, a bit more robust, and crucially generally result in a much reduced colour cast than cheaper filters.

For what it's worth, I don't use PS at all for any of my images - PI can do everything I want. Probably the only thing I'd use PS for would be watermarks/signature image addition. Depending on what your source material is you've probably stretched with HistogramTransformation while you had a STF applied. Super easy to do depending on what your starting point was (linear vs nonlinear, starting exposure levels, etc).