Electronic Roulette

[element7k]

Hi all,

A pub owner has enquired if I can help him custom build a electronic roulette where customers can press a button and the roulette will light up a large panel with light bulbs (100W) in it. It will stop in options like free drinks or  better luck next time (6 options in total). He wants to be able to set the bias so it won't give out too many free drinks.  Anyone got ideals if this device can be built for approximately  US$50 and advise on the isolation between the electronic circuit so it won't electrocute anyone? I found some relays that can do this but they are rather expensive.

E7k

[LabVIEWguru]

Hmmmm... I'd use a micro and build a table. Figure out how many times he wants to give something away free. There are random number generators on the internet, or get the 1st ten thousand digits of pi, pick a random place to start and take the next 2048 numbers mod 6 - so you have 2048 random numbers 1 - 6 (or whatever # of options he wants.)

Now assign the numbers to options. Lets say you assign #6 to the highest value prize - now I'd go through and pull out half (or whatever) of the #6 from the table and replace it with "Try again" (or whatever). Keep on mind there will be nights someone hits four free drinks in a row, then no one will hit it for the next couple nights. You don't want too *few* grand prizes, either.

Now you have a fairly random table of 2048 digits (or 4096, or whatever you pick) without too many "grand prizes" in the table.

Then, I'd get on my favorite search engine and look up "pseudo random code" (usually based on the hardware timer) for the micro I'm using.

I'd output the result to a port, use solid-state relays on the ports to turn on the lights, and you are a genius.

I'd put a routine in the switch-press read code that if I pressed the switch with a certain sequence it would always give the hot young lady you are trying to impress a free drink. Just keep it secret.

Obviously this will require a bit of experimentation, but what I've given you should work.

In your experimentation, the table without too many "grand prize hits" should be OK - if you have the time, you might populate the table from $00 to $FF 2K times, then when you hit a number you loop a subtraction until the result is <= 6.

That  might be a fun project  - maybe one of my colleagues on here has a better idea. Or if you use a micro that has an A/D converter, look up "Zener diode random number generator" or "Zener diode noise generator" and get something (approaching) random. Or just build a table.

[Parmin]

Biasing is easy.

For a combo of 6 numbers, just simply get a random number, divide by 7 and get the remainder.
You would get numbers from 0 to 6 (7 numbers)
you would then bias by equating the number 0 to whatever number you wish to bias.

ie:

y = random

x = y // 7
if x = 0 then x = Number_to_bias

result_of_random_selection_with_a_bias = x

[CocaCola]

Hmmmm... I'd use a micro and build a table.

Most all micros already have a pseudo random table built in...  Most all micros already have a pseudo random generator built in to the compiler libraries...  For something like this just use the built in table, it's plenty random for this, but not random between starts (it will repeat the same pattern with each reboot) so keep a running counter of the spins and write it to the EEPROM, use that counter as the seed between restarts to give it some more pseudo randomness, or constantly save the last random value in EEPROM for future seeding...

In PICBASIC this random number is between 0-65535 the easy way to weight it is like this, this is long hand 'BASIC' way of weighting it for simplicity of concept...

SEED = (READ_EEPROM_VALUE) ' this is the saved value in eeprom based on whatever counter to add randomness between reboots
RD = SEED ' this will start at the seed location of the random look up table
RANDOM RD  ' get a random value between 0 - 65535 jumbled start location in look up based on seed or previous value of RD
VALUE = 0 'default
IF RD < 60000 THEN VALUE = 1
IF RD < 50000 THEN VALUE = 2
IF RD < 40000 THEN VALUE = 3
IF RD < 20000 THEN VALUE = 4
IF RD < 10000 THEN VALUE = 5

In the above table here is what the results will look like for the VALUE variable...

VALUE=0 returned for 65535 - 60000 (5535) about 8% of the time
VALUE=1 returned for 59999 - 50000 (9999) about 15% of the time
VALUE=2 returned for 49999 - 40000 (9999) about 15% of the time
VALUE=3 returned for 39999 - 20000 (19999) about 31% of the time
VALUE=4 returned for 19999 - 10000 (9999) about 15% of the time
VALUE=5 returned for 9999 - 0 (9999) about 15% of the time

*edit each value in () should actually be +1 but for visual simplicity I'm leaving it as is...

Looking at the above, in theory 1, 2, 4 and 5 are equally weighted outcomes...  Value 3 should pop roughly twice as often as any other, while value 0 only half as often as any other... You can of course shift the values in the table around to tailor it to your winning needs...

I'm by nature a lazy coder, and unless programming space is at a premium I will do long sloppy coding like this...   For me it's simply easier and faster, and I find it easier to tailor to the task and adjust on the fly...  For a simple program like this I doubt code space will be a big concern

[LabVIEWguru]

Three excellent, excellent answers. I must admit, if you want to do this in one afternoon then I think Mr. CocaCola has the best answer. I have never experimented with PICS, maybe it is time to start.

