Recently, Cammegh has introduced a wheel that subtly changes speed during the spin. The idea is that it’s supposed to thwart prediction by vb/rc players.
However, the nature of the design introduces a potential flaw that should be investigated. If a wheel speeds up and slows down, then there may be a subtle pattern to the rotation that can be recognized by observing some high quality video of the wheel in action. The trouble is finding a live online video feed that’s good enough. Another method would be examining long streams of data from the live wheel. This is where the bot guys could be of some use.
Here are some ways that you could possibly attack such a wheel. It does not directly involve VB or the use of an RC.
By viewing the video feed, you could, if the video is good enough, examine it frame by frame using Avidemux software. There’s a buit in clock (counter) in the software, that would enable you to determine how long it takes part of the wheel to rotate, while watching it in slow motion. The idea is to map the rotation of the rotor segments in order to try and find potential ‘slow spots’ that may exist below any dominant drop points on the wheel. Even if there is servo that is run by an rng, there may by a rhythm to the speeding up and slowing down (interval), despite the wheel speed itself being random. I doubt that such a high quality feed exists. However we could possibly send someone to collect some intel from certain locations or use a different and more time consuming approach.
Each time the dealer shoves the rotor to speed it up, it’s possible that the action of pushing on the wheel could introduce a speed up and slow down kind of ‘wave like function’ that could be observed and or measured by various means. (Remember, this type of wheel is designed to speed up and slow down.)
This is NOT some kind of VB. It’s more of a bias approach. It’s a potential way by which you could determine which section of the rotor (wheel head) is most likely to be below any dominant deflector. Theoretically it may be possible to predict where this section is before the ball is ever spun. In short, you would be attempting to predict which portion of the rotor will be traveling the slowest at the end of the spin in relation to a dominant drop area.
[quote=“Snowman, post:1, topic:972”] It’s a potential way by which you could determine which section of the rotor (wheel head) is most likely to be below any dominant deflector. Theoretically it may be possible to predict where this section is before the ball is ever spun. In short, you would be attempting to predict which portion of the rotor will be traveling the slowest at the end of the spin in relation to a dominant drop area.
-Snowman[/quote]
I studied and keep on studying these behavior. I do this on air ball rouletes.
It takes a VB expert to calculate the section that would be (or not)below the drop point or the dominant deflector.
My challenge is to predict it before the ball is spun, hard work but not imposible.
Not very clear what you done as i understand you clocked laps in two posittions 0 an 10.5. Now if in E column is seconds then what means columns I M Accelerate and decelerate ?
Guys, probably a stupid qvestion,but how long is last ball revolution,and how many diamonds wheel has? Is there a possibility to get more samples? I only can see 2… Where is this wheel? INTERNET? What is qwolity of video?framse/sec?
Sorry, I did a poor job of labeling the spreadsheet.
Column E is a Cammegh Wheel without the RRS system. The times shown are half revolution lap times.
Column I was supposed to be where the wheel accelerated during the spin. The times shown are half revolution lap times.
Column M was supposed to be where the wheel decelerated during the spin. The times shown are half revolution lap times.
I retrieved the video from Cammegh’s website. They are the ones that labeled each video. By just viewing the half revs, that “accelertation and deceleration” is NOT what shows. I need to revisit the videos to see why they are saying that. To me it appears that both wheels automatically adjust to a 4 second rotation at the end of the spin, regardless of the start speed. If that is the case, then you could probably compensate using vb/rc.
I have seen these videos befor… :D. I think it was a topik somewhere at the forum… Probably , if someone find internet casino with such a wheel… it would be good idea to take more data on it… at least 50 spins… Anyone knows such a whell? Just my 20sent… l think that the change prodused should be somehow logical, remembering the purpose of the wheel to combat us :D, the change shouldnt be totaly rendom. There is no point for exemple to make a change for 18 pokets for obvios reasons… so change should be around -/+ 9… ± 13…
At least at autorulets this padron of change is used a lot…
Anyhow, l hope You are right and they were stupid enough to make it adjust till 4sec/rot. That would be Super :
My experience has been that manufacturers will sometimes introduce new flaws into the wheel when they attempt to make improvements. Such flaws sometimes create new opportunities for AP play.
The logic control in the auto wheel for RRS is developed out of house by a company who
specialise in random. Not sure what it is for the manual wheel, though I see no reason
for the control unit to be different. On the autowheel there is no set speed, the variance
is a broad spectrum whether it speeds up or slows down, ever increasing from the point
NMB are called. It also seems to have some kind of setting options as some wheels change
alot more abruptly then others and can be seen with the eye.
Interesting data can come of these wheels I feel, I am sure, Toby would be the guy to work
this topic more precisely.