Post
Topic
Board Project Development
Re: I am going to build a true random number generator ...
by
bucktotal
on 09/04/2014, 22:21:26 UTC

The source or the tube however isn't going to be the bottleneck (at least through 1 kbps).  The hard part is going to be getting a timing circuit which can register events with sufficient accuracy.  We are talking an average interval of 500 microseconds so a timer with microseconds scale accuracy (or at least tens of microseconds) is going to be necessary.  This is beyond the capability of most micro controllers, and it probably going to mean a dedicated real time clock ( something like http://www.maximintegrated.com/datasheet/index.mvp/id/4627/ln/en ).  

As a proof of concept I am going to start out without a RTC but that means much lower timer accuracy and lower throughput first.  Something in the order of <3,000 cpm which produce ~24 bps of entropy.  Even that will depend on micro controller having true 1ms clock accuracy.  For the early test I am going to use a gas lantern mantle (thorium & beta emitter) as the particle source.


noticed this statement here.... not sure if its been mentioned already but i regularly use the latest 32-bit microcontrollers from Arduino (Due) and chipKit (Max32). they can both run an accurate microsecond counter with 10s of microsecond program loop-time. so it seems well within needed resolution. processing the timestamps using some logic statements will increase the loop-time but i think you can very likely keep it under 50us.


edit: did some tests using a fairly reliable pulse generator (AMPI master-9, stated at <4us accuracy for up to a few days of running time)
 
1) loop-time of the max32 running only a microsec counter and a digitalWrite pin (TTL output) is about 5us loop-time

2) adding a serial connection (usb) and a printTimestamp routine to print the microsec timestamp is about 10us loop-time

3) adding a digitalRead routine with a 500hz square input on the pin takes us to about 45us
- printed timestamps have about a 2us jitter over a 2 min recording

4) adding another digitalRead routine on a second pin with 60hz input has little to no effect

... after 20min of testing, seems <50us was a decent guess Smiley