discardedastro

Definitely never spray cleaning fluid onto eyepieces or objective lenses - the risk is high that fluid may migrate beyond the outside surface and between lenses, leading to condensation etc. Ultra-clean wipes are the key, combined with a good fluid like the Baader stuff (Calotherm's lens cleaner is a good option also). I would generally recommend disposable lint-free wipes; e.g. https://www.amazon.co.uk/Solwise-Fibre-cleaning-Lint-Free-Pk-300/dp/B06XYRN5V2/ rather than using a microfibre cloth since there's no risk of foreign material being dragged across the lens coatings, but if you have to use a reusable cloth make sure you keep it impeccably clean and use it only for lens cleaning. The Caloclean cloths that FLO sell come in a resealable pouch which is ideal.

They had a bit of a reshuffle when -vcodec and friends moved to the new -c:v format, but it's been pretty stable since then drove me up the wall for a year or so when the transition was happening and I was working on boxes with both versions and a lot of scripts with cli callouts to ffmpeg. That was "fun"... https://handbrake.fr/ is one of the nicer GUIs for ffmpeg, which might be an easier option. VLC can also do quite a lot of this stuff.

ffmpeg is an excellent answer for any sort of A/V conversion, recoding, splitting, and general fiddling about. It's incredibly powerful (and under the hood of at least 50% of professional video tools out there). The important thing to consider in any conversion is what you're changing. A video file is a container which has one or more streams of information in, each of which is normally encoded with a specific codec. PIPP I would presume discards the audio since it's designed to process images, so doesn't have an interest in audio. MOV is a container, MP4, AVI, etc are all containers. Codecs would be things like H.264 (probably what you've got video in if it's from a phone), Theora, AV1, etc for video, MP3, AAC, FLAC, Vorbis etc for audio. Not all containers can hold all codecs - AVI is quite limited, for instance. If you just want to repackage the streams of information - i.e. move the stuff from the MOV into AVI without changing the content - you can easily do this with ffmpeg: ffmpeg -i input.mov -c:v copy -c:a copy output.avi This will copy the contents from your input (-i flag) to the output file. If it can't, it'll throw an error. Swapping containers is always preferable to re-encoding or compound coding as this will normally degrade quality noticeably, especially if you're working with lossy codecs like H.264 etc. If you need to re-encode then you can do this - there are lots of options for most codecs but bitrate is a common one. For instance, to encode your video with H.264 video and AAC audio into a Matroska container, with (approximately) 2Mbps of video and 128k of audio: ffmpeg -i input.mov -c:a libfdk_aac -b:a 128k -c:v libx264 -b:v 2000k out.mkv The ffmpeg wiki has lots more good information. It really depends on what you're trying to acheve - if you're targeting a specific container and codec for a specific service or tool then you'll usually be able to find out what's expected and then configure ffmpeg accordingly.

Basically only relevant for large format cameras, as I understand it. 2" will do you full frame with pretty minimal vignetting, though I suspect 3" and above wouldn't hurt for that, but for larger sensors like medium format you have to go beyond 2" - I think for medium format you'd have to be at at least 3.7". The FSQ-106 has an 88mm image circle and a 4" focuser and can support medium format sensors. So I think it's not so useful unless you're planning to hang a very expensive CCD/CMOS on the back!

If it's got the Synscan hand controller (looks like it top right), then worth them powering it up. The last observing location entered will be stored as part of the initialisation sequence - may not be "home", but might get you close, and if you're lucky it's the back garden!

I have it on the primary end of things rather than at the secondary - it's all fine under cover (there's a guidescope there too). Definitely won't make a difference to dew or anything like that but has been stable in extreme conditions so far. I haven't gotten to the point of sealing it up or conformal coating anything. My setup does live permanently outdoors under a TeleGizmos 365 cover.

I went the opposite way - given I have a Newt on the top which benefits from some counterweight on the tube, I did a similar thing with wide adhesive velcro strips to attach the USB hub and a small project box with the Raspberry Pi in it directly to the back of the scope opposite the focuser.

OK, for imaging you should be OK with the HEQ5 or AZ EQ5-GT, but might be worth stepping up to an EQ6-R if you're going to do much imaging for the performance. You'll need to consider guiding whichever way you go for DSO AP with those scopes, which will add weight beyond the imaging camera (potentially guidescope plus camera), so do think that through - you could easily be up to ~15-18kg all told. Not familiar with the iOptrons but the CEM25 is borderline too small to handle the Omni and is going to be marginal for the 150p. Don't forget that with bigger scopes you'll also be fighting wind loading, so being a little bit clear of the max capacity limit is a good plan. I'd probably be looking at the EQ6-R or CEM40. If you're exclusively doing planetary imaging then you'll probably be OK with the smaller mounts. From a purchasing perspective alone, I would strongly argue in favour of saving up for the right mount with some headroom - it's definitely worth getting right!

