Forum Replies Created
-
Posts
-
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.
I currently use the 4100 and 5200H files as they give a V or Gaia g mag (I work unfiltered) and it allows the colours index of each star to be assessed.
One interesting thing to try is the Astrometry.Net –verify option. Got it going at the weekend (I use FITS bintables to identify star locations via columns of x, y, flux). Improves the number of stars employed in WCS polynomial generation (smaller median errors) and also helps Zp estimation. A useful refinement I think.
Ah, yes. I remember ansvr. Its a cygwin thing isn’t it? Surprised the guy who did the conversion job has not updated it Apparently, the absence of a true Windows version is due to the way AN maps the Index files to memory.
I was forced over to WSL (or Linux on a Rpi) because the ansvr version of AN is quite old and it was failing to solve some sparsely populated fields, while the latest AN did.
Ansvr certainly worked okay most the time though.
Hi Robin. Just being nosey. Is the astrometry.net instance under WSL2 or cygwin or are you running Linux?
No, I meant to rerun it leaving out every second frame to show the progress, but have never found the time. I have a plot of mag versus time somewhere too but that merely tells you that it was stable and not rotating fast. Though it did tell me it would be mag 29 at 1AU. 🙂
Nice achievement and the probe was quite easy to spot on the way out, though it was fun the night it was moving at 3 arcsecs/sec
The image attached shows dozens of short exposures overlaid and processed to record the highest value for each pixel.
Attachments:
