discardedastro

7 minutes ago, Stuart1971 said:

I must admit I did consider running your way a while back, as I use a 4k 28” monitor and over VNC 4k is useless, so had to settle for just 2k..

But your way I could run the indoor RPI on 4k connected directly to my monitor, with Kstars / Ekos running,mand then the RPI on the mount just as INdI server….🤔🤔

I though about one of the new RPI 400 that’s built into its own keyboard, but they only do them with. 4gb of RAM and not 8…

To be fair the full stack uses nowhere near 4GB of RAM in my experience, even with reasonably high-res imaging (I'm using a 183MM-PRO and 174MM guider), so you'd do fine with a Pi400. I went for an Argon ONE case which has a neat USB-to-SATA bottom plate for a 500G SATA SSD which I use as a cache volume (there's a daily rsync job that shoves everything to the real filestore when nothing's busy, which is 30TB usable of ZFS RAIDZ3 in the garage in a big Supermicro JBOD).

Throwing a screen on at least so I can glance at it is something I've considered but I'm pretty tight on space - I think what I am going to do is pop it next to the TV so I can use a spare HDMI input there for monitoring at night. I find 1440p (which is what I use) works fine over VNC, but 4k would be a push; at that point the Pi will mostly be spending CPU cycles drawing KStars and encoding it!

19 minutes ago, Stuart1971 said:

Can I ask why you use another RPI in the house, and not your normal indoor PC, and then run Kstars / Ekos on that…?

I have an RPI on the mount and it runs it all, and I just VNC into it from a PC in the house….

The scope sits outside 24/7/365 under cover, but doesn't have permanent power, so by running KStars on the Pi indoors I have all the data accessible to transfer off to the NAS long after I've shut down the scope in the wee hours, and can hop on it at any point to fiddle with KStars etc on simulators and so on even if the scope's off.

I much prefer Linux for stability and updates for KStars versus Windows, and since it's all the same platform (Arch) I can keep INDI etc on both devices updated in version lockstep. I used to use a Linux laptop for the indoors portion but having a dedicated device made more sense to me because that laptop sometimes ended up doing other bits and pieces, and the Pi's much more energy-efficient.

I'd definitely +1 KStars/Ekos and the Raspberry Pi route - I've had a Pi4 on the 'scope for a long while now and it works great. Personally, because I prefer to run KStars on something that's "always on" and INDIserver on the scope itself I have a second RPi4 sat in the house which runs a remote desktop via VNC for KStars/Ekos, and the Pi4 on the scope just runs indiweb/indiserver on start. Apply power to the scope, start up KStars/Ekos, hit connect and I can be imaging in minutes - it works really well. I plate solve on the Pi without issue (and at 0.5"/px, so at the "difficult" end of plate solving!) and use PHD2 as the guiding software.  For the Pi on the scope I used a random metal project box from Maplin (RIP) with a bit of plastic offcut to provide a "platform" for the Pi and keep it off any metal (I covered the other surfaces in Kapton tape for good measure). The whole box has a velcro strip on the bottom to adhere to the scope's velcro hooks.

I also use PHD2 for drift alignment - I haven't used Ekos for PA but find that a Polemaster for rough alignment and PHD2 for precise drift alignment works really well (to the point that the biggest ongoing issue I have is actually the ground moving under the telescope - really must sort a pier!) and it's very easy to do.

By having the remote desktop Pi running KStars/Ekos I just VNC into that from either my desktop or a laptop or tablet and get the same "state" so I can view the same thing in alignment or imaging from either my laptop or desktop or even my phone which is great for keeping an eye on things but also makes for easy PA as I can take the laptop out if I have to do drift alignment which will take a while or just use my phone if I want to see if everything's OK sat on the sofa!

In practice with the Pi4 you can do this "all in one" these days rather than having two Pis, but either way they're great hardware and more than up to all of the most complex AP requirements.

The only thing I'd say on PA would be that if you need to do it quickly then a Polemaster is hard to beat for that "pretty good" alignment, assuming you have a modest laptop with you as a control surface. If you're setting up fresh every day it's a good route. If you're setting up once and leaving things in situ, then PHD2/KStars/Ekos is all you need.

Bought a scope in lockdown (my new 16" VX16 Dob) and am slowly adding to it now with a Nexus DSC, various black and green eyepieces, etc.

Rational? I mean it's for looking at stars etc, it's not wholly rational to spend lots of cash on this, but...

Now, there's all the other lockdown purchases - the modular synths, the fancy espresso machine, the alcohol - yeah, okay, none of this is rational... 😁

On 11/05/2021 at 17:23, Grant Fribbens said:

I have had my EQ6-R for a while and started to get issues like you had in PHD2 when I put on my GSO 8" RC. So I have decided to take a look and found that I could feel backlash in both RA and DEC so have tightened this as per the video which was done by Cuiv, The Lazy Geek. Then I also checked the status of the belts and sure enough found that using the hand controller on rate 2 had quite a lot of backlash on the RA belt similar to what this chap, Rosco Bird DEC backlash, had. So I adjusted the belt tension slightly (1/8th of a turn clockwise on the grub screw after loosening the stepper motor screws) and it has made it so much better. 

That's a great set of videos. Belt tension would make quite a bit of sense and I'll take a look at that for sure - it's about that time of year when I take the whole setup apart and inspect/clean/maintain it all anyway given we're now getting too bright to do anything much with DSOs! I've been doing alright in more recent times - I wonder how much those belts and the whole tensioning setup "walks" with temperature variation.

22 hours ago, Astro Waves said:

I hadn't thought about polar alignment helpers but now you mention it I might have a look into that. If it doesn't take much doing then I might see if I can find a tablet to run it on to save weight whilst having to cart everything around each time I need to shoot. 

If you do the guiding setup right it can also (as @Space Oddities said) act as a polar alignment aid. PHD2 has great tools in this regard - a static polar alignment tool which can get you there or thereabouts, and a drift alignment tool for getting the alt/az set just right. This will actually be more accurate than a Polemaster etc in general though if you're shooting reasonably wide fields you don't need to get that close for long exposures - but if you want to shoot narrowband, it'd definitely be the way to go.

Have you considered tools for polar alignment? Either iPolar if the SGP supports it or a Polemaster.

You should be able to get better exposure times out of the mount if properly aligned. Guiding won't help much if your PA is spot-on. PHD2 doesn't take much grunt so even a Raspberry Pi would do fine on that front if you wanted to go down that route.

I'd definitely focus on getting your subframes "good" in terms of duration and stability before considering filters. An Optolong/IDAS LP filter will certainly help somewhat in 7 skies but not as much as longer exposures will!

Hi all,

So I'm now the proud (and sore - it's heavy!) owner of an OOUK VX16 400mm Dobsonian, and am now learning how to use it and figuring out all the things I need to add on to make it really usable in my environment - but would appreciate some advice from other Dob owners!

I managed to get a first light tonight - lots of cloud about so it was a bit hit and miss but I managed to collimate fairly well and look at some bright stars. Defocused, tube currents were very, very obvious - I'd kept it outside in a shed for half the day but it was still clearly a bit warm (the back of the mirror measured 5c compared to 0c ground temp on infrared). After about an hour it was down to temperature, but I was struggling with eyepieces dewing up. About half an hour later to warm up the eyepieces, the finderscope was completely dewed over, and both the primary and secondary had a degree of dew on them. The ambient temperature was about 1-2c with humidity around 70-80% by the met office and 50% by my local sensors.

I also had some issues pointing the scope. I figure a RACI finder and/or Telrad would be worthwhile upgrades - the Explore Scientific RACI finder looks ideal - so will aim to upgrade those. The azimuth bearing seems very tight - it takes a lot of effort to get moving, so fine pointing adjustments are really hard. Thinking I may need to renew some bearing surfaces; I am using a few paving slabs as a base so it's got a fairly flat surface to rest on. Altitude I didn't quite get balanced right so need to shift that around a bit more and then can slacken the brake off.

I called it a night and put the scope back in the shed - while I can move it around fairly well on the sack truck I bought for it, I'm definitely going to get it a Telegizmos 365 cover so I can leave it set up in situ for longer periods. We're in a fairly damp area - low lying, 25m from a small stream - so suffer quite a bit from dew.

The mirror cell has a position for a 12V fan which I've now bought from OOUK, which I suspect will help quite a bit with both dewing of the primary and tube currents/cooldown - will fit this once it arrives and see if it helps.

I'm also thinking that as a beginner in observational astronomy (imaging for a few years now) a digital setting circle is going to help a lot with finding my way around and building up confidence - is the Nexus DSC still the way to go?

Do I need to consider dew heaters for either the eyepiece/tube, or secondary or primary? What else should I consider for dew control?

Any tips on things to consider with finderscopes?

Any other hints and tips for practical accessories for larger Dobs?

Lots of questions - grateful for any advice!

5 hours ago, old_eyes said:

We just need a supercomputer each  - that's all!

Fugaku 415 PetaFlops

When I was a young academic, the CDC Cyber 205 could do an amazing 400MFlops. The Intel i3 over 300 GFlops, nearly 1000 times as fast. Ain't progress great?

http://www.computinghistory.org.uk/userdata/images/large/51/91/product-105191.jpg

It really is 🙂 I came in at the start of the Pentium era, though had a fair bit of time on Amstrad and friends prior, but no coding. i386 was my first chip - we've come a long way!

If shipping all the image data around wasn't so prohibitive for most people I think there'd be a huge case for a render-farm style service for PixInsight and others; it's bursty, not something all users do all at once, so quite well suited to workload sharing. I did toy with the idea of using an AWS virtual desktop instance for PI (pay by the hour when you need it), but since I did my last PC upgrade I've not needed to consider it. And that's only because I've got a 1Gbps upstream from home, so pushing all the data to the cloud isn't a big deal - easily done in a few minutes for most jobs. Different story for typical rural/semirural ADSL/VDSL/DOCSIS!

1 minute ago, old_eyes said:

It's a mix. Calibration and stacking you can leave to computer to get on with it. Noise reduction, even on mono images, is quite time consuming. Building and processing the LRGB image is variable. Some processes are quick, histogram and curves transformation, others take quite some time. With PI it makes the use of Previews to test out what you are going to do very attractive! 'Playing' with the data is a lot harder for big files, and that is the way we seem to be going.

True. The latest PI release with the quick subframe previewing has helped a lot in my workflow for that sort of thing, particularly noise reduction - but things like TGVDenoise, MureDenoise, and Deconvolution are still very processor intensive with poor previewability (and in the case of deconv particularly a lot of trial and error required on most images).

Just now, Commanderfish said:

That hand truck is way cooler than mine!! Looks.like it's extendable too?

It's actually not quite as good - the platform doesn't extend far enough to fully support the base! It's a 3-in-one so you can lie it down and use it as a platform, and it has some other weird configurations I've not played with yet. 16" is quite a lot to lug around as one person, especially in a very non-flat garden, but I managed to set up a base for it with some spare paving stones and park it in the shed without dropping anything - I think a Telegizmos 365 cover is in this scope's future so it can sit out most of the time.

28 minutes ago, Neil27 said:

I was the postman today, collected from a fellow astronomer. Part 2/4 of my imaging rig.

May I present my beautiful looking Esprit 150, and it definitely is love at first sight!

Included is the flattener, lakeside focuser, dew heater, flats panel. Aside from a little dust on the front lense it’s perfect.

That's an absolute beauty. Congratulations - that imaging rig is going to be very sorted!

1 minute ago, Dazzyt66 said:

I'm pretty sure that is the case from watching a couple of tutorials. It doesn't matter to me really as VNC is plenty quick enough even over the wifi - I only want to plate-solve and then start imaging - its not like I'm stacking live or anything - so once the captures are underway I can just leave it going. Its easy enough the next day to move the captures over through wifi even if it does take a bit longer than wired. Suits me fine and I'm loving it all! 😀

Yep - I normally just have KStars sat on the graph view so I can keep an eye on things. Once I've finished writing this Rust INDI lib I'm hacking away at (or give up and fix some of the pure-Python ones) I do want to hook up a watchdog program that can alert me if imaging or the mount stops - I've had one too many kstars crashes on overnight imaging sessions!

FWIW, I'd consider myself PixInsight competent/familiar and WBPP confused the hell out of me - it relies on a lot of stuff in filenames etc which is pretty unobvious and the documentation isn't great! I'd strongly recommend starting out with the Inside PixInsight book and/or doing manual processing to get started. It'll be slower and less straightforward but it's a much easier way to learn the software than running straight into WBPP, in my view.

Just now, Dazzyt66 said:

Yeah, I'm not sure why I'm having a problem, but it occurred to me that even if I save it only on the rpi the FITS image viewer is still gonna get the feed over the connection - which in my case is wifi - so I think having Kstars on the laptop is not going to make any difference (in fact its probably slower) than just using VNC...

Quite likely, yep. For what it's worth I use KStars on a Pi remotely via VNC and it's plenty quick enough in my experience (I actually run VNC'd into a Pi4 sat in the house which is running KStars, with INDI running on another Pi4 which is strapped to the back of the telescope). This is with everything wired through a good 1Gbps network, though!

1 hour ago, old_eyes said:

I am also using some data from an ASI 6200MM full-frame camera at a remote observatory and those 9576 x 6388 frames are beasts! Start working on a mosaic and you need plenty of coffee breaks.

Yeah, excellent point - full frame I would argue demands a pretty high-end PC, realistically. Technically so long as you've got a reasonable amount of RAM you can get away with a lot, but practically it's really painful. I've got some images off a Nikon Z6 which is 6048x4024 natively and I think if I were doing an awful lot of that, I'd be looking at something Threadripper based with 64G or more RAM, especially for mosaics! The ASI183MM I'm using today is reasonably high resolution but since it's monochrome the resulting files aren't huge, and once you've got an LRGB master set the processing is generally quick stuff anyway. OSC is a different beast altogether.

6 minutes ago, Dazzyt66 said:

Indeed! I am finding it quite easy to use! I easily use Kstars/Ekos using the built in VNC 'Reminna' or via firefox no probs, so its all good there. And its really fast!

I am struggling to get kstars to work 'locally' on the laptop but with  indi/ekos remotely on the RPI (astroberry) - I can get them to work the mount and navigate fine (so I must've set it up OK), but I want to just capture images only on the rpi  for speed (and then move them later for processing), but for some reason I'm struggling with this - it always wants to find a folder on the laptop not the rpi and wont let me direct to a folder on the rpi - so I guess I'll need to do some youtubing over the next day or so. 👍

You should be able to set this up on the imaging sequence by selecting upload to remote only and inputting the path there or in the camera settings under the Options tab, at least on recent-ish KStars. If you've got a reasonably fast (wired) network then you'll likely find it doesn't win you that much performance - I think KStars will still pull the image down from the remote end in order to show it and do any analysis (e.g. HFR for automatic focus triggers), so saving it locally isn't a big overhead.

1 hour ago, JeremyS said:

Looks brilliant. You’ve got a great scope there.

Sorry, I have to ask: what’s with the bats and the BBC Club sign? 🤔

The bats are decorative (we've got pipistrelles living in the outside of the house, so thematically accurate) and the BBC Club sign was rescued from Television Centre before it closed for good 🙂

Definitely looking forward to first light - which looks like it might be this evening, if I'm lucky!

Alright, so the postman didn't bring this, I had to go get it myself - but still worth a post I think!

OOUK VX16 from @Commanderfish now being checked over, tweaked, and roughly collimated after a 2h drive up. Bit of play in the focuser to sort and the mirror cell wants a fan fitting, but otherwise good to go and a superb "little" scope I'm looking forward to trying out!

If you're on Uist then some friends up the north end of things have good internet - up on Berneray. BT did FTTC to the islands as part of their government-funded builds (though failed to actually connect it up till a few competitors started pointing out they hadn't actually delivered anything to people), but there's also a lot of fixed wireless stuff back to the mainland which is pretty quick!

http://sealview.com/gettinghere.html

Last time I was up there I wasn't really doing astro stuff, but knowing how populous it is (my friend had to go to Lewis to do their driving test because it's the only island with a roundabout) I can believe it's superb! Enjoy while you're there!

5 minutes ago, iapa said:

I have the Logitech Circle cameras - powered of USB and wireless.

Not particularly cheap - but what is?

Do they work well in darkness without IR?

I've got a fair few Reolinks and they're practically useless with their IR switched off, even if the manual exposure is maxed out.

19 minutes ago, catburglar said:

Thanks for the suggestion.

I don't need the GPS, but I can't seem to disable gpsd....if I run 'sudo systemctl stop gpsd.service && sudo systemctl disable gpsd.service' EKOS connects and everything works OK, but after a reboot of the pi I have to do the same thing again- I thought that if I disable gpsd.service it wouldn't come back up after the reboot....

I'd like to find a way to tell gpsd to ignore /dev/ttyUSB0 - but I can't find a way to do that easily. The only thing I can think of would be to build gpsd from source, but leave out the support for the usb-serial chip (cp210x) that's in cable....but that seems a bit extreme....so I guess I'll just ssh onto the pi and disable it each time I run.

It's not a massive issue, but it's a bit irritating and I can't seem to find a good way to fix it.

 

Try this: sudo systemctl disable gpsd.sock

To explain a little more - both gpsd.service and gpsd.sock are things provided by gpsd to systemd, which will ensure that all the dependencies for the service/socket are met. That includes, if you just disable the service, bringing it back to ensure the socket is available.

If it's still booting up then try systemctl list-dependencies --reverse gpsd.service - this will tell you what is dependent on it and bringing it up.

1 minute ago, old_eyes said:

I think I am getting the leakage from behind the Atik, when the camera is pointing directly at the security cam. I don't think an IR Cut filter would help.

But as you say. The way forwards seems to be no IR,

Ah, around the focuser?

I did consider that I had some light leakage from a nearby light and packed the gap between tube and focuser base (as mine had some gaps) with Sugru, and the opposing side of the tube is flocked, so maybe that's helping minimise ingress.

Seeing your image there I'm now realising that I'm probably actually seeing the same thing in my imaging. I'd noticed in some geometries - generally lower altitudes - I was picking up a bar across the image. Nowhere near as severe as that, though - it was only when I stacked things I picked it up, and I was able to generally correct it with some careful background correction, but the same basic artifact. I've only had it rarely and it wasn't the end of the world so I hadn't dug into it properly.

I am using an IR cut filter (mostly just to have a parfocal filter with my RGB) as my L, so all of the filters I'm using are in some way filtering IR, which may explain the reduced intensity.

I've been toying with the idea of something like the ASI120MM mounted side-on in a box with a Raspberry Pi, though I think these days the Pi high quality camera can also take long exposures and take a variety of fast C-mount lenses. Dropping IR entirely would seem the best approach.

Edit: Interesting, I can't post to this with some content...

I don't suppose the LX200 will be returning GPS data in a format that gpsd can take advantage of anyway, so I'd disable it.

If you want a GPS, then USB GPS devices that work with Linux can be had for <£20 on eBay or even Amazon et al. gpsd can be forced to look at a specific serial port and not autodetect with a startup parameter, normally configured in etc default gpsd. Otherwise systemctl disable gpsd would do the trick, so long as you've got an internet connection for time.

For good time sync, gpsd can do basic clock control but you're much better off configuring ntpd or chrony to treat gpsd as a clock source as they'll do a much better job of regulating your clock. If you get a board-level GPS module or hat you can also configure chrony or ntpd to use the pulse-per-second input from a GPS module to properly discipline the clock, making your Pi a "stratum 1" reference with very good stability for very little money!
https://thepihut.com/products/raspberry-pi-gps-hat

This is probably the easiest solution to achieve that - it's a GPS module hat to drop onto a Pi, but also has an RTC, all the wiring needed for the PPS pin already done, and an external antenna port. The RTC means that even without a GPS fix or internet the Pi can get reasonably-close time quickly.

Edit: OK, so the forums for some reason block paths like etc default gpsd.conf if you have / in them. Guessing some very overzealous web application firewall...

Yes: https://astronomy.tools/calculators/magnification

However in practice sensible maximums are going to depend a lot on what you're observing!