pete_81

Hello all, Rather than blocking up (and losing the thread) in the "imaging with 130PDS", or starting the same topic again, thought I'd post here. Going around in circles with what CCs are ideally suited to the 130PDS for both visual and imaging, with the primary aim of improving my images (with APS-C DSLR). From searching around, there are several possible choices of CCs for the 130PDS, each having pros and cons: TV Paracorr ES HR CC TS GPU SW Aplanatic f/4 Sharpstars (selection of different ones around) SW 2" SW 0.9x CC (I think this is differerent to the one above, where there is no change to the focal length) Baader MPCC III GSO Coma Corrector The paracorr is out of the price range! The ES is likely best suited to visual, and there's not much on using it for imaging. Also expensive to others that mean others better suited. The TS GPU both in this thread and the 130PDS imaging one, finds itself at the top of quality ladder (and likely top of budget!) I think the SW Aplanatic is essentially the same as the TS (same optical prescription), and the sharpstars seem to fall into this too? The SW 2" seems to do a decent job overall, but seems like folks tend to go for the f/4 version? The Baader seems to get lots of negativity when it comes to misalignment of any sort The GSO sounds like quite a nice CC, quietly sitting in the background, but cheapest of the bunch. From what I've read on reviews and here, there's the requirement to chop the focuser to avoid the pacman effect on stars, on pretty much all the CCs except the GSO. I think I'm being directed towards the GPU (or SW aplanatic) or GSO. Earlier in this topic, @alacant did tests on some of these and found the GPU (SW f/4) the best optically, with the GSO coming close behind... For half the price, the GSO did a very good job correcting coma optically, but at expenses of increasing focal length (+10%) and extra back-focus required, so balancing becomes harder/may induce extra tilt to stock focuser. Now, the extra back focus (quoted as 75mm rather than ~55mm) may be attractive - I am thinking about the ZWO filter drawer, which could be used in the GSO setup as follows: 130PDS + M54 Compression adapter + GSO (uses M48 thread, which would connect directly to) + M48/M42 Filter Drawer (21mm thick) + T-Ring (11mm thick) + Canon (44mm to sensor), so I'd get 76mm back focus, which is very close to the 75mm GSO (and other reviews) recommended. I can take or leave the filter-drawer, leaving it out with any setup is fine, but the GSO would need extra spacers to get the working distance correct (I think?) Using the standard T-Ring is possibly too thick (11mm) for some of the correctors that say 55mm back focus, but actually perform better at ~53mm (other links within this thread direct to this), so a thin (1mm) profile T-Ring and ~8mm spacers are reportedly the way to go... So, looking for further thoughts on the GSO and GPU in use before Christmas 2023! Thanks!

Follow up with bug report after simulator crashes: Github And more responses from the follow up on Indi.