CocaCola: Should he seed the Random Number Generator each iteration so it doesn't come up with the same "random" numbers?

I was on Ebay this morning and found this:  SSR-25 DA Solid State Relay 25A Output 24-380VAC - $5.80 with free shipping

You could probably drive them directly, but I would get the data sheet  - at the worst you could use a little mosfet (2N7000 or something) on the output line of your port. You could make it "pretty" by making the lights "chase" a few times and slow down before stopping on the selection - you already know what the selection is, so that isn't too tough. Maybe have the lamps do "random" patterns if your device sets too long without someone pushing the button. Possibly use high output commercial LED lamps instead of 100 watt incandescent - I don't think they will last too long being turned off and on  - but maybe they will be OK. More experimentation! If you use the new CF lights they will melt.

Element 7K, we three are heading to the UK when you get this done and you get to buy us free drinks for a couple of days! Please draw your design up when you have it finished and post it on here.

[Bobbla]

Hallo

I remember a few years back I made a electronic dice using a cheap oscillator circuit, a switch(finger connecting two pads on the PCB), a counter and some other stuff(LEDs, power, etc.). The idea was that the oscillator would make the counter count so fast that the human operator wouldn't be able to manipulate the results.

So lets say the oscillator had a (low) frequency of 6 kHz, that means that the counter would have restarted a 1000 times if you had hold down the button for 1 sec. This translates in to all the combinations in a matter of 1ms for which the human operator is not able to do anything with. And since the cheap oscillator and human operator is so full of "error" that the outcome is more or less random.


The above will have a more or less equal chance for every outcome, so I therefore suggest that you get a MCU with a timer and an interrupt based on input level.

