While working towards his Computing and Information Systems degree at the University of London, [Jason Fenech] submitted an interesting proposal for generating random numbers using nothing more exotic than an aquarium and a sufficiently high resolution camera. Not only does his BubbleRNG make a rather relaxing sound while in operation, but according to tools such as ENT, NIST-STS, and DieHard, appears to be a source of true randomness.
If you want to build your own BubbleRNG, all you need is a tank of water and some air pumps to generate the bubbles. A webcam looking down on the surface of the water captures the chaos that ensues when the columns of bubbles generated by each pump collide. In the video after the break [Jason] uses two pumps, but considering they’re cheaper than lava lamps, we’d probably chuck a few more into the mix. To be on the safe side, he mentions that the placement and number of pumps should be arbitrary and not repeated on subsequent installations.
To turn this tiny maelstrom into a source of random numbers, OpenCV is first used to identify the bubbles in the video stream that are between a user-supplied minimum and maximum radius. The software then captures the X and Y coordinates of each bubble, and the resulting values are shuffled around and XOR’d until a stream of random numbers comes out the other end. What you do with this cheap source of infinite improbability is, of course, up to you.
While this project has been floating around (no pun intended) the Internet for a few years now, it seems to have gone largely overlooked, and was only just brought to our attention thanks to a tip from one of our illustrious readers. An excellent reminder that if you see something interesting out there, we’d love to hear about it.
Are you waiting for something that may never happen? Maybe it’s the end of your ennui, or the release of Half Life 3. While you wait, why not build a Godot Machine? Then you can diversify your portfolio and wait for two things that could happen today, tomorrow, or at sunrise on the 12th of Never.
The Godot Machine is a functional art piece that uses a solar panel and a joule thief to charge a bank of capacitors up to 5V. Whenever that happens, the Arduino comes online and generates a 20-bit random number, which is displayed on an LED bar. If the generated number matches the super-secret number that was generated at first boot and then stashed away in EEPROM, the Machine emits a victory beep and lights a green LED. Then you can go back to complaining about whatever.
We like that [kajnjaps] made his own chaos-based random number generator instead of just calling random(). It uses a guitar string to collect ambient electronic noise and an entropy generator to amplify it. Then the four least significant digits are used to seed the logistical map, so the initial value is always different.
Many languages feature a random number generator library for help with tasks like rolling a die or flipping a coin. Why, you may ask, is this necessary when humans are perfectly capable of randomly coming up with values?
[ex-punctis] was curious about the same quandary and decided to code up an experiment to test the true randomness of human. A script guesses the user’s next input from two choices, keeping a tally in the JavaScript backend that holds on to the past five choices. If the script guesses correctly, they take $1 from the user. Otherwise, the user earns $1.05.
The data from gathered from running the script with 200 pseudo-random inputs 100,000 times resulted in a distribution of correct guess approximately normal (µ=50% and σ=3.5%). The probability of the script correctly guessing the user’s input is >57% from calculating µ+2σ. The result? Humans aren’t so good at being random after all.
It’s almost intuitive why this happens. Finger presses tend to repeat certain patterns. The script already has a database of all possible combinations of five presses, with a counter for each combination. Every time a key is pressed, the latest five presses is updated and the counter increases for whichever combination of five presses this falls under. Based on this data, the script is able to make a prediction about the user’s next press.
In a follow-up statistic analysis, [ex-punctis] notes that with more key presses, the accuracy of the script tended to increase, with the exception of 1000+ key presses. The latter was thought to be due to the use of a psuedo random number generator to achieve such high levels of engagement with the script.
Some additional tests were done to see if holding shorter or longer sequences in memory would account for more accurate predictions. While shorter sequences should theoretically work, the risk of players keeping a tally of their own presses made it more likely for the longer sequences to reduce bias.
There’s a lot of literature on behavioral models and framing effects for similar games if you’re interested in implementing your own experiments and tricking your friends into giving you some cash.
There’s not much time left now. If you’re going to put something together to give the youngsters some night terrors in exchange for all that sweet candy, you better do it quick. This late to the game you might not have time to do anything too elaborate, but luckily we’ve come across a few quick Halloween hacks that can get you some pretty cool effects even if it’s only a few hours before the big night.
As a perfect example, these LED “blinking eyes” were created by [Will Moser]. Using nothing more exotic than some bare LEDs, an Arduino, and a cardboard box, these little gadgets can quickly and easily be deployed in your windows or bushes to produce an unsettling effect after the sun goes down. Thanks to the pseudorandom number generator in the Arduino code, the “eyes” even have a bit of variability to them, which helps sell the idea that your Halloween visitors are being watched by proper creatures of the night.
The hardware side of this project is very simple. [Will] takes a container such as a small cardboard box and cuts two holes in it to serve as the eyes. He notes that containers which are white or reflective on the inside work best. You’ll want to get a little artistic here and come up with a few different shaped sets of eyes, which is demonstrated in the video after the break. Inside each box goes a colored LED, wired back to the Arduino.
For the software, [Will] is using a floating analog pin as a source of random noise, and from there comes up with how often each LED will blink on and off, and for how long. Both the hardware and software sides of this project are perfect for beginners, so it might be a good way to get the Little Hackers involved in the festivities this year; if you’re the type of person who enjoys replicating small humans in addition to creeping them out.
We just wrapped up the Musical Instrument Challenge in the Hackaday Prize, and for most projects that meant replicating sounds made by humans, or otherwise making musicians for humans. There’s more to music than just what can be made in a DAW, though; the world is surrounded by a soundscape, and you only need to take a walk in the country to hear it.
The most impressive board [Kelly] has been working on is the Mother Nature Board, a sort of natural electronic chorus of different animal circuits. It’s all completely random, based on a Really, Really Random Number Generator, and uses a collection of transistors and 555 timers to create pulses sent to a piezo. This circuit is very much sensitive to noise, and while building it [Kelly] found that not all of her 2N3904 transistors were the same; some of them worked for the noise generator, some didn’t. This is a tricky circuit to design, but the results are delightful.
So, can analog electronics sound like a forest full of crickets? Surprisingly, yes. This demonstration shows what’s possible with a few breadboards full of transistors, caps, resistors, and LEDs. It’s an electronic sculpture of the sounds inspired by the nocturnal soundscape of rural Virginia. You’ve got crickets, cicadas, katydids, frogs, birds, and all the other non-human musicians in the world. Beautiful.
What do you do, when you need a random number in your programming? The chances are that you reach for your environment’s function to do the job, usually something like rand() or similar. This returns the required number, and you go happily on your way.
A shift register configured as a pseudo-random number generator. [by KCAuXy4p CC0 1.0]Except of course the reality isn’t quite that simple, and as many of you will know it all comes down to the level of randomness that you require. The simplest way to generate a random number in software is through a pseudo-random number generator, or PRNG. If you prefer to think in hardware terms, the most elementary PRNG is a shift register with a feedback loop from two of its cells through an XOR gate. While it provides a steady stream of bits it suffers from the fatal flaw that the stream is an endlessly repeating sequence rather than truly random. A PRNG is random enough to provide a level of chance in a computer game, but that predictability would make it entirely unsuitable to be used in cryptographic security for a financial transaction.
There is a handy way to deal with the PRNG predictability problem, and it lies in ensuring that its random number generation starts at a random point. Imagine the shift register in the previous paragraph being initialised with a random number rather than a string of zeros. This random point is referred to as the seed, and if a PRNG algorithm can be started with a seed derived from a truly unpredictable source, then its output becomes no longer predictable.
Selecting Unpredictable Seeds
Computer systems that use a PRNG will therefore often have some form of seed() function alongside their rand() function. Sometimes this will take a number as an argument allowing the user to provide their own random number, at other times they will take a random number from some source of their own. The Sinclair 8-bit home computers for example took their seed from a count of the number of TV frames since switch-on.
The not-very-random result of a thousand analogRead() calls.
The Arduino Uno has a random() function that returns a random number from a PRNG, and as you might expect it also has a randomSeed() function to ensure that the PRNG is seeded with something that will underpin its randomness. All well and good, you might think, but sadly the Atmel processor on which it depends has no hardware entropy source from which to derive that seed. The user is left to search for a random number of their own, and sadly as we were alerted by a Twitter conversation between @scanlime and @cybergibbons, this is the point at which matters start to go awry. The documentation for randomSeed() suggests reading the random noise on an unused pin via analogRead(), and using that figure does not return anything like the required level of entropy. A very quick test using the Arduino Graph example yields a stream of readings from a pin, and aggregating several thousand of them into a spreadsheet shows an extremely narrow distribution. Clearly a better source is called for.
Noisy Hardware or a Jittery Clock
As a slightly old-school electronic engineer, my thoughts turn straight to a piece of hardware. Source a nice and noisy germanium diode, give it a couple of op-amps to amplify and filter the noise before feeding it to that Arduino pin. Maybe you were thinking about radioactive decay and Geiger counters at that point, or even bouncing balls. Unfortunately though, even if they scratch the urge to make an interesting piece of engineering, these pieces of hardware run the risk of becoming overcomplex and perhaps a bit messy.
The significantly more random result of a thousand Arduino Entropy Library calls.
The best of the suggestions in the Twitter thread brings us to the Arduino Entropy Library, which uses jitter in the microcontroller clock to generate truly random numbers that can be used as seeds. Lifting code from the library’s random number example gave us a continuous stream of numbers, and taking a thousand of them for the same spreadsheet treatment shows a much more even distribution. The library performs as it should, though it should be noted that it’s not a particularly fast way to generate a random number.
So should you ever need a truly random number in your Arduino sketch rather than one that appears random enough for some purposes, you now know that you can safely disregard the documentation for a random seed and use the entropy library instead. Of course this comes at the expense of adding an extra library to the overhead of your sketch, but if space is at a premium you still have the option of some form of hardware noise generator. Meanwhile perhaps it is time for the Arduino folks to re-appraise their documentation.
Cloudflare is one of those Internet companies you use all the time, but don’t usually know it. Big websites you visit use Cloudflare to shore up their defenses against denial of service attacks. The company needed some truly random numbers for its security solutions, so it turned to some groovy old tech: lava lamps. In their office is a wall of 100 lava lamps monitored by cameras. The reaction of the lamps is unpredictable, and this allows them to generate really random numbers. [Joshua], a Cloudflare employee, talks about the technical details of the system in a recent blog post.
You might think this is a new and novel idea, but it turns out the LavaRnd (or maybe it is LavaRand — there’s some dispute if you read the comments below) system has been around for a while. In fact, we covered it way back in 2005. Silicon Graphics patented the system in 1996.
If you want to build your own BubbleRNG, all you need is a tank of water and some air pumps to generate the bubbles. A webcam looking down on the surface of the water captures the chaos that ensues when the columns of bubbles generated by each pump collide. In the video after the break [Jason] uses two pumps, but considering they’re cheaper than lava lamps, we’d probably chuck a few more into the mix. To be on the safe side, he mentions that the placement and number of pumps should be arbitrary and not repeated on subsequent installations.