Coming back to this, with over a week since last imaging session. Might look into the installation of Bullseye, but for the moment, I'm obviously interested to see why astroberry has such issues as it's meant for this purpose... Same thing as before with the crashing. So I'd disabled all FITS options so that no images are displayed after capture, and also ran my custom script to track memory issues. My findings are non-conclusive as there seems to be plenty of memory available - the KStars log just ends after a 60sec exposure started, and pretty obvious from the tracking output when KStars crashes: [2022-03-26T00:33:03.451 GMT INFO ][ org.kde.kstars.indi] - "CR2" file saved to "/home/astroberry/Astro Imaging/Light/UV-IR/M82_Light_UV-IR_60_secs_2022-03-26T00-33-03_077.cr2" [2022-03-26T00:33:03.452 GMT INFO ][ org.kde.kstars.ekos.capture] - "Received image 77 out of 400." [2022-03-26T00:33:03.478 GMT DEBG ][ default] - WARNING: Phonon::createPath: Cannot connect Phonon::MediaObject ( no objectName ) to Phonon::AudioOutput ( no objectName ). [2022-03-26T00:33:03.487 GMT INFO ][ org.kde.kstars.ekos.capture] - "Capturing 60.000-second image..." [2022-03-26T00:33:03.500 GMT INFO ][ org.kde.kstars.indi] - Canon DSLR EOS 550D : "[INFO] Starting 60 seconds exposure. " 2022-03-26 00:33:55, Temp=25.3ºC. RAM available: 2.5GB; RAM used: 1.1GB. 2022-03-26 00:33:56, Temp=25.3ºC. RAM available: 2.5GB; RAM used: 1.1GB. 2022-03-26 00:33:57, Temp=25.3ºC. RAM available: 2.5GB; RAM used: 1.1GB. 2022-03-26 00:33:58, Temp=23.8ºC. RAM available: 2.5GB; RAM used: 1.1GB. 2022-03-26 00:33:59, Temp=25.8ºC. RAM available: 2.5GB; RAM used: 1.1GB. 2022-03-26 00:34:00, Temp=25.8ºC. RAM available: 2.5GB; RAM used: 1.1GB. 2022-03-26 00:34:01, Temp=25.3ºC. RAM available: 2.4GB; RAM used: 1.1GB. 2022-03-26 00:34:02, Temp=25.8ºC. RAM available: 2.5GB; RAM used: 1.1GB. 2022-03-26 00:34:03, Temp=26.2ºC. RAM available: 2.5GB; RAM used: 1.0GB. 2022-03-26 00:34:04, Temp=25.3ºC. RAM available: 2.5GB; RAM used: 1.0GB. 2022-03-26 00:34:05, Temp=25.8ºC. RAM available: 3.1GB; RAM used: 417MB. 2022-03-26 00:34:06, Temp=26.2ºC. RAM available: 3.1GB; RAM used: 442MB. 2022-03-26 00:34:07, Temp=25.3ºC. RAM available: 3.1GB; RAM used: 429MB. 2022-03-26 00:34:08, Temp=24.8ºC. RAM available: 3.1GB; RAM used: 429MB. 2022-03-26 00:34:09, Temp=25.3ºC. RAM available: 3.1GB; RAM used: 429MB. 2022-03-26 00:34:10, Temp=24.8ºC. RAM available: 3.1GB; RAM used: 429MB. 2022-03-26 00:34:12, Temp=24.3ºC. RAM available: 3.1GB; RAM used: 429MB. 2022-03-26 00:34:13, Temp=24.3ºC. RAM available: 3.1GB; RAM used: 429MB. 2022-03-26 00:34:14, Temp=25.8ºC. RAM available: 3.1GB; RAM used: 429MB. It seems to crash 1 min after the exposure starts, so somewhere around the attempted download of the ~22MB image CR2 fille. What's frustrating more is that I closed my VNC at around a quarter past midnight, after starting the session at 8:30pm, so lost all night from midnight to ~4am having had almost 4hrs of successful imaging up to that point. Is anyone else having such issues or frustrations? What are the alternatives for RPi (my installation was with astroberry and blanenaEtcher, then adding conky and anydesk; other than that, its use is for imaging)? Thanks again folks

