ADC linearity at high frequency with ATmega328

Go To Last Post
44 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I suspect this is a question for ADC experts -- those who know a lot about the inner workings and foibles of ADCs.

 

The background: I've created a noise source using an avalanche diode with the following characteristics: Bandwidth (roughly) 500kHz, Amplitude 370mV RMS, about 2V pk-pk. The signal has been analyzed using a Tek scope with a record of 12.5M samples and shows a very flat power spectrum (estimated using the Welch method). This signal is connected to one of the ADC input channels on an ATmega328.

 

The ADC is running with 125kHz clock (9.6kS/s) -- it is intentionally undersampling -- aliasing is desirable for my purposes (true random number generation). The ADC has 3.3V Vref and the ATmega is running at 5V with 16MHz system clock. The RMS value of the ADC data is about 330mV which is a good indication that the analog input bandwidth is close to the signal bandwidth and that I'm getting a lot of aliasing (since the input signal is 370mV RMS). Because the noise doesn't span the entire ADC input range, only the 8LSBs are being used (a total range of 825mV).

 

So here's the issue. When this data is analyzed some odd behavior is found. Taking a large sample of data (e.g. 10 million values), the number of occurances of each bit value (0..255) is counted and graphed (attached image). Some values are quite a bit less likely to occur than others -- and this behavior has an exact periodicity of 16 ADC counts. For example, values with the four LSBs 0011 are much more likely than those with LSBs 1011.

 

This really smells like an issue with the ADC, and if so it may well have something to do with the high frequency content of the input signal. Any thoughts or suggestions for figuring this out would be appreciated.

 

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

aweatherguy wrote:
When this data is analyzed some odd behavior is found. Taking a large sample of data (e.g. 10 million values), the number of occurances of each bit value (0..255) is counted and graphed (attached image).

Since this AVR can not hold 10M samples, how is the data transmitted to the host system?

Can you post your code so we can see how the ADC is being read and the data is being transmitted.

 

Jim

 

 

Keys to wealth:

Invest for cash flow, not capital gains!

Wealth is attracted, not chased! 

Income is proportional to how many you serve!

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This may be the lecture to start with.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sure, some more detail. This is running on an Arduino Uno, with code compiled in that environment. Reading the ADC just looks like this, which I believe should read ADCL/ADCH registers in the proper sequence and format the 10-bit result into a uint16_t. The ADC is configured with right-justified result. That's followed by an assignment to extract only the 8 LSBs.

 

uint16_t rdg; rdg = ADC; uint8_t lsbs = rdg;

 