As others have said, hard to advise without knowing what telescope/camera/eyepieces you intend to mount on it, and the usage. AP has very different requirements to visual use. Any of those options might be wildly over-specified or wholly inadequate depending on what the use is!

Perhaps - though with constant motor motion, you shouldn't see huge variation in current anyway. The most interesting bit of the current/time graph should be the start, though, where the motors are getting things moving at the "worst case" position of the mechanical system, force-wise. I'm going to wire up something and borrow work's scope to have a proper look I think. However, having said all that, I'm sure it'll get you pretty close, and may well beat careful manual adjustment.

So long as they support DC current measurement and you separate out the conductors in the cable to measure, you should be OK. You'll probably get more accurate measurement with a shunt, though. Measuring power on the input might be OK with long periods of movement but the PSU may hide small variations (full of capacitors, etc). With a couple of 12V sockets it'd be easy enough to wire up something like https://smile.amazon.co.uk/Multimeter-Droking-6-5-100V-Voltmeter-Detector/dp/B07WR3PRTV/ and measure current that way. Might also be a handy inline box to have if you run off batteries, given it can measure watt-hours. A fun project might be to make a little box which has a current shunt and a mount control output - it would be pretty easy to automate the measurement routine and do the calculations, showing an indicator for how to adjust. Hum...

If it's anything oil-like or organic I clean fairly promptly - it can cause issues if not removed. For dust etc, leave it till it's noticeable. Edit: I'll +1 to the Baader fluid but the Calotherm cloths are nicer - I keep one sealed up in its pouch, it gets removed for cleaning (carefully!) any optics, and put back immediately to avoid any contamination.

And there's definitely still a bit of that in Rust, though it has at least got a proper package manager (glares at Go and Elixir) baked in pretty well so managing versions of stuff is at least trivial. I think Rust's one of the more promising ones for doing astro coding in - it's designed specifically to focus on systems programming and so lends itself well to doing "always on" applications and that fuzzy area between "safety critical" and "really just don't want this to fall over at 3am and leave the observatory roof open..." where you don't need formal, provable correct code but do want a bit more compile-time scrutiny 🙂 I can heartily recommend giving it a go. But yes, let's stop derailing Gina's thread!

Those bugs are the best sort of bugs! This is why I really love working with Rust - while it's a bit slower to write than C and friends, it's super easy to debug and very hard to write code that breaks in odd ways - the compiler doesn't let you. I also had some fun with rust-fuzz to fuzz a binary parser I wrote a few weeks back - throwing automatically-generated random data that attempts to probe absolutely every code path and potential error can throw up errors very easily (especially ones you didn't even consider possible!) when you're dealing with third party input. I keep meaning to have a go with Rust on the ESP32 - there's now a good uC toolchain developing for a (pretty broad) subset of Rust.

Depending on how you're doing your averaging, could be hitting data type limits and wrapping to a negative? If you're averaging on device by doing (x+y+...+z)/n, depending on n the sum of xyzetc could exceed a short/small int.

I don't have a 130pds but if it's constructed anything like the 200pds I'd pop the primary and secondary spider (or at least the mirror holder) out entirely to start with. I'd precisely-as-you-can measure and cut sections of material to fit the tube diameter, and work from the middle out to each end (since you can then work on the ends to adjust to length). Cut slots as required for the spider and tidy up as needed. I laid in each piece of material still on its backing, removed one edge and adhered it to the seam running down the tube as a reference, and then progressively removed the material backing while pressing it into place. I just eyeballed alignment - a bit of overlap isn't the end of the world (you don't want any significant protrusions, of course, but so long as it's broadly sitting flush it won't enter the 100% zone). Of course, while you've got it all in bits, I'd consider what else you might want to do at that point - fitting e.g. dew heaters, painting interior surfaces you can't flock, adding light blockers around/behind the primary, etc. Cleaning and spotting the mirror with a CatsEye hotspot may be worth thinking about if it's due a clean. Good moment to make any holes in the tube you might want to add for e.g. Telrad, etc, too. Worth getting it all in hand before you get it all torn to bits!