Haven't delved deep enough into things, but I know the resource limiter was enabled with the FITS viewer in KStars settings. I've disabled all the FITS viewer data as it doesn't do anything for me other than show hopefully that the image is correctly being captured (eg DSLR in 'M' rather than 'Av' (forgetting to reset after flats!)) or some other issue. Generally I'd download images to MBP after starting to see how things look anyway - and I've got RawTherapee on the RPi so could do preview of that to see what the image looks like rather than letting EKOS/FITSviewer do the work. I tried to do the EKOS debugger version of kstars, but the adding to APT ppa sudo apt-add-repository ppa:mutlaqja/ppa got the error: aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for Raspbian/buster My Kstars build is currently: 3.5.7, Build: 2022-01-29T12:50:57Z I've just thought that I can monitor RAM with a little script similar to the temperature monitoring one that's recommended on most of the RPi forums. So written that, it'll output a text file once started and just log time, temp, CPU & RAM. That way, I can track possible crashes to how much RAM is used, and compare with timestamps in the KStars log. Might show nothing, no harm trying! Script and output: #!/usr/bin/env bash set -eu -o pipefail SECONDS=${1:-36000} current_cpu_temp_in_c() { /opt/vc/bin/vcgencmd measure_temp | cut -d"t" -f2 | cut -d"'" -f1 } RAM_Summary() { free -h | head -n 2 | cut -b 1-6,15-20,27-33,71-79 # Total,Used,Available... } RAM_Available() { free -h | tail -n 2 | head -n 1 | cut -b 75-79 } RAM_Used() { free -h | tail -n 2 | head -n 1 | cut -b 27-31 } echo "New Data Starting Here" >> "/home/astroberry/Astro Imaging/SystemLog.txt" for i in `seq 1 $SECONDS`; do NOW=$(date '+%Y-%m-%d %H:%M:%S,') # echo $NOW "T$(current_cpu_temp_in_c)ºC. CPU:$(actual_cpu_clock_speed). RAM available: $(RAM_Available); RAM used: $(RAM_Used)" >> "/home/astroberry/Astro Imaging/SystemLog.txt" echo $NOW "T$(current_cpu_temp_in_c)ºC. RAM available: $(RAM_Available); RAM used: $(RAM_Used)" >> "/home/astroberry/Astro Imaging/SystemLog.txt" sleep 1 done New Data Starting Here 2022-03-23 17:55:05, Temp=41.3ºC. RAM available: 3.2Gi; RAM used: 323Mi 2022-03-23 17:55:06, Temp=40.9ºC. RAM available: 3.2Gi; RAM used: 324Mi 2022-03-23 17:55:07, Temp=40.9ºC. RAM available: 3.2Gi; RAM used: 324Mi 2022-03-23 17:55:08, Temp=40.9ºC. RAM available: 3.2Gi; RAM used: 323Mi 2022-03-23 17:55:09, Temp=40.4ºC. RAM available: 3.2Gi; RAM used: 324Mi 2022-03-23 17:55:10, Temp=40.9ºC. RAM available: 3.2Gi; RAM used: 324Mi 2022-03-23 17:55:11, Temp=40.9ºC. RAM available: 3.2Gi; RAM used: 325Mi Simple, but might shed light on some issues should they occur. Must remember to start the script from the terminal so a CTRL+C will stop writing to it! Then it just appends rather than overwriting if started again. Tonight is meant to be clear again so might get it running and leave to see if disabling all the FITS options has worked, or if a crash occurs, if it's related to a memory issue or not. Time will tell!

Thanks Nish and Jonathan, I've seen a couple of things suggesting it was a RAM issue, with resource limiting mode solving the issue, (indi forum), but as it was 3 years ago (and on RPi3), would have thought such an issue would have disappeared. Can others shed any light on things (and if so, then we can all ask for ekos/indi/kstars folks to look into it more). Rather frustrating that the idea is to automate things and I'm then wondering if I'm wasting imaging time! And the amount spent on RPi and cabling to get nice setup and things don't work as intended! Not quite as frustrating as the cloud cover though!😂 Others seeing similar?

