How good are roulette video spins to fully test roulette computer


#1

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.

  1. FF during set up measures clocked ball times without mistake.
  2. FF during play mode measures clocked ball times without mistake.
  3. 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.


#2

Forester, with all the researches you’ve done and with all the knowledge you have by now you could write a PhD dissertation about roulette advanced play :D.


#3

I agree with that!! :smiley: :smiley:


#4

;D
I’ll do another test on a large TV screen and may ask few more people to do the test to see what they’ll get clocked at particular ball revolution.


#5

I asked Bebedictus to do the same test with video spins.
His findings were similar to mine, where first clocked ball rotation is 30-40 ms shorter.
Are we both making similar human errors on a first click when timing the ball or it is something that video spins are causing. The problem is that such test can be done on a video spin where the same spin can be repeated and compared results. To test it on a live wheel is a problem since same spin can’t be repeated so the clocked times can be compared.

For that I made a new experiment.

I used 2 FF’s in set mode then placed external clocking switches on top of each other. That way I can take sample for both FF’s with a single click and clocked times should be similar. Switches were different in sizes on one switch I could press at the corner and trigger just that switch. On that way with one FF I start clocking the ball one rotation earlier so the second clocked rotation few of error should have same time as first clocked rotation with the other FF.

This is the result.

[URL=http://imageshack.us/photo/my-images/856/compare2ff.png/][/URL]

Samples 6-9 are clocked with the other FF and with an extra ball rotation.

You can see in Sample-1 1087ms value marked in yellow. It is a first clocked time for that FF but in sample 6 it is 1086ms second clocked time. Now there is no error of 30-40ms to make the first clocked time shorter but only 1ms difference. You can see same if comparing other samples marked in red, blue or green. I did this test few times so I am confident to say that the 30-40ms error on a first clocked ball rotation is caused only because of video recording. When playing live roulette such things are not happening.

Since the FF can have multiple predictions during the same spin to confirm previous result in play mode I did additional test. I’ve set the FFs and selected the play mode.
With one FF I clocked ball got prediction then continue clocking with both FF’s.

For the first FF on a next prediction it would be second ball time clocked but for the other FF it is first time ball clocked. These times should match and here is the results.
Ball1…3144…3141
Ball2 …2517…0

FF-1 first ball time clocked is 2517ms , second time is 3144ms which is very close to 3141ms first clocked time with FF-2.

This confirms that on a live roulette wheel there are no 30-40ms errors on a first ball click during the play mode. When I add all learned on this subject I can confidently say that the FF roulette compute is far superior then any video recordings can be.

[size=12pt]With such findings we can rise an issue about using roulette computers to play online live wheels.

Such online videos, also have frame rate of about 30 frames per second, making the ball to move in 30-40 ms steps. Same problem may be happening on such videos. If the player has roulette computer as the FF with an option of multiple predictions during the same spin, or even better if he has 2 FF’s, he can do same test as I did and take an appropriate action based on results he may find. If there is a problem, making a first click one pocket earlier would almost eliminate 30-40ms error. If there is time using FF’s third prediction would be without any errors. [/size]


#6

I took video spins from Cammegh roulette wheel available for download (for members)
http://rouletteplace.com/index.php?topic=1699.msg14850;topicseen#new
And I experienced same problem.


I set the Acrobat to accuracy 30 ms.
I set the system clocking at position x.
Theoretically with + and minus 30 ms limit I should be able to do clocking at different positions point to the left and to the right from point x within limits. But the distance where the system stops predicting on both sides should be the same.
With my experiment to the right I was getting predictions up to the point 1 and on the left only up to the point 2. It means my clocked time is still shorter as previously discussed. Since the problem is not with the FF the only other options are the video or my clocking. But how my clocking each time can be about 30 ms shorter only on first rotation clocked?

My next experiment was only to pretend with fingers that I am doing first click but I do not press the switch, so I kind of worming the muscles and start focusing. Then on a next rotation I start clocking. And BINGO by doing that the problem disappeared. I tried to look deeper in to it and it really looks that on first click without preparation I am a bit late, making the measured time shorter.


After simulating first click i could get predictions on bot sides equally, as on the picture.

In such case compensation for it should be added to the system. 30 ms error on Cammegh wheel is a lot especially if someone uses first systems prediction. On second prediction it would be reduced on third it would be completely eliminated.
Have to love FF’s multiple predictions. ;D


#7

The same thing can be when we clock in play.


#8

Yes, and it is very important especially if you use the systems first prediction, something needs to be done about it. It is enough shifting on a multi-diamonds setup to make what is direct hit to be seen as something in between DD or even different DD . Before i wasn’t sure was it video problem or something else but now I know it is our clocking or perhaps just mine. Please do the same test and let me know if you have same problem.


#9

Hello forester. I know the problem is present with me also, I usually just set predictions 2 revs earlier then I would play and ignore the first prediction. The first prediction is just like a practice or dummy run, but it is not ideal.


#10

Thanks,
If everyone has same problem then we should learn to make first click one pocket earlier or should do it in program. If you use second prediction you are still affected by 50% about 10-15 ms.
It was interesting for me to discover if I pretend first click that the mistake disappears.


#11

Is it a similar problem if we use toe clocking? If so, is the 30ms time frame the same for hand and toe!?


#12

Yes about 30 ms. you should try to do same as i did, move clocking position left and right to see up to which point you getting predictions.


#13

lol!

I am so dummy then… :’(

I just would like to push the button and to receive the prediction - number to bet, nothing more…

ahh not only… and in the free time to take a coctails on the beach with nice girls 8)

which are will tell me: “you’re the best roulette player baby!”…
but only in my mind I will know the truth…
…the FF!! :stuck_out_tongue:

FF Forever friends! :wink:

heheheheheehe :smiley:


#14

It is not so simple, what if you do not have 30 ms delay as i do.
You should read the test how i did it and check what you will get.


#15

hahaha, I think I will have more delay… with mine shaking hands I have :stuck_out_tongue:

and how the device will know if smb. that use it has delay and how much is it
but take an eye EVERY TIME WHEN HE CLOCKS!!!

maybe have to be option of +5ms/-5ms or less limits to play and not +30/-30
or more? as we could se from the picture the limit of +30/-30 could be near
to half a wheel :o


#16

It is only about -30 ms on the first click. With 2 rotations clocked it is as 15 ms mistake with 4 it is 7.5 with 6 it is canceled.


#17

useful information


#18

contact me for simple mathematic formula to win roulette. the thing about roulette is only to find the roulette seed number then you can win each time. Why are people engaging in too much studies and analysis while we have the solution on seed number of roulette. A seed number is the number which the roulette machine uses in its algorithm to calculate the next spin number. So by definition, if you make your formula correct you can accurately predict the next number, PERIOD!