Random Seed using Micro controller floating pin

[Unordung]

Hello,
I recently created a simple project (electronic dice) which required a random function using the Arduino development platform. In this project I opted to use the random function with an analog Read as the seed.
Previously I had discovered that using this function I would consistently get higher numbers on the output of the function (once I created a box plot of the data).
To counter this I created a PCB based Antenna which in theory would amplify random noise and in turn provide a more random output.
Once I tested the results and created a histogram the results, did indeed seem to level out with no statistical outlier.

My question is, am I insane or did I get lucky?

The more I think about this the more confused I get. The floating pin is an antenna, it will naturally change its voltage in relation to the background noise. My thought process seems too simple, the bigger pin means bigger variation. Whilst it seemed to work and indeed created a more even histogram, I'm not entirely sure as to why.

To create a PCB antenna, is simply lengthening the trace enough to create a greater variation of noise on the pin?
Is there a more dare I say, "professional" / mature way to approach this using the Arduino platform?
Wouldn't the length of the PCB antenna translate to the frequency being amplified?
Given the frequency of Australian AC, would it make sense to "tune" the antenna to match the 50Hz frequency?

Kind regards,
Unordung

[BrianHG]

I would bias an analog input to 50% vcc and run the adc, summing up the noise in the least 2 significant bits, no antenna.  After accumulating noise from a few k samples, use that number to feed your random number generator.
 

[Psi]

Another way is to combine all the random things you can find on your MCU,
Temp sensor
Floating ADC
ADC of supply rail
ADC of any extra bandgap references

Then store a large array of true random numbers in code/flash/eeprom and use above method to pick the number of positions to increment through the block by each time you need a random number.
This will mask any non-randomness in the floating adc/hardware system which can sometimes pick similar numbers.
But keep in mind the only values it will ever output are numbers in your array. So the array really needs to contain all numbers in the range require unless extra methods are done.

[Rerouter]

Shift your biases, the internal RC clock of an arduino is generally about 1-5% accurate, so you can use the beat frequency between it and the external crystal to make something very hard to externally influence.
https://sites.google.com/site/astudyofentropy/project-definition/timer-jitter-entropy-sources/entropy-library/arduino-random-seed

[soldar]

One of my first projects decades ago was an electronic dice. You put your finger on a pad and you were the antenna collecting random noise. As long as your finger was on the contact the internal counter was counting, when you took off your finger the counter would stop.

A standard way of generating random numbers is by using white noise generated with a reverse  biased transistor emitter.

[T3sl4co1l]

Add to the list of sources: different clock generators.  A classic is measuring the internal RC oscillator to an external crystal oscillator, or really anything else of reasonably known frequency will do.  Sampling one with the other using the capture input, take the LSBs off the count and use that.

Ambient electric fields are a poor source because they're basically mains 50/60Hz, potentially very predictable, also easily manipulated as mentioned.

In general, any source of modest entropy can be used (like these examples), and the resulting bit streams can be "pooled" into a common, higher rate bit stream.  This should then be sent into a scrambling function, like an LFSR or hash function, which generates a balanced 50% output and makes it difficult to predict the output, even if the inputs are known.  Then you sample the statistically clean output and generate dice rolls.

Tim

[soldar]

Add to the list of sources: different clock generators.  A classic is measuring the internal RC oscillator to an external crystal oscillator, or really anything else of reasonably known frequency will do.  Sampling one with the other using the capture input, take the LSBs off the count and use that.

Ambient electric fields are a poor source because they're basically mains 50/60Hz, potentially very predictable, also easily manipulated as mentioned.

In general, any source of modest entropy can be used (like these examples), and the resulting bit streams can be "pooled" into a common, higher rate bit stream.  This should then be sent into a scrambling function, like an LFSR or hash function, which generates a balanced 50% output and makes it difficult to predict the output, even if the inputs are known.  Then you sample the statistically clean output and generate dice rolls.

Tim

IMHO for a 1/6 die no high-quality random generator is needed. Take a divide by 6 counter and a fast-enough pulse stream and that is pretty much all you need.

At 60 Hz you would need to be able to release the button with a precision of 1/60 sec and that is assuming you could see the display which can easily be prevented. That is plenty enough IMHO. But, OK, want more? Use a 60 KHz oscillator. There ain't no one in the world who can time their push of a button with that precision. OK, make it 600 KHz.

[iMo]

My question is, am I insane or did I get lucky?

You did get lucky.
Generating random events/numbers is rocket science. There is only one true random generator known today, afaik - the radioactive decay.

[soldar]

My question is, am I insane or did I get lucky?

You did get lucky.
Generating random events/numbers is rocket science. There is only one true random generator known today, afaik - the radioactive decay.

I disagree as explained in my previous post.

[Domagoj T]

I'll just leave this here: