discardedastro

Good to know, thanks. I'm inclined to leave well enough alone till I can test this with some starlight, and see how it's performing backlash-wise. If it's all happy, no problem - otherwise I'd want to do a full teardown and rebuild of RA (and I'd be inclined to replace the bearings as a matter of course with fresh SKF/FAG high-quality replacements all round). Somewhat surprised that I can't find any EQ6-R Pro teardowns or rebuilds documented on the net. It's been out for over a year now! I'll definitely document my attempt thoroughly if I go ahead.

Clutches might be the answer - I am running 15 kilos of stuff on the mount, and being a Newt it's got plenty of sail area. I set up a couple of tests in the living room to explore the software tracking issue angle, with no kit on the mount - just a fairly precise marker on the RA axis (scalpel-cut piece of tape to form a nice pointer), set to 0 on the setting circle. I ran the mount for a couple of hours on the hand controller with tracking set to sidereal. I repeated the same configuration with INDI's EQMOD driver doing the tracking instead but otherwise identical. A quick bit of maths gets me an averaged arcseconds/second value for both configurations. I got answers within 0.5 arcseconds per second of each other, both within 1 arcsecond/second of 15.04. I reckon my measurement precision with the setting circle and pointer is probably +- 2-3 arcseconds/second. I'll repeat the same with the full load on and see how it fares. I could also point a big fan at it for the duration 🙂, but one thing at a time. Then I think the only thing I can do is wait for clear skies and do two 1-2 hour sessions where I track something nice and high altitude, once with PHD2's guiding output disabled, once with the guiding output enabled, with the clutches very firmly engaged. Recording both should give me a good A/B comparison that will at least tell me if the problem is guiding related or not, and if not, might give me a hint as to what it is with some FFT analysis.

Hi all, I've been following the EQ6 guide for worm tuning here: http://www.astro-baby.com/EQ6 rebuild guide/EQ6 worm alignment.htm - this appears to be the same process as for the EQ6-R Pro, broadly, going off the PDF instructions from Sky-Watcher. I've adjusted my RA (Dec seems fine, but RA had some play in it) and run it 360 degrees a few times and it feels smooth (with some slight periodicity to the "hum", I'd say around 1.5-2Hz - but nothing significant enough to cause the ammeter to move). Full speed slewing pulls about 2A@13.4V (Nevada PSU). So I've now got RA with very nearly no play, all seems well. However, when it comes to adjusting the end float adjuster, I've hit a difference between the mounts. The EQ6-R has an optical encoder on the worm - I'd assumed this was internal to the worm housing, but apparently not: This looks to just be held onto the end of the worm shaft with a single posidrive screw (hopefully with some Loctite!) but the encoder head of course sits over the top of the plastic disc. I think this means the only way to get access to the adjuster must be with the worm carrier off the RA axis, with the encoder dropped in on top after adjustment is complete during manufacture. Thought I'd document this here in case anyone else was thinking of doing the adjustments (which otherwise seem very simple and effective). I did also pop the belt drive housing off while I made the adjustments, as I thought it could bind or otherwise hold the worm carrier to the main body of the mount. That didn't yield much of interest - the belt was tensioned well, and there appears to be a tension adjuster (middle screw). The lower gear appeared to not be perfectly flat in running or in surface - the light reflecting off it came and went as it turned. Doubt that'd have any performance impact on the mount, but thought I'd mention it. Slowly building up confidence to maybe take the RA axis apart and make sure absolutely everything is perfect, adjust/tweak shims if needed, etc, but maybe that's a "next year" project if I can get everything running well enough for now...

Well, I'll try the hand controller out. I was doing my last bit of testing just before running off to a festival (any other Cropredy-goers?) so haven't been able to check that yet. However, I did get one quick test in before I legged it - using PHD2's automatic/guided star-cross test I got only a single line in the output image and the guiding steps (other than West) completed "instantaneously" rather than taking any time, so I think this is probably software - I just need to dig into what's going on and work out which bit of software is failing to do its thing. Next step I think is to pull the whole rig indoors and do some tests in the evening. Either it's comms between PHD2 and INDI (less likely) or an EQMOD INDI driver setup/configuration issue (which my money's on). I did tighten the clutches up very thoroughly as I've had issues with clutch slippage in the past. I did have a mount crash early in my ownership of the mount which went unchecked for some minutes, so in the back of my mind there's always the possibility that I've knackered something mechanically; in which case I'll have to strip it all down and replace anything damaged. But mechanical damage wouldn't cause that PHD2 weirdness, so that's still my leading theory.

That is what I did, basically - I just used PHD2 (with mount set to a 0 guiding rate, while tracking sidereal) to record it against a star. Sorry if my explanation wasn't particularly clear above! Also, I think sidereal rate should be ~15 degrees per hour? 15.041'/s, so 15.041*60*60 = 54147.6 arcseconds per hour, 60 arcseconds per arcminute, 60 arcminutes per degree, so you come back to 15.041 degrees per hour. Edit: I don't have an easy way to use the Windows flavour of things, no. I could just use the Synscan controller (which would definitely just do simple sidereal tracking) and do the same recording exercise, I suppose...

Yes, sorry, I should point out that the pictures were both taken at 0.5, which is what I normally have the pulse guiding rate at - I set it to 0 so I could record in PHD2 what the RA was doing *without* any guiding. My anticipation was to load this into PECPrep but the runaway RA belies something more than just PEC!

For some reason I'd never considered that, but I do wonder! However, it doesn't feel quite right - I'd be expecting to see much larger variance, and a quick number-crunching exercise suggests the mount is tracking, just with an average 1.25 arcsecond error per second of RA motion. Should mention I'm using KStars/Ekos/Indi, so not the usual ASCOM/EQMOD drivers, but the eqmod drivers for INDI.

Definitely having some trouble with my EQ6-R; I thought I had guiding issues initially but I'm now thinking that I might have a mount problem. I set up last night for half an hour or so amongst clouds, so not ideal conditions, but set my guide rates in EQMOD to 0 and let PHD2 guide without being able to influence the mount, so I could get some data. This is a 200PDS plus a Primaluce 60mm guidescope mounted on very solid rings (CNC machined, friction-fit to the guidescope). Imaging for guide is a 120MC at 3.75um pixel size/260mm for ~3"/px. This is what I got - obviously a bit in the middle where it lost tracking but RA just seems to be careening off. I polar aligned with a Polemaster and did a polar drift alignment with PHD2 before I started, which entailed only very minor corrections from the Polemaster alignment. In practice on 2 minute subs I'm seeing this sort of thing, guided - these are from a ASI183MM-PRO at 0.5"/px. So I'm not sure what to make of this or how to really go about debugging it - any ideas? As far as I know the mount's in good health, I had the scope off it the other week and followed Skywatcher's backlash compensation guidance but this doesn't seem to have changed anything. It's got good power (a Nevada 12V supply off mains) and is in a stable location (solid grass where it's been sat for over a year). DEC looks pretty much perfect with ~1" of wobble unguided... Any ideas? PHD2_GuideLog_2019-08-06_220852.txt

I've now had first light with the Sesto Senso and it works well with the Baader Diamond; I'd definitely consider it if you have no need for manual control. Disengaging it is a bit fiddly but only a few grub screws - however, since it replaces the fine focus knob (which has a lot of mass in it, and which contributes quite significantly to the feel of the Baader) it's not a very pleasant thing to use disengaged. I'd be more inclined to go for something with manual control. There's definitely a gap in the market for a generic handheld focus controller that can be configured to send commands to an INDI server. Thinking about making something now I have the Sesto Senso - an encoder, a few buttons, and a small screen on an ESP32 WiFi board sending generic commands to a server on the INDI box to act as a bridge, or something...

And just to add some "lessons learned" after a brief first light... With the Clicklock in place the focus position is very close to the "full in" position, but there's still plenty of room (it sits around 5000-7000 in absolute terms). The standard low-profile mount might be all you can get if you're already fairly well racked in at focus on the stock SW focuser - I was usually about half-way out or thereabouts. It works perfectly, as far as I can tell, in any case - mount issues stopped me getting a perfect in-focus frame but the V was clearly defined in Ekos autofocus. Racking out to either extreme and coming back to focus was absolutely dead on. I'm running the motor in the "Medium" preset, which seems to work fine.

Right, since I couldn't find anyone who'd done this before I did, and because I'd really have liked to have it when I was doing it, here's a write-up with pictures of how a new Baader Diamond Steeltrack NT fits on a Skywatcher 200PDS, replacing the stock focuser. Spoilers: it doesn't! While all the documentation (including FLO's site) suggests it's designed to retrofit Skywatcher and similar scopes, and the install documentation suggests using existing holes to align the placement of new ones, this turns out to be wrong. The holes are wildly off and so you can't do the alignment using the old focuser holes. Note also the bonus 5th hole on this one - thanks, Skywatcher! So this got a bit more involved. I started by removing the secondary, fitting the new focus motor, and removing the screws holding on the old focuser. Here's both side-by-side, ready to go. In retrospect you'll need access to the side "underneath" the focus motor, so best to prep but not fit it at this stage. Next you remove the four bolts on the Baader plate and slacken (but don't remove) the eight tiny grub screws around the plate to remove the focuser itself. A set of long-handled (not right angled) 1/1.5/2/2.5mm allen keys is a godsend during this, incidentally. After realising the holes wouldn't align I sat down and did some maths; on my 92.6mm wide hole in the tube I needed a 5.9mm gap above and below to the screw holes. This turned out to not quite be right but I drew those lines in as a reference, using a set square off the front of the telescope and some calipers to measure. Masking tape on the tube gives a nice surface to mark on and helps reduce swarf when we get to drilling. I put the base in place and used two small G-clamps through the drawtube hole to temporarily secure it. This let me see I was a bit too far away with my hole placement so I put a centre punch mark about 1.5mm off the lines drawn. On the long axis I just eyeballed the center of the slots in the plate after getting the plate itself roughly centered; I figured this gave me about 5-10mm of travel to fix it precisely, which was plenty. Once all aligned, I stuck some paper in the tube to help catch debris and popped the holes in. I was using a 2mm Bosch HSS-TI bit, followed by a 5mm. I deburred afterwards, just to keep things clean. I taped over the old holes to provide some light blockage and atmospheric sealing, since my scope lives outdoors. I had to experiment with the shims - I thought I wouldn't need any, as the instructions note the base is designed for a 8" tube. However I think this actually means 'an 8" tube made by someone who over-sizes their tubes more than Skywatcher do' - I added one shim on each side in the end and that looks snug without distorting the tube. Note the plate has definite gaps around the tube - if you're concerned about light leakage or dew ingress these gaps need filling, along with the empty screw holes in the plate. I'll probably just put a bit of black foam in the big gaps and tape over the rest. I then got the plate central to the hole, tightened it all up, and fitted the focuser. This is where the non-right-angle allen key drivers are a godsend - modelfixings.co.uk do a nice range. Note here I've had to remove the Senso Sesto to get at this screw. I used a right-angled allen key to tighten up everything once it was all nipped up. So that's the focuser actually fitted and the motor fitted in place: I hacked the end off the power cable for the Senso Sesto because unlike everything good and proper using 2.1mm DC jacks it uses a 2.5mm and I have no 2.5mm to terminal block lying around. I added a couple of blocks to split the camera power supply in two - this definitely needs making neater, but that's another project. Fitting the Clicklock was easy but fiddly - tiny tiny grub screws galore rather than a screw fit for the adapter. Note the Clicklock requires a minimum length of your 2" component - I had been using a 1.25" adapter which only had 1cm of protrusion into the 2" barrel. This did not work. Fortunately I had another which did. I stuck a laser in and used a ruler to validate that the focuser was square (measured laser intercept off the front of the scope). Up/down I didn't verify but it looked spot on relative to the spider vanes. I then sat down for an hour of flipping between collimation guides (Vic Menard's, mostly) and FLO's sight tube/Cheshire to get the secondary back in and collimated. While I've achieved pretty good axial collimation I think my focuser position is a bit too far "down the tube" - this is the first time I've done "proper" secondary collimation! Here's a shot from a Barlowed laser: And a view down the sight tube - not quite as badly offset as this shows but it's hard to take photos down a Cheshire! First impressions of the Baader while putting it together are very positive, other than the plate awkwardness it's very well built and feels very solid. Time will tell how well it performs for AP but with the new motor it should be a considerable step up from the stock focuser and the Hitecastro DC focus! Hopefully this helps someone else trying to make a decision on this focuser or considering how to install it.

