People take their tabletop games very, very seriously. [Andrew Lauritzen], though, has gone far above and beyond in pursuit of a fair game. The game in question is Star War: X-Wing, a strategy wargame where miniature pieces are moved according to rolls of the dice. [Andrew] suspected that commercially available dice were skewing the game, and the automated machine-vision dice tester shown in the video after the break was the result.
The rig is a very clever design that maximizes the data set with as little motion as possible. The test chamber is a box with clear ends that can be flipped end-for-end by a motor; walls separate the chamber into four channels to test multiple dice on each throw, and baffles within the channels assure randomization. A webcam is positioned below the chamber to take a snapshot of each “throw”, which is then analyzed in OpenCV. This scheme has the unfortunate effect of looking at the dice from the table’s perspective, but [Andrew] dealt with that in true hacker fashion: he ignored it since it didn’t impact the statistics he was interested in.
And speaking of statistics, he generated a LOT of them. The 62-page report of results from his study is an impressive piece of work, which basically concludes that the dice aren’t fair due to manufacturing variability, and that players could use this fact to cheat. He recommends pooled sets of dice to eliminate advantages during competitive play.
This isn’t the first automated dice roller we’ve seen around these parts. There was the tweeting dice-bot, the Dice-O-Matic, and all manner of electronic dice throwers. This one goes the extra mile to keep things fair, and we appreciate that.
Generating random data is incredibly hard, and most of the random data around you isn’t truly random, but merely pseudo-random. For really random data, you’ll have to look at something like radioactive decay or *holds up spork* something like this. YouTube commenters will also suffice. The idea of using random data for generating musical notes is nothing new, but [Danny]’s experimental MIDI controller is something else. It’s a MIDI controller with the control removed, generating random musical notes based on radioactive decay.
The design of this controller is based on an off-the-shelf Geiger counter kit attached to an Arduino. The Arduino code simply counts up in a loop, and when the Geiger tube is triggered, an interrupt sets off a bit of code to generate a MIDI note. That’s simple enough, but where this project excels is its documentation. There’s a zine going through all the functions of this MIDI controller. There are single note or sequencer functions, a definable root note and scale type, an octave range, and velocity of the note can be set.
This is just a MIDI controller and doesn’t generate any noise on its own, but the video of the device in action shows off the range. [Danny] is getting everything from driving bass lines to strange ambient music out of this thing with the help of some synths and samplers. All the code and necessary files are available on the GitHub, with the video available below.
Amidst the vast expanse of sand dunes in the Namib desert, there now exists a sound installation dedicated to pouring out the 1982 soft rock classic “Africa” by Toto. Six speakers connected to an MP3 player all powered by a few solar powered USB battery packs, and it is literally located somewhere down in Africa (see lyrics). The whole project, known as TOTO FOREVER, was the creation of film director [Max Siedentopf] who himself grew up in Namibia.
“I set up a sound installation which pays tribute to probably the most popular song of the last four decades…and the installation runs on solar batteries to keep Toto going for all eternity.”
– Max Siedentopf, Creator of TOTO FOREVER
[Siedentopf] certainly chose a song that resonates with people on a number of levels. Toto’s “Africa” was one of the most streamed songs on YouTube in 2017 with over 369 million plays. The song continues to reach a new generation of fans as it has also been the subject of a number of internet memes. Though those local to the sound installation have had some less than positive things to say. [Siedentopf] told BBC, “Some [Namibians] say it’s probably the worst sound installation ever. I think that’s a great compliment.”
The idea of the installation “lasting for all eternity” will certainly be difficult to achieve since the components most certainly lack any serious IP rating. The audio player itself appears to be a RHDTShop mp3 player that according to its Amazon listing page, has three to four hours of battery life per charge. Considering the size of those solar cells the whole thing will probably be dead in a week or two (it is in a desert after all), but no one can deny the statement TOTO FOREVER makes. Below is some footage of the art piece in action taken by the artist himself. Continue reading “Somewhere Down In Africa Toto Is Playing On Loop”→
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.
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 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 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.
Let’s start off with one of my favorite quotes from John von Neumann: “Any one who considers arithmetical methods of producing random digits is, of course, in a state of sin. For, as has been pointed out several times, there is no such thing as a random number — there are only methods to produce random numbers, and a strict arithmetic procedure of course is not such a method.”
What von Neumann is getting at is that the “pseudo” in pseudorandom number generator (PRNG) is really a synonym for “not at all”. Granted, if you come in the middle of a good PRNG sequence, guessing the next number is nearly impossible. But if you know, or can guess, the seed that started the PRNG off, you know all past and future values nearly instantly; it’s a purely deterministic mathematical function. This shouldn’t be taken as a rant against PRNGs, but merely as a reminder that when you use one, the un-guessability of the numbers that it spits out is only as un-guessable as the seed. And while “un-guessability” isn’t a well-defined mathematical concept, or even a real word, entropy is.
That’s why entropy matters to you. Almost anything that your computer wants to keep secret will require the generation of a secret random number at some point, and any series of “random” numbers that a computer generates will have only as much entropy, and thus un-guessability, as the seed used. So how does a computer, a deterministic machine, harvest entropy for that seed in the first place? And how can you make sure you’ve got enough? And did you know that your Raspberry Pi can be turned into a heavy-duty source of entropy? Read on!
When [::vtol::] wants to generate random numbers he doesn’t simply type rand() into his Arduino IDE, no, he builds a piece of art. It all starts with a knob, presumably connected to a potentiometer, which sets a frequency. An Arduino UNO takes the reading and generates a tone for an upward-facing speaker. A tiny ball bounces on that speaker where it occasionally collides with a piezoelectric element. The intervals between collisions become our sufficiently random number.
The generated number travels up the Rube Goldberg-esque machine to an LCD mounted at the top where a word, corresponding to our generated number, is displayed. As long as the button is held, a tone will continue to sound and words will be generated so poetry pours forth.
One of the standout talks at the 33rd Chaos Communications Congress concerned pseudo-random-number generators (PRNGs). [Vladimir Klebanov] (right) and [Felix Dörre] (left) provided a framework for making sure that PRNGs are doing what they should. Along the way, they discovered a flaw in Libgcrypt/GNUPG, which they got fixed. Woot.
Cryptographically secure random numbers actually matter, a lot. If you’re old enough to remember the Debian OpenSSL debacle of 2008, essentially every Internet service was backdoorable due to bad random numbers. So they matter. [Vladimir] makes the case that writing good random number generators is very, very hard. Consequently, it’s very important that their output be tested very, very well.