A better random generator :-)?

Sounds like shot noise. Nothing new there.

John

On a sunny day (Tue, 26 Oct 2010 10:36:54 -0700) it happened John Larkin wrote in :

Yes,

it has been a while since I played wit photo multipliers... In the old fast pulldown [1] color film scanners they used a green CRT scanned a frame on it, and red green and blue photo-multipliers looking trough color splitting optics on the other side of the film. The red photo-multipliers were huge, as there was almost not 'red' in the green CRT. Red needed a lot of gain, many dynodes.... Noise...

[1] Fast (maybe called 'quick') pulldown refers to pulling the film to the next frame in the TV flyback time (few milliseconds) by means of vacuum, made lot of noise too.

CF...

green CRT.

xt frame in the TV flyback time (few milliseconds)

I did the analog processing and part of the servo system on this flying spot scanner around 8 years ago. There is actually more red and blue in the green phosphor than you think. We also got rid if the 10 dynode PMTs. If you don't need the extreme gain of PMTs there are better options. The machine us still in production.

If it reminds you a a Rank, the underlying frame and mechanics is a Rank but almost all the Rank electronics is gone. All that remains is the power supply for the reel motors and the driver for the optical audio light source. When I was working on it is was the DAV (Digital Audio and Video) CineGlyph. Got one at work.

G=B2

CRT.

frame in the TV flyback time (few milliseconds)

WWII vintage radar jammers used a 931A PMT as a noise pulse generator. They ran it in the dark and just cranked up the HV until they got the pulse rate they wanted.

I used to buy these when I was a kid, the PMT noise generator chassis assembly, something like $4. You could get an entire under-wing radar pod for $70.

For TV film scanning, wasn't there some clever rotating prism thing that let the film move smoothly, gradually blending successive frames?

John

On a sunny day (Wed, 27 Oct 2010 11:22:46 -0700) it happened John Larkin wrote in :

Yes, there was the 'polygon', it was at least in my time, mainly used in film editing tables, with on the other end a vidicon camera.

These days these things are done digital.. The quality obtained by using a polygon is not suitable for broadcast.

For that there are scanners that use a one line CCD and move the film continuously past it. If you do that at the right speed it is much like scanning on the analog TV:

Again, these days, for example the StarWars II (the latest one made) was mostly done digital IIRC. I do not want to say film is dead, but it sure seems to go that way. For less then 1000 $ you have a 'film look' HR camera these days that is better in some aspects than the old 35 mm film ones...

See also:

So how, in practical terms, would one go about converting quantum noise into random bits? Preferably with the minimum number of components, a decent data rate, and minimal artifacts (bias, correlation, injection of mains hum or RFI).

1. make an entropy estimate of the raw data source.
2. Collect enough raw data to meet your entropy requirements plus some extra as a fudge factor (2 times would not be unrealistic)
3. Feed raw data into a cryptographic hash function.
4. Hash function output is believed to be random and unbiased

Aim an LED at a photdiode. Back bias the diode, and dump the resulting current into an opamp, as a transimpedance amplifier, or into a grounded inductor. AC couple and amplify the resulting noise.

An optocoupler would work, too.

1 mA of DC photodiode current will have about 18 nA of RMS noise, in a 1 MHz bandwidth, from photon quantization. Small but usable.

A zener diode is a more practical noise source, and is just as random.

John

I was more interested in the electronics side, i.e. how to generate the bits which comprise the raw data source. In particular, how to generate bits at a decent rate and with decent entropy.

It's easy enough to get a high rate with poor entropy (just sample whatever noise is available) or good entropy at a low rate (time "slow" events to sub-microsecond precision and use the bottom bit).

The question is whether there's a reasonably simple way to get raw bits as fast as e.g. a PIC's UART will clock them in and with enough entropy that the "cooked" data rate is comparable to (e.g. 25%-50%) the raw data rate.

AC-coupled white noise, thru a comparator to fit it into 0 to +5V, sampled thru a D-FLOP? ...Jim Thompson