Data is transmitted over USB with the Serial class. The serial port is configured at 1Mb/s baud rate which is more than adequate to keep up with the data being sent. Each byte requires 3 chars over USB -- two hex digits and a line feed (I'm not using println()), so at 10-bits per char that's 30bits x 9600 = 288kb/s, well under the 1Mb/s port config. Each char including the line feed is sent with a single call to Serial.print( char ).

 

Then I just run a puTTY terminal to log the data until the desired number of samples is collected. 

 

Is that enough detail, or would you like me to post the entire program (it's maybe 70 lines or so)?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

aweatherguy wrote:
10-bit result

You not need 10b. Change the ADC to measure 8b only, and compare results.

If you read proposed thread in #3, then you should answer: what you are measuring.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There may be some confusion about why I only use 8 LSBs. The noise voltage input does not span the entire 0...3.3V ADC input range, and therefore the two MSBs do not contain meaningful data. If I switch to 8-bit mode, then I'll still be measuring the entire 3.3V input range and the two MSBs will still be useless for my purposes.

 

What I'm trying to measure is heavily aliased noise, for the purpose of generating true random numbers. I'm not trying to reconstruct the original signal or estimate its frequency spectrum. While normally the Nyquist sampling theorem would be of prime importance, here it is of zero interest.

 

What I am trying to figure out is why the distribution of the acquired ADC data does not have a uniform distribution, as it should when measuring noise, but in fact has an odd periodictiy with peaks in the distribution every 16 ADC values.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

aweatherguy wrote:
The background: I've created a noise source using an avalanche diode ...

...

This really smells like an issue with the ADC, ...

...

Have you considered instead the analog comparator?

Reason : AoE TRNG avalanches a bipolar transistor, amplified and bandpassed, sampling analog comparator, cPLD (sampled bits into characters), UART

Uncertain a mega328's AC is fast enough for this use case; XMEGA32E5 AC may be fast enough (AVR DB AC?)

 

The Art of Electronics 3rd Edition | by Horowitz and Hill

Download a sample chapter

[page 18, bottom of left column]

13.14.7 “True” random noise generators

Analog Comparator Specifications | AVR® DB Family

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sounds interesting.

 

My brain is too old to calculate the impact of the aliasing upon the flatness of the sub-band, (0-125 KHz).  I’ll simply mention that that was not the setup when you evaluated the signal’s flatness with the Tek scope.

 

I agree, your current data doesn’t look too flat… 

 

Probably not the issue, but certainly a point of interest.  What is the output impedance of the stage driving the ADC?  Obviously, you want this to be a very low impedance driver, and it should have a high enough BW so as not, itself, to filter the input signal it is passing.   Somewhat related, I do not know the characteristics of the ADC’s S&H circuit with a signal that is varying widely over the (brief) sampling interval.  That is not the normal state of affairs, for most signal processing that complies with Shannon-Nyquist.

 

I suspect two reasonable tests would be to:

  1. Use an external Vref, via the Vref pin, and configuring the ADC to use that reference source.  Then get and use a very stable ext Vref signal against which the ADC is making its measurements.  That would help to tell you if the Analog Voltage Bus inside the chip is varying as a function of the various steps in the ADC’s multi-step process.
  2. Get an External ADC chip, (Analog Devices, or other), and make similar measurements of the Vsource using it, with a very, very clean power supply, (i.e. a well filtered and By-Passed ADC chip running on a battery).  In this case, the analog measurement process is contained totally within the (clean, stable) ext ADC, and the micro is only contributing its digital reading of the ADC chip and passing the data through to the USB channel.

In this case, if the present non-flatness is in fact internal ADC related, then the new signal should be flat.

If the new signal is again not flat, then one might suspect the signal source is being contaminated by changes on its supply, (or ground) rail, or even perhaps some radiated EMI, (?).

 

I assume that the signal generator is running on its own, very clean, battery power supply, at least for now.

 

Remember, you expect the distribution of the input voltage across the stair-step ADC thresholds to be flat.  So any trace variability in the Vref will slightly shift the exact threshold voltages at each stair-step level.  Tiny variations within the middle part of each stairstep level go unnoticed, as they are too small to cross an ADC stair step threshold level.  But small variations right about the switching point will influence whether you get the lower step or the next higher step as the output value.  It will, obviously, only impact the LSB, as the variations are too small to impact the outcome of the higher order bits.

 

Another test you can run is to look at the flatness of your signal if you ignore the bottom 1 or several bits, to totally avoid the micro-threshold voltage jitter issue.  If you just look at the upper 6 bits of your 8 bit data is that flat?  And if so, and you then ignore the lower 2 bits and move on?

 

Interesting problem.

 

JC

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting idea...worth a try. Comparing the noise source to its average value would in theory give a bit stream with equal numbers of ones and zeros. With the source I have, sampling the AC output every 2-4us would give me an equivalent data rate too. The spec'd AC prop delay of 500ns makes me think that a sample every 2us might be within reason. I'll give it a shot and see what happens.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you 100% positive you are forming your histogram without error?

 

Instead of using the ADC,  supply  a count 1.2.3.4.5...255,  1,2,3,...255, 1,2,3 (exactly as though read from the adc  result register) etc for 10 million. samples..then your histogram better come out flat...if not, you know it is not being created properly.

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC: Thanks for your thoughts. Attached is the schematic of the noise source. It's powered by the same 15V DC input that drives the Uno board, and that's from a wall wart, so definitely not an ultra clean battery supply for now...but I could temporarily substitute a couple of 9V batteries in series perhaps as a check. Note that the input filter capacitor C2 is not 47uF as indicated, but a 330uF aluminum electrolytic which has a reasonably low impedance up to 1MHz.

 

The output is level shifted to the midpoint of the ADC Vref (3.3V for now), and I could at least put some heavy analog filtering on the 3.3V supply (aka ADC Vref) to see what difference that makes.

 

The noise source output impedance is 2k ohms so should be low enough for the ATmega analog inputs. I don't see any obvious degradation of the waveform at the analog input that's synchronized with ADC sampling. However, I could hack in an op-amp buffer to be sure.

 

Both the Tek scope data and the 8 LSBs from the ATmega show a very flat power spectrum.

 

As it is, the output data rate is just barely fast enough, so if I start throwing out more bits that could be a problem. To get rid of the 16-value periodicity I'd have to throw away 4 bits, cutting the output rate in half.

 

You've suggested a couple experiments that could eliminate some possible causes, and I'll work on carrying those out. 

 

I'm also going to try the other suggestion of using the analog comparator to see what happens there. Reading the comparator once every 13us would give the same effective output bit rate. I'll need to calculate the autocorrelation function on the Tek scope data to get an idea of how fast I could reasonably sample the analog comparator to keep the individual samples uncorrelated.

 

 

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the suggestion. Checked that and its working correctly. FYI, here's the Octave code used to compute the histogram -- the data is in the "b" array.

 

nvals=zeros(256,1);
for k=0:255
    idx=find(b == k);
    nvals(k+1)=numel(idx);
end

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmm...your random gen has a relatively hi  Zout for what the ADC likes to see...wonder if its ADC sampling cap (with the high Z) is supplying some "smoothing"  ...certainly any smoothing might change things a bit.  

Can you use a  unity buffer to drive the ADC?   Of course any buffer adds its own flavoring to the noise cauldron. 

 

What does the scoped wave at the adc pin actually look like (over a few hundred or thousand samples)

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Sat. Jul 31, 2021 - 04:21 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think I would try another, much slower signal source as an additional test.  Maybe a function generator putting out a triangle wave at 100 Hz or so.  See if the 4 LSBs look any different.  Maybe even increase the frequency 10x and test again, until something interesting shows up.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

aweatherguy wrote:
uint16_t rdg; rdg = ADC; uint8_t lsbs = rdg;

So how does that code wait for a conversion to complete before reading the ADC value? 

Why not use the AnalogRead() function? 

An ADC read takes 13 clocks to complete the conversion before a full 10 bit value is available, perhaps your sampling rate is reading the successive approximation in progress of the ADC register.....

 

Jim

 

 

Keys to wealth:

Invest for cash flow, not capital gains!

Wealth is attracted, not chased! 

Income is proportional to how many you serve!

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm a bit rusty on this signal analysis stuff but should we not expect a normal distribution of amplitudes from a "perfect" noise source ?

 

I might try an audio analysis program on that large dataset. You could import as raw 8-bit mono. An FFT would be interesting.

 

[Edit]

Hey I just noticed this:

aweatherguy wrote:
uint16_t rdg; rdg = ADC; uint8_t lsbs = rdg;

That's wrong - you need to scale a 10-bit value onto an 8-bit value. You can't simply truncate, but you can perform this scaling by shifting a right-aligned value down by 2-bits or a left-adjusted value down by 4-bits.

 

Now where did I read about 4-bits being a relevant factor ...

 

 

Last Edited: Sat. Jul 31, 2021 - 03:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

N.Winterbottom wrote:

I'm a bit rusty on this signal analysis stuff but should we not expect a normal distribution of amplitudes from a "perfect" noise source ?

All you sparkies and math whizzes will need to thresh that out.  But I do have quite a bit of experience in using AVR8 ADC in production apps.  To summarize my past participations:  The AVR's ADC is much maligned.  Yeah, it is only 10 bits and yeah it is modest speed and yeah if you add up all the error numbers you plumb run out of LSBs.

 

But in practice, one is hard-pressed to quantify the real offset error and non-linearity and such in normal operation.

 

Whoa, you say, look at OP's data!  To that I'll point out all the times that the "problem" turned out to be mains hum.  On the signal; on AVcc; on the ref.

 

So, my first approach here wouldn't necessarily be the numerical analysis textbook.  These cyclic problems here:  What is the timing?  Now, let's change the ADC clock -- how do the symptoms change?

 

Don't change?  Let's change the environment just a bit, varying only one factor at a time.  Location, power source, shielding, and similar.  Oh, yeah -- how many different samples, and how close to identical are each?

 

Let's say the above uncovers a situation -- that doesn't help OP's aim of the good noise source.  But it allows a rational approach going forward.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry that I left some stuff out there...that code runs in an ISR for ADC conversion complete. I was only just showing the code to obtain the ADC bits...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So, hey all -- thanks for all the inputs. And I did find the main problem, which is...wait for it...I'm stupid! The code was printing the nibbles of a hex byte in reverse order. Once I fixed that everything looked pretty reasonable, and the ATmega's ADC reputation is intact. Never mind how the nibbles got put in reverse order...you have to buy me a beer to find that out.

 

What I did end up discovering though is that given the ADC Vref and the random waveform amplitude, there were only about six  really random bits in each ADC conversion. Also, running the ADC at 250kHz (faster than recommended by Atmel) did create some issues with the random data.

 

The idea from JChapman to use the analog comparator may turn out to be the best idea, maybe. Generating a single bit a time by comparing the noise source to it's average value can generate random bits much faster than by using the ADC. Some tests using this technique also yielded some very good random sequences which have good results with computation of entropy and chi-squared. The one possible gotcha is that the result is fairly sensitive to the reference voltage on the comparator -- if you want to get an equal number of 1's and 0's. The ATmega analog comparator has a large input offset spec (40mV)  and probably a fair bit of temperature drift. It might be necessary to use an external precision comparator to make this approach work.

 

Anyway, I've temporarily given up on the ADC idea and am exploring the comparator approach further. Thanks again for all the inputs!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:

Hmm...your random gen has a relatively hi  Zout for what the ADC likes to see...wonder if its ADC sampling cap (with the high Z) is supplying some "smoothing"  ...certainly any smoothing might change things a bit.  

Can you use a  unity buffer to drive the ADC?   Of course any buffer adds its own flavoring to the noise cauldron. 

 

What does the scoped wave at the adc pin actually look like (over a few hundred or thousand samples)

 

The ADC pin waveform actually looked pretty decent...and if I hadn't screwed up the output data, the data would have looked much better (see previous post). I don't think the impedance was an issue, but only getting six usable bits on each conversion was an issue. I could have rescaled the random signal, or adjusted ADC Vref to improve that, but I'm trying to keep part count to absolute minimum. 

Last Edited: Sat. Jul 31, 2021 - 11:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The code was printing the nibbles of a hex byte in reverse order. 

If the values 0-255 are all equally likely, then the actual ordering of the bits shouldn't matter.  Each bit position would appear as 1 in half the samples.  Perhaps if only a subset of the values are randomly encountered (say from 45 to 118) then rearranging the bits might leave some gaps or pattern. 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

aweatherguy wrote:
The ATmega analog comparator has a large input offset spec (40mV)  and probably a fair bit of temperature drift.
Not an issue with enough amplification into the analog comparator.

mega328 follow-on is in AVRxt (mega3208, AVR Dx)

aweatherguy wrote:
It might be necessary to use an external precision comparator to make this approach work.
AoE TRNG did use such in the form of a sampling analog comparator (akin to a 1-bit ADC)

 


AC | ATmega3208/3209 Data Sheet

Analog Comparator Specifications | AVR® DB Family (AVR DB have a few op amps)

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The idea from JChapman to use the analog comparator may turn out to be the best idea, maybe. 

Interesting idea, but what if the comparator is biased (tilted) towards one direction?  If the coin is out of balance, you'd could get more heads than tails..Interesting to try...maybe you'd find 5000005 ones and 4999995 zeros.Of course 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
Interesting idea, but what if the comparator is biased (tilted) towards one direction?
The AoE TRNG has a trim on the reference for the analog comparator.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

aweatherguy wrote:

What I did end up discovering though is that given the ADC Vref and the random waveform amplitude, there were only about six  really random bits in each ADC conversion.

 

That makes sense, as only a truly ideal ADC with precisely equal LSB steps would give identical column heights for each bit.

Real world ADCs have non linearities, (and especially MCU ADCs ) that mean each LSB step is not exactly VRef/2^Bits

 

Is  'six really random bits' not enough for your application ? 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
If the values 0-255 are all equally likely, then the actual ordering of the bits shouldn't matter.  Each bit position would appear as 1 in half the samples.  Perhaps if only a subset of the values are randomly encountered (say from 45 to 118) then rearranging the bits might leave some gaps or pattern. 

 

You are correct. However, since the input waveform did not span the entire range of the ADC, the upper bits were not evenly distributed. When I swapped them and made them into LSBs, the funny behavior ensued. After fixing it, and looking a the distribution of the full 10-bit readings, it was clear that I either needed a bigger signal, or to throw out some MSBs to get random data.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
Interesting idea, but what if the comparator is biased (tilted) towards one direction?  If the coin is out of balance, you'd could get more heads than tails..Interesting to try...maybe you'd find 5000005 ones and 4999995 zeros.Of course 

 

After running some more tests, this turns out to be the key. With proper balance, I get a sequence that passes most of the DieHard(er) statistical tests. Once things get out of balance too much then tests start to fail and the distribution of values becomes skewed. 

 

I think this is going to work but needs some more experimentation with time/temperature stability. The comparator can be sampled at 160kHz, yielding a random byte stream at 20kB/s which is fast enough for my needs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
If the values 0-255 are all equally likely, then the actual ordering of the bits shouldn't matter. 

No - Not even the ADC values over a sub-range of the ADC are all equally likely.

 

I's a moot point now that the Comparator Method is being trialled, but the distribution of sampled amplitude for Johnson Noise does indeed turn out to be Normally Distributed.

 

I said I was rusty in #16 so I had to look it up:

https://www.allaboutcircuits.com/technical-articles/introduction-to-statistical-noise-analysis-basic-calculations/

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not even the ADC values over a sub-range of the ADC 

That's an excellent point. . He started talking about uniform distribution; then the above comment could apply..However, it does seem much more likely to be a Guassian distro...wonder why we jumped on the uniform distribution wagon?  Maybe  thinking about the flat spectrum? 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

aweatherguy wrote:
With proper balance, I get a sequence that passes most of the DieHard(er) statistical tests.
The data from the AoE avalanche TRNG was input to a process of multiple sampling and shuffle and DES and XOR to result in a reference sequence; some XMEGA have a DES instruction, XMEGA AC can generate events that can be counted in a TC via EVSYS.

aweatherguy wrote:
... but needs some more experimentation with time/temperature stability.
Concur as a possible issue even with enough amplification (integrated 1/F noise affects offset relative to duration)

Might be possible to null the AVR's AC offset by an external zero-drift op amp.

 


Numerical recipes art scientific computing 3rd edition | Numerical recipes | Cambridge University Press (on the CD-ROM is directory "Museum")

Instruction Set Summary | AVR® Instruction Set Manual

Table 2. Arithmetic and Logic Instructions

[bottom]

DES

Documentation | ATXMEGA128A1U | Microchip Technology

AVR XMEGA AU Manual

 

The Art of Electronics 3rd Edition | by Horowitz and Hill

Download a sample chapter

[page 12, top right]

5.11.4 Auto-zero miscellany 340

E. External auto-zero  341

 

edit :

Numerical Recipes : The Art of Scientific Computing

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Mon. Aug 2, 2021 - 04:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

aweatherguy wrote:
... but I'm trying to keep part count to absolute minimum.
Attach a crypto-authenticator?

Reason : TRNG

FULLY CUSTOMIZABLE SECURE ELEMENT | Microchip Technology (ATECC608B, search for RNG)

https://github.com/MicrochipTech/cryptoauthlib/blob/main/lib/calib/calib_random.c

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

aweatherguy wrote:
With proper balance, I get a sequence that passes most of the DieHard(er) statistical tests.
re AoE avalanche TRNG :

Incidentally, the raw output of the Hororan box easily passes all of the tests in Marsaglia's "Diehard battery of tests."

That box does an XOR.

You may be very close.

 


GitHub - jeffThompson/DiehardCDROM: A re-creation of the original Diehard random number CD-ROM

[mid-page]

The Diehard has since been updated and renamed Dieharder by Robert G. Brown of the Duke University Physics Department.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

interesting:

Marsaglia Random Number CDROM, Including the Diehard Battery of Tests of Randomness, pressed in an edition of "several hundred copies" and given away for free. The CD-ROM also included 60 files containing a total of 4.8-billion random bits, an "unassailable source for those who absolutely positively have to have a large, reliable set of random numbers of serious simulation studies."

Well, I guess they were no longer an unassailable random source!! ...hey buddy I know what your random values are!!!

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
Attach a crypto-authenticator?

Reason : TRNG

 

Okay, I misspoke...what I meant was I wanted to keep cost to absolute minimum. 

 

I think I've finally arrived at a good answer, tested and working well:

 

* Use the avalanche diode source as indicated in the schematic earlier in this post. One cheap transistor, a diode and a couple resistors.

* Offset the output (about 8V average value) down to 1.65V average with 2 resistors and a capacitor.
* Add an LMV331 comparator ($0.35US from Digikey in tensies)

* Create a very cheap 6-bit DAC using six digital outputs from Arduino board (e.g. D2..D7, aka PD2..PD7), and 12 resistors to make an R2R ladder (about $0.50US). This is used to adjust the reference voltage for the comparator.

* Resistively sum the DAC output with a voltage divider on the 3.3V supply to generate the comparator reference voltage.

 

A schematic of this is attached to this post. Note the comparator shown is an LMV761 because it has push-pull output. Could be changed to LMV331 with addition of hefty pullup resistor on output. The voltage divider for the comparator reference will need to be hand-trimmed so that the DAC output covers the range of temperature drift. Not suitable for mass production! 

 

Firmware generates the random sequence by sampling the comparator at fixed intervals (9usec used in my tests). These bits are used to make bytes and then output as hex chars over USB. Roughly at 14kB/s in my tests.

 

The count of ones in large block of data (e.g. 200k bits) is monitored and used to adjust the DAC to produce something very close to 50% ones -- e.g. values of 50.001% are typical. This is absolutely crucial for passing many of the Diehard(er) tests.

 

This prototype now produces data streams that, when collected in 50-100MB blocks, will pass nearly all Diehard(er) tests, and sometimes all of them with only a couple of weak results. 

 

 

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why mess with 20 resistors  & trim adjustments etc?  Why is the background solid black??---that will deplete your ink/toner pretty quick!

 

Just use a timer to set a pwm and an RC filter , then you will have an adjustable voltage.  A 16bitter timer will give you 65000 settings...you can even scale the range so it just tweaks the random value over a small range (s  you get 65000 levels over a narrow span).

 

Use an RC feeding into another RC...will be nice and smooth.   

 

Note also your supply voltage(s) play a big part in all of this entire scheme(s)...so those need to be stable & paid attention to, if you want 50.00000000% balance.

 

Your comparator is missing a positive feedback resistor, which is a big no-no, as the output can then be very noisy....but maybe you'd like that!!

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

aweatherguy wrote:
* Create a very cheap 6-bit DAC
fyi, the follow-on to megaAVR have a DAC.

A digital potentiometer has switched resistors; some are non-volatile.

aweatherguy wrote:
Not suitable for mass production!
A zero-drift op amp can compensate for analog comparator's offset and offset's temperature drift (AC couple the noise source)

aweatherguy wrote:
... and sometimes all of them ...
Well done!

 


DAC - Digital-to-Analog Converter | Migration from the megaAVR® to AVR® Dx Microcontroller Familie

Features | DAC | AVR® DB Family

DAC Support | GitHub - SpenceKonde/DxCore: Arduino core for AVR DA, DB, and future DD-series parts

https://octopart.com/search?q=avr32db28&currency=USD&specs=0&in_stock_only=1

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If the noise amplitude after a Comparator is satisfactory- seems that instead of an ADC, T0 or T1 may be used. Reading TCNTx may provide 8 random bits.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:

Why mess with 20 resistors  & trim adjustments etc?  Why is the background solid black??---that will deplete your ink/toner pretty quick!

 

Just use a timer to set a pwm and an RC filter , then you will have an adjustable voltage.  A 16bitter timer will give you 65000 settings...you can even scale the range so it just tweaks the random value over a small range (s  you get 65000 levels over a narrow span).

 

Use an RC feeding into another RC...will be nice and smooth.   

 

Note also your supply voltage(s) play a big part in all of this entire scheme(s)...so those need to be stable & paid attention to, if you want 50.00000000% balance.

 

Your comparator is missing a positive feedback resistor, which is a big no-no, as the output can then be very noisy....but maybe you'd like that!!

 

SMT resistors (0603) are about $0.015 each, so the 12 resistors comes to $0.18...not a big deal. The PWM idea would work too, but I prefer this solution. I think it boils down to personal preference. For a bit more money, 8-bit R2R ladders are available in SIP format, but are not as easy to find in stock. If those digital outputs were needed for something else, the PWM idea would be more attractive.

 

Supply voltage stability is not a problem, thanks to the adjustable offset. It cures all manner of drifts -- temperature supply voltage, etc. Tests were run with a cheap CUI 15V wall wart for power with no supply stability problems. 

 

The comparator does not need a feedback resistor. It works fine as is, as evidenced by the waveforms observed in operation. This partly has to do with the nature of the waveform, but the bottom line is that positive feedback is not necessary in this application.

 

A zero drift op-amp would help with drift, but adds cost and there would still be other residual drifts to deal with, so an adjustable offset would still be required. 

 

One thing I discovered is that the average value of the noise waveform is different than the median value, so getting 50% ones out of the comparator requires an offset from the average value set by the voltage divider (a few 10's of millivolts). I don't know if that changes from diode to diode but it might. It also might vary with temperature. I haven't experimented with different diodes yet but that's on my todo list.

 

Some specifics on the PWM idea: With a 16MHz MCU clock and no prescaling, Timer 1 would generate a 244Hz waveform, requiring a low pass filter with cutoff between maybe 3Hz and .03Hz to smooth the result. Capacitor values of at least 10's of uF would be required. That's for 16-bit resolution. For only 8-bit resolution (which would be more than adequate), things are easier with a 62kHz  waveform and filter bandwidths between 6Hz and 600Hz could be considered.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Supply voltage stability is not a problem, thanks to the adjustable offset. It cures all manner of drifts 

Not sure what you mean by that---if the supply moves a couple dozen mv & shifts the trip point or other parameter a fraction of that, seem like it could easily skew statistics measured in parts per million or billion. 

Yes, you could recalibrate at some point, but you would have already generated/used the skewed data.  

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

aweatherguy wrote:
Tests were run with a cheap CUI 15V wall wart for power with no supply stability problems. 
SMPS switching frequency will alias due to typically low PSRR at those frequencies.

AoE avalanche TRNG has jelly bean voltage regulators (non-LDO) on a 12V power supply.

AoE describes reducing wall wart's noise by a capacitance multiplier (jelly bean NPN, two resistors, one capacitor)

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:

Not sure what you mean by that---if the supply moves a couple dozen mv & shifts the trip point or other parameter a fraction of that, seem like it could easily skew statistics measured in parts per million or billion. 

Yes, you could recalibrate at some point, but you would have already generated/used the skewed data.  

 

Sorry if I haven't explained everyting clearly. The firmware running on the AVR is measuring the percentage of ones in the bit stream, and periodically adjusts the offset voltage to keep the percentage as close to 50% as possible. Supply voltage shifts are easily compensated for in real time with this method.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
SMPS switching frequency will alias due to typically low PSRR at those frequencies.

 

AoE avalanche TRNG has jelly bean voltage regulators (non-LDO) on a 12V power supply.

AoE describes reducing wall wart's noise by a capacitance multiplier (jelly bean NPN, two resistors, one capacitor)

 

SMPS noise from the wall wart is managed as follows, and AFAICT is not a problem -- i.e. it does not cause any issues with statistical tests, including FFT analysis of the bit stream. Items (2) and (3) below are on the Arduino board. Item (1) is part of the TRNG circuit.

 

1) The power source for avalanche circuit is filtered with RC low pass filter, 100 ohms and 820uF, which has reasonably low impedance past 1MHz (as measured with HP4275A LCR meter).

2) 15V runs through a MC33269D linear regulator with 47uF/100nF capacitors on output -- which I suspect will do a decent job of removing SMPS noise. This is the 5V supply used for the comparator. 5V will be polluted by current draw from the ATmega328 and ATmega8U2 processors however. PSRR is not usually specified for comparators, but I doubt that what little SMPS noise survives the linear regulator and it's output filtering to the 5V supply would cause much problem with the comparator.

3) The remaining circuitry depends on a clean 3.3V supply, which is generated from the 5V supply by an LP2985 linear regulator plus 1uF output filter. There is no load on this supply on the Arduino board, and virtually no SMPS noise should get through there.

 

