BCN_Sean

Until I started with imaging, I didn't believe there was a direct correlation between hardware and weather, and as kit started to be delivered it was spring so it was cloud season. Chalked it off to coincidence, until the day I organised to borrow an SV305 (which I'm finding is quite a nice camera for the money, now I've got the quirks ironed out) and the village got hit by a tornado. Just don't organise a quick get-away to north eastern Spain for the next few weeks, as it will be cloudy and lashing it down as I've just paid for the aforementioned camera.

Plate solving can be done with some success, hardest part is the declination because of the lack of powered adjustment there; using a tool like this to set it manually to target will get somewhere near but would need the accuracy latitude in plate solving being quite wide (mine is set to 1200 arcsec or 1/3rd a degree) as the adjustment isn't that precise on the DEC rotator (https://www.astropills.com/blog/declination-setting-circle). A Star Adventurer 2i connected as an EQMod mount (don't know about the earlier versions) will slew on to target after solving, though with not as tight an accuracy, as mentioned above. The way I do it on mine with it being coupled to a Raspberry Pi (primarily for guiding), is look up the coordinates of where I'm looking, set the DEC, and then manually input the coordinates in to kstars to initially fix a rough starting point, then capture, solve and sync through EKOS, then back to the manual input but this time issuing a slew command. It's doable, but as the mount isn't really thought for things like this it does have some quirks compared to a complete EQ mount, and depending on which way around it's implemented can reduce the thing that makes the SA a fun tool, the portability. Learn how to go about it manually first, then if you feel you need add more frustration to the SA, look in to a plate solving system.

Just realised where we've met before in another place! If the bluetooth adaptor is working, then I'd probably be thinking more that it's a cable issue than a mount issue; there is something in the handset, called PC-Direct mode but it's only what I've gleaned off the manual not anything else. The other thing, have you tried directly connecting the mount via USB and going through checking the connection with different baud rates? Some of the skywatcher stuff (I know the SA has, connects on 115200) has something like eqdirect built in to it and recognises without using the cable.

I've seen it fail as well for the fact of MS Office, and not for power usage; admittedly I've not found anything better than Excel on Windows for certain things that most people wouldn't do normally, and because of the wife being a business admin it's why we keep a Windows box at home. The reason for it failing, though, is brand mentality where an end user thinks they are being short changed or devalued by an employer if there isn't a paid product on a machine; but it doesn't matter if it's a pirate version, as long as it's something the employer should have to pay for. A couple of places around where I am have had union action because they've switched, and usually it's not to cheap out, but the employees got in a mood about it and the companies have quietly switched back as it's cheaper than solving staff problems.

To someone who has knowledge in building things it does seem quite costly, but to an ordinary person maybe not. It's something I have to remind folk when they come to me for things that it's not the materials that cost what they are paying is the price of experience.

Can't really add much more to it than that the biggest investment in this isn't money, it's time. I got in to it with a Star Adventurer (2i model) which is a very nice little drive system, especially if explored in depth as there are some tricks it's got that aren't really documented, as well as a sturdy tripod and an optic around the 200 - 300mm length. Thing is, though, for every hour I spend imaging with it, I probably spend three or four doing something that isn't directly imaging (waving my fist at clouds, tuning, staring at the whole ensemble sucking air over my teeth wondering where to route cables, building bits, trawling around here and learning things) and still it's taken me a good few months with it to get everything down enough to make an image that I'm actually satisfied with but still a bit nervous to put up here to let experience over it. It really isn't a quick hobby, and there's not really a route to instant gratification with it, but if you like the slow burn, the learning and little victories when things come together it's a hell of a lot of fun.

I think that comes from the old fallacy of "Linux can make an old computer run like new", where it was more the nuking of ten years of grot on a boot drive when the file system changed that created the illusion. Whilst I don't think it'll be on everyone's desks in the future, even though now it's in a lot of people's hands, the stuff that can be pulled out of Linux now especially in the areas of machine learning, also with old Linus taking a step back from the day to day goings on and going to work on his anger management issues and (whilst it's probably not relevant to folk like us that much) more games developers working targeting Linux then things might just start getting interesting!

