malc-c

It's amazing just how quick a scope can be covered in cobwebs or excretion form woodlice etc... Spring (or in this case autumn ) cleaning is a major component of running your own observatory

@The Lazy Astronomer asked for info on what interest you, can you provide us with that info as it can help others give you a more targeted suggestion or advice. Astrophotography is so diverse. At one end of the spectrum you have someone using their mobile phone to capture the image form the eyepiece on a £200 table top scope, up to a large £100K fully computerised scope with sensitive full frame cameras located in fully automated observatories.... Also one scope doesn't fit all options. Taking exquisite images of Jupiter and its moons as if you were flying past on a spaceship requires different equipment than a set up capturing faint gaseous nebula DSO's.

Have to agree with Julian. As mentioned in another thread of similar lines, as my imaging equipment is basic by most peoples (QHY5 mono guide, D400 DSLR main camera, and an HEQ5) the observatory PC is a bit of a dinosaur, but still copes with the job it has been purposed for. If the weather is nice I will run the imaging session from the warm room, but more often than not I'll remote into the observatory PC form my main PC in the lounge over a 1GB CAT5 cabled network. When I come to processing the results, the subs are copied form the observatory PC to the main PC in the lounge (normally over the network, but this could be done via external drives in required). The stacking and processing is then done on the lounge PC which is a much more capable machine (8 core Ryzen processor, 16GB DDR4 ram, and blindingly fast NVme and SSD drives). I have twin 24" BenQ monitors running off the main PC, which makes the task of processing, monitoring emails, streaming music via spotify or watching videos at the same time a doddle. I built my lounge PC form components and it's not difficult, but you should still be able to have a decent spec machine made and supplied with windows 10 within your budget. Have a look at CCL for inspiration

IMO that will do just fine for controlling the hardware. I can't find any site detailing the specs of the USB ports, but that may not matter as a USB 3 camera will still work over USB 2, but data won't comedown the pipe as fast. In reality this may not make much difference in practice. As mentioned I'm using an old QHY5 mono camera that uses USB2, but it can still provide ample frame rates and when it comes to guiding performs just fine with PHD2. As for processing, it will be possible to use Deep Sky Stacker on that machine, but if you have a powerful imac then transferring the raw images to the imac, either via an external hard drive or over the network and using that as the processing machine is always an option. I do that when stacking my subs in Deep Sky Stacker, which when processing makes use of all 8 cores of my Ryzen PC

That's like asking if a ford fiesta is any good... you need to define what "good" means, or more importantly what are your expectations.

I've not been in a position to update the imaging equipment due to one thing or another, so using the old hardware (2 core 2 thread Pentium E5700 @3Ghz, 8GB DDR3 memory, 500GB system drive and a 2TB imaging drive) still handles the QHY5 and Canon D400, both of which used USB 2.0. My main PC is a 1st gen Ryzen 1500x (4 core 8 threads), 16GB Vengeance DDR4 ram, 256GB Samsung Pro960 Nvem system drive, and a couple of 3TB data drives, which is mainly used for Video editing and PCB design / CAD and needless to say it makes my observatory PC looks like an old 286 from the early 90's !! The thing is that these days they seem to have reached a point where the gap between four or even eight year old technology hardly makes much of a difference to low demanding applications such as those used for imaging. Processors have been running at 3Ghz in that time, but RAM timings have improved a fair bit, and the Nvme format that access the PCI bus direct has been a vast improvement. Granted with the bus speed mazing out between 3 and 4 Ghz, the core and thread count has increased and now the "average" has gone up to 8 core 8 threads, but unless the applications have been written to take advantage of this then you won't really notice much difference. In fact you may find that some of the software we use is still legacy and will hammer just one or possibly two cores at most.....

These days SSDs are more commonly fitted to PCs, at least for the OS drive, and yes they do make a difference. The PC I'm currently using on a daily basis has a Samsung 960 Nvme drive and that is another leap in speed over SATA SSDs. I agree with the comment that whilst its possible to run an imaging rig on old technology, a PC with higher spec and performance will make things easier. If you have a camera that uses USB3 then it's no point in getting an older second hand machine that has no USB 3 sockets. It will still work over USB2, but you're not going to get the maximum performance.

So are you looking at using a mount to track satellites - EQMOD has this option (never tried it) - No need to re-invite the wheel

Something like this ?? But it would still need to have some form of step down regulation between it and the 12v mount supply (which in essence is what I described). Not sure you will find an off the shelf product that has a standard 2.1mm centre positive connector at one end, and a canon dummy battery with built in voltage drop from 12v to 8v at the other

This was discussed a few months back. I got slated for using a standard 7808 8v regulator as I hadn't included the smoothing caps in the setup ! My scope is in its observatory, with a small power box attached to the pier. In this box I have the 12v coming in, passing through to a connector which then has a cable that powers the mount. The feed in is split and taken to a 7808 8v regulator with a couple of electrolytic capacitors to give a stable 8v DC out to a second connector. A lead then goes off to a dummy battery that I made by taking out the two rechargeable cells. This powers my Canon 400D without any issues. There are loads of commercial options to power cameras form the mains... just google - Here's an example

Two basic choices when using a laptop. * Windows, ASCOM, EQMOD / GSSeerver, planetarium software such as CDC, Sharpcap, and a CCD camera * Linux, INDI, KSTARS or CDC, Ekos, Sharpcap, and a CCD camera As for hardware, you don't need anything exceptionally powerful. I'm running my observatory on an old 2 core Pentium system that is circa 10 years old technology. I have even managed to run an imaging session on an old Eee900 netbook back in the day when these were popular (circa 2011), all be it I had to use an external drive to save images to. Any entry laptop in todays market should be very capable of running the software and controlling the hardware.

You may find a standard DIY service could give the old tired mount a new lease of life ? The thing is people often uprate the bearings and such to high spec ones, which is fine, but in reality given the speed at which the RA/DEC axis move, and the fact that they hardly rotate a complete circuit there is often very little wear and tear on the originals. These mounts are made to a certain level of precision that mass production permits. I'm sure if someone machined more precise and hard wearing worm gears that reduced backlash even more then that would be more practical, but given where these HEQ5 / EQ6 mounts are placed is that going to be much of an improvement, or worth the cost. I mean it's quite easy to get guiding accuracy of one arcsecond or less with these mounts without any upgrades other than a belt drive, which is going to give some nice tight round stars and detailed images in anyone's book.

Did you get any response from the mount when you sent :e1 or :e2 ? Looking at the EQ8 manual, it might be possible to connect the mount directly to a PC via USB via the USB-IN port - no need to use any serial cables or EQDIR cables. Also if you did use a standard USB/Serial adapter and then the SW serial cable connected to where the handset normally connects then there is a high risk of damaging the mount as a standard USB to serial adapter may not use the same voltage levels as a dedicated EQDIR cable would, and if 12v signals are sent to the mount when its normally using 5v it can fry the electronics. Normal serial runs at +/- 12v where as TTL serial (that used in EQDIR cables) is +5/0v We really need a lot more information on how you are connecting the mount, and what you are wanting to achieve... Firstly, can you just confirm that with only the handset connected you can set the slew speed to 9 and slew the mount in NSWE directions. This will confirm that the mount hasn't been damaged in any way. If the mount is fully responsive then see what happens when you connect a USB cable to the mount - if it shows up in Device Manager as a new COM port then this will give you the option of PC control. With regards to the commands have a look at this it provided the ASCII codes to send to the mount... using that with the document you mentioned may allow you to apply variable slew speeds to either axis independently. But I have to ask the question why you want to slew the DEC axis at a different rate to the RA ?

Personally, my take is that having any mount overhauled and tuned with higher tolerance bearings etc is really down to the level of imaging you are at. I know of one person who has just had his EQ8 services and upgraded parts fitted (not by the company mentioned above) to resolve and improve his imaging results. But he is what I would call a "professional" amateur, with equipment valued at many thousands of pounds, and he produces results that grace the covers of Astronomy now, and Popular Astronomy. If, like me you are a casual imager, with more humble equipment, in a less than ideal location but are still happy with the results, then I can't really see the need to turn what may well be a perfectly function mount that is well capable of giving the performance needed straight out of the box. Also, as others have mentioned, any such work will invalidate the warranty, and an EQ6-R isn't cheap.

I don't have that confidence that NINA will myself. Whilst things like Skywatchers protocol is well documented, writing the code to do the same task as EQMOD or GSServer does, it is quite time consuming and needs a lot of effort. Given the conversation I had with the devs yesterday over modifying the code for NINA to make the serial release option work when a canon camera is connected (which would be considerably less effort than adding telescope control or guiding functionality) I can't ever see NINA becoming this application myself.

Steve, to be fair none of us really knows any background to his state of affairs, and we can only speculate or comment on what we read or hear about from others, but you are right that this is all so, so sad. Especially as those lucky enough to have received their observatory from HOUK have certainly praised him for the quality of the product and the way the installation went. For the sake of replying to a few emails or taking a few hours a week to ring his customers to keep the in the loop he could have saved himself all this grief without a CCJ hanging over him... - So sad.