About the only thing not considered here is noise conducted by poor PCB layout and/or radiated noise, and if that were a problem it should show up in some of the statistical tests.

 

Just for fun, I'll see what noise I can measure on the three supplies and post some images here.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


Here are the promised measurements of power supply noise. Surprisingly good for a cheap wall wart.

 

Measurements made with a Tek MSO2024B scope and P2220 probe set on 1X. This has an advertised bandwidth of 6MHz and spectrums are shown out to 10MHz. Scope records are 1.25M points long, sampled at 1Gs/s. The scope was isolated from AC ground and several turns of the scope probe coax were wrapped around a high permeability RM core to create a common mode choke.

 

Spectrums computed using the Welch method of averaged periodgrams with each scope record split into ten non-overlapping segments.

 

The first two graphs show measurement noise floors, first with the scope probe shorted out and floating, then connected to ATmega ground (common mode noise). There is very little common mode noise apparent over this bandwidth.

 

Next is the 15V wall wart measured at the Arduino Vin pin, and after R-C filtering. Although SMPS noise is apparent, it is fairly low in amplitude (no more than a couple mV or so in total), and reduced below the noise floor by R-C filtering.

 

Finally, the 5V and 3.3V supplies. Noise on 5V, although elevated, is still quite small and much reduced from that on the 3.3V supply.

 

The bottom line is that noise from the 15V wall wart is not that bad to begin with, and well handled by filtering and linear regulators on the various supplies.

 

[moderator: the attached picture...]

Attachment(s): 

Last Edited: Fri. Aug 6, 2021 - 08:47 AM