Forum Replies Created
-
Posts
-
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:
Interesting to see that PV Cep really is recovering after a brief drop in brightness to nearly 18th mag in June.
It would be nice to see another outburst in the nebula. Certainly looking hopeful.
Now if McNeil’s would come back again too, that would set us up for a very nice winter.
I don’t see why not – but am happy to be corrected if I am wrong.
I use a coma corrector on my telescope and do photometry.
Just be sure to always do dark subtraction and flat fielding.
I wanted to write my own code for controlling the camera without carrying along the huge baggage of filter wheels, dome control, mounts, derotators etc that will never be used.
As I have written code previously for the cameras to run under VB6 I hoped it wouldn’t be stupidly difficult.
With the RPi, I have found the problem to be that I do not have drivers for the SX cameras. I made it so the RPi recognises my Lodestar camera when it is plugged in, but it doesn’t have a driver to associate.
Previously, I went looking for the EKOS source on github and when I searched for the phrases “Starlight” or “sx” I found nothing. Having, accidentally, missed the introduction of github I must admit to some confusion/uncertainty as to how it works but didn’t seem able to find anything about the SX cameras. Must get a “Github for Dummies” book sometime.
Prompted by you I have now again looked at the Indi site and this time spotted that the cpp driver code appears to be available at http://svn.code.sf.net/p/indi/code/trunk/3rdparty/indi-sx/
I will download it all shortly.I shall have a play. Not quite sure how it will go, as its 20 years since I did C++ in anger, so it should be an interesting learning experience. There may be bad language at some point. Hopefully, I can eventually tie it all into Python / QT.
If anyone has already gone this route. Any “lessons learned” would be welcome.
I measured it at mag 15.0 and a couple of arc minutes out of position. Think it was doing 47 arc secs / minute. Had not realised it would be so bright.
It will get harder once they stop the orbits and head for the Moon.
I processed last nights data and got magnitudes of between 13.8-14.0 (Gaia g unfiltered) with a 0.12 mag spread – which is okay given it was initially viewed through a hedge and very low. Position errors were within the seeing disk.
Give it was moving at ~300 arc secs/min I used either 1s or 0.6s exposures. I think that was near perigee. It looks rather slower tonight.
Its clear tonight so, after 90mins on Gyulbudaghian’s, I had a bash with the 300mm Newtonian. Hadn’t noticed how fast Chandrayaan-3 was predicted to be moving. 4 arc secs per second…
Got it in 1 sec exposures. Will work out a magnitude tomorrow.First observations were through a hedge which really did not help.
