Hello Everyone,
I wanted to start a discussion about timing based systems and issues. It may be that we could solve some of the timing complexities through discussion that currently appear to be holding back the automation of some of the tasks.
Forester has found an ingenious way around the timing problems by using the eyes almost infinite sample rate and observing any delay. This method however oves some of the calculation complexity onto us the users and for people like me that struggle to do maths in their head and with memory. :roll:
If we could therefore find some solutions to the timing issues that allow us to do more with buttons (accurately) and less with brains we should end up with a more robust solution !
Review Feedback on Timing Problems
The problems with roulette based timing generally relate to one of three camps:
-
the human inability to do something exactly when we wanted to (that sounds like a life problem not just button pressing !)
-
the Hardware variations i.e. not doing things exactly the same every way each time
-
the Software variation i.e. not doing things exactly the same every way each time
Examples and discussion of each are:
Human Error
Obvious really we just can’t get in sync with the task. The pioneers in the Newtonian Casino reported that provided you are consistently wrong (late or early) a simpe, adjustment to software is all that is required, so no real issue there.
More problematic is the random error (sometimes late, sometimes early). Taking the right amount of drugs helps - really - they found one or two drinks improved performance, more that that decreased performance.
The other issue that helped greatly here was training.
With the right hardware/software test rig (using actual play hardware) this can be reduced constantly to 0.03 seconds fo the more dextrous amongst us (some couldn’t get below 0.2 secs).
So the question is how serious are errors in this range. The short answer is it depends what your measuring. If your measuring five ball circuits its negligible. If your measuring one circuit its potentially a lot. The Forester system for example rotates at around one number every 0.015 secs so its 2 numbers. Multiplied by whatever factor you are using gives you an error in the range 4 to 6 numbers. Worse for the less able.
On the face of its that’s a big problem. It is certainly true that there is nothing we can do about it - humans are not perfect hand eye coordinated bits of kit. Our skills are good enough for hunting and that’s it, maybe give it a few millennium and the kids that play arcade games will have mutated into something that will be able to get the resolution required. 
So, its really up to the system design to work with this error tolerance and minimise it. There are plenty of people that appear to have done just that with the traditional physics based systems so its not a fundamental limitation.
Hardware and Software Variations
Once we press the button the hardware has told the software it wants it to do some timing please. The software is now supposed to start fetching values from the counter, storing data and generally getting on with the timing loops it is supposed to. How quickly it will respond is linked to what it was doing when we interrupted it, can take 0.06s (60 ms) to interrupt Windows just to see the flag - that’s 8 numbers already right.
How accurate its calculations then are depends on where it gets the count data from. Using the ‘wrong’ counter in windows for example means the best accuracy we can get is another 60ms at each end of the time measured - basically no good.
The Real Issue ?
The traditional solution to solve the hardware and software issues is to use bespoke hardware and software solution. However, new technology means that the right hardware and software selection, programmed correctly could allow off the shelf hardware - mobile phone - to be used and work well within the tolerance we require. Several options there then.
This seems at odds with the limitation of the human button press right !
So the real question in relation to timing appears to be how do we either develop a solution that is robust to the intrinsic human error and/or use other techniques to capture timing data and/or make our calculations ?
Brainstorm :idea:
Lets consider a simple trajectory base roulette computer system that relies on the capture of timing data, Forester is a specific case of this so it may help to think about extending this system for brainstorming !
The objective then is to automate some system functionality and make life easier for the likes of goldfish memories like me.
Timing / System Improvement Concepts
Lets say we need data about the ball speed, wheel speed and their relationship each spin. Lets also say we can capture some characterisation data pre play.
1. Buttons and Statistical Mapping System B1
Collect all timing data using button input.
Separate the collection of decay data ball and wheel to pre play and use
statistical non linear regression (curve fitting) to remove random human timing issues and create a known system function (equation) and offset before playing.
During play collect ball/0 crossings (4 rot), wheel speed (1 rotation, maybe separate button). Fit the known curve to the data, this process removes some of the timing error introduced. Map the cleaned play data onto the known actual trajectory made during prepay. Slide the play data to fit prepay data and hence use the ideal 4.2s sample period for calculation. Lookup the predicted value of the curve. (I’ve already done this last bit in Excel and works well, even on a piece of graph paper accuracy is surprisingly good). Note that a longer play collection period allows for a better curve fit, less noise and a lower multiplication factor applied to the automated initial prediction.
This is my ideal concept solution and could involve only standard hardware. Bet placing being via sector vibration feedback. Question is does it work or are there systemic parts that can be used to improve Foresters current solution with his hardware ?
- Audio Ball Speed Sensor
The ball makes a characteristic sound each circuit. The max/min of this ‘wave’ are quite defined and offer the opportunity to both hardware and software detection methods. A bit of DSP programming for example to eliminate background noise and pull out the ball spectrum should suffice.
The other lower speed data such as wheel rotation collected via buttons. There would appear to be a sync issue with knowing the ball/wheel relationship but I believe this could be covered by a button capturing a few circuits and then averaging given we know the system decay rate already from pre play. Could also use the single button release technique when aligned and correct visual offset with additional presses for up/down.
- Doppler effect Ball/wheel Sensor
This has already been done apparently by Jonathan Kantler in the 80s. Doppler will detect both the ball and wheel rotations simultaneously. Then its all as above. I’m still looking into this implementation and will report later if it looks promising. Almost certainly would have to be bespoke hardware so security an issue.
- Camera based Timing Sensor
The white travelling ball is easy to pick out of a video stream. Combine that with button injected data about wheel position and you have an extremely accurate system. Requires either dedicated hardware (miniature camera and programmable gate array - actually quite straightforward design exercise) or fast DSP to extract the timing. Looks unlikely this could be done with standard small and discrete hardware.
- Lazer Timing Sensor
We’ve all heard the one about the Ritz club. Personally I don’t this they were using lazers. Looks like a valid method for timing improvement but working conditions don’t look good to me - fine in a lab.
- Rate Sync System
A solution where you set up a model of the system in software (think rotating roulette ball and wheel model inside the software) and then adjust parameters using buttons during play to bring the systems real and virtual in sync. Relationship could be mapped via the zero crossings using a fixed sync offset from each other. Then its the lookup method in 1. Looks less likely to me as the time to get into sync is short compared to the availability of feedback about being in/out of sync. Would work on tables with a strong dealers signature I guess, but then so do plenty of other easier implementations.
- That all I can think off for now …
What else ?? Any thoughts, ideas, feedback anyone ?? Apologies for the spelling, no time to check it.