Part of the problem is that all the software mentioned has evolved over time. Initially APT and BYEOS were developed to control DSLR cameras (namely cannon as implied by BYEOS), and some of the more popular CCD cameras. Their primary function was the automation of taking repeated subs which could then be stacked and processed in some other application. Sharpcap came about primary for use with video cameras, or fast exposure CCDs and was primary aimed as luna and planetary work. EQMOD was used for telescope control, and then the original PHD was developed for guiding. Most of this software was either free, or less than £15 to purchase. There were other dedicated astronomy applications like MaximDL which already had a guiding option, and sort of merged a few of the other programs together so you to take all the subs and then process them in one application. But their cost was prohibitive for a lot of people at the time. Now we see the lines blurring... Sharpcap is venturing into sequencing long exposure subs, has a wonderful PA tool, and the list of cameras supported is covering all ends of the affordability scales. Likewise APT has developed and has a host of tools and wide range of cameras are supported. It even still supports serial shutter release of older Canon 400D and below cameras, something that I discovered NINA doesn't and after chatting with the developers on discord, never will. All these programs also integrate with each other through the ASCOM platform, so whilst you may still need to have PHD2 running, you don't need to open it to see how the guiding is going as NINA etc can display the graphs and guidance for you. The main thing here is that software wise we can find applications to gather and process the data in whatever imaging session we do, be that Luna, planetary or DSO, and most of that software is free or keenly priced. Which packages we use is down to personal preference. My workflow means that I hardly use the bulk of the functionality APT has. I don't use the focus aids as I use a mask on the scope and my eyes to check the pattern - which works. I simply use the main function of creating a sequence and letting it run (it can even shut the PC down after running the darks sequence which suits me). As mentioned APT works with my ancient but capable modified D400, so even though I do like NINA, I'm not prepared to replace my camera just so I can use that item of software. One day I'm sure someone will either develop a single applications that has all the functionality of current applications such as EQMOD/PHD2/CdC/APT etc, natively all rolled into one, or possibly at this rate NINA / APT / Sharpcap may evolve into that application. - who knows.

It's not sounding too good if he's ignoring the courts... and through efforts of various people he is probably aware of this (and previous) discussions so it's strange that he does appear on the face of it, burying his head in the sand, hoping it will all go away. Good luck Steve, and hope you get your deposit back soon

Oh I can understand that it might not be worth the time and effort for something that supports a small section of the community....But then the developers of GSServer and previously Chris of EQMOD updated their applications to suit the individual who wanted custom mount settings (Can't think who that might be 🤔 😉) and I bet that was a lot more work than making the existing serial trigger working with Canon cameras. I've done embedded coding, so know that somethings have a domino effect, but seeing that the functionality exists it could be as simple as adding a check box to instruct the software to use the same subroutine as the Nikon does.

Well I've had a response from the developers. Seems they never implemented support for the Canon Dxxx below a 450 (which uses USB anyway). So if you have a D400 or below and use a serial cable to control long exposures and want to use NINA then regretfully due to the time, and effort the developers of NINA would have to put in to making the function work they feel its is not warranted. Apparently this was only tested on Nikon cameras that required this method of control. The ironic thing is that both Nikon and Canon serial cable releases both use the RTS line as the trigger... So I'm at a loss as to why they claim it would need a lot of time and effort to resolve. In theory if the RTS goes high then the shutter is triggered. But then this error seems to be COM related - in that NINA is not actually communicating with the com port and still looking at the USB port and then getting its knickers in a twist as USB doesn't support 30+ seconds.... You can't fool the software into thinking its a Nikon camera, and removing the USB lead is treated as a disconnected camera... So its back to APT

@nephilim that's a nice image... I would be more than proud of that.... but throwing £400 at software on a dedicated hardware box is out of my budget, and I believe these boxes only support ZWO gear (?) so wouldn't work in my DSLR

I know that... that was the point... In essence what we have is individual scope control, guiding control, imaging sequencer, plate solver, etc etc applications all connected via ASCOM. For those with SW mounts EQMOD is often used as the scope "driver". If CdC is launched and connected to the scope, it (via ASCOM) launches EQMOD. Same goes in NINA, or APT. Click connect to the telescope and up pops EQMOD. What I was suggesting, was to have single application, that has all that functionality coded within. It's just a pipe dream as in order to cater for all the possible mounts, or cameras etc the code would be quite extensive. This is why people write ASCOM compliant code... so that it can call and receive data from other ASCOM applications that already do that functionality

I agree, APT (and I'm running an old version) does what I need. NINA seems a good application, and I found my way around the sections and application settings quite easy. But for me it just doesn't work with my camera, even though serial connections have been provided. What's needed is an application that has EQMOD built in, PHD2 built in, an imaging section like APT / BYEOS / MAXIM / PIXINSIGHT, and a planetarium option built in rather then having them as linked standalone applications. Or have them as services that run in the background, but configurable through the one application.

And the only support seems to be via discords and I've been waiting ages for a text to verify the account, despite trying it with the zeros and without...... Well I managed to get in by setting up an account on Discord and then pasting the invite in (Discord newbie !) once verified by email. Have posted the question and see what comes back. I can see why it fails as it works (and has done for 10 years) with APT....

Well I was bored whilst waiting for a video to upload to Youtube, so I downloaded NINA onto the Observatory PC and started to have a play, and ran into my first big problem. I image with a modified Canon D400, and it's nice to see that NINA has native support for this camera. So you would presume it knows about the connectivity and exposure quirks the 400D has. This is that for exposures of 30s or less it uses the USB for shutter control, for anything above it uses a serial shutter release cable. In the hardware set up I have set the option to use COM9 which is the port the shutter release cable is attached to, but if I try and take any exposures over 30s it pops up a warning to set the dial mode to bulb.... which it is as nothing has changed since it was last used with APT and APT works fine.... I've looked through the camera settings in NINA and can't find any other option or reference to mode settings.... So at the moment it's not looking like a glowing review when actually used in anger