Cross - reference system

[Roulettebeater]

I will record tonight first video on how my cross- reference works... I am not interested in sale !

The goal of this thread is to share tips and tricks that relates to this system..

The method is based somehow on physics and it shows some good result, but not all the time, my goal is to identify the intervals when this system works at best ..

Stay tuned, I will record first video tonight and share it here

[Steve]

You need the variables, results, the understanding of the dynamic relationships between them all, and cross referencing data so you dont need as many spins for statistical relevance. The last two are the hardest part. You can code automated testing software to narrow down the algorithms.

If you simulate static conditions, and gradually change conditiins, you'll better able to understand the dynamic relationships.

Do it right, and you can increase the accuracy of predictions for anything that can be predicted. I do a similar thing with my cryptocurrency trading bot.

[Steve]

You should also have rating algorithms to assess risks. Some wheels can be very predictable in some conditions, but too volatile in changing conditions.

[Roulettebeater]

I will show in the video a demo, the predictions will be validated against a live wheel...

I need three variables for the predictions :

1- launch point (exact pocket)
2- exit/drop point ( exact pocket)
3- result

I input these three variables into a program (the interface is simply a cmd window)... for now I can’t give details about the algorithm ...

I really hope that you view the predications and tell me if there is somehow enough accuracy... next step is to go into a privat chat with some of you who have skills in order to improve the algorithm

[Roulettebeater]

You should also have rating algorithms to assess risks. Some wheels can be very predictable in some conditions, but too volatile in changing conditions.

That’s my problem !
Changing conditions ! I need support ... I have the algorithm but still can’t asapt it to these conditions, hopefully you can work with me

[Steve]

I've already given all i will. The clues are the same and dont change.

[Loc]

That’s my problem !
Changing conditions ! I need support ... I have the algorithm but still can’t asapt it to these conditions, hopefully you can work with me

Where is the rotor? How you predict where it will be, when the ball will land? You have any partners already?

[Loc]

I will show in the video a demo, the predictions will be validated against a live wheel...

I need three variables for the predictions :

1- launch point (exact pocket)
2- exit/drop point ( exact pocket)
3- result

I input these three variables into a program (the interface is simply a cmd window)... for now I can’t give details about the algorithm ...

I really hope that you view the predications and tell me if there is somehow enough accuracy... next step is to go into a privat chat with some of you who have skills in order to improve the algorithm

If you say "somehow enough accuracy", then probably it will not work, because you need a logical answer, Why it should work, if you hope, then chances are it will not.
Rather than talking some morse code, tell what you need, i am always ready to work with anyone real about the thing.

[Firefox]

Where is the rotor? How you predict where it will be, when the ball will land? You have any partners already?

This is where I don't pretend to understand cross reference systems. I can get an edge with VB and DS under some conditions but rotor speed is a crucial element in both these. A 3 second rotor and a 4 second rotor will carry the ball to quite  different places with the same release point, even with a constrained drop off and same scatter to help matters along.

For example, difference between 3 and 4 second rotor is 3 pockets per second. SInce we are measuring neither ball speed nor wheel speed, over 15 second spin that's 45 pockets or over 10 second spin that's 30 pockets. We don't know which, even assuming other variables are constant. And the spin could 18 secs or 8 secs or the wheel speed could be 2.5 second rotor or 6 second rotor. This will lead to totally different sectors being favoured.

RB mentions his system is VB, but since it does not involve spin data ie betting before spin, I don't see that it can be. It is more likely an AP system based on observation.

But for me to understand this system I would need to know release point,  rotor speed, cw/acw, ball revolutions, struck diamond number, end result number, struck diamond scatter plot.

This seems to be much more data than is being collected. What I don't understand, I can't judge.

What I want to do is measure wheel speed and ball speed in first few revs. Then place a bet based on similar known data. Or no bet if the parameters are outside limits. Then I understand it.

[Loc]

This is where I don't pretend to understand cross reference systems. I can get an edge with VB and DS under some conditions but rotor speed is a crucial element in both these. A 3 second rotor and a 4 second rotor will carry the ball to quite  different places with the same release point, even with a constrained drop off and same scatter to help matters along.

For example, difference between 3 and 4 second rotor is 3 pockets per second. SInce we are measuring neither ball speed nor wheel speed, over 15 second spin that's 45 pockets or over 10 second spin that's 30 pockets. We don't know which, even assuming other variables are constant. And the spin could 18 secs or 8 secs or the wheel speed could be 2.5 second rotor or 6 second rotor. This will lead to totally different sectors being favoured.

RB mentions his system is VB, but since it does not involve spin data ie betting before spin, I don't see that it can be. It is more likely an AP system based on observation.

But for me to understand this system I would need to know release point,  rotor speed, cw/acw, ball revolutions, struck diamond number, end result number, struck diamond scatter plot.

This seems to be much more data than is being collected. What I don't understand, I can't judge.

What I want to do is measure wheel speed and ball speed in first few revs. Then place a bet based on similar known data. Or no bet if the parameters are outside limits. Then I understand it.

That's true, mine collect all that data, rev, the diamond hit, rotor speed range that dealer spins and more, i wanna see how he do it.

[Firefox]

Steve has a Xref system based on struck diamond reading, spin direction, and result. It uses computer analysis of this data. But for me it's not enough data. It would pick up wheel bias and wheels with predictable scatter. I'm uncomfortable there are too many unknown variables, and for that reason I'm unable to comprehend these methods

However since Steve sells the system as JAA, he's reluctant to give any more info. So have to respect that, I guess.

[Steve]

There are many variables you can add. More variables mean higher accuracy and assurance, but reduced practicality. You need a balance between accuracy, assurance and practicality to male a viable approach. Rather than a system, its an analysis method.

[Firefox]

Would it be able to accept rotor speed as an input. I clock rotor speed manually by head count on every spin to within about 0.2 second. It's the first thing I do on a spin. I don't think that's impractical if you are used to it.

[Roulettebeater]

Question to the experts :

rotor speed= 1/2 ball speed > scatter = 18 pockets
rotor speed = 1/4 ball speed > scatter = 9 pockets
rotor speed = 3/4 ball speed > scatter = 22 pockets
rotor speed = ball speed > scatter = 36 pockets



According to your experience, Are these assumptions valid ?

[Firefox]

When are  you measuring ball speed, because it is constantly changing (decelerating).

In general rotor speed and ball speed are not directly relatable.

But since ball speed at fall off is usually constant, scatter is a mild function of rotor speed. More important for scatter is fret/wheel rotor design.