Reason that made me to write this article is 2 problems I have noticed during months of testing.
Problem 1,
The FF Roulette computers have an amazing and very unique feature to predict same roulette spin multiple times in different ball rotations. During a lot of testing I noticed that occasionally the result of first prediction may not be in line with following predictions. In usual it can be explained as the ball is to fast where the difference in between ball rotations are smaller. Such condition together with players inaccuracy in timing the ball, may cause the system to not be able to make a proper correction and predict as expected.
To analyze this problem I created especial system set up conditions. During all tests I noticed that with so early prediction when the system makes a mistake most of the time it is to predict further distanced ball drop point. For example on an European wheel with clock way ball direction the system first time may predict number 34 then all the other predictions it may be number zero. The question in my head was why the system always predict more in front where conditions were artificially set that with average errors the system has same chance to predict and backwards, for example number 9.
Could it be that the system somehow measures when playing the ball time wrongly, for example instead of 700ms it measures 670ms?
Or maybe it is during set up process that somehow the system instead of 670ms measures 700ms?
Could it be that most often when clocking the ball my first click is late by 30ms so even if the next click is on time the measured time would be 30ms wrong? But firstly let me explain and the problem 2.
Problem 2
The other problem is related to systems capability to detect when the ball speed is within few milliseconds range where the ball destination can’t be so certain. For example the clocked ball speed is predicted to hit right in between 2 diamonds. In such case the system makes a specific calculation and together with predicted number it also gives a warning to the player which he can use for example to reduce his bets. When testing this part I’ve noticed that in some conditions it doesn’t work as it should.
I took a single video spin where the ball ends at diamond (DD) 3 (3 o’clcok) from position 12 where I was clocking. Made a set that way then repeated process but this time I was clocking the ball at 3 and telling the system the ball dropped at 6. Such two settings should produce results on opposite side of the wheel. That way when reading the prediction I could define by which set sample the system was predicting.
I start predicting the spin fist clocking at DD12 then with each time when I repeat same spin constantly moving clocking position towards DD3 in steps of 1-2 pockets. Searching when the system will switch and predict from set sample at DD12 to set sample at DD3. I was expecting it to start happening when I was clocking the ball right in between 2 diamonds. But on the earliest first prediction it wasn’t happening. It was ok with following multiple prediction. On very first prediction most of the time the system was still using DD12 set, even my clocking position was very close to the DD3. So this test rinsed the same questions as in the problem 1. I run the FF set up with a simulator where times of rotations a known and when I play it often shows me that the first clocked time is about 30 ms smaller than what it really is. It is a slow process since sometimes mistake in clocking can make it different.
For some time I was checking program if there is any chance for such mistake but I couldn’t find anything.
Set the FF using simulator, and again most of the time the first clock ball rotation was most of the time ~30ms shorter. At least that convinced me that there is no difference in time when setting the system and when playing but the same error shows in both situations.
The FF for some reason doesn’t measure right first ball rotation or it is still my error on a first click when timing the ball.
There is only one way to find it.
I used 2 FF’s. One was programmed to give on output constant times for ball rotations and it was interfaced with the other FF which was used in set up mode to record time intervals. I made 3 sets on that way and save it. Here is the data.
Sample 1 62 569 568 568 568 569 568 568 569
Sample 2 62 568 568 569 568 568 569 568 569
Sample 3 62 569 568 568 569 568 568 568 570
One FF was sending pulses every 568 ms and the other one was measuring it correctly including first time marked in red.
The accuracy of both FF’s in generating time and reading it is about 1ms. It should be actually even better then tat but the FF during 50ms zap switches the output 100 times. I had to use capacitor to filter it and the 1 ms difference most likely coming from capacitors difference in discharge time.
Conclusion after intensively researching two problems.
- FF during set up measures clocked ball times without mistake.
- FF during play mode measures clocked ball times without mistake.
- Clocking ball rotations from recorded video spin in usual injects error on a first measured time.
Understanding it without any doubts I could start researching human factor during ball timing. With this I am not talking about possible random errors but only on previously explained problems.
Again I’ve set the simulator to generate ball times. But this time it wasn’t set to start with 700ms then progress increasing the value by 100ms until it reaches 2000 ms. Instead I started with 1600ms and increasing the value in 50ms steps. This gives me a slower ball to start clocking but if I make 30ms error on my first click it should be irrelevant how fast is the ball. This time I was getting much smaller error on time of first ball rotation clocked, about 10ms range. Why it is reduced and why it still exists. Is it constantly repeating? Should the system compensate for it.
The answer is actually very simple. I spent 2 days researching problems to find out that there is nothing to worry about, but I had to be sure. It is not that for some reason I am late with first ball click but it is video spins causing problem. 30ms difference is 1 - 1.5 pockets at the start of rotation late click. If you looking how recorded ball looks when is spinning about 0.7 seconds per rotation you will see it wide or even as 2 balls. When we do clocking eye simply see an average while front of the ball is ahead. That distance with slower ball speeds is reducing therefore and error is reducing. The error at earlier moments during the spin has stronger effect since differences in between ball rotations are smaller. Later on with multiple predictions the system actually uses 4 ball rotations to make calculation where the original 30 ms error gets reduced beyond the point where it makes difference.
Perhaps when testing the system on a video roulette spin it may be good to first click make 1 pocket earlier especially if you are testing something where higher precision is required.
Such error shouldn’t happen on a live wheel but who knows, maybe my first click is really mostly few ms late.
