gilesco

The software I use has an RGB combine tool, and provides a number of preset combinations to try. I generally try many of them, and then make some minor manual adjustments to try to pull some detail out, without bringing out too many aberrations.

Asi 1600mm pro with 8 slots filter wheel, LRGBHaOIISIII, 2 x 10 180s frames each filter across 2 sessions. I blog my progress https://www.coochey.net

Had a couple of goes at the Soul Nebula, wish I had the money for an apo... this were taken with a 120mm f/5 achromatic refractor, still a work in progress, need to add to the mosaic, but too tired to set up this evening.

I think you might just need to be sure that it is a Null Modem or Null Modem with Handshake cable. https://www.decisivetactics.com/support/view?article=crossover-or-null-modem-vs-straight-through-serial-cable But, wait for someone else to confirm, pretty sure a straight through cable won't work.

I was not trying to hijack the thread, but as I have no experience with DSS, I thought I would give my experience of how this is done with a different, but similar piece of software, from other posts, it appears the same nomenclature and processes apply, so it is still relevant.

Last Sunday, on a rare clear night, but had been wet during the day so was setting up in the dark, once it had dried up a bit. Anyhow - Guiding was giving me lots of issues, I thought I had good PA, but everything was going haywire, so I halted taking subs and turned the lights on, to my astonishment I discovered the counter-weight just lying in the conservatory - I had not balanced the scope on the mount at all. After further inspection of the mount I also noticed that the filter-wheel was jarring against the azimuth knobs on the mount - my target was near the zenith. I did try to continue, but I my scope must have lost its alignment during rectification, and subsequent exposures just went off alignment, still managed to stack with registration, and I did get an image out of the night, not too impressed though. Can't stress enough to have a runbook for set up and take down, and keep it updated as you learn... I put mine online

APP has multi-session mode, which means you assign Darks, Darkflats, Bias and Lights to each session. Sessions could mean the same telescope / equipment at different times, or equally different telescopes and equipment at either the same time or at different times.

APP (Astro Pixel Processor) does this using a process called registration as part of the workflow, the pictures do not have to be aligned, they just have to share features across frames, you can use APP in this way to create large mosaic images of sections of the sky. As long as you have the targets in view it will improve the detail of your targets. APP can also take data from different cameras and telescopes and do the same thing.

There's a good YouTube presentation out there, by the author of SharpCap, which goes in depth as to where long exposures are not necessarily the best way to go. And with increasing satellite trails a concern, 60s but many of them with low noise images seems to be a good option for Bortle 4+ skies. If that is your second attempt then you must be a natural at this, please tell the rest of us that it wasn't plain sailing, excellent image imho - doesnt appear to have any aesthetic modification, yet intriguing detail.

I just realised I had bought a book "The Deep Sky Imaging Primer" and it goes into PixInsight a lot. It seems to me that it differs from APP in that you make a lot of aesthetic decisions during processing. APP pretty much has a set workflow for your stack of pictures, you can fiddle with which algorithms and parameters for those algorithms to use, but a lot of the actual work is simply done by the maths, and the developer is really concentrating on making most decisions automatic. Anyhow, both have free trials, APP tend to give out 15% vouchers if you find them at exhibitions etc... Obviously would highly recommend a try before you buy, because if anyone is expecting GIMP like tools when they purchase, or rent, APP then they will be dissapointed.

Took a look at this as you mentioned it, cant find pricing information on the website, then on looking for it I seem to enter into having to agree to a no refund policy - dont think that is compatible with my nation's laws, would think about APP really- more in line and centric with EU/UK law, PixInsight seems a bit US like, buy it, get no help, useless.

Do the stars flare up like that in your original frames? I never see that with mine. Dont mind artistic license - just looks like a movie still, not an astrophotography photo / composite. Sorry if some optics actually make this happen, I'm new.

If you do go for the perspex, maybe get two, they are dirt cheap (you might pay more to get them delivered), and just reducing and randomly diffracting the light a bit more might make it even better. I do get good flats from this though, although I'm messing around with different gain settings so much at the moment that I didn't take flats/darks/bias frames last night (partly due to the frustration of the wheel hitting the mount, and other issues).

Snap!

I use APP, can recommend it! I use a LED pad too, when it arrived I found it was not really even field, so I also ordered some frosted perspex and taped it on infront. LED pad: https://www.amazon.co.uk/gp/product/B07YXNXV2N/ref=ppx_yo_dt_b_asin_title_o02_s00?ie=UTF8&psc=1 Perspex: https://www.amazon.co.uk/gp/product/B00WVF4HU6/ref=ppx_yo_dt_b_asin_title_o05_s00?ie=UTF8&psc=1 The list is always endless, I have maybe 10-15 items in my wishlist, and not the money to buy it yet without going seriously and irresponsibly in debt.

