If you’ve never seen a double pendulum before, it’s basically just a pendulum with another pendulum attached to the end. You might not think that’s anything special, but these devices can exhibit extremely chaotic behavior if enough energy is put into the system. The result is often a display that draws attention. [David] wanted to build his own double pendulum display, but he wanted to make it drive itself. The result is a powered double pendulum.
There aren’t many build details here, but the device is simple enough that we can deduce how it works from the demonstration video. It’s broken into two main pieces; the frame and the pendulum. The frame appears to be made mostly from wood. The front plate is made of three layers sandwiched together. A slot is cut out of the middle to allow a rail to slide up and down linearly. The rail is designed in such a way that it fits between the outer layers of the front plate like a track.
The pendulum is attached to the linear rail. The rail moves up and down and puts energy into the pendulum. This causes the pendulum to actually move and generate the chaotic behavior. The rail slides up and down thanks to an electric motor mounted to the base. The mechanics work similar to a piston on a crankshaft. The motor looks as though it is mounted to a wooden bracket that was cut with precision on a laser cutter. The final product works well, though it is a bit noisy. We also wonder if the system would be even more fun to watch if the rotation of the motor had an element of randomness added to it. Or he could always attach a paint sprayer to the end. Continue reading “Powered Double Pendulum is a Chaotic Display”
If you’ve written a great library to generate random numbers with a microcontroller, what’s the first thing you would do? Build an electronic pair of dice, of course.
[Walter] created the entropy library for AVRs for a reliable source of true random numbers. It works by using the watchdog timer’s natural jitter; not fast by any means but most sources of entropy aren’t that fast anyway. By sampling a whole lot of AVR chips and doing a few statistical tests, it turns out this library is actually a pretty good source of randomness, at least as good as a pair of dice.
The circuit itself uses two 8×8 LED matrices from Adafruit, an Arduino, and a pair of buttons. The supported modes are 2d6, 2d4, 2d8, 2d10, 1d12, 1d20, a deck of cards, a single hex number, a single 8-bit binary number, or an eight character alphanumeric password. It’s more than enough for D&D or when you really need an unguessable password. Video demo below.
Continue reading “The Most Random Electronic Dice Yet”
[Karl] was in need of a hardware random number generator, but is needs had a few caveats: it needed to be cheap, and sufficiently random. Random number generation can get quite crazy with Geiger tubes, lava lamps, and radioactive decay, but a much smaller solution was found in an 8 pin AVR microcontroller.
The solution uses AVRentropy, a library that uses the watchdog timer’s jitter in AVR microcontrollers to provide cryptographically secure random numbers. Setting up the circuit was easy – an ATtiny45 microcontroller was connected to a cheap chinese USB to serial converter. Three wires, and the circuit is complete. The code was simple as well; it’s just a call to initialize the entropy and write the bits to the serial port.
There are a few drawbacks to this build. Because the entropy library must wait until enough entropy is gathered, it can only produce about two 32-bit numbers per second. That’s all [Karl] needed for his application, though, and with an enclosure made from a wine cork and marble, he has the prettiest and smallest random number generator around.
It’s time to get those jack-o-lanterns twinkling for Halloween. If you don’t want to use candles or buy a jack-o-lantern light this Halloween you can do like [Johannes Bauer] and code your own pseudo-random flickering super bright LED. His wife wanted their pumpkin to be illuminated this year and he knew it would be easy to do with an Arduino, but that would be overkill for such a simple project. Plus, he doesn’t have an arduino. [Johannes] used very few components; 4 slightly depleted AA batteries, a super bright LED, 680 ohm resistor and a little custom code on an 8 pin ATtiny13. The circuit does work great for a pumpkin lantern but his video is more of a tutorial on coding linear congruential generator (LCG) for the 8 bit pseudo-random LED flickering.
The code is short and can be gleaned from the YouTube video. [Johannes] used avr-gcc to compile and has packaged his code and build scripts for download. The hex file can be flashed over to the chip using avrdude or AVR Studio. If you have any ATtiny13s lying around you should cobble this hack together just in time to emulate that real look of a pumpkin candle without the hassles and hazards of real flames.
If you want something with a lot more light that still has that candle like flicker then checkout “Flickering Pumpkin Lanterns” that used the signal from LED tea lights to power some 12 V lamps.
Follow along after the break to watch [Johannes Bauer’s] video.
Continue reading “Pseudo-Random Flickering Jack-O-Lantern LED using ATtiny13″
This is a screenshot from the Atari 5200 version of the classic game Berserk. But the write-up we’re featuring actually looks at the original coin-op version. The maze for each level was established on the fly using a seed number fed into a rudimentary algorithm . Here’s a close look at how the maze building code actually worked.
Recently we saw a talk by Pitfall creator [David Crane] as part of our Retrotechtacular series. That is a real gem of programming history, and one of our favorite take-aways was that the levels were not hardcoded, but built using a random number generator algorithm with a hardcoded seed (so that the game was the same each time you played it). This uses a similar method but with a somewhat random seed.
The maze building was reverse engineered by observing the game in a MAME emulator, and by digging through disassembled code. Each time the code is “cold started” the seed starts out at zero, but from there the room number is used as the next seed. This is fed through a very simple algorithm. It generates directions for the walls, which use s few bit-wise operations to add the pillars inside the rooms.
It’s a great thing to study if you’re writing games for your embedded projects. By generating the room programmatically you don’t use up as much program memory. Of course these days even simple hobby controllers have way more storage to work with than [Alan McNeil] had when he designed Berserk.
[Wardy] built himself a high quality entropy source with parts he had lying around. It’s based on the hourglass entropy project we saw in a links post earlier this month. Just like that project, he is bouncing a laser off of the falling sand and reading the result. But he brings a few innovations to the party, and has test results to back up his work.
The first change is an obvious one; motorize the hourglass so that you don’t need to flip it by hand. We thought this might mess with the laser alignment but the clip after the break proved us wrong. He changed up the sensor, using an LED connected to the base of an NPN transistor. The next change was to mount the light sensor at an angle to the laser rather than straight on. This picks up reflections of the laser and not the direct beam itself, resulting in a wider range of readings.
He used an Ethernet shield to get the system on the network. It’s pushing 420k random numbers per second and was tested with the DieHarder suite. It didn’t get a very high score, but it did pass the test.
Continue reading “Improved hourglass entropy”
[Lambgx02] got tired of his Android device getting bogged down and decided to dig down to the cause of the issue. His investigation led him to believe that entropy is causing the slowdown. He believes that his workaround reduces 90% of the lag on the average Android device.
So how is it possible that entropy is causing the problem? It seems there is a bottleneck when an app requests a random number from the Linux kernel running at the lowest level of the device. Android is set up to use /dev/random for all random number requests, but [Lambgx02] says that location has a very shallow pool of numbers available. When they run out the kernel has to reload with a new seed and this is blocking the app that requested the data from continuing.
His solution was to write his own app that seeds /dev/random once every second using a number from /dev/urandom. He mentions that this might cause a security vulnerability as seeding the random data in this way is not quite as random. There may also be issues with battery life, so make sure to monitor performance if you give it a try.