I would be seriously surprised if this thing actually does 72kbps - 220k/0.1u is too slow for that kind of speed.

Ahh, I see your problem danny. The first stage is not an oscillator in the classic sense. Since the 220k is negative feedback the 393 just unstable away around it's threshold voltage.

 

I documented my work on my 12f675 TRNG here: https://dannyelectronics.wordpress.com/2016/03/19/true-random-number-generators/

It comes with complete code (for XC8) if anyone wants to implement it.

 

@ronv
As I can understand the original asm code, fast counter is incremented until there's a change of level (from 1 to 0) in "digital noise" signal at the input of AVR and if this change is occurring as it should (noise signal period should be faster than 2ms) this asm routine will be executed maximum 8 times to form one new random byte. I've found an image from my scope captured while ago (signal at avr input). You can see the info on average frequency and period. I 've tested the generation of 1+GB of random data and during this long period the device never activated the safety feature or gone into reset, so I don't think there's any missing pulses.

.macro  MaintainRandomPool
xfrp:
        inc tcntv               ; fast counter provides random bits
        in dnnew, PINB          ; load current state of PINB
        andi dnnew, 0b00010000  ; mask port bit 4
        cp dnnew, dnold         ; compare to previous state
        breq xfrpx              ; no changes -> leave
        mov dnold, dnnew        ; remember portbit has changed
        lsr tcntv               ; half tcntv and shift out lsb to carry
        rol rnbyte              ; shift that carry bit into rnbyte
        dec rnds                ; round count down for a new random byte
        brne xfrpx
        ldi rnds, 8             ; re-set round counter to 8
        ld robyte, x            ; load older random byte from current X
        eor rnbyte, robyte      ; xor old+new random byte
        st x+, rnbyte           ; store new byte in X and increment X
        cp  xl, rpel            ; check for last address in RP reached
        cpc xh, rpeh            ;
        brcs xfrpx              ; if not overrun, leave
        movw xl, rpsl           ; else point back to RP start address
xfrpx:
.endmacro

@dannyf
About the 72kbps "speed of delivery", I've done 50+ consecutive tests for writing 1024 random KBytes (1MB) into a file. I've measured the time from start to finish for each test, and they were all between 113 and 114 seconds long. This gave me 1024KB/113s = 9KB/s or 72Kb/s.
I know this is not the proper way to calculate, but ...
Can I assume the following:
After I issue the "start delivery of 1MB" command to device, for each random byte that I request some time is needed, and to receive each random byte from device, there's also some time, and I also need to take into account start and stop bits..., so how to characterize the speed of my device? When someone tells "the speed of RNG is X bps", what that really means?

 

@dannyf
Missed your last post and link toproject
Awesome work and a lot to think of, thank you!!!

 

This gave me 1024KB/113s = 9KB/s or 72Kb/s.

That's the right calculation.

The firmware could be changed so that it just transmits once powered up. It is much less useful if it has to wait for a command from the PC.

 

I've built a double RC oscillator accoriding to @dannyf suggestion (one hc132 and one 4070), but I'm still waiting for a friend to lend me oscilloscope, so I can't say exact frequency (it should be around 1MHz, used 1nF and 1k1). What I can confirm is that my device using this new "noise generator" takes exactly the same 113 seconds to deliver 1MB of random data
More to come...

 

I can confirm that "xored double oscillator" circuit is working. I have ~1.5MHz "random period" square wave signal.
I'm still waiting for Attiny85 dev board to arrive (didn't want to use my existing RNG setup) and in the mean time I've tried to do some tests with my Arduino Uno.
No matter what I try, statistical characteristics and entropy of acquired bytes are very poor, almost unusable.
The idea is to use the ISR that reads input pin, and in the loop() I form a byte which is finaly sent to serial port. The values are captured in putty log and further tested using dedicated SW. This is working rather fast (tried up to 1Mbps), but I think that this approach isn't good because it reads and writes too many consecutive 1s and 0s (resulting byte doesn't apeare random at all). Tried also to use LSB form millis() but I'm probably doing it wrong so...
On to more reading, trials & errors!

 

Both xor and and/nand will work, as long as the two oscillators are sufficiently different, as the phase noise is small.

As to your arduino approach, if you had use the stock arduino adc, it will not work - that piece is incorrectly code by the arduino folks and I have done enough work to prove it.

If you used the phase noise approach there, a potential downfall is the slow arduino gpio routines that limit the resolution.

 

I expanded my random number generator to produce parallel bits. See the update at the bottom of the page here: https://dannyelectronics.wordpress.com/2016/03/19/true-random-number-generators/

Schematic + waveform attached.

It uses a low frequency relaxation oscillator (1Khz+ in my case) to gate a high frequency oscillator (4Mhz crystal oscillator in my case). You can lower the frequency of the clock signal to drive leds visually, or to increase it to deliver high data rate random bits.