Hi guys, Think this is the best place to post this issue which I've seen several times before without thinking too much of it. So over the w/e, we've all been enjoying some really clear nights and I set my rig up on Thursday night on patio, looking to get in some nice imaging time before the shorter days don't make it quite as worth it! Previously I'd wait until I'd got enough images, clouds rolled in, or bed beckoned, so I'd dismantle setup and retreated. This was the case again Thursday night when clouds came in. But from Friday until this morning, setup has been left out meaning a quick (<15min) startup time, and hoping to leave camera imaging all night long. M42, IC405 & M81 were the planned targets and happy to say I'm pleased with what I got done, but let down by crashes of unknown origin. KStars, EKOS & Indi, internal guiding, logging into RPi using the hotspot and astroberry.local/desktop approach. Each night (well, early morning!), a crash has obviously halted any image grabbing. But no idea what's been causing it. With this issue previously, I'd still be up so be able to restart things. But over this w/e, I'd left the setup doing what it wanted, hoping to see successfully completed imaging session in the morning. The logfiles (verbose) don't really tell me anything about what caused kstars to close (Indi still running as reopening kstars=>ekos and reconnecting the devices brings up the "another instance of Indi found... closing in 5" dialog box). A quick scan through them and last entries tend to be [2022-03-17T22:50:46.170 GMT INFO ][ org.kde.kstars.indi] - Canon DSLR EOS 550D : "[INFO] Starting 60 seconds exposure. " or [2022-03-19T00:18:57.957 GMT INFO ][ org.kde.kstars.ekos.guide] - "Dithering in progress." So not really sure what's off. I have noted plenty of lines (latest one had ~400 lines out of 2500) with occurrences of: [ default] - WARNING: Phonon::createPath: Cannot connect Phonon::MediaObject ( no objectName ) to Phonon::AudioOutput ( no objectName ). but due to the number of these (and that they occur from just after autoguiding starts), I'm assuming that's not one to chase down (just yet)? Last night, I thought I'd try starting via terminal, so 'kstars' at the prompt, and hoped either this would give more help on what the cause may be, or perhaps make it run more stable. Last line in the terminal is the highly descriptive linux error, "Segmentation fault"! I've tried searching for similar issues in the Indi forum, and whilst there are reports of folks getting miffed with crashes (consequently moving back to Windows & ascom), they are few and far between so hope there is a solution. Anyone experienced similar, know how to get around the issue, or is this one to post on the Indi forums? Could it be a connection (eg USB) or RAM issue? Although nothing extra is running on the RPi which is mounted to the dovetail under the telescope, so not used for any other purposes. Left outside, it has been cold? Log files of the crashed sessions over the w/e attached. Thanks in advance. logs.zip

Last posted on here back in September, and have since upgraded to the 130PDS, with new supplies to heaters, USB hub, fancier 3D prints for cable management, and only 1 cable going from the ground to power everything I have! Here's last night where we got clear skies for the 3rd night in a row! Taking flats, using old white baby vest, holding on the end with elastic! Single cable to power the lot! 4x GX12 connections, individually fused to Mount, RPi power (via buck converter), USB hub (also powering the USB dew heaters on guidescope & 130PDS) and DSLR (via 12-8V reducer cable) Rpi to USB hub, feeds from guiding, DSLR, mount & USB wifi dongle. Rather chuffed with the cable management!

Answering first question - you should be able to do both visual and imaging with the 130PDS? I've watched the posts on this page and now have one too - once mount working again, the 130PDS is clearly a lovely scope and has lots of imaging potential. Might be a little 'long' for some DSOs compared to a 400mm 'wide field', but there's plenty to write home about with it from the praise it gets from 2014 on that link! I'm sure I've read somewhere that the name comes from: 130-diameter of primary mirror; P-parabolic, better than spherical primary mirror for focusing light D-dual-speed focuser, so getting sharpest focus is easier S-shorter tube, so a camera sensor can reach focus I used mine for the first imaging last night, and had the following setup Camera => T-mount => 2" adapter (with filter insert) => 130PDS. I was hoping to have the following, Camera => T-mount => filter wheel => 2" adapter => 130PDS, but the filter wheel is too thick to use. I've no coma corrector, which complicates it a little - this has to have the correct setup with the correct backfocus from the coma corrector (commonly seen as "CC") rather than the mirrors. Are you using a CC? Perhaps send photo of your setup if you're not able to get focus as this scope should give it without moving primary (for imaging).