I've got a Senso Sesto and a Diamond Steeltrack for Newtonian arriving in the next couple of days, so holding out hope for that combo. The SteelDrive II looks nice if you want manual control on-device, but it is pricey - one of the reasons I didn't go with it in the end.

Passive daisy-chaining is very safe using standard singlemode SFPs (10/20km optics) - you typically have -9dBm launch power (worst case) and a receiver sensitivity of -22.5dBm (worst case), so a link budget of 13.5dB. Assuming a 30 metre patch cord (~0.009dB loss in fibre) and a typical connector (0.5dB) you can put 25*30m patch cords + couplers in (750m) and have room left over for a patch panel at each end! In practice -9dBm launch is worst-case so you'll get another 3dB or so atop of that. But if you're burying in duct, I'd definitely stick to pre-terminated runs of the appropriate length. fs.com will make you up cables for £100 or so for ~100m, last I checked.

fs.com are a very cheap retailer, but do good parts - plenty of professionals and big networks in the UK running off some of their optics etc. My advice: Stay single-mode. Multimode is cheaper, but comes with many more headaches. Single mode (OS2) is also more widespread. The cost differential is not significant, and the longer range gives you more margin of error. You'll need a pair of SFP modules, and either switches that accept SFPs (Mikrotik and Ubiquiti both do 'em, some cheap Netgears even do now) or media converters (which are transparent, from a network perspective) Those SFP modules will have LC UPC connectors and need two fibres to work (one for transmit, one for receive). You can do single-fibre working and an SC connector using different wavelengths (so-called bidi) but two-fibre working is easier to work with. You will therefore need cables that are terminated in LC UPC duplex pairs - this is very common. UPC just means "Ultra polished contact" and is distinct from "angled polished contact" APC connectors. UPC is blue, APC is green. Avoid APC. You can daisy-chain patch cords if you need more length, but having a continuous run is preferable. Joints outside will need to be in waterproof boxes with rubber seals that don't put too much pressure on the cable. Consider getting a cable made to length if you need >50m; it's usually pretty cheap, and the cost of fibre is all in the ends until you get into very large cables (we do 864 fibres in a 20mm cable at work - that's fun to work on). Otherwise, you just need couplers to join cables together - they're cheap as anything, just plastic to push the two cores together. Get pre-terminated cables unless you know someone who does fusion splicing for a living. And even then, get pre-terminated cable. If you're pulling cable any appreciable distance, tension can kill fibre - use a pulling sock and be gentle. Be mindful of bend radii. Cleanliness is king. You can be pretty abusive to fibre cables, especially newer G.657.A1/A2 cables which will bend quite severely, but if you get dust or dirt on a connector you'll have a Bad Time - it can damage connectors or transceivers. Just keep dust caps on everything until you're ready to plug it together, tape up before pulling through duct, and buy a one-click cleaning pen (~£20) which you can use a few times before mating any connectors. In short runs, so long as you don't lick them/clean on your t-shirt, you'll be fine. Treat the ends like telescope optics and it'll all be alright. If it doesn't work, swap the transmit and receive cables on one end - the most common "I plugged it together and nothing works" cause is inverted polarity.

Just reading through the last few pages - some great progress made! While getting an electrician in is definitely the way to go, on grounding I'd just throw conductive concrete out there as a thing that exists - at work, we (and many other telcos) use http://www.cubis-systems.com/uk/conductive-concrete-landing-page/ underneath our concrete pads for utility cabinets that have electronics in. It's basically a carbon-concrete matrix which bonds to a copper electrode cable laid within the concrete that comes up to provide your earth. It can be poured dry without needing water or mixing - it'll absorb enough from the surrounding earth. The huge benefit is that it doesn't corrode, so lasts absolutely ages, and the conductivity is actually much better than an earth rod - so you can do a relatively small and shallow installation and get a very good ground. Worth considering if you've got challenging material 50cm+ down that makes getting a rod in hard or makes the rod less effective! Also, if you're planning to run Ethernet back to your house, consider using fibre optics. If you're running off different supplies or phases or just have a different ground, there is a risk that you put more volts across your Ethernet cable than are tolerable from either end; I've seen someone cook a very expensive network switch (~£80k if memory serves) by doing this across two racks fed off different phases at a trade show booth. You can get pre-terminated 30m LC patch cords for £10 or so, and TP-Link and others make media converters to go between a fibre SFP and a copper RJ45 on each end. Fibre SFPs for 1G again around the £10 mark for short distance stuff. So it's not a huge outlay, and you really can't end up with any ground loop excitement via glass 🙂

Finally got a Cheshire/sight-tube for my 'scope so I can do my secondary collimation perfectly - the FLO premium one, since the Catseye one is pricey and on a long lead time. Plus a Catseye spotting template for my 200mm primary and a hotspot. I'll get an autocollimator eventually - but it's going to be great to nail down the secondary and get the mirrors perfect before I embark on replacing my focuser...

You can't, no, but making one using ImageIntegration is pretty trivial. Just disable normalization (in both the main settings and the pixel rejection settings), disable noise evaluation, use whatever rejection works best for your setup and quantity of dark frames (average sigma will work for most, linear fit if you've got loads of frames). You can then either load it as a master dark in the Batch Processing script, or use ImageCalibration yourself with your light frames prior to manually aligning and stacking.