That's a beautiful project, something that I'll keep in mind as occasionally unpowered eq3-2's and the equivalent pop up around here for not a lot! If the mount has the capability to trigger the camera, then it's possible to leverage that instead of using something like a dusb; it does mean another connection between the camera/mount/controller though and writing a bit of script to read a virtual serial port. It's something I've been thinking of doing, picking up an old D7000 and using that as an imager. Here's a link to the indilib post where it's being described https://www.indilib.org/forum/ccds-dslrs/8485-setting-snap-port-as-external-shutter-in-indi/65152.html

Not planning going Windows -> Linux, but when the current pair of Mac don't do the business any more, then seriously thinking about using Linux as my main OS. Now-a-days, Linux is pretty good and software wise there's plenty to go from and if installed on a decent box it's rather painless; yet on the latter most people first encounter it on an out of date crate or on something like a Pi where it's a bit crippled down because of hardware and the out of the box OS not being able to take full advantage of the hardware it's on. My next project on the list is to try and build the at mount applications on a 64bit OS (already looked at the Raspbian 64bit beta but still too buggy) as I'm sure that most of the issues that I see now on my rig are down to the memory access limits on a 32bit system.

One thing I'm surprised hasn't popped up more in this thread, the cameras. I've had an SV305 for a week to test out so probably not experienced enough with it to drop a full conclusion, and it's a tasty camera for the money as it can be bought for less than the price of a zwo 120 mini-C but with a more modern sensor package (as well as memory buffers), the pro version a bit more (and apparently there's a mono version coming down the line), but as of yet I'd be sceptical recommending it on someone else's coin outright as the SDK is quite young, it's not compatible with Macs (don't know if there's going to be a future implementation that is) and the driver package is quite immature and sometimes things get broken (the current dev version of PHD2 is one). It seems to perform well enough once the niggles have been worked through, but as the moon has been getting in the way of things I've not had chance to give it a full work out. If this is their first "proper" astro-cam, as opposed to digital eye-pieces, whilst it's still green and young it does show a promise to what they are potentially capable of dropping in the next few years.

To be honest, I don't know if just using a simple splitter cable would work safely without risking damage to one or both the cameras as it doesn't offer any form of separation between the two cameras. On the first webpage which @iapa has linked, there's a section about half way down mentioning about triggering multiple cameras at once and there's a diagramme with diode protection on there, the switch side of it is already in the SA. If you know a bit about soldering things together, or have a mate who's handy with electronics, a splitter with the diodes would be pocket change to make and offer peace of mind against damaging a fairly expensive bit of hardware.

Make sure you've got the correct dependencies installed or up to date and in the correct places; it's looking for something that isn't there.

I've a few bits, and for the price paid I can't find fault.

No, not much of one; I'm on a bug hunt at the moment. I was noticing some odd behaviour in a couple of the 1.9.0 indi-3rdparty drivers/3.5.3, like west slewing in the eqmod not responding and sidereal tracking kicking in when using the drift align, and also a couple of others not releasing and resetting when Indi is restarted after Ekos crashed; and then also under certain conditions the internal solver causing a memory segmentation error. Having two different builds does make it a bit easier to decide if it's something in the builds themselves or something underlying on the system if it only occurs on one install or both.

Just said a few choice words, as spent the day off yesterday building the whole lot from source!

If using a Pi4 for this, ignore the SD card completely as the main system drive; buy a decent USB 3 thumb drive, set the Pi so it's going to boot off it and use that instead. The biggest bottleneck I've found with these things is the time it takes to pull the image down from the camera on to the Pi if it's having to buffer it to the Pi's SD card, also boot times are a lot quicker and the system is a lot more responsive as well. With testing my setup with it, using a USB drive over the best SD card I have, the image actions are significantly quicker especially if the camera is connected to the USB 3 ports; I've not timed it fully but it's in the order of tens of seconds. The other thing with it, is using solving using the local astap seems to make a better job than the inbuilt EKOS solver and as the DB is already in place, there's not the need to download the extra database files.

There's only a couple of other things I could throw in to the mix here, the first being to remember to turn the camera off before swapping the battery (I don't know about Canon but the memory on a Nikon only saves data on a clean shutdown). The other is if using any control system for the camera, like an indi driver or other software, is to make sure that it's not writing it's own values to the camera at connect time. Best thing to do, though is to use RAW, not worry too much about on camera white balance and fix it post capture.