First outing for my 130PDS last night. It's a 2nd hand older type 130PDS (gold SW writing), then modded with the primary mask. No CC, and likely needing better collimation, but am pleased with outcome for Bortle 6 (ignoring factory floodlight!) M42, 82min of 30sec lights, +flats+bias, UV/IR filter; DSS, processed in StarTools. It's not going to win any awards, but I'm shocked and pleased what can be pulled out from my back garden!

Posted again on another thread about my experiences with getting new mount (following on from the GEM1)- this got me reading more into SNR calcs and using the site Jerry mentioned in the topic opening (SNR Calculator). Jerry also mentions that @vlaiv that you may have a spreadsheet to do some calculations? Care to share? Clearly the greatest thing from what Jerry posts is dark(er) skies - I've a large factory about 100m south of home, which has a new LED floodlight lit all blooming night! That's clearly not going to do much for my imaging, but with visual, it's not too bad (I've a home-made light shield using photographic light stands and damp-proof which keeps light from the floodlight out of my eyes so I can at least think about 'dark adapting' even when just outside the back door). I just wanted to query if I've entered things correctly (ish) - browsing online, I've managed to find stats for the T2i at QE40%, ReadNoise=2.5e and DarkCurrent=0.5e/s. Do these numbers sound sensible? The QE is fine, but querying the others. Also, filling in some targets, suggested that using 60sec subs and aiming for SNR of ≥10 (Brian's recommendations on the SNR calculator homepage), I'd need 10min of subs for M27 with mag7.5 vs 17hrs for NGC7000 with mag4??? So my original queries about number of subs/length of exposure really has no relation to magnitude? Or am I missing the point? I know @The Lazy Astronomer said that AP is completely different to daytime, but is it really that much?! Where there's no 'sense' between magnitude and number of subs?! TIA

In closing, thanks again to Alan @symmetal for the tremendous help on this with the tips and checks. Just done the PSW30 with PX of the PS08. Think this works best for my present usage and future proofs things too. Might add a final photo once everything is operating on next clear night. Tidy cables, here we come!

Been there, done it. Only bought one major mount update in (close to) 15 years, but very much needed. I was running a 10", f/4.8 (10kg) OTA for visual on an eq3 equivalent (which came with the scope), and asked myself would the eq5 range (obviously cheaper) would be ok, but advised on SGL that the weight (and possibility of imaging) would realistically require the eq6 range for stability. It was a tough decision, but worth while investment. I ended up getting the AZEQ6 as it's slightly better for doing visual (AltAz mode with the controller), and would indeed future proof any imaging (with weight of guiding, filters, camera, etc), and the endless list of kit is still building! I've got into imaging now, and initially used the mount with DSLR and fairly light telephoto lens (500mm mirror) so the mount wasn't taxed in the slightest. I was able to add guiding with this setup and then acquired a smaller, lighter refractor (ST102). Whilst the mount is still OTT for this setup with guiding, I feel it's well future proofed up to anything I'm likely to put on it. Coming back to the original question, no need to update/upgrade unless your setup is struggling with the weight of kit. If you're tracking decently enough, then no need. If the mount can't handle setup, then thinking about updating may be required, at least in thought! Again, my thoughts, future proofing should be thought about before rushing into it (obviously budget too!). Echoing Malcolm above I believe.

Hi @symmetal Alan, Many thanks for your response. Just to detail this further, plan is a 4-way CCTV splitter that will feed from the main supply, and split into the 4x 2.1/5.5mm DC barrel connector, with each of these supplying: 1) RPi, powered via the buck converter you recommended previously (so input to the buck will be DC 2.1/5.5 female and get fed via the splitter), and BC-USBC to RPi as present 2) Anker USB3 powered hub (12V,60W with 3 USB-power output and 7x USB3.0), which as you point out correctly, will indeed power the dew heaters (also using the USB ports to connect guide camera, DSLR, USB-wifi dongle and the AZEQ6 USB connection) 3) DSLR, so 12V-8V reducer which already has the 2.1/5.5 connection 4) AZEQ6 power, 12V up to 4A, so I'm making a GX12-DC connector that will just again plug into the 4-way splitter (yes, will be checking polarity and triple checking it(!) long before it's plugged into the mount. I had looked at the open frame type supplies but kinda dismissed them as they don't 'look' as safe, although they do seem to review higher than the other brick types. Only concern about it is that it'd be outside - how do you house yours? I'm tempted to do the frame one and house it in this for example (alternatives). I'd also looked at the idea of waterproof LED supplies (example), a disadvantage is the short output cable but would need to extend a frame type anyway. The more I think about it, I'm still debating the PSW30. In summary, am I right in thinking that any supply rated at 12V will be OK, provided that it can supply (more than) adequate current/power to the setup? Thanks again!

