Seeding the random number generator is occasionally discussed on the forum. I think I have something that works well. The technique generates about 150 KB of data per day. Which is probably fast enough for seeding the Arduino random number generator (~2.5 seconds).
But it will take approximately 77 days (ouch!) to generate enough data to perform proper statistical tests. The help I need is rather simple. I need lots of people to run a Sketch, collect the binary data, and send me the file(s). If you would like to help, please reply or send a Personal Message.
Seeding a random number generator selects where in it's sequence you would like to start- but the sequence itself is actually a formula which returns the sequence the same each time. Since it's a long, that gives us +- 2.1 billion positions, or a 4.2 billion number sequence (non repeating). That alone is a big number base, effectively more random than can be predicted.
I've always seeded random with a floating analog input.. that gives 1024 potential start points out of the roughly 4.2 billion number sequence- though I suppose the actual seeds float around 512 in a bell curve type thing, I don't think analogread on a port returns a flat profile for returned numbers- so the noise may be clustered around the center. If we throw a couple more reads at it, and shake it up, we'll get a wider number of potential start points, making it that much more random.
The seed is Long, -2,147,483,648 to 2,147,483,648 - which selects a start point in the sequence. How about:
Three analog reads, giving a total of 102410241024 (over a billion, a quarter of the entire sequence) potential start points in the random sequence... done a random number of times (1-100 that is). That's MUCH more random than can be predicted, effectively making it as close to totally random as one can get without getting funky with their own algorithms.. and even then, you are just making your sequence and substituting yours for the system's.
Random is random if the sequence cannot be predicted from the outside.
What about using 32x the last bit as it fluctuates the most, something like
unsigned long getSeed()
{
unsigned long rv = 0;
for (int i=0; i<32; i++)
{
if (analogRead(0) % 2) bitSet(rv,i);
delay(rv%5); // give the ADC some time to fluctuate
}
return rv;
}
I like the idea and I hope to do some more testing on it.
But I can imagine a potential problem. Typically, a seed is generated when power is first applied (in setup). At that point, the processor is presumably still warming. This could create a pattern in the readings.
And I know of a problem. The ATtiny85 processor always returns even values when reading the internal temperature sensor. Well, I can't say they all do but mine do. According to the datasheet, that is actually within the specifications.