--
| James E.Thompson, CTO                            |    mens     |
| Analog Innovations, Inc.                         |     et      |
| Analog/Mixed-Signal ASIC's and Discrete Systems  |    manus    |
| Phoenix, Arizona  85048    Skype: Contacts Only  |             |
| Voice:(480)460-2350  Fax: Available upon request |  Brass Rat  |
| E-mail Icon at http://www.analog-innovations.com |    1962     |

               I can see November from my house :-)

A reversed biased transistor e-b junction, gain stage, and then sample with a PIC ADC.

Or just use a couple of noisy JFET op-amp stages AC coupled (TL081)

The Flip-flop unbiases the input signal but the AC coupling introduces autocorrelations. How much depends on the time constant set up with the cap.

You also have to do a "runs" test to see that you are not sampling too quickly.

Nobody wrote: > On Fri, 29 Oct 2010 10:32:26 +1000, David Eather wrote: >

That's a surprisingly subtle business. Things like air currents and power supply variations can easily mess up the nice autocorrelation properties of white noise. Zener noise waveforms are quite asymmetric, as we've discussed here in the past, so people do things like running two zeners and subtracting their voltages. That's fine as an engineering expedient, e.g. for noise figure testing. Getting noise good enough for cryptography or lottery number generation is really really hard--you have to be completely paranoid, and then check everything over again a few times.

(Herodotus reports that the Medes, whose laws once enacted could not be changed, made a point of debating them twice--once sober and once drunk. That would probably be a good start here too.) ;)

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal
ElectroOptical Innovations
55 Orchard Rd
Briarcliff Manor NY 10510
845-480-2058

email: hobbs (atsign) electrooptical (period) net
http://electrooptical.net

In the USAF in the late 1960s to early 1970s, I worked on radar jamming transmitters. For that, they told me that they needed really really high-quality noise. They used MBSTs, Magnetron Beam-Switching Tubes.

but they didn't wire them as counters - I thinkk they just biased all the spades in their linear range, or something.

Then they'd series-modulate a magnetron, or modulate the grid of a BWO or so. ;-)

Cheers! Rich

To clarify further ... I guess I'm mainly curious about the step of turning noise into bits. E.g.

1. Bias. I figure that feeding a comparator with a) noise and b) a low-pass-filtered version of a) would solve that (i.e. the output should be roughly 50:50 zeroes:ones) at the expense of introducing some correlation (i.e. after a long string of zeroes, the next bit is more likely to be a one, and vice versa). I think that's inevitable; I can't see any way to get the "correct" threshold without this problem (essentially making the Gambler's Fallacy a non-fallacy).
2. Sampling. If the digitised noise (e.g. comparator output from 1 above) is changing faster than the sampling clock, is that going to be a problem? I.e. does sampling in the middle of a fast transition have a bias? If so, that can be gotten around by a low-pass filter, but too much will increase correlation (i.e. adjacent bits will be more likely to be the same than different).
3. Rejection of interference. Calculating the difference between two noise sources will eliminate common interference. But then sampling both noise sources and taking a bigger hit in the conditioning step might work out better in the end.

e the

erate

slow"

bits as

py that

a rate.

ic,

e ? e

I believe the paper cited ran the data into a counter for an appropriate time, and then selected a zero if the resulting count was even and a one if odd. Of course, if all they are looking at is odd- even, they only need a 1-bit counter.

I'd be very nervous about any sort of amplitude-sensitive scheme. I've measured shot noise to have Gaussian amplitude statistics within 0.1 dB out to 7.1 sigma (threshold crossing rate < 1E-11 * BW), but I'd expect that the kind of precision you need for good randomness is much higher than that, not to mention possible vulnerability to hardware hacks and cell phones.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
ElectroOptical Innovations LLC 
Optics, Electro-optics, Photonics, Analog Electronics 

160 North State Road #203 
Briarcliff Manor NY 10510 

hobbs at electrooptical dot net 
http://electrooptical.net

Just start with something like zener noise and run it through a good digital scrambler.

--

John Larkin         Highland Technology, Inc 
picosecond timing   laser drivers and controllers 

jlarkin att highlandtechnology dott com 
http://www.highlandtechnology.com