Metric M4 sounds familiar to me - the central screw is a PZ2 I believe. I'll give thumbscrews a big thumbs-up - well worth swapping, it makes collimation much less fiddly and entirely removes the fear caused by waving a hex driver anywhere near the glass. I used Bob's Knobs from FLO.

Nothing to the kit this week - though next weekend I plan to dismantle the lot, bring it all indoors, and clean up and apply fresh paint on the counterweights and some anti-rust stuff on the mount in general. I did finally cave and buy a 3dconnexion Space Mouse for my observatory CAD work. Want to try and get the basic design turned into a more detailed design so I can get materials planned and costed.

Definitely the way to go if the right thing turns up. TV hold their resale value quite well, though, and most owners know this - so don't expect a huge drop in price. And of course, once you have them, look after them well - if I know one thing in this hobby it's that you'll always want to do something different after a while! The TV kit will last very well, of course, if you want to hang onto it instead of reselling.

I will add to this that Sony and TSMC have just announced a major new plant: https://image-sensors-world.blogspot.com/2020/07/tsmc-builds-dedicated-28nm-fab-for-sony.html?m=1 Approx value of the new plant is £8 billion, will focus on CMOS image sensors (CIS) and is a dedicated fab purely for Sony's sensors, adding to Sony's other existing fabs and fab capacity agreements. 28nm is quite a large/old mode but still makes a lot of sense for image sensors (since you're working with big pixels anyway, so there's not huge gains in making the processing/amp electronics ultralow power etc). The fact that it's still widely used in sensors does rather suggest that cost of fabrication will remain pretty low for both mono and colour. And Bayer filters don't tend to be terribly precise, no - they're necessarily quite simple constructions. If I was going to treat colour-as-mono I'd take flats from a spectrally known/well-characterised broadband source and use R/G/B filters in front of the sensor rather than treating R/G/B as 100% R/G/B. Using a known source spectra you could calibrate the different spectral bandpass, in the main, per pixel. May be overthinking that, but I think that's probably the way to go.

While switching to a Pi/INDI based setup is a bit more faff it'll be infinitely more reliable than those USB-over-Ethernet widgets. Lots of stuff makes assumptions about timing and bandwidth based on locally negotiated bandwidth, so when the end-to-end pipe falls short it can create Exciting Weirdness. Definitely stick to wired. WiFi has no place in an observatory except for browsing SGL on your phone during observations! 🙂 The device server types are the most reliable if you absolutely must go down that route. Consider grounding carefully if you're running copper data cables for any appreciable distance outside/between structures - odds are good your building earths will be different, may be at different potentials, and so your data shield can start carrying currents and/or picking up exciting interference. Lightning can cause problems, too. Pre-terminated single-mode fibre and media converters (or switches with SFPs) is definitely the way to go for new installations with significant outdoor cable runs - the overall cost is similar, and glass can't carry lightning potentials 😛

Yep - just set it as required. But do make sure the legs are splayed out fully, which is I think what the manual is trying to say.

You can get DC-capable clamp meters, but they tend to be a bit more high-end (we have some DC current probes for our portable oscilloscope at work, for instance - now I think of it, might be interesting to see what the current waveform looks like on a mount in motion). I've not seen any for <£150 - I think we paid about £300 a probe from Rohde & Schwarz. I've actually done this test without any load on the mount using the ammeter built into the Nevada power supply I use, but as part of adjusting my backlash/worm gears - I could just use that for balancing. It's analogue so a bit harder to read but otherwise easy enough to use, and already inline in the right place.

Should do - it's just PostgreSQL, basically. The Debian packages ought to work (though they may not have armhf) but the install from source would definitely work: https://docs.timescale.com/latest/getting-started/installation/debian/installation-source I'd personally want to keep my long-term data on something with a bit more of a resilient storage solution - SD card failures are still sadly common in high-write situations, even with industrial-use-rated cards. I've seen some creative use of USB hubs and USB sticks/SD cards for low-cost, low-speed RAID, used with ZFS (RAIDZ2), for low-cost-but-robust-as-heck storage on a Pi - but it's not fast, and you can't boot off it, so for my money I'd go for something a bit more PC-like. Lenovo used to have heavy rebates/discounts on their entry level ThinkServer line - not sure if that's still going on.

The clampmeter trick is a nice one, haven't seen that before! Given how cheap current meters/shunts are, could almost see that integrated within the mount itself or as a nice little widget to sit between the mount PSU and incoming cable.