There's an oddness with the USB ports on this model, the ports on one side are slower than the ports on the other; the ones to the right of the machine are not as quick as the ones on the left, and also the adapter if it's a similar age to the machine has some oddness with it as well if it's the Apple one. Putting in a decent adapter on the left side ports should make some difference, but how much I can't say.

One thing you've got to watch with the latitude knob, though and this caught me out a time or two is that it can slop if it's adjusted in to the weight on top instead of out of. So with mine what I try and do is to push it up over ~42º (which is my latitude) to about 45 - 50º and then bring it back down so the weight is pushing against the worm gear. And a third one, on the little adjuster itself, there's a little grub screw and sometimes that will work loose and that can make you think you're adjusting but it's just slipping on the shaft until it bites the other side of the detent (and a pain to find if it jiggles loose and drops out at night) but a drop of loctite will deal with that one.

You have read correctly about the washer; if you feel you need to do it first off undo the handle and the bolt should just slide out. In the sides there should be two washers, one thick and one that's about the same as a bit of cling wrap. Find a bit of single use plastic (the transparent stuff which most things are packaged in is about the right thickness), cut a new washer out and replace the thin washer with that. As for the dec knob, it will still adjust even if the clutch is tight, but with a lot more resistance, so less slop and better precision.

Just to have a look at PSS, I spent some time installing it earlier, and whilst there's an installer in the binary package from GitHub, there's something awry with it; and installing it from the repo is dependency hell. Best way after a few attempts was to install it in it's own virtual environment and run it from there; so here's the commands for it (PythonEnvs in this is where I keep my Python Virtual Environments), if you've got virtual environments in a different location, change the path accordingly. mkdir -p ~/PythonEnvs/PSS python3 -m venv ~/PythonEnvs/PSS source ~/PythonEnvs/PSS/bin/activate pip3 install --update pip pip3 install numpy pip3 install scipy pip3 install psutil pip3 install planetary-system-stacker One per line in the terminal, and it will take some time to complete. And to run : source ~/PythonEnvs/PSS/bin/activate && PlanetarySystemStacker Whilst I was reading up on Planetary System Stacker earlier, I found out the author of the planetary stacking part of SiriL and PSS are the same guy and a lot of what he did for the latter found it's way in to the former.

I was going to suggest some of them that are on the list which @rpineau linked, though there's a lot more on there than I knew about! SiriL is the main one I use off that list, bit of a steep learning curve but very good.

I can quite regularly be found building bits and pieces for a lot of things, whether mechanical, electronic or code based as whilst a lot of this kit can be bought or bought kit modified to fit an end point, a lot of it really seems expensive to what it actually is; well it actually isn't when accounting for experience or time put in to developing it, but if it can be built then it's more satisfying (to me, anyway) than a brown box arriving on the door step. In astro, I've built a barn door with compensation on it, af units for the rig (though they're going to be miniturised now and running a WiFi hub on one of them, which I found possible by accident rather than design), and the next project is an automated dew heater control for USB powered bands... And then, I don't know as there's a lot of scribbles on the note pad and I don't know how long cloud season is going to last!

I've really been enjoying this thread so far, really nice little idea resource if ever something like this pops up on my workbench; and very heartening to read about systems being brought back to life rather than being binned especially when everything now seems to be so geared to disposable.