To successfully apply a roulette computer, the player needs to be able to receive an accurate prediction before the dealer calls no more bets. With the typical roulette computer, because dealers spin the ball at different speeds, you will find that many dealers don’t spin the ball fast enough for the ball to even reach the target speed (especially after you’ve just clocked a slow rotor). This makes the typical roulette computer algorithm impractical in many circumstances, and is particularly frustrating as you may need to wait hours for a suitable dealer to return. It is the same case with visual ballistics methods as they use the same approach. Remember that both the simple roulette computer and visual ballistic algorithm involves waiting for the ball to reach a target speed, and then obtaining a prediction. As this can be impractical with different dealers, a computer often needs to be able to predict at any ball speed for application to be practical.
Linear Vs Actual Ball Deceleration Curves
The very first version of my computers were capable of obtaining predictions at anytime in the spin. This is possible only with sophisticated algorithms unless you sacrifice accuracy with a simplistic solution. To obtain predictions anytime in the spin, rather than targeting a specific ball speed, you cannot simply assume the ball deceleration is linear. Assuming it is linear is assuming that the ball deceleration will be constant no matter what the ball speed is, and it is a critical mistake.
Shown left are two curves for the same ball timings. This is from a John Huxley Mk7 roulette wheel with Velstone ball track, which is one of the latest roulette wheels. The blue line shows the exact and actual timings with an ivorine ball. The red line shows the deceleration if you incorrectly assumed it to be linear. The red line looks smooth and accurate, but to give you an idea of how inaccurate the linear assumption is, consider that between two dots represents just one ball revolution. The data shows that at some ball speeds, the linear line is approximately between 0 – 2 full revolutions inaccurate.
This means that if you assume the ball deceleration is linear, on some spins you will be accurate enough (target the correct revolution), on some spins you will be 1 revolution off target, and other revolutions you will be about 2 more revolutions off target. This results in very poor or no accuracy, and this is only assuming you are still using a very basic approach where you solely consider rotor position at estimated ball drop time. If the ball deceleration is smoother without the distinct bend which is very common on wheels, then the deviation will be between 0-1 ball revolution at best. This would then be acceptable, but only if you are playing on a wheel with a very strong dominant diamond. However, a deviation of 0-1 revolutions is enormous and unacceptable if you are using any advanced approaches, such as targeting which diamond the ball will hit. That is unless you are predicting which diamond will be hit when the ball is just about to actually hit the diamond, in which case there is no point because you can’t bet that late.
In summary, assuming ball deceleration is linear is a “cheap shortcut”, and is only acceptable if you intend to play only very easily beaten and rare wheels (wheels where the ball barely bounces, and almost always hits the same diamonds). But if you intend to play on modern wheels, you will be unable to achieve significant accuracy.
My Lite, Uber and Hybrid computers all correctly model the actual ball deceleration curve. They do NOT assume the ball deceleration is linear and use a much more complex algorithm. Therefore my computers can obtain predictions anytime in the spin without a significant loss in accuracy. However, only the Uber and Hybrid computers are capable of dynamically adjusting for ball deceleration rate changes.
Misleading Demo Videos
Only two other roulette computers are capable of obtaining predictions anytime in the spin. These are devices from Mark Howe and Miro Zirdum’s (Forester). However, they both incorrectly assume ball deceleration is linear. In particularly Miro Zirdum creates deceptive videos in which he promotes his computer’s ability to obtain predictions anytime in the spin. Specifically he continuously clocks the ball in a recorded spin on dvd, and shows how close each prediction is to each other. Basically the closer the predictions are, the better. This may seem impressive without sufficient knowledge, but in reality he is merely demonstrating:
* how linear the ball’s deceleration is on one particular wheel
* his computer’s ability to target a specific revolution
The second point is most relevant. You may recall how in earlier pages I explained how even a poorly designed computer with inaccurate timings can target when there are 4,5,6 or so revolutions are remaining. And that the timings for the last few revolutions are much the same between different spins. So there are only two possibilities for what his algorithm does: either considers complete revolutions, or partial revolutions.
If he used complete revolutions, predictions will almost always be exactly the same number, with the occasional jump to a different number (because it may occasionally lock onto the wrong revolution). So mostly two particular numbers will be predicted. But if he considers partial revolutions, then it is impossible to apply the algorithm on anything but wheels with very strong dominant diamonds and with minimal scatter. Additionally, as the variation in accuracy on individual spins will range between 0-2 ball revolutions, there is absolutely no chance his assumption of linear ball deceleration can achieve even close to maximum accuracy. To better explain how you can easily replicate this “anytime prediction”, test on a recorded spin and guess when there are about 10 seconds until the ball falls. Then count down each revolution, 9,8,7,6 etc down to 0. If you were correct to within 1 revolution accuracy, congratulations, you have just replicated the “anytime predictions” without a device. Certainly it sounds overly simplistic, and it isn’t any great achievement. But when a computer repeatedly predicts around the same number on each revolution, it appears more impressive despite it being essentially the same thing.
Ultimately his device’s assumptions are an inappropriate and limited shortcut. To keep predicting the same number on the same spin with subsequent clicks, he would only need to continue clicks while the ball speed is linear enough to be accurate to within about 250ms. Again consider that the average clocking error is 50ms. In other words, the incorrect assumption of linear deceleration may be acceptable on a very easily beaten wheel where advanced algorithms are not required. But if a wheel requires advanced algorithms, the loss in accuracy is far too great for the advanced algorothm to be viable. Also importantly, this is assuming the device performs other required functions perfectly.
See a video of a poorly designed device that assumes ball deceleration is linear:
How my computers model the deceleration curve
My computers use a combination of advanced polynomials and actual ball timings to accurately model the true ball deceleration. Shown left is an example of a polynomial curve (green) with the actual ball timings (blue). You can clearly see it is far more accurate than linear assumption. The deviation from precise timings is barely noticable.
These charts can be seen in my roulette computer’s settings. Additionally, the polynomial order value can be changed to accurately deal with any distinct bends in the ball deceleration curve. Ultimately the much better “curve fit” ensures that a high degree of accuracy is maintained even when the computer user needs to obtain predictions anytime in the spin. With the exception of splines which have some disadvantages, use of high order polynomials is the only accurate method of modelling a relatively complex curve.
Putting it all together
In addition to accurate initial modelling of the deceleration curve, as discussed in previous sections, the ball’s deceleration curve will change. So the computer must learn the ball’s deceleration. This is an extremely complex problem that only my Uber and Hybrid computers solve. Without automatic learning of ball deceleration rate changes, even an accurate initial modelling will eventually become obsolete as the ball deceleration changes.
But assuming everything to this point is done correctly, now the computer user needs to be able to get all timings (clicks) done, receive the prediction, then place bets all before the dealer calls no more bets. With a typical roulette computer, you need to first clock the rotor (one click each time zero passes the diamond to take the rotor timing), then make your clicks for the ball. Some of the problems that need to be overcome are:
* Correct modeling and learning of ball deceleration: (as already discussed)
* Getting ENOUGH clicks in time: this is essential. You can easily get a prediction with 2 ball clicks (1 revolution), but it wont give you enough accuracy. A common problem with basic computers is that when the ball is released, the rotor’s green zero has already passed the reference diamond you use for timings. This means you’d need to wait for the rotor to come all the way back around before you can clock it. This wastes 3-5 seconds. Then after you finally clock the rotor, you can clock the ball but it is often too late as the ball is either too slow, or the prediction is too late to bet.
My hybrid roulette computer does everything automatically without any “clocking”, so it is inappropriate to compare other devices to it. Below is a comparison between my Uber computer and every other “manual clocking” computer:.
Prediction process comparison
| My Uber Computer | Other computers | |
| Prediction process | Single player version: can use either one button for both rotor and ball timings, or two buttons at the same time: one for rotor and one for ball. This means there is no waiting for the rotor to come back around to begin clocking. You can clock ball before rotor, or the other way around. Additionally, the player can clock the rotor from up to two different positions, so even if the player uses only one button, they can clock the rotor from the opposite side, and predictions are automatically adjusted with no loss in accuracy. The player can also clock 1/4,1/2, 1, or 2 revolutions of the rotor to be adaptable to any conditions.Two player version: It can do everything the single player version does and much more. The two player version consists of two phones. Any combination of clocking can be done including:
* Player 1 clocks rotor and ball, player 2 bets only * Player 1 clocks rotor, player 2 clocks ball at same time * Player 1 and 2 clock rotor, player 1 clocks ball * Player 1 and 2 clock both rotor and ball There are even more combinations, and they can be done at the same time with precise accuracy and communication between each phone. These abilities are exclusive to my Uber computer. The main benefit is very early predictions WITHOUT a loss in accuracy. For example, you can have two players both clocking 1/4 revolution of a rotor. If only one player clocked a 1/4 revolution, the clocking errors are far too large. But with two players clocking the rotor, even with just 1/4 rotor clocking errors are enormously reduced. The same benefit is obtained by two players clocking the ball at the same time. An example is if you needed very early predictions, you can set each player to clock 1/4 rotor revolution, and 1 ball revolution at the same time. With two people clocking the same spin, clocking errors are greatly reduced. In contrast, even if another computer also clocked 1/4 rotor and 1 ball revolution, there would be enormous errors if only one player took the timings. |
Wait for the rotor’s green zero to reach the reference diamond, then click once. Wait for zero to pass again, then click once more. Now click each time the ball passes the reference diamond until you get a prediction. If you missed the first turn of the rotor, you will probably not get prediction in time if at all.This is the process used by almost every other roulette computer because it is required for the basic computer algorithm.
Some roulette computers allow you to take 1/4 or 1/2 rotor revolution timings. But the problem is with only one player clocking, there will be no accuracy with clocking such small rotor arcs. The smaller the arc you clock, the greater the clocking errors. This can only be covercome by multiple player clocking with the Uber, or automated timing acquisition with hardware such as theHybrid. Incredibly, some sellers like Miro Zirdum boast that their computer doesn’t need to clock at the same position, so it can get early predictions. But what he doesn’t tell you is the consequence is usually a complete loss of accuracy. Because of the deception, you need to be vigilant and properly understand the principles so you know when someone is trying to scam you. |