Forum Replies Created
-
Posts
-
The new image gallery software is able to do this, but currently it is only permitted for gallery administrators (e.g. archivists uploading images on behalf of BAA sections) to associate multiple files with a single observation.
We can certainly consider rolling this out to all BAA members in due course, once we emerge from the immediate post-launch testing phase.
Existing links should continue to work. They will point to an archived version of your old member page content, with some features disabled – e.g. the ability to leave comments.
The new member albums are now live. We had a few minor teething issues earlier today, but you should now be able to upload images using the new interface.
I think people here in Cambridge would say it’s an indication of just how good the Gaia data now is that all these biases can be measured and corrected.
None of these effects were measurable before, because they were entirely hidden in random noise. The measurements are now so stable and repeatable that these systematic skews start becoming apparent.
This is one of the reasons why so much work goes into every Gaia data release, and why successive data releases can’t simply come out at the push of a button. When you get rid of all the random noise, what’s left is the systematic noise, and that’s where the really hard work begins.
I work on the PLATO mission, and we’re seeing similar trends there. We set E2V the challenge of building the lowest-noise CCD they’ve ever made. What happened last year when they got rid of all the random thermal noise? They discovered entirely new leakage current patterns which no mission has ever seen before, because they’d always been entirely hidden in the noise before.
The G-band was never part of the standard Johnson-Cousins system, and so my understanding is that it’s not particularly standardised. In fact, professional observatories now tend to all have their own bespoke sets of filters, and so you can’t directly compare a PanSTARRS g with an SDSS g, for example. Though they’re very similar.
As I understand it, the Gaia G-band is indeed the unfiltered response of its CCD. Though, of course, Gaia doesn’t have any atmospheric extinction, so it won’t be a perfect match to anything you can get on the ground.
If one is being really pedantic, there are multiple different revisions of the Gaia G-band, as each data release includes improved instrumental corrections (which depend on colour). If you google for Gaia photometry you can find plenty of long gory papers about the process.
I’m impressed that you manage to achieve 0.1 mag accuracy!
I have also played around the background subtraction and flat-fielding with my meteor camera, which I use to get as many stars as possible when calibrating the pointing and lens abberations using astrometry.net. But the stars have a tendency to be horribly saturated (which isn’t an issue for me).
Presumably you have to tweak the gain manually for each target, to place the star optimally within the very limited dynamic range you have? I’ve noticed that stars often have quite evident “ringing” artifacts on either side of them, due to a analogue signal losing its higher frequency components, which would be another noise source. The limited number of pixels is another factor that I would imagine might making accurate photometry difficult.
Yes – unfortunately CUP is going through a lot of changes currently. You may have heard the news that CUP is going to merge with Cambridge Assessment in 2021. The university says there will be lots of exciting opportunities for CUP to produce “digital education” tailored to exam syllabuses. But at the same time, they’ve admitted they will be laying off a significant number of staff:
https://www.cam.ac.uk/news/cambridge-university-press-to-join-with-cambridge-assessment
I fear the future is not very bright for the bits of CUP not connected with “digital education”, given it will soon be a sub-division within an exam board.
The BAA Forum Terms of Use do say:
“We ask that contributors to the forum and member pages use their full name, to promote a sense of collegiality and community amongst our members.
We certainly consider that to be best practice. However, we currently only enforce this where we suspect dishonesty.
It is important to recognise that many people have very reasonable concerns about posting information about themselves online. People who work in certain professions (state school teachers, social workers, civil servants, etc) can live under the threat of immediate dismissal in the event of a single online post which is perceived to violate their employer’s code of conduct. It is understandable that such people increasingly want to err on the safe side (or feel extreme pressure from their employers), and prefer that their posts should not come up in Google searches for their names.
Others may simply feel they don’t want to release information about themselves to fraudsters Googling for their name.
If there are specific concerns, the website administrators are able to cross-reference any forum post against the BAA membership database.
Grant,
Using the median isn’t a good way to exclude outliers, especially if a significant number of pixels are outliers (stars in a busy field). If, let’s say, 10% of pixels contain stars, then those outliers at the top of your distribution effectively mean that your median gives you the 55% percentile of the sky background distribution, which might be rather a noticeable skew towards the brighter end of the distribution.
Of course, that would be far better than taking the mean of a distribution containing stars, because the latter really would give you a nonsensical result. But to do this well, you really want to entirely get rid of the stars from your sample of pixels.
As Nick says, the way to do that is via “sigma clipping”. Take the mean and standard deviation of your pixel brightnesses. Exclude all pixels which are more than X standard deviations away from the mean. Iterate a few times.
I’ve come across this problem in the context of doing background subtraction from the images from my meteor cameras. In that context, the median has an additional issue that it’s quantised. If you take the median of a large sample of integer values between 0 and 255, you can’t get the noise below 1 ADU unit. With the mean of large numbers of samples, my sky background model sometimes reaches a formal precision of about ~ 0.2 ADU unit.
I would assume Nick has enough bit depth in his data that quantisation is unlikely to be a worry, though.
Cheers,
Dominic
Nick,
You’ve got me attempting to do undergrad statistics at 2am after a couple of beers, so this may be a pile of nonsense. But the formula I get is as follows…
* By definition, SNR = Signal / sqrt(Sky_Noise^2 + Photon_Noise^2)
* Define the sky noise in an individual pixel to be sigma_sky. If the standard deviation of M sky pixels is measured to be sigma, then your best estimate of the sigma_sky = sigma*sqrt(M/(M-1)). The sqrt() term comes about because sigma is a slight underestimate of sigma_sky, since the same sample of M sky pixels was also used to calculate the mean sky level relative to which their standard deviation was measured. For large M, sigma_sky=sigma.
* The total noise in the summed brightness of all N pixels within your aperture is sigma_sky*sqrt(N) = sigma*sqrt(NM/(M-1)).
* This equals Sky_Noise in the SNR equation above.
* Now for photon noise. Define the number of photons collected from the star to be N_photon. By the definition of the gain, N_photon = S/G. The noise in N_photon is sqrt(S/G) since it is a Poisson process. Thus, the noise in S is sqrt(S/G)*G = sqrt(SG).
* Putting it all together…
SNR = S / sqrt(SG + sigma^2 * NM / (M-1))
* My formula is closer to yours than the AAVSO’s, but not quite the same.
* In my formula, SNR decreases as G gets larger. This must surely be correct? Higher gain cameras have more noise. In your formula, and the AAVSO’s, SNR increases with G. This doesn’t seem to make any sense.
* I think this formula behaves correctly when images are stacked. When you stack X images, sigma is divided by sqrt(X), and G is effectively divided by X. Net result: SNR increases as sqrt(X), as you expect.
* I’ve never done any aperture photometry in my life, so the above may or may not be complete nonsense.
Cheers,
Dominic
Jean Meeus’s statement that it can only be deduced from observations is (unless I’m mistaken) only true for UT1 – a time standard which strictly follows the Earth’s rotation.
The time that the clock on your wall reads is UTC, which is pinned to International Atomic Time (a realisation of TT), but has leap seconds added to keep it closely aligned to UT1.
The quantity you’re almost certainly looking for is (TT-UTC), which is exactly 37 seconds currently, and changes in 1 second steps when leap seconds are added to UTC.
Whilst observations certainly are needed to determine (TT-UT1), it’s not a very useful quantity for most people, because UT1 is only used for a few specific applications that directly involve the Earth’s rotation. The ones that come to mind are calculating precise sidereal time, and calculating the Earth’s rotation angle during eclipses. Oh, and of course deciding when to put leap seconds into UTC! 🙂
If the problem you’re working on involves the times when the Moon is at certain positions in its orbit, then that’s a problem where the Moon’s orbit is defined in TT, and you want to report times in UTC. So UT1 doesn’t come into it.
Your question doesn’t make sense!
If you’re after (TAI-UTC), then that’s not an observed quantity. It’s defined by when leap seconds are inserted. A simple list of leap seconds over recent years will give you an answer that is 100% accurate by definition:
https://www.ietf.org/timezones/data/leap-seconds.list
The current value is precisely 37 seconds.
But… if you’re after UT1-UTC (I can’t quite think why you would be – it’s only relevant to rising and setting times!), the full gory details are all here with awful lot of decimal places (see Bulletin A):
https://www.iers.org/IERS/EN/DataProducts/EarthOrientationData/eop.html
However, UT1-UTC is maintained at a value less than 0.5 seconds by inserting leap seconds whenever it drifts outside that range. If, as you say, you are only interested in accuracy to the nearest second, then you can assume that UT1-UTC always equals zero.
This was indeed a very beautiful meteor. Two of my meteor cameras caught it, on opposite sides of Cambridge…
https://pigazing.dcford.org.uk/moving_obj.php?id=20200922_035352_b29217a987c61766
https://pigazing.dcford.org.uk/moving_obj.php?id=20200922_035353_ca8e636784ff1d42The times on the Pi Gazing website are all in UTC, in case you’re wondering.
I haven’t got around to doing any triangulation with my data yet, and I also don’t have built a mechanism for exporting data from PiGazing into a format compatible with the larger UK networks. But it sounds like you’ve already got plenty of data for this one! 🙂
Dear Alan,
I’m sure the BAA Office will be very glad to help you with this. You can find their contact details here:
https://britastro.org/contact/Contact-the-BAA
Best wishes,
Dominic
White dwarfs have good thermal conductivity, so the core won’t be much hotter than the surface.
Young white dwarfs start life at ~10 million K. But that phase doesn’t last long. Heat dissipation scales as T^4 (Stefan’s Law), so the initial cooling is very rapid.
A rough calculation suggests that if a white dwarf takes 10 billion years to cool to 10,000 K, the same white dwarf would take only about a decade to cool from 10^7 to 10^6 K, and a few hours to cool from 10^8 to 10^7 K.
That is without masking tape, so the graph is basically justifying that your suggestion in May was correct! 🙂
I made my post in May immediately after refocussing my camera, and have only just got around to opening it up again and looking for a more permanent fix.
I would second the suggestion above that you trying putting a *powered* USB hub between the laptop and the camera. You should be able to buy one online for around £15.
If the problem is noise on the USB power lines (or possibly insufficient current?), then a simple fix might be to draw power from a hub rather than the laptop itself.
Incidentally, to judge from your photo, I also bought a very similar new HP laptop last week, and I’m very pleased with it. Though I haven’t tried connecting it to any astronomical cameras (yet).
Welcome to the wonderful world of Python, where specific versions are only supported for a couple of years before programmers are expected to update all the code they’ve ever written to run in a newer language version.
However, the good news is that Python 3.7 isn’t dead yet (it’s supported until 2023), and I believe Anaconda still support it too.
It’s just that the Anaconda website is entirely unhelpful. If you download the current installer — the one Anaconda tell you is Python 3.8 — and then you follow the completely incomprehensible instructions here: <https://conda.io/projects/conda/en/latest/user-guide/concepts/environments.html> then you can use it to create a Python 3.7 installation.
In case you are not a fluent speaker of gobbledygook, and need somebody to translate the Anaconda website into English for you… there’s a StackOverflow thread here where somebody has asked a question very similar to yours, and the comments explain exactly what commands you need to type to get a Python 3.7 installation… https://stackoverflow.com/questions/42978349/anaconda-version-with-python-3-5
I think the point here is that this is a very long-period comet, so its speed is very close to solar system escape velocity right now. Even a tiny bit of extra energy from Jupiter can push its aphelion out a long way and significantly increase its period.
This is what Nick meant when he said that a small change in eccentricity has a big effect on period. When e is very close to 1 (i.e. a long-period comet), a very small change in e has a very big effect on the (1-e) term in Nick’s equation!
Alan,
Satellites are normally referred to by their NORAD ID numbers, which are assigned by the US military. There are various websites which will list these. Here’s a table from my own website…
https://in-the-sky.org/search.php?searchtype=Spacecraft
The UN have their own separate satellite numbering system, which is the COSPAR ID you see in the second column. Not many people seem to use it, though.
I think when somebody refers to “element set satellite ID”, they’re refering to the “two-line elements” format used by websites such as Celestrak when publishing the current orbits of spacecraft. For example, their current data for the ISS is as follows…
ISS (ZARYA)
1 25544U 98067A 20208.81898250 -.00001223 00000-0 -13780-4 0 9996
2 25544 51.6445 152.3082 0000916 163.1489 218.7089 15.49504233238167<There’s full documentation on the Celestrak website about what all the numbers mean, but the second number on each line is the NORAD ID number of the spacecraft in question. The ISS has a NORAD ID of 25544.
Hope that helps,
Dominic