Not sure on the mechanics of the Baader but your assessment seems good - if the 1:10 reducer is like the GSO ones then the grub screw in the gold wheel will let you remove the knob and get access to the reducer (which will be greased). The exact size I don't know but it'll be a metric size, so either M1, M2, M3 - it could be M1.5/M2.5, but fairly unlikely I'd have thought. Model Fixings are my go-to place for buying those sorts of things - they're cheap, deliver promptly and have pretty much everything you'd ever need for small mechanical bits: http://www.modelfixings.co.uk/tools.htm#allen keys Edit: One other thought, it may not actually be the wheel making noises - the reducer is inside the wheel, so you're most likely hearing something wrong with the reducer.

Bit of a quick and dirty camera-only setup, since the 200PDS is on a mount north of the house, making south seeing a bit tricky. The restricted horizon made portability critical anyway. Crap seeing, suboptimal kit, but hey. Nikon Z6, FTZ adapter, ancient telephoto Nikkor at 200mm f/3.5, ISO 100, 1/100th of a second. Got a few shots off but these came out nicely.

I get all that, but the two examples talked about on here, are both using a laptop to control and rpi as the server, and with Kstars running on said laptop, so in those scenarios, there is no need whatsoever to even see the INdI web manager....it will run auto when ekos starts...and run in the background. I don’t understand when running in this mode, why the Indi web manager is even mentioned as it’s just invisible... you never actually have to see, start or have anything to do with it, when running Kstars / Ekos on a laptop and INdI on the rpi...Ekos does it all for you.. Ekos+KStars runs on my laptop, not the RPi. The Pi runs INDI Web Manager at boot, which then allows KStars/Ekos to automatically start indiserver remotely. It is absolutely invisible from an end user perspective, once it's all set up, but the absolute minimal Pi setup is: Install indi and all the required drivers, as well as indi-web Set up indi-web to start on boot (for this purpose I use a systemd unit file, which enables the systemd daemon to look after indi-web and restart it if it crashes) Connect Ekos to the Pi, whereupon Ekos will use indi-web to start indiserver with the drivers configured in Ekos Obviously if you're using a pre-packaged distro like Stellarmate this is being done for you under the hood; I've just built this up headless. Running Ekos+KStars on the Pi itself is somewhat attractive - as @david_taurus83 says it's nice to have everything on the same box, and means it's a completely self-contained setup from a things-to-go-wrong perspective - having my laptop crash or WiFi connection drop wouldn't be a worry. Just a bit concerned about performance and latency.

