Multiple rotor clockings

Advanced roulette play
1

In another thread today Forester wrote:

If repeating same spin and prediction shifts few pockets it is more because of inaccurate rotor clocking, because system doesn't use error corrections for rotor cocking since we clock only one rotation.
Why not add a third rotor clocking then?

You begin with clocking the rotor whole or half revolution, like today.
Then clock the ball four times.
And then CLOCK THE ROTOR ONCE AGAIN!

Time is of essence here. I know that you will argue that there is not enough time for clocking the rotor again. But maybe this can be ameliorated?

The third rotor clocking would consist of only one click, not two new ones. If the rotor turns at 2.5 seconds per revolution according to the first clocking as today, then the software could easily understand wether it is has turned 2 or 3 revolutions if its final timing comes 5.4 seconds later (two, because 22.5 is much coser to 5.4 than is 32.5). The average speed of the rotor would then be (2.5+5.4)/(1+2) = 2.63 seconds. [Or maybe the average of 2.5 and 5.4/2 = 2.60 seconds? Or some version thereof, preferably including the deceleration fo the wheel speed.]

Since there might not be time enough to wait for the zero to return to its original clocking point, consider using two types of final rotor clockings:

  • Click and reslease. This signals that the zero is at the same diamond as in the first clocking.

  • Click and hold. This signals that the zero is opposite the diamond of its initial clocking, it has made x+½ revolutions. The software could easily conclude which integer value of x is most reasonable.

This way one wouldn’t need to wait longer than half a rotor revolution, that is about a second and a half I suppose, for this third rotor clocking. Half of the time one would only need to wait less than a quarter of a rotor revolution, which is less than a second. Wouldn’t the added precision be worth that?

And the procedure could be made optional. A first prediciton could be called just like today without this third rotor clocking. But if the button is pressed again within tolerated time interval, it would be interpreted as a third rotor clocking and an adjusted prognoses would be called on that. This way, one could flexibly skip the third rotor clocking if NMB is closer than the next rotor whole or half revolution seems to be. Or of course, if for the time rotor clocking doesn’t seem to be an important problem for the moment.

And besides, if one of the first two rotor clockings was an error, the third one would likely reveal it as such. Maybe the greatest practical value of a third rotor clocking doesn’t lie in increasing the precision of correct clockings, but in making it possible to alert the user on mistaken rotor clockings, as is already done for ball clocking.

2

It is hard as it is.
Adding more makes it harder.

We even use ½ rotor clocking and it is good enough.

Common mistake in clocking full rotation would be as 0.2 pockets per second.
If we have 10 sec. to the end then it makes 2 pockets error.
With FFA it could be more ~ 3 pockets, because the system needs to calculate rotor from time when we clock it. Additional error may com up to ~2 pockets if rotor deceleration is too much off from average and if we clock rotor once 10 sec. to the end and other time 15 sec. to the end.

For example if we clock 3 sec rotor
It would be 3000ms / 37=81 ms per pocket
Also rotor speed is 37/3=12.333

If we press the switch on pocket late we will give to the system time of 3 sec + 81 ms
Then 37/3.081=12.090 which makes measurement 0.24 pockets per sec. wrong.

That is up to 2.4 pockets error since most of the time we can clock rotor within one pocket of accuracy.

3

So, up to 2.4 pockets error due to mismeasured rotor speed (if one clicks one pocket off). Add to that the effect of deceleration will be practically eliminated if the rotor is clocked a third time late.

And a third clocking would allow for a sanity check. Unreasonable rotor clockings could be weeded out.

I mean, the ball clocking is good enough to find out which diamond will be hit. Better ball clocking could possibly lead to a prognosis about whether it will strike high or low on the diamond, as you have investigated. But that kind of precision would be quite a challange to achieve.

So what can be done is to increase the precision in the prognosis of where the zero of the rotor will be when the ball strikes the predicted diamond. A late rotor clocking would do the trick. Isn’t a couple of pockets better precision worthwhile?

4
So, up to 2.4 pockets error due to mismeasured rotor speed (if one clicks one pocket off). Add to that the effect of deceleration will be practically eliminated if the rotor is clocked a third time late.

Yes, it will eliminate and need for calculation for rotor position, but it will lose few seconds of prediction since we will have to wait until rotor comes to particular position.

Floating prediction by 2-3 pockets when combined with scatter it doesn’t make any difference.

I mean, the ball clocking is good enough to find out which diamond will be hit. Better ball clocking could possibly lead to a prognosis about whether it will strike high or low on the diamond, as you have investigated. But that kind of precision would be quite a challenge to achieve.

FF only on tilt can know that, on leveled wheel it doesn’t know which diamond will be hit, bit it goes by rotor numbers. If happened that a diamond is earlier on the balls way, most likely it will be hit at top and allow ball to fly longer until hits the rotor, which partly compensates for to early diamond hit.

So what can be done is to increase the precision in the prognosis of where the zero of the rotor will be when the ball strikes the predicted diamond. A late rotor clocking would do the trick. Isn't a couple of pockets better precision worthwhile?

Yes, experienced player doesn’t have to clock rotor instantly if spin is to strong.
.

5

Yes, it takes more time. But not too much!

With click-and-release vs click-and-hold one can distinguish between whole and half rotor turn. Then on average the rotor needs only turn a quarter of a revolution, which takes less than “a couple of seconds”. Also, it could be optional, calling out a modified second prognosis only if such a final rotor click was made.

on leveled wheel it doesn't know which diamond will be hit
Do you think it is impossible because of chaotic sensitivity, or that with perfect measurement one could predict diamond hit?
6

Few umbers inaccuracy vs. additional task, and lose of time.

Losing on sec in roulette prediction is to much.
With prediction of each sec. earlier we are less accurate.

If I want to predict when the ball is about 1 sec. per rotation if additional rotor control is added it would mean that I will have to use data when the ball is O.6-0.7 sec.

FF doesn’t calculate function but copies it and calculates only differences.
That is mostly to get the best from ball clocking but same applies to rotor.

I did tests on long spin.
For example I clock rotor at 20 sec to the end and get predictions 0,26,0,15,26,35,3 on same repeated spin. Then I wait and do rotor clocking 15 sec to the end and get 26, 0, 32, 0, 3, 35, 3 it doesn’t make noticeable difference. Maybe if more data is used the prediction in average may shift by 1 or 2 pockets. Or if wheel is with different rotor deceleration it may be 0, 19, 4, 32, 26 a bit shifted to the right.

If we do what you suggest we still wouldn’t fix all problem but only 1/3 of it.
Next would be to compare calculated rotor position with time of additional click to readjust it then calculate how much wrong previous measurement was.
The difference could be created by inaccurate clocking or by different rotor deceleration.
So how we can fix it?

Lets say the rotor made 2 pockets less. So instead of zero we really have number 3.
If our measurement was ok but rotor simply decelerates faster it is not problem since it will reflect to every spin therefore it is better to not adjust anything. But if 2 pocket difference is because of inaccurate rotor clocking we can adjust. But there is no way for system to know from where error is coming.

Maybe better solution will be to take 2 rotor samples. But even that will not fix it all.