So back in the summer, I started this topic as I had been getting 'tingles' from my mount, camera and RPi which wasn't good! I'd reported in my last note that I had purchased a buck converter to power the RPi (5A, 12V-5V USB Buck Converter) which had solved my issues of any 'mains leakage' and tingling sensations. My Nevada PS-08 unit now powers my setup with no issues - cigarette socket to AZEQ6 mount using the supplied SW adapter, and banana plugs powering the RPi (via the buck above) and DSLR via a 12V-8V step-down connector. No issues with this and the PSU seems to have no trouble in supplying the power required. Coming into winter months for imaging, obviously colder with hopefully more imaging time, I'm now thinking about keeping frost (& dew) off the optics. I've got 2 dew heaters both USB, 5V,2A so have to think about getting these into the mix. So also to keep cables everywhere and reduce load on the RPi (put the load elsewhere), I've got a powered USB and debating my main supply now. Obviously the Nevada PS-08 is rated at 12V 6A (8A max). Using 2x dew heaters at max, (2A @5V x 2)= 20W (hopefully mid setting so not quite at this) The RPi wants 3A@5V=15W Camera=10W (recommended value is 2A when using 5V and converting to 8V) Mount=48W (slew only) Total power = 100W when at max draw => 12V,8A. I've worked out that I can have a single supply powering everything above (mount, dew heaters, camera and RPi) with a single cable going to the mount (really tidy!), supplying everything from one source and no need for a return cable (unless using ethernet to the RPi). However, this is on paper at the limit of the Nevada. So I think I'm going to be looking at an alternative power source, 12V 10A (120W), similar to the post above that @7170 recommended, rather than the Nevada? I'd assume the 12V holds stable when under load as I've read several posts about the mount supply failing outside of 11-16V (incl appendix 1 in manual)? Also driving at closer to the current limit when slewing, I'm assuming all would be fine with a 10A supply when in regular tracking/guiding mode (when the total load should be closer to 12V,5A) On closing, if my calculations are right, this suggests that the Nevada "may" be OK, but not sure how to connect it - max of 5A through the cigarette plug is all the info I can find ("Output current 6A continuous (8A surge). Max 5A via Cigarette Socket") , but does anyone know the current limit across the banana plugs? What I don't want to do is connect a total of say 5A (8A surge when starting slew), to just the banana plugs, if the cigarette socket is max 5A and the banana plugs max is 4A (assuming then nobody would be using 2A on the cigatette adapter to put it over the 6A max). Not sure that's worded well, so can anyone confirm the current limits on the Nevada connections based on the following quick table: Cigarette adapter: Banana Plugs: 0A 6A 1A 5A 2A 4A 3A 3A 4A 2A 5A 1A 5A (max) 0A Anyone else care to share about 10A supply they're using? FLO go to max of 5A switch mode before jumping to the Nevada PSW30, which I don't think I need (just yet!) Cheers

This is the output from DSS - the individual subs were the previous histograms with the significant gap on LHS. Just to confirm: Histogram from light subs with likely cloud reflection: Histogram from light subs where there is (hopefully) no cloud reflection: Histogram from the 16-bit stack from DSS (using only the light subs with the 2nd histogram, just above): So query is, is the middle one OK or would you suggest it's too bright?