Re: Random Data from Geiger Counter

New Message Reply About this list Date view Thread view Subject view Author view

Antonomasia (ant@notatla.demon.co.uk)
Tue, 7 Jul 1998 00:47:11 +0100


ben@algroup.co.uk:

> Sorry, brain went on strike momentarily. Yes, 3 hits per bit. Though you
> could amortize them (if that's the right word in these circs) to get ~1
> hit per bit, of course.

Without reading the doc you've referred to I'd say the obvious way to
get random bits is to compare "this interval" to "next interval"
and get a 1 or a 0 depending on the relative size. It sounds as if that
could be what this paper is describing.
(And would be similar to RFC-1750 deskewing advice.)

I wouldn't like to run this more economically than 1 bit per 2 hits.
The reason is that a particularly long/short interval is likely to be
longer/shorter than both the neighbours, leading to correlation.

> Well, it seems to me that the standard deviation of the interval between
> hits should be predictable (a fixed fraction of the mean interval -
> anyone remember enough stats to know what that fraction is?) and from
> that and the timer resolution you can guesstimate a reasonable number of
> bits to allow per hit, which can simply be derived from the timing of
> the particular hit minus the mean.

Timing gets messed up by the counter dead time. This is the interval
following a detection during which no further detections can be made.
(It arises from the fact that an ionisation is amplified to detectable size,
swamping the tube momentarily. Ordinary counts correct for this easily, but
it will interfere with stats by imposing a rough minimum interval.)

> Hmmm ... I can see that this train of thought is going to lead to
> someone demanding that I back it up with some maths, so perhaps I'd
> better shut up.

I think I remember the standard deviation of the decay rate being
the square root of the decay rate. All this derived from single
atoms having the same probability of decay in a given time.
If you used the count rate to feed your program and it had say
100 counts per second (sd=10 c/s) then you'd be using 100 counts
to get several bits [maths omitted], but I think the bits per count
would be lower than the method you are already considering.

--
##############################################################
# Antonomasia   ant@notatla.demon.co.uk                      #
# See http://www.notatla.demon.co.uk/                        #
##############################################################


New Message Reply About this list Date view Thread view Subject view Author view

 
All trademarks and copyrights are the property of their respective owners.

Other Directory Sites: SeekWonder | Directory Owners Forum

The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:20:07 ADT