Heh, well we were both looking at the same target at the same time, the problems... I had loads of problems (other than the fact I'm using an achromatic scope) - in the UK, at least, this target is very close to the zenith, which meant my filter wheel collided with the mount (something to remember in the future), this sent tracking / guiding haywire and took me a while to sort out, there were other issues too, which I won't go into (always learning).

I'm at 50.42 latitude, so already exhausted the going south within the UK idea!!

I was wondering whether people travel south during the summer months and take their Astro gear with them so as to get more Astronomical twilight (and perhaps less cold viewing). I have searched online for possible holidays on the Spanish mainland and see that some places seem to cater for some sort of Astronomy, but a lot of it looks like structured classes / tutorials, rather than catering for someone turning up with a telescope and expecting to set up somewhere near the accomodation. Not wanting to fly, we would probably look at taking a car ferry if we did this, with the Astro gear in the boot of the car. Anyone have experiences like this to share? Good idea, bad idea? comments welcome!

Didn't see FLO, but did see Ikarus Imaging on the list.

I don't have a github account, wish there was a way to do this anonymously, I'd rather not subscribe to yet another online account, with yet another password, but all I've done from the 2.0.0 image build is the following: sudo systemctl disable dhcpcd Let me show you the issue I had with these command excerpts: #First let's look at the routing table with the default astroberry setup: root@indi:/home/astroberry# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 0.0.0.0 0.0.0.0 U 303 0 0 wlan0 169.254.0.0 0.0.0.0 255.255.0.0 U 303 0 0 wlan0 172.21.1.0 0.0.0.0 255.255.255.0 U 600 0 0 wlan0 #For some reason the gateway has been set to 0.0.0.0 #Checking the IP address for wlan0, shows it got the IP from DHCP root@indi:/home/astroberry# ifconfig wlan0 wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.21.1.71 netmask 255.255.255.0 broadcast 172.21.1.255 ... So disable the DHCPCD daemon: root@indi:/home/astroberry# systemctl disable dhcpcd Synchronizing state of dhcpcd.service with SysV service script with /lib/systemd/systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install disable dhcpcd Removed /etc/systemd/system/multi-user.target.wants/dhcpcd.service. Removed /etc/systemd/system/dhcpcd5.service. It is still running (but won't be after a reboot), note the highlighted debug in the status: root@indi:/home/astroberry# systemctl status dhcpcd * dhcpcd.service - dhcpcd on all interfaces Loaded: loaded (/lib/systemd/system/dhcpcd.service; disabled; vendor preset: enabled) Active: active (running) since Sat 2020-01-18 15:49:01 GMT; 1min 47s ago Main PID: 419 (dhcpcd) Tasks: 1 (limit: 4915) Memory: 2.3M CGroup: /system.slice/dhcpcd.service `-419 /sbin/dhcpcd -q -b Jan 18 15:49:11 indi dhcpcd[419]: wlan0: soliciting an IPv6 router Jan 18 15:49:12 indi dhcpcd[419]: wlan0: soliciting a DHCP lease Jan 18 15:49:12 indi dhcpcd[419]: wlan0: offered 172.21.1.71 from 172.21.2.253 Jan 18 15:49:12 indi dhcpcd[419]: wlan0: ignoring offer of 172.21.1.71 from 172.21.2.253 Jan 18 15:49:17 indi dhcpcd[419]: wlan0: probing for an IPv4LL address Jan 18 15:49:23 indi dhcpcd[419]: wlan0: using IPv4LL address 169.254.46.130 Jan 18 15:49:23 indi dhcpcd[419]: wlan0: adding route to 169.254.0.0/16 Jan 18 15:49:23 indi dhcpcd[419]: wlan0: adding default route Jan 18 15:49:23 indi dhcpcd[419]: wlan0: pid 419 deleted default route Jan 18 15:49:25 indi dhcpcd[419]: wlan0: no IPv6 Routers available So, let's stop dhcpcd: root@indi:/home/astroberry# systemctl stop dhcpcd Now restart network manager: root@indi:/home/astroberry# systemctl restart NetworkManager root@indi:/home/astroberry# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 172.21.1.1 0.0.0.0 UG 600 0 0 wlan0 172.21.1.0 0.0.0.0 255.255.255.0 U 600 0 0 wlan0 I get the correct gateway from DHCP which is managed by NetworkManager.

My problem is resolved, I disabled the dhcpcd daemon, and leave Network Manager to spawn it's own instance of dhcpcd. Giles (CCNP, CCNA Security, CCNA, CCENT)

I know it is a different Linux distro, and not Raspbian, but this link explains the problem better than I can with respect to Network Manager and dhcpcd: https://bbs.archlinux.org/viewtopic.php?id=170813 Astroberry is running both dhcpcd as a service in addition to Network Manager (which spawns its own dhcpcd when you decide to set up a connection as "Automatic") This causes a conflict, you may not notice it because you are on a single subnet network, whereas I have multiple subnets on my network and need the default gateway to operate.

I've just loaded the image onto a Raspberry Pi4, things by and large seem to work, but I used NetworkManager to connect to my own Wireless Network. Something interesting is that while I obtained an IP address from my DHCP server, my default gateway was set to 0.0.0.0 and not the IP address of the gateway (which the DHCP server serves to the clients on this subnet), so network connectivity seemed pretty patchy - I could connect to resources on same subnet from Astroberry, and remote systems on remote subnets can initiate connections to the Astroberry, but the Astroberry itself couldn't connect to the Internet, or other subnets on my network. Turns out that in addition to NetworkManager, dhcpcd is also running as a standalone daemon. So I disabled that (sudo systemctl disable dhcpcd), I still get my IP address via DHCP (through Network Manager), but now the gateway is stable and correct in the configuration (confirmed with route -n). So my advice is if you don't want to use the VAP, remove all that config, and either use the legacy /etc/network/interfaces config and disable NetworkManager, or disable dhcpcd and just use NetworkManager.