Roulette computer inside mobile phone

Advanced roulette play
1

This option is completely out.

After talking to few people familiar with programming they all suggested to me to find a professional for a particular task. So I found the best and here is the answer.

It’s better to learn it now than after $15000+ of development :slight_smile:

To achieve what you describe, it would mean basically REMOVING the OS from the phone and programming directly the processor in assembly... In that case, you would get what you want... If you let the OS running in the background, even if you don't use it, it will continue to do its things and take processing cycle when you don't know it, rendering any real time processing impossible...

can windev mobile deliver needed accuracy and speed

Not at the level you are describing... [b]Neither could java or C[/b] if the program runs under any kind of NOT REAL TIME OS (there are some real time OS out there in the industrial world, but we are not talking cell phones anymore)
Either you build your own device from scratch (eventually HIDING it in a cell phone wrapping), or you find a cell phone containing all the hardware that you need and strip it down of its OS before coding it from scratch (all cell phone are flashable and you generally find several version of the BIOS/OS to replce the original one, so it's perfectly feasable...)

Your assembly development skills should make this approach even easiser
for you…

After long conversations and explaining everything this is the best part.

I understand, but based on what I know now, anything using an OS not specifically designed for real time work will not match your requirements... You would end up with something absolutely not accurate ([b]perhaps one of the problems of your concurrents[/b])

Bad luck, it would be much easier to load program to mobile but there is no way that I would compromise accuracy for making easy money on system sales. It looks as I am stuck with building custom hardware.

2

So it turns out Barnetts description(of howes + stefanos "computer) was quite correct!! :slight_smile:

"other roulette computers which have technology in mobile phone appear more elegant but this seems

to be nothing more than mere window dressing to increase sales" (taken from original draft of review, not exact qoute)

Well you looked in to it properly and objectively and it turns out it’s not the best way so onwards and upwards anyway.

I always had doubts about mobile phone to be honest, it just seemed a little too good to be true, too user friendly.

Anyway its great that your looking to improve FF and it leaves the door open to new ideas.

3

Yes it is, and his description of the FF is ok. Now it is matter only how you will interpret it. He used the FF out of the box without any questions asked. And he did all correct. The only unexpected was his problem with not getting enough predictions on leveled wheel.
But more is coming from Barnett so we shell see.

In addition to named problems their solution about predicting roulette is based around wrong idea. Stefano’s computer can’t even handle small rotor changes. Than I can only imagine how he can handle the ball timing and calculation. With his computer if rotor changes from 4 sec to 4.5s it would be called invalid spin. Why?
Just imagine buying it paying $10,000 then buying and video camera from him ($2000) to record wheel in casino. Then go home run it in slow mode and manually take timings which are already in errors of 40 ms because of video frames, then run back to casino. Of course on top of that you have to expect that every spin the ball has to behave as on recorded spin and data you entered. You can believe it but definitely it is incorrect.

I always knew that programming on machine language is the best, for timing applications but it is the hardest and slowest process to develop application.
However I thought that program on mobile phone may just pass the requirements but it looks as it is to far from that.

My main reason for researching mobile is because mobile phone has already added Bluetooth and display. Using the display for particular settings may be handy and easy but it may be suitable only if it is used by team. Single player simply can’t leave the table to do adjustments. With FF as it is I really never have to leave the table. I can do all settings without looking device.

This morning I woke up with new idea which I will discuss with programmer.

What if?
I use the FF’s processor as independent platform as it is, added on top of Bluetooth transmitter. All together can be very small. On the other side, use a mobile phone only as interpreter for data that the FF sends.

For example the FF sends data 0000 0001 (01H) mobile receives it and calls audio file to pronounce “one” . Then use the display on mobile where you can set from ( -18)-(0)-(+18) for offset . If you set for example +5 then mobile calls audio file which is 5 places distanced from number if there wasn’t offset adjustment. So mobile phone only processes final result and transforms it in to audio. I hope that wouldn’t be to slow as well.

If you look Stefano’s video you can notice that actually audio number is called much later then his last click. The FF processes all calculations in few milliseconds his java program for same must be close to 100 times larger which makes it much slower.

However the delay may not be only reason of slow calculation but it may be that it takes long for audio file to be initiated. If I lose 0.5 s to call audio file on mobile I simply cant afford it. Objective of roulette prediction is to get it earlier as possible with maximum accuracy. One second change in time of prediction in some cases may significantly change accuracy, therefore the time can’t be wasted because of inadequate hardware.

4

I have not much luck with mobile phones. Plan “B” was to not use phone for calculation but only for audio files. After asking to much this is the replay of one of mobile phone developers.

Perhaps, the only problem with this concept is that it takes time to initiate a player to play an audio file just when bluetooth data is received. Because the operation of "prefectching" player which preceeds audio playback takes some time (1 or more seconds usually), depending upon the file size and the mobile device... So if you find a way to make a 1-2 seconds delay before player starts not critical, I think that this plan is not complicated to implement with j2me. BTW, player in j2me has to be prefetched each time a new file is to be played

I am asking myself how Mark or Stefano couldn’t see those problems.
Ok, Stefano is not skilled but Mark does have some knowledge in programming.
Maybe better I ask myself why I have to see it all. I simply can’t swallow it and proceed with such design.

The idea of using phone in java for calling numbers doesn’t match my requirements.
Roulette system can’t afford to lose 1-2 sec in waiting for audio file to play.

I looked for that on Stefano’s video.
He loses 1.2-1.5 sec after his last click until audio starts.
His audio file of one number takes close to 1 sec, all together it makes 2.5 sec.

If I do it my way it will take 0.5s.
I will make audio running a bit faster and processed instantly.
It doesn’t matter if it sounds as kid’s voice. Purpose of the FF is not to entertain you with sexy female voice but to perform the best.
Total saving of 2 sec is a huge benefit.
It is about 2 ball rotations.
I prefer to have prediction 2 sec earlier, or if it is not required I can always drop time of prediction to get better accuracy.

Even if we exclude all the otrer problems with program running on mobile phone, such program to match the FF’s prediction at settings 2, must take ball samples much earlier. It means clocking last ball revolution at about 0.7s per rotation. At that speed range it is imposable to have any accuracy. The time difference in between rotations is still too small, (about only 80ms). Additionally they use wrong design where it is not that system decides when is the best to predict but the player. So if the player does it, it means that sometimes his last clocked rotation will be when the ball is 0, 5 sometimes 0.60.9€¦etc. Other words that’s disaster, not roulette prediction.

Put this all together and you will understand why mobile phone computer works only as good random number generator.
It also means that I will have to keep the FF as it is, build my own hardware for audio, there is no other option.

5

Use a bluetooth module with serial port profile.
These devices would fit inside the current FF with room to spare. They work of 3 volt and would add very little to power consumption as they only power up the TX when required.
You don’t store voice files on FF.
These devices are very simple to implement, a serial byte goes in at it’s serial port and out as a bluetooth.
FF sends a byte out of it’s serial port to the BT module ( a different byte for each number or phrase).
This byte is received by any bluetooth phone which interprets it and uses a lookup table to reference each byte with a wav fie.
The additional programing of FF is trivial; the receiving phone is not modified in any way; the program is easily written an one of many easily available programs, you can even write a program in Basic.
The player or an accomplice can wear the phone.

6

That was the plan B.
It loses more then one second to start playing audio file.
I do not want to lose so much in waiting for file to start playing.
It maybe doesn’t look much but it is. I need to have prediction as the FF gives in setting “accuracy 2”. That would mean that the FF has to process data of ball faster then one second and since it uses few ball rotations it may come all the way to 0.6s.
It is close to imposable for leveled wheel prediction.

What you doing is different. Tilted wheel prediction may be still possible; you do not have to use clocking correction so even if you clock the ball at 0.8s and if you define wrong revolution, if rotor is reasonable slow you may be ok. But the leveled wheel prediction must use few ball rotations to get needed accuracy of the ball timing and to learn how the ball decelerates.

Other way plan B would be perfect because mobile phone display can be used for some settings. As you said it would be easy to do. I wouldn’t add Bluetooth to the FF, I would insert same chip but few times smaller in size in to Bluetooth transmitter which is already cased and has built in rechargeable battery.

So the last option is plan C, custom built hardware where the FF can start audio instantly.

7

This is project review from an application developer.

Good day,

Finding information on the problem of precision timing is proving more difficult then I thought. Theoretically java does have timers that should be as precise as 1 millisecond. However most mobile devices use different chips for processing information which operate on different frequencies so the compatibility of such a precise system is deeply in question. I am not exactly sure that the timing will be same on all devices. We would have to test it out. The problem with this is that if the timing mechanism is not precise, I can not rely on it to give me an accurate measurement in milliseconds to see if our calculations are correct.

Maybe you have some kind of hardware that could independently (from the phone) measure the timing and we can compare the result?

I use Netbeans IDE 6.0 for mobile java application programming. It is computer based and has an emulation system for a mobile phone. My problem is however that such emulation is only confined to testing the application on the pc. It does not actually emulate the hardware of the mobile phone itself, it just passes through a Java virtual machine on the PC. This means that if I use my profiler (an application add-on which is used to calculate memory usage, timing etc. ) I will actually get a measurement of the program running on the PC and not on the mobile phone. And when I do transfer the application to the mobile phone I might not get the same result. This would have to be thoroughly tested and measured. I am not sure you know how Java works and I don’t mean to offend you if I am being overly simplistic. Java has a virtual machine on top of every hardware so basically every java programmer programs for the virtual machine and not for the hardware itself. Java sun and various other open source projects develop the virtual machines which interface with the hardware itself. This is why Java is compatible with almost everything out there (mobile phones, pc’s, macbooks, pda’s etc).

I also have concerns using Bluetooth to transmit sounds to the mobile phone. As see it the system should be as covert as possible. Therefore I would recommend using a Bluetooth audio hands free device. Those are usually just ear pieces which use Bluetooth to communicate. Bluetooth itself already has many different protocols programmed on top of it and we would have to use those as developing a new protocol for Bluetooth. It would be a hard job for many people. Now, Bluetooth can be jammed or scanned theoretically. It would be best if the earpiece was linked to the serial port of the phone by a wire like regular headphones you get with every mobile. This would make the system more visible, but reduce the chances of it being scanned or jammed. I think Bluetooth hands free devices, once paired create a serial gateway which transmit audio files and the connection remains active until the gateway is broken.
Different Bluetooth protocols do not remain active after data is transmitted (one example is the OBEX push protocol which is used to transfer files to and from the mobile phone) they just switch on, transmit data and switch off after the transmission is complete. In my opinion it is essential to save time where ever possible. It would not be wise to transfer audio data to the phone from one device via Bluetooth, and then transfer the data to a hands free earpiece device as too much time could be lost. Whether we use a Bluetooth hands free device or a regular (wire) hands free device for the earpiece you would have to decide. The wire would be more visible, but the transmission could not be scanned and we would save some time and gain some accuracy. Which is more important to you?

The most precise solution would be this. Your hardware device does the measurement of time as precisely as possible. It just sends the timing information via Bluetooth to the mobile device via OBEX push (not the audio itself, but rather some piece of information which my software could decode and make the necessary calculations). My application is started and prepared on a mobile device. The application itself has all the audio files within it. It calculates from the data received from your device and from a certain algorithm decides which sound to play. The sound is played through a regular wire mono headphone. The wire could be hidden by clothing or by using transparent or skin color wire. Or if we use a Bluetooth earpiece then the sound would be transmitted through radio waves to the Bluetooth earpiece. If I understood you this would be option B.

Option A would be that the entire application could be in JAVA and that pressing a button would signal the start of the timer. If we decide on this option there are some problems. One, as we already discussed would be precision. We would have to test it out and compare it to some other independent system of timing. I think you could think of a better way than me to achieve this. It would then do all the timing measurement’s decide which sound to play (sound would again be hard coded in the application itself) and play it either via regular wire or Bluetooth earpiece.
Another problem is that your system is rather expensive and many people could be tempted to disassemble it hire a hacker to crack the application, and steal the idea and sell it themselves.
I can make many different types of protection for the mobile application, however I myself given enough time and willpower could crack any and all protections made by anyone. I used to be a security consultant for a government agency here. That is really my greatest fear there are many people with excellent technical skills who can and will find holes in the system if they have enough time and resources. I think that most people using your system would be professional gamblers which wouldn’t be much of a threat themselves, however if they want to steal the idea they could find and hire a hacker to do it for them.

It is up to you to decide which could suit our needs best.
I am ready to do a small test application and need specific instructions on what we need to do.

Any and all calculations would be completely customizable via either a hidden menu or a public menu. I can code any or both of these. For example there could be a hidden menu for us which would be brought up by pressing a series of keys for tweaking sensitive data which could give ideas to potential thieves which want to steal the idea. We could also make a public menu which would be used by the system user himself for comfort or to customize options which would not be a threat.

Is the option of selling the system complete with the mobile phone possible? This would perhaps raise the price but would eliminate the possibility of inaccuracy which could be caused by using different phone models. Also one other option could be using a PDA they use much faster processing chips. It is not required to sell the device itself along with the software we could just test the most popular devices and make recommendations for users which devices to use. A second option would be to raise the price and box the complete system in a nice little package along with a system that we tested and which could be sold along with the Bluetooth earpiece any and all miscellaneous electronic devices, documentation and a nice color picture for the system.

There is also the option to make the system dependent of an online server and sell monthly subscriptions generating codes on a remote server and inactivating software after the subscription expires. Those are all just ideas which spring to mind.

We would have to brainstorm any and all details together and make something which would be profitable enough.

Let’s start one step at a time though and make sure that the system is plausible. You mentioned a simple test application and I agree that this would be a good place to start.

Please explain what exactly I can do to test the possibility of the system out.

Thank you for taking your time to read this letter,

xxxxxxxxx.

P.S. I do not think this will be an easy project, the programming might be simple in theory, however I think there will be a lot of trial and error testing and tweaking. I am confident we could achieve success.

8

Why are you trying to re-invent the wheel? I have had programs running on Symbian and pocket PC platforms for the best part of ten years. I can assure you that any timing errors caused by the processor highjacking a couple of it’s 400MHZ processor cycles to perform housekeeping tasks are miniscule and irrelevant compared to the errors introduced by the human being pressing the button.

Before you get too carried away by attempting to improve the user interface you should concentrate on ensuring that your principles and their practical application are viable.

I did this by using four fixed lasers to clock and monitor ball speed and another to clock the rotor, all data was processed using machine code.

Step one;

Be professional, obtain a modern roulette wheel, laser clocking equipment, high speed lossless video recording equipment and a professional roulette croupier.

Step two:

Remove human error to ensure that the algorithm can accurately predict on a real wheel (not video).

There’s no point in going any further if you can’t get a statistically significant advantage with laser-perfect clocking.

Step three;

If the above modus operandi can accurately predict the rotor entry point (forget about scatter for the time being) over a broad range of ball and rotor speeds and over a statistically significant number of trials, you then try and replicate those results using a human to do the clocking.

Step three;

If you are successfully able to gain a statistically significant edge by manually clocking against a real wheel and an experienced dealer, don’t tell a living, breathing sole until you’ve made some serious money :slight_smile:

The latest (December 2007) FF is currently being exhaustively tested on a current casino wheel operated by a professional dealer.

The tester is very experienced.

The tests are being recorded by professional recording equipment.

I will keep you informed.

It is my strong belief that you are way too hung up in nano-second timing and esoteric theories than you are about making money at roulette and really, isn’t that what it’s all about?

9
Why are you trying to re-invent the wheel? I have had programs running on Symbian and pocket PC platforms for the best part of ten years. I can assure you that any timing errors caused by the processor highjacking a couple of it's 400MHZ processor cycles to perform housekeeping tasks are miniscule and irrelevant compared to the errors introduced by the human being pressing the button.

I am not re-inventing wheel I already did it but I am more likely adding tires for more comfortable drive. I am only testing what can be done on mobile platform and at which cost to accuracy.

It doesn’t matter on which speed processor running if the program is not using it.
All developers told me java can’t do real time applications. Maximum timing is 1 ms and it doesn’t have to be accurate. Especially on mobile phone where other applications are running in background.
Take home PC play video then run another application and it will be slow.
I can live with one ms timing as bottom limit. The system will probably produce extra 1-2 pockets error. It is still fine. But if measurement is not constant there is no point of using it.
I still did not give up, and probably with this guy I will try to develop very basic program to see if it will work. I also discovered that Mark and Stefano losing more then one sec. simply because of wrong design in calling audio file. By my standard it is not acceptable.

You used your way and you come in conclusion that prediction of leveled wheel is imposable.
I used my way and I found out that it is possible.

Remove human error to ensure that the algorithm can accurately predict on a real wheel (not video). There's no point in going any further if you can't get a statistically significant advantage with laser-perfect clocking. If you are successfully able to gain a statistically significant edge by manually clocking against a real wheel and an experienced dealer, don't tell a living, breathing sole until you've made some serious money :-)

Prediction on real wheel will be always more accurate then prediction on video spin. However video spin can be repeated and it will be always same which of course is not possible on real wheel. Therefore video can be used as valuable tool for testing purposes, because it gives constant parameters. But predicting home on viodeo spins and expecting same in casino is different thing and I can agree with that. Close to laser perfect clocking was first thing I did. If I couldn’t do that I wouldn’t work more on the project.

I can exclude experienced dealer, since I am choosing the dealer. There is not much that dealer can do except to call NMB earlier, to short spins or to spin rotor to fast. After rapid winnings it happened many times. But I as a player always can make choice what I am going to do. Of course it is bad, because after finding nice conditions player gets simply stopped to take more advantage of it. I think dealer manipulations as described should be excluded from the test.

The truth is that I did not make even close as Ritz team or probably you with your tilted wheel approach. That includes and my play on tilted wheel.

Perhaps I am not old enough so I couldn’t be at right time and at the right place for that. Such big winnings these days are close to imposable especially not if you do not invest huge amounts. If you do it is not smart to get advantage buy using any device. You simply wouldn’t last long. Sharing ideas and solutions with the others is not bad thing at all in usual it leads to progress.

If you are doing intensive testing on the FF, I can assume that you managing to get enough predictions. On Cammegh Connoisseur I couldn’t get many because it is on bottom edge of FF’s specification. I did some changes on program to allow few more spins so the system can come closer with settings to specification of the wheel prior then it goes in to fine tune, now after few spins I get more predictions but I did not test it enough.

10

There was 2 topics with same post. I tried to merge them but it did not work, so i will copy here PJ’s post.

I’m afraid I have to agree wih Survtech on this… however it does hurt to say so given that Survtech consults with casinos on such issues. So I am somewhat bemused by their apparent concern for us method players/gamblers who are fed to the wolves when we are detected In fact I was going to post a remark a couple of days ago about peoples apparent hang up on nano second timing… As far as I see it the game is beaten once you can safely and reliably identify a rotor entry point that is within 3 or 4 numbers of the actual point of impact by the ball with the rotor. This information would be ““GOLD”” to say the least. I would add one more comment to Survtech’s “Step3 (version 2)” and that is that beating an experienced dealer as he puts it is not necessarily an absolute necessity because there are many trainee dealers on any casino floor and so avoiding an experienced dealer is very easy to do.

So now a question for Survtech… are you going to post the results of your tests of the FF on this forum immediately your tests have concluded?

Cheers
PJ

11

@PJ

I will let forester decide whether or not to publish my findings.

@forester

The tester’s preliminary figures show predictions 31% of the time.

He did mention that he now “knows” when he isn’t going to get a prediction, this is usual with experienced clockers.

There are very good reasons why I am skeptical about getting an edge on a random wheel and I’ll explain when I have more time.

12

I never insisted on 1micro sec. timing. I think I am rational enough and at start I said 1 ms. may be good enough.
I am only higlighting other problems.
What I see from developer’s letter is only problems.
If I have to do it all from the start it would be imposiable.

Simply because the poject must be divided in many parts where each one must have own nethod of testing. With my FF design I was able to go step by step in slow motion every single instruction, and I did developed loops to test program with different parameters so I could compare results. I think I will simpl separate part of ball timming and basic error correction and see what happens in java. At same time I am looking in developing my own hardware. Maybe I invest in some equipment for surface mounting technologu and do all by myself.

it may sound just as this :smiley:

13
The tester's preliminary figures show predictions 31% of the time.

Survtech, something must be wrong, that is what I was getting on Cammegh wheel.
Any single wheel I played in casinos I can get better then 80%. Even Stefano on his video with the FF have had 60%

Please make sure that he does continues clocking and that he don’t start too late.
Did you watch video about settings? Maybe it helps.

He did mention that he now "knows" when he isn't going to get a prediction, this is usual with experienced clocker.

Yes, I always know will the system predict or not, I also know when it will predict.

I think you have programmer, if you can read EPROM after he makes 10-20 predictions I would be able to see what is happening. Even if you turn power off it will be there.

14

“Something must be wrong”

Obviously “something’s wrong”!

The point is forester, that the tester is an intelligent adult, he understands the principles of wheel clocking, he has a real wheel in a real casino, he has your Powerpoint presentation, he has your video, if he isn’t getting predictions then your average device purchaser isn’t going to get them either, particularly when you consider that my tester is not trying to do this covertly while squinting over someone’s shoulder.

I have given him some tips and will also pass on your comments, I’m sure we’ll get there.

15

If you can get those details it would be perfect.
If not used accuracy level and amount of pulese after set up may help.

As I can remember wheels in WA are same as in vic, qld, act so it shouldn’t be the problem.
I talked with few people and they all are ok with percentage of predictions.

Maybe the FF become self conches learning intelligence, so it starts teasing if it is used by casino staff. :stuck_out_tongue:

16

The tests are not being carried out in Western Australia.

When calculating offset for a “drop-zone” wheel, one can easily take account of how the ball enters the rotor:

  1. “Dead-dropping” from a vertical diamond.
  2. “Skating” off the top of a horizontal diamond.
  3. Taking a lazy curve in between two diamonds.

Each one of these entry styles result in very different ball behavior or scatter.

Even though a “drop-zone” will allow you to tailor the offset, it is still no mean feat to maintain a significant edge.

I your case, you can not predict scatter because you can not predict how the ball will enter the rotor.

I doubt that you can accurately and consistently predict when and where the ball will leave the ball track (at least not by manually pressing a key) but even if you can, I’m sure your edge will be severely diluted until you are able to predict (and curve fit) the ball entry method.

The person testing FF does not know how I feel, in fact I am showing much enthusiasm, so the testing will in no way be biased.

I don’t want to be right on this one, I want your device to work!

17
The tests are not being carried out in Western Australia.
Well if he has good clocking skill and if he is getting only 31% then it must be the wheel. If ball deceleration goes outside system limits he will get less predictions and even some inacuracy.

A
X
Xxx
Xxxx
Xxxxx
Xxxxxx
Xxxxxxx

B
X
Xxx
Xxxx
Xxxxx
Xxxxx
Xxxxx

Instead something as graph A for some ball speeds he may get top cut as on graph B.

FF can handle 100-255ms difference in between ball rotations.
Less then 100 is pointless accuracy will drop.
More then 255 would need clocking faster ball or prediction will be too late.

The ff does go partly in to scatter. If expected number where the ball will stop is zero.

  1. “Dead-dropping” from a vertical diamond.
    Most likely it will happen 2-3 pockets in front of zero and this ball most likely will end up there.

  2. “Skating” off the top of a horizontal diamond.
    If this happen expected zero would be most of the time 9-12 pockets from there.
    Because of those two simulations of multiplying 2 graphs “ball to rotor” and scatter in reality should be better. How much better it also depends on the rotor speed. Meaning of explanation that there is shifting of about 6-9 pockets in between those 2 situations.

  3. Taking a lazy curve in between two diamonds.
    Could be anything, but all of those are still dependable on how the ball hits rotor divider.

This is only basic explanation, and reason why I am not trying to predict diamond hit.
I did some tests trying to group different ball speeds that may hit same diamond. At some particular situations (which we do not have control) it may be better but in general it isn’t the best way.

18

The ff does go partly in to scatter. If expected number where the ball will stop is zero.

[b]1. “Dead-dropping” from a vertical diamond.
Most likely it will happen 2-3 pockets in front of zero and this ball most likely will end up there.

  1. “Skating” off the top of a horizontal diamond.
    If this happen expected zero would be most of the time 9-12 pockets from there.
    Because of those two simulations of multiplying 2 graphs “ball to rotor” and scatter in reality should be better. How much better it also depends on the rotor speed. Meaning of explanation that there is shifting of about 6-9 pockets in between those 2 situations.

  2. Taking a lazy curve in between two diamonds.
    Could be anything, but all of those are still dependable on how the ball hits rotor divider. [/b]

I see you acknowledge that the scatter will vary depending on ball entry method but I don’t understand, how can FF “go into scatter” when it has no idea what the ball entry type will be.

19
I see you acknowledge that the scatter will vary depending on ball entry method but I don't understand, how can FF "go into scatter" when it has no idea what the ball entry type will be.

image
Explanation here
http://myrulet.com/forums/index.php/topic,203.msg2095.html#msg2095

Then follow few posts from here
http://myrulet.com/forums/index.php/topic,252.msg2395.html#msg2395

image

And this may be useful
http://myrulet.com/forums/index.php/topic,156.0.html

20

Let’s do some hard talking here:

I am not talking about relatively minor differences caused by the point at which the ball hits the same diamond, I’m talking about three distinctly different scatter patterns or behaviors depending on whether the ball hits a vertical diamond, horizontal diamond or no diamond.

If we know when, where and how the ball is going to begin it’s entry to the rotor we have a good chance of an accurate prediction.

If we know the entry characteristic of the ball (as you do when predicting off a drop-zone) we can allow for it as an offset.

Minor clocking errors and/or ball speed anomalies are smoothed by the drop zone.

Even under near perfect conditions as outlined above, 20% is about as good as it gets.

How do I know this?

  1. I have played near perfect drop zones under zero heat conditions (before device peddlers got on the Ritz bandwagon) with a device which has been proved to work under controlled tests by the British Government.

  2. I watched Tosa, and friends take three million aussie dollars from two different wheels, both with near-perfect drop-zones.

  3. I watched Christian Kaison and son for several hours playing a wheel with a near-perfect clockwise drop-zone.

  4. I have the surveillance reports of Kovacs’s play at Star City.

  5. I have watched Australia’s best cerebral wheel clocker playing under near-optimal conditions.

I have never seen anyone, including me, consistently achieve better than 20% on turnover. It’s not just a case of betting more numbers, all that does is reduce variance, there are simply too many factors which influence the ball’s behavior after it enters the rotor.

In your case, forester, you do not have the smoothing effect of the drop-zone to take up clocking errors, timing errors or ball deceleration anomalies.

You do not know how the ball will leave the ball track.

You do not know how the ball will behave as it enters the rotor because you do not know how it will enter the rotor.

Tests are by no means complete but I have observed that, when FF does accurately predict the correct number, the end result(s) appear to be random. I doubt that they are random, I think that when I get enough data it will show that when FF accurately predicts there will be four distinctly different offsets (one of them being random) depending on the entry characteristics previously discussed.