I had first light for my setup last night and it worked beautifully - this was headless, with INDI on the Pi4 (wired Ethernet) and Ekos/KStars on a separate laptop (wireless, since I'm nipping in and out of the house with it). Web Manager for INDI, started+managed by systemd. Only snag I hit was with my GPS, which turned out to be a simple GPS receiver issue, not a gpsd issue - hopefully now it's had a warm start it'll fare better, otherwise I'll fake a device with the correct fixed position and time from my home's NTP server. Everything else worked fine. Obviously running things like guiding over WiFi isn't ideal, so if the desktop-and-VNC-on-Pi approach works well for others I'll give that a try, otherwise I have a few spare Atom servers lying around I can easily convert. I did have one KStars crash but that's not new - I think that's mostly due to running latest-and-greatest release from the Arch repositories on the laptop. Seems to be something in the auto-focus module - I need to run it within gdb and capture a stack trace next time it explodes. Lots of mount/telescope issues, but nothing new there more work to be done overall!

Worth noting those 8P8C cables are *not* network cables - they won't pass Cat5e/Cat6 certifications and thus may not operate properly at 100M or 1G depending on your distances. From a switch on the mount or pier to a thing on the telescope, you might get away with it, but if you're using a passive coupler (not ideal anyway) or patch panel to get back to a switch you're unlikely to make it work. I've used https://www.canford.co.uk/CANFORD-RJ45-CAT5E-SCREENED-PATCHCORDS-Using-Cat5E-F-deployable-cable for similar sorts of things in the past - they're very flexible, cheap (~£10/cable), and being straight cables won't snag on protrusions like curly cables can sometimes. Plus they're screened, so a bit more resistant to interference from motor drivers etc.

Yeah, astroberry et al are sensible choices if you're not au fait with a terminal 🙂 Pi4 will be a bit more DIY for a few months probably. Spent an hour or so fiddling about with velcro and getting everything mounted on the telescope, using an old project box to mount the Pi and 12V-to-5V/12V distribution. There's definitely a gap in the market for a "long and thin" box and some brackets to mount on an offset from a dovetail... it's a bit of a bodge but it all fits and is secure. There's only 12V and Ethernet coming onto the scope, and a cable down to the mount. Definitely +1 to the comments on Ethernet vs WiFi - cable it up! I'd strongly suggest using a switch on or near the scope so you can use flexible cables onto the scope, "installation" cables don't flex/bend well.

Yes - which will install new files, like it says on the tin. It will not clean up old files, remove things that should be removed, or alter things that should be altered (outside of complete replacement of files if their content has changed). Upgrading the packages thusly, a 30-second job: wget http://new-indi-url tar zxf new-indi-package cd new-indi-package .circleci/build-deb-packages.sh cd 3rdparty nano -w make_deb_pkgs # adjust DRV_LIST ./make_deb_pkgs sudo dpkg -i *.deb sudo dpkg -i ../build/*.deb ... will correctly clean up anything now unneeded, remove anything that should be gone, amend permissions that might need adjusting, call any OS-specific hooks, and so on

I'm an old sysadmin at heart, I still treat my boxes like pets, not cattle I find this much simpler, in any case, and going through the "proper" packaging route also means that any OS-specific quirks the maintainers build into the packaging process get properly enacted/called, like amending group memberships/user ownerships, etc. Been burnt plenty of times before on that sort of thing. And SD cards aren't that cheap (not decent ones, at least)...