Forum Replies Created
-
Posts
-
While a Committee member of a local society I well recall a keen amateur I knew who fell on hard times and had to sell his telescope and give up luxuries, including membership of our society, to help make ends meet. Its a common thing – jobs are insecure these days.
I always thought it odd that we insisted on 50 continuous years rather than 50years in total – but there I must declare an interest, as astronomy did drop out of my priorities when prog rock, girls and beer entered my life in the mid 70s. I cannot say I regret it though…
As an aside, given the resources consumed and the mailing costs, should we not be encouraging members to move to a Digital model?
I have some images I took a few weeks back as a test. I could take some more if the weather clears. Do you want FITS (after dark/flat) or precalculated mags?
Also, are unfiltered observations okay with you? I assume if I took images on multiple occasions you could derive an instrumental offset? I’m currently using in field stars to derive a Gaia g Zp for each frame and employing tha -though theres a twist to that as I don’t use reference stars that are highly red or highly blue.
Yeah, When I plate solve images I run a Python script under Windows that does all the image processing and file handling which then kicks off a Linux session under the MS WSL Linux environment on the same machine. That runs astrometry.net and then hands back the results. Works really well – but took an evening or two to work out how to do the hand over (and it changed during the last year when WSL2 was updated).
The only reason I don’t run Windows on an RPi5 is because I would then need to buy a £100+ W11 Pro licence and suddenly quite a lot of the cost case has gone away. Certainly I would like to but I have heard that setting up Windows on an RPi was a bit hard going.
Over the years I’ve used DOS, CPM, VMS, SunOS, OSF, various Linuxes and every Windows instance excluding 2000, 95 and W8.0.
Its not really a comfort zone issue. I spent a good while writing SXcon VB6 code to control the SX CCDS I have owned and want to stick with it if I can. As you might imagine, having written the interface, its intuitive to me and I make fewer 2am errors. Change will be more likely once I fully retire and have time. 🙂
At some point I will be making the move – RPi5s make it more reasonable (I don’t think my 4B has enough grunt), possibly used with Stellarmate – but was waiting for INDI to port to a more recent version of Raspbian. If I already had code that ran the SX 694 under Linux/Python I would already have started writing a QT interface.
Thanks to all for their comments.
Yes, Beelink and MELE look interesting – slightly confusing that the detailed Amazon info on the Beelink says DOS as the OS. Heard ASUS picked up the latest NUCs from Intel when they withdrew from the market, but it look like its the top end of the market only.
With a new disc, the old ACEPC runs fine for Word processing and light browsing via Mint but lacked the grunt for TheSkyX plus a CPU intensive VB6 program.
Have looked at the old Dell workstations and its a good solution, but can’t yet work out how to avoid cable tangle – the 100mmx100mm Minipc sits on the polarscope port of the EQ6.
This morning it occurred to me that as the system is run headless (no keyboard/monitor/mouse) it could have done a Windows update without me knowing. Will check the Intel NUC site and see if there are driver or firmware updates I could try re/installing. Nothing to lose. Its under 3 year guarantee. Something to do this afternoon.
STOP PRESS: A combination of 4 new drivers (2 relating to USBs) and 2023 Firmware upgrade got it going again. Just observed T Crb. Yay! But thanks to everyone anyway, its focussed my mind on what to do about Windows – also, I’m faintly ashamed I had not done a Firmware upgrade before.
It should be mag 25.5 according to JPL Horizons – that is within reach of the HST/JWST but the HST has had bad gyros lately.
For the record, 20231113 18:13*, using Gaia g magnitudes derived from stars in the FOV and applying an aperture that was just 6x 1.55″ pixels across, I get a brightness of about 14.7 with an estimated error of 0.15 (not sure why its a big as that).
*20231113.759
I’m no expert, but I don’t recall seeing A_ORDER, AP_ORDER, CTYPE1/2 or CRPIX1/2 in any FITS file that I had not plate solved. I think they all relate to parameters defining how the x/y pixel location is related to the RA/Dec value associated.
Its a polynomial, usually, so the comments about polynomial order are suggestive. 🙂
I’m not familiar with ASTAP but the file appears to have a WCS and has a record of some lights darks and flats. The keyword CALSTAT is also suggestive ie DFBS – dark, flat, bias, stack?
When you display it does it look like the original frames but with less noise? If so I would assume its your stacked image. You could check that by using a different stacking method (SUM? ADD? Total?) and see if the sky count jumps up. Has any vignetting present diminished? Those would be big hints.
I thought it was the case that when Windows Defender objected to something you could bypass it by choosing the other option (which isn’t highlighted and doesn’t say “bypass” 🙂 ).
Last version I used, Tycho handled flats and darks, but not flat-darks.
Could AIP4WIN make your flat and master dark?
I use AstroArt8 instead.
I would suggest the PPARC Starlink package CCDPACK (I’m biased) but thats under Linux and a lot of it command line.
With old and noisy sensors I found the best way to get a decent clean background was via dithering. However, while using my old Super Polaris the periodic error helped – though the defective pixels could cause a streaky pattern in the direction of my declination drift.
Realistically, using a series of darks to find the noisiest pixels and then spatially filter them might be worthwhile as the Gaussian random noise assumption made when applying median stacking may not apply well for CMOS sensors – each pixel has its own amplifier characteristics.
The paper:
https://conference.sdo.esoc.esa.int/proceedings/neosst2/paper/7/NEOSST2-paper7.pdf
is quite an interesting read. Looks like a reasonable number of noisier pixels on quite a popular camera.
AAVSO also have a report on the QHY600 camera from 2020 and S&T have a review of the QHY600 (De Cicco?) – where the bias issues were mentioned.
One thing to remember is that it comes in two flavours: research grade (best used with their fibre link) and the lower quality chip (mainly USB3) cameras.
I’ve been wondering how each pixel having its own read out noise characteristics works when stacking images using Medians or Sigma Clipping. My gut instinct says not quite as well, but I would recommend testing that in practice. I think it means dithering may have become an essential but the saved readout time over a night may balance out the need for more frames.
Might also try a defect map.
The impression I got from colleagues was that CMOS bias frames, even when taken at the same sensor temp and gain setting, were not as reliably repeatable as CCD. To me, that suggested that collecting darks immediately before or after your imagery might be a good idea. Collecting darks on another night – less so.
Afterall, its worth noting that professional astronomers have been slow to take up CMOS and I rather doubt thats because they are all stuck in their ways – as some have suggested in the past.
I must admit, as a CCDer, I have never used bias frames because I only use 3 or 4 exposure settings and just redo those every few weeks – just to be sure.
For CCDs a dark of the same exposure length as the lights works fine. Throw in a decent flat field image and a defect map and its as good as it gets.
After some thought and contemplation on how little spare time I seem to have, I am trying to give in and go over to using Indi and then controlling the Lodestar using that, from Python – possible apparently.
I had a look at the website and saw a GetIndi>RaspberryPi link so, I pressed that and was informed:
“INDI Library is available for Raspbian Buster.”
I checked the target RPi and its a later version of Raspbian. On the off chance I tried installing it anyway, but there were lots of errors (no ordure Mr Detective) – I will redownload the image and refresh the machine later.
So, I’m now wondering whether Astroberry is actually under development still. Certainly Astroberry’s github site looks like its not been updated in 2 years. As RPis are now up to version 5 – which I think does have an onboard clock – its looking out of date.
I suppose I could just get an old image – rather than install on a fresh Pi installation – but that does sound a bit clunky.
I wondered about Alpaca/Ascom but, from the sometimes incomprehensible webpage, I didn’t get that warm fuzzy sense that it had drivers suitable for Starlight Xpress on a RPi. It sounded like it would connect if someone had written/provided an Alpaca compatible/RPi driver, but has anyone?Ho hum. Need to ponder – Confused of Wiltshire
I suspect you may need to make a metal base to mount the OTAs on and then bolt that on to the Versa Plate. You may need some balance arms to help balance if you change cameras or filter wheels or autoguider. Its doable though. Probably up to 14″ OTAs – perhaps a RASA and C14.
I just ran the platesolving code with the astrometry.net –verify option fully implemented against a set of T Tauri data I collected last night and am getting a smaller positional error and 50% more stars to be used when estimating Zp.
Looks worth doing.
Must admit I only look at the forum when I have some specific problem in mind.
