# Further on Arduino Random Numbers…

After my previous article on Random numbers I posted on the Arduino forum looking for similar experiences.

One big result of the responses: a second, simpler way to generate the numbers. It’s based on not the change in values, but simply the least significant bit of each value, which fluctuates considerably. According to the Wikipedia article on hardware random number generators, it qualifies as random, but is still in need of debiasing (turns out that ‘unbias’ is not the proper term!)

The result? A simple, somewhat random, but biased option is the following code:

```unsigned long seedOut(unsigned int noOfBits)
{
// return value with 'noOfBits' random bits set
unsigned long seed=0;
while (noOfBits--)
return seed;
}```

You no longer need bitOut() from the previous code, and that removes the two static longs used in that function, for eight bytes of valuable memory saved.

This function leads to a pretty good spread of values, and seems random enough, even without the biasing. I’d recommend it as the seed for the randomSeed() generator, but it’s fast enough to use directly if you prefer. However, in that case, I think you should still debias it with the following code:

```unsigned long seedOut(unsigned int noOfBits)
{
// return value with 'noOfBits' random bits set
unsigned long seed=0, limit=99;
int bit0=0, bit1=0;
while (noOfBits--)
{
for (int i=0;i<limit;++i)
{
if (bit1!=bit0)
break;
}
seed = (seed<<1) | bit1;
}
return seed;
```

The ’99’ in the code is the bias limit – adjust as you want, in line with what I mentioned in the previous article.

Finally, if you just need a ‘good enough’ random generator for most projects, here’s one you can use to seed the internal random generator easily, in just a few lines of code in the setup() function:

```unsigned long seed=0, count=32;
while (--count)
randomSeed(seed);```

For most projects (ie just about everything aside from commercial grade encryption I suspect), this code should do the job.

SOME ITEMS YOU MIGHT ENJOY
Micro USB UNO R3 MEGA328P with CH340 CH340G Board for Arduino
 \$6.49End Date: Thursday Mar-22-2018 17:55:30 PDTBuy It Now for only: \$6.49Buy It Now | Add to watch list
NEW Arduino compatible UNO R3 ATMEGA328P CH340G Board + USB Cable + wires
 \$5.50End Date: Wednesday Mar-21-2018 19:29:05 PDTBuy It Now for only: \$5.50Buy It Now | Add to watch list
UNO R3 Ultimate Starter Kit For Arduino LCD Stepper Motor Servo 1602 COMPLETE
 \$38.97End Date: Wednesday Mar-21-2018 13:39:28 PDTBuy It Now for only: \$38.97Buy It Now | Add to watch list

## 4 thoughts on “Further on Arduino Random Numbers…”

1. Von Neuman filtering requires that two bits do not have any correlation between them. If you make two successive reads from the analog input, the propability for them being the same is high. The output of this implementation propably has more numbers with alternative bit sequences, such as 0xAA and 0x55.

My proposed improvements are to use two separate analog inputs and compression.

Let’s imagine that you have two sources where the other one is constant and the other one changes with random intervals. You would read always either 01 or 00. And your random bit output would be constant 0. But if you take into account how many times you read before input changes, then your output includes the randomness in timing. That’s compression.

2. Actually, Von Neumann filtering is specifically for number lists that are not truly random – after all, there is no need to remove bias if the stream is completely random. As for repeated calls returning the same value, removing that is the purpose of the extra code in function #2 here. Unfortunately, with the Arduino there is always the possibility of grabbing a non-changing bit (for example, accidentally using an analog port that is in use) – however, these functions do improve the randomness of the initial value.

3. Two comments. With your debiasing code, if the result of analogRead were to wander slowly, then your code would be guaranteed to produce either 01010101 or 1010101, which would likely be worse than your simple case.

And on to the simple case, why throw away the potential extra random bits of analogRead? Why not instead: