[littlebird] posted a tutorial on making electronic dice. He’s using an ATmega328 for the numbers work, and a mercury switch to activate it all. A nice blue enclosure to match the blue LEDs he’s using for the number display wraps it up nicely. Of course, someone had to mention that this was an amazing amount of over kill and it could just be done with a 555 timer like they used to do “back in the day”. [littlebird] responded with another tutorial to prove that he hadn’t forgotten how to work with the basics. He goes on to point out, now that we see both in action, that he can expand his microcontroller based one quickly with a few lines of code, where every new feature added to the 555 timer version would require additional components.
You can catch videos of both after the break.
[youtube=http://www.youtube.com/watch?v=BYCv0avM-uQ]
[youtube=http://www.youtube.com/watch?v=E3qwNPPrAQ0]
A little bit more programming needed.
At the moment, the ‘dice’ can flip from one ‘side’ to the opposite ‘side’ instantly. EG: the numbers can be seen to flash through from 3 to 4 (opposite sides of a die) without any transition number between the two.
The devil is in the detail.
Good project though :-)
Ooops – I was a bit hasty in commenting
It appears to count from 1 through six several times before displaying a random number.
:-))
D&D addicts are gonna love this :)
Thanks for mentioning it on hackaday.com
Glad you liked it!
john
that’s pretty awesome. i know what i want to use when playing GURPS now.
Now get to work on a d20! :D
i wish it flashed a couple times to tell you when it’s done rolling.
I don’t think you need to go all the way to a 55 for a project like this. I would just use a smaller processor.
Every product line has parts ranging from big to small. Find a family, get familiar with 2 or 3 parts that cover the product range well, and then use them appropriately as needed. If you standardize on using the same few procs, you get used to their quirks and have the parts on hand when needed.
It makes sense to use a flyswatter for a fly and an elephant gun for an elephant. However, you don’t need to use a spear on an elephant just because that’s the way they used to do it in the “old days.”
How is this a “spear on an elephant”? He used the processor which had the best development tools (arduino) because using other processors would mean more development time.
He could have simplified the circuit outputs to 4 instead of addressing each of the 7 LED’s. 3 freed pins means more expandability. I remember making one of these with 4 multiplexers.
An electronic die can be made with the 7XXX series ICs, a microprocessor is overkill IMO. I’ve made one with some logic ICs and it works quite well.
I love mercury switches though. Rollerballs just can’t compete; too bad they’re getting hard to find. I’ve started making my own with steel wire and glass tube, but they don’t look nearly as professional as the “real ones”
I had an electronics kit when I was a kid that used a 7-segment display and some 7xxx TTL to produce a dice.
OK, somebody has to point out that you don’t even need the 555 timer for this. You can actually simulate this functionality with a small cubic piece of plastic. You paint the numbers 1 through 6 on the sides…
Needs 13 more leds.
You know, a MSP430G2001IPW14 costs $1.20 in quantity of 1 units at Digikey.
A 555 chip needs external components like resisters and capacitors to be configured as a square wave generator, and these extra parts cost money.
The era where a simple microcontroler is overkill for a simple logic circuit is just about dead. Use the tools you know how to use.
Ho many kinds of dice can you emulate with 10 I/O lines?
BTW- there’s a 2d6 circuit in Don Lancaster’s CMOS Cookbook too.
Nice project! But need some ajustens for when the dice is cast
good work :)
I recall that theory establishes that deterministic systems cannot create non determinist outputs. How is this device, assuming that the output is non determinist, non determinist? It occurs to me that, moving a bit further afield, net traffic that consisted of genuine random “data” would necessarily encounter efforts at decryption. There being no actual encryption this would create meta-noise that would tend to expand decryption efforts at a rate (and cost) several orders of magnitude greater than the input, eg it takes less effort to seem to place a needle in a haystack than it takes to find it, particularly if it’s not there…