0. MCU starts up and init..
1. MCU ready to go.... (waiting for human interaction)
2. Human operator push down a button (input level change)--> interrupt starts a timer.
3. Timer counts and counts and counts and counts some more, hopefully overflowing a couple of 100 or 1000 times..
4. Human operator lets go of the button (input level change)--> interrupts stops timer.
5. MCU takes the counter value and compare it to a "win-chance-table" (see CocaCola's post)
6. Finds the result and displays it...
7. ? ? ?
8. Profit
9. Goes to stage 1.


This means that you do not really need any random generator as the human interaction will make the process random enough.


Hope it seemed reasonable, and good luck.  

[FTL]

Most all micros already have a pseudo random table built in...

They do not have random number tables built in. There are no machine instructions (i.e. assembler op codes) for directly generating a pseudo random number on any CPU I'm aware of.

The libraries that come with various compilers have pseudo random number generators. These use a mathematical sequence (usually something like  R(n+1) = Rn * X + Y Mod Z - where X, Y and Z are prime or relatively prime numbers) to generate what appears to be random numbers. The maximum size of the 'random' number is strictly determined by the code in the library.

The key to the random number generators is to create a random seed value to start it off. That is often difficult to do on a larger computer. Accessing a low-level timer can be useful so the seed value is different every time you start the program.

On a microcontroller it is possible to access a truly random source for the seed value. If you have an A/D converter you can read the value of a pin that has noise on it. If you're not happy with only 256 seeds, do it a couple of times and add the results together. If you don't have an A/D, you can use the value on a single input pin (0/1). Connect a high-gain comparator to the pin, so it amplifies some noise to the 0-5V range (assuming a 5V system). Then read the pin a bunch of times doing some different operations on your initial static seed value. i.e. 0=add a prime number. 1=subtract a prime number. Use a circular list of 16 prime numbers and you'll end up with a good random seed.

[h0nk]

They do not have random number tables built in. There are no machine instructions (i.e. assembler op codes) for directly generating a pseudo random number on any CPU I'm aware of.

The STM32F4 contains a Random number generator (RNG).
> The RNG processor is a random number generator, based on a continuous analog noise,
> that provides a random 32-bit value to the host when read. The RNG is expected to provide
> a success ratio of more than 85% to FIPS 140-2 tests for a sequence of 20 000 bits,
> measured on corner conditions by device characterization.

For an electronic game like an electronic roulette this seems not necessary.


Best Regards

[CocaCola]

CocaCola: Should he seed the Random Number Generator each iteration so it doesn't come up with the same "random" numbers?

It is seeded with the previous 'random' value with each iteration, so yes there is a pattern but far from one you will be able to crack easily, you could certainly seed it again, or manipulate that seed for even more randomness...

You need a source of 'random' if you want to do this, and IMO overkill for such a project...  That is why I suggest keeping a running counter in the EEPROM and use that as the initial seed to avoid any repeat pattern, at least an obvious one...  Without this initial counter seed (or another changing initial seed) the pattern will be identical with each reboot, using the counter seed the 'pattern' is still the same in the grand scheme but you are starting at different point in the sequence with each reboot, thus it would take a ton of work to figure it out, especially if you don't know the weighting pattern used to return the limited 6 results...

If you want to sample something 'random' and continue to reseed the random generation, that is always an option, there have been a few ideas tossed up already, but here are a few more...

You time how long the 'roll' button was held and use that as a seed...  (Edit I see Bobbla suggest this already)
You time the duration between rolls and use that as the seed...
You time how long the micro has been powered up using a circular rolling counter in the main loop, and use that value as a seed...
You continue to generated pseudo-random numbers in the main loop (not just on a spin) of the program at all times, and grab one as the seed when it's time to roll...
Use a real time clock and use values from the current time as a seed, not random but if you don't know the source and equation of the seed nearly impossible to figure out...   Example seed = (hour * 3) + (minute * 5) + (second * 4) + (minute * second)

And there are many more mathematical and hardware tricks that can be used, but again IMO overkill in this project...

They do not have random number tables built in.

I was implying at the compiler level, no it's not a hard coded firmware table...  Sound have made that more clear, as you suggest it's also not hard coded table but a mathematical equation, but that equation will build the same table every time...

I would have been better off stating "Most all micros already have a pseudo random generator built in to the compiler libraries..."

[LabVIEWguru]

Don't worry about it - I and everyone else understood completely that you were inferring the compiler had that function. Your answer was excellent.

[CocaCola]

Don't worry about it - I and everyone else understood completely that you were inferring the compiler had that function. Your answer was excellent.

Good to hear it wasn't totally lost...  I was more focused on the weighting issue in the post then the random number generation...

To the OP the only real issue I see with this proposed design is the $50 price tag... IMO there is no labor time that can realistically be factored in at that price point...  The circuit itself can be done cheap with a micro and a few transistors, but the interface to mains for the bulbs drives the price up exponentially, the relays and sockets for the lights will easily push you close to $50 and you also need a wall wart to power the micro from the mains, all those $1s add up real quick...  For the button I would use a low cost 'arcade' replacement button, they can be had cheap and once mounted in a panel are plenty durable even around drunks...  But, then that brings up another factor, the housing for this entire device and it's potential cost...

Realistically I can see this costing $100 - $200 even if it's a hook up a friend project...  But, IMO even at that price the bar shouldn't really complain, it's still a low cost gimmick that they can make money off of in the end...  Even if they implement something like a 25¢ a spin night for the ladies...

BTW this could easily be done without the micro, but it's a little more work and not as flexible...  You could use a 555 timer to count up a chained series of 4017 chips for example...  The user presses the button and the 555 starts clocking the chain of 4017 chips, when they release the button the 555 stops and only one output on one 4017 will be active...  The outputs and even entire chips in the chain could be grouped for the weighting...  Example 4017 #1 and #2 are all "better luck next time" while pin 1 and pin 5 on 4017 #3 is a free drink and the remaining pins on that chip are whatever...

[David_1]

to make it look random just make a 250 odd look up table. and increment a counter at million instructions a seconds yes it will overflow back to zero...

anyway then just jump into a lookup and it will return the number 1 to 6.
if 6 is free drinks only put in a few number 6s say 25 then it will pay out 1 in 6 times
250/25 = 6

or only put in one 6
250/1= 250   = 250to1 pay out good for pub but custermers wont like it LOL

[element7k]

All,

great suggestions from everyone. Especially the ideals on bias and isolation. I am thinking of not using a PiC to keep cost down but I appreciate it will be complex to implement bias without it. Will have to spend the weekend costing up the project. It has to be within budget. The pub landlord is a tight yorkshire man    @Labviewguru do POP by If you all are anywhere near Yorkshire.

Will post updates later.

E7k

[CocaCola]

I am thinking of not using a PiC to keep cost down

Not sure I can follow that logic, unless you are not setup to do use micros...  A PIC is pretty much a one chip solution here and the cost will be about $1, I don't see you doing it cheaper with other logic chips and getting the same results or nearly as much control and flexibility as a software solution provides...  It's the other components like the relays, light sockets and running it off mains that drives the cost up...  Stick to a low voltage design with LEDs and $50 is plenty doable, switching mains lighting is really the pivotal cost factor here...  Using LEDs you can just drive them from the PIC with a simple transistor or darlington chip, total component cost can be well under $10 doing it this way...

[Parmin]

+1 with cocacola

PIC solution is pretty much the CHEAPEST there is.

[Bobbla]

Hallo again 


I had some time on my hands so I made a "Electronic Roulette" sort of. It needs more stuff before it can become a real product, but I did program a PIC to do the "smart" stuff. All you need now is the "other" stuff, like lights to flash and a small power circuit to power it all up, ect.

Contains files from proteus and mplabx/xc8

Hope it helps

[element7k]

Thank you for everyone for their input. I will use the pic method since bobbla has so kindly done most of the work. I will need to modify the program slightly such that it will read in input from a dip switch so probability can be changed as desired. 

[Brosske]

Hi All,

+1 for the PIC solution. Plenty of demo programs to do the job... I'd use 5V SSR to make the link to bulbs.

greetz