Wicked Air Sportz: Turbo Rev

[manike]

Originally posted by hitech
Since it can't store anything permanently, and it clears the tables after paint stops flowing the best it can do is adjust to a single string of shots. Artificial intelligence software? Really?

Yes and apparently it takes at least 16 shots before it works out the table so if you fire less than 16 shots in a burst it won't be able to do it's 'thang'.

And it stops using the ball data after 30 shots... so if you fire a longer string it is no longer 'adapting' to the balls dropping.

So to summarise, it won't be more than an agitator if you shoot less than 16 balls. (What happens at the start of an 18bps burst then....) and it won't be more than an agitator if you fire a burst of over 30 balls...

So if you want to shoot fast besure to count and make sure you do at least 17 balls (the last one will be 'extra fast' ) and no more than 30 or you might chop them...



manike

p.s. Still waiting for the 18bps video of a turbo rev on a non ace'd gun...

[cphilip]

Originally posted by manike
I'm still waiting to see any theory of yours that isn't absolute codswallop.

manike

Ummmmmmm....how the heck am I supposed to Moderate that? I have no idea what that means!

grumble grumble grumble...

[WickedAirSportz]

Where did you get the 30 balls figure? Yes, the syncronizing routine requires no less than 16 balls, but no more than 32 balls to syncronize, and is designed to work around a steady stream with little fluctuation in the ball spacing (about a 80ms window).

As far as the video goes, I did not video this event - it happened a year ago. If you notice on our website, it states 16bps (not 18bps), and has for a year. By your own admission, you have seen 16bps possible. If you spent years doing research, how come you have not come up with the fastest agitated hopper upgrade like I did in a few months?

By the way, a BYTE is not always 8 bits. That is the old school way of thinking. If you program assembly on a PowerPC processor, you are going to have some problems. A BYTE is 16 bits, a WORD is 32 bits, and a LONG is 64 bits, and a DOUBLE is 128 bits. In microcode technology, a BYTE represents the smallest path size of the execution pipeline.

[hitech]

Originally posted by WickedAirSportz
By the way, a BYTE is not always 8 bits. That is the old school way of thinking...In microcode technology, a BYTE represents the smallest path size of the execution pipeline.

You (and others) can re-define the term byte if you want. That seems to be what "kids" do these days, change things to fit their current situation. A byte is 8 bits.

Interesting choice of statments in my post to comment on...

[manike]

Originally posted by WickedAirSportz
Where did you get the 30 balls figure

Oh I'm sorry it's 32 balls... Thanks for putting the correction in on that point.

Originally posted by WickedAirSportz
As far as the video goes, I did not video this event - it happened a year ago. If you notice on our website, it states 16bps (not 18bps), and has for a year.

But you claimed it on a website... would you like me to quote you? again... So you have no video, and no proof that it is possible? Then how can you say...

Originally posted by WickedAirSportz on 24/08/01
You just can't argue with the fact that a gun set to shoot at 18bps (in full auto) empties the hopper in a just a few seconds, without breaks, chops, or misses. This is what we are seeing with the TurboRev upgraded hopper.

You can argue with it if there is no proof. If it was true at that time why does your website now claim 16bps? Surely you hadn't originally exagerated the truth had you?

you see once again you have no proof of your claims when you make them. I believe you reduced the number from 18 to 16bps after I called you last time. I'd even be interested in seeing a gun on FA empty a Turbo rev at 16bps "without breaks, chops, or misses" Surely that will be easy for you? There has never EVER been a video or proof of it happening. Isn't that a little strange when people usually can't wait to show off what their guns can do on the net?

Originally posted by WickedAirSportz
By your own admission, you have seen 16bps possible

Yes between two shots only, and purely as a lucky event, never as a reliable feed rate for a whole hopper that a gun could shoot on FA "without breaks, chops, or misses"

Originally posted by WickedAirSportz
If you spent years doing research, how come you have not come up with the fastest agitated hopper upgrade like I did in a few months?

Because I found that it wasn't possible to do with an agitating loader, and so went off and developed something else instead

manike

[mykroft]

WAS: I'm wondering if you ever looked at standard practice amongst players. String of over 16 balls are rare in the tournament scene, except for back players, and even then the strings tend to be shorter. As far as I can tell from your explanation of how the Turbo-Rev works, the adaptive algorithm is useless for 75%+ of the tournament scene, who tend to snap shoot strings of 3-10 balls.

So the adaptive algorithm would appear to be useless since it requires a steady string that's excessivly long, I would suspect you pick up most of the Turbo-Rev's performance the same way an X-Board does, by spinning faster & with more torque. Now if you store the data gathered, and got the minimum string down to 8 balls or so, I could see this working, but that would take more RAM than the PIC you are using has.

[314159]

Originally posted by hitech
And BTW, a byte is 8 bits, period.

the rom on the 12c508a is 512x12bits.... that's why i used the term words.

[WickedAirSportz]

WAS: I'm wondering if you ever looked at standard practice amongst players. String of over 16 balls are rare in the tournament scene, except for back players, and even then the strings tend to be shorter. As far as I can tell from your explanation of how the Turbo-Rev works, the adaptive algorithm is useless for 75%+ of the tournament scene, who tend to snap shoot strings of 3-10 balls.

You're absolutely right! I am a back player, and I do shoot long strings lasting sometimes 5 or 6 seconds. I find it quicker to just move your barrel as you are shooting then to stop shooting, moving your barrel, and then continue. The benefits of THIS PORTION of the AI will not help snap shooters. The previously mentioned AI, where the motor speed is adjusted based on the time between balls, does increase the feed rate (which apparently is not being disputed here).

So the adaptive algorithm would appear to be useless since it requires a steady string that's excessivly long, I would suspect you pick up most of the Turbo-Rev's performance the same way an X-Board does, by spinning faster & with more torque.

The x-board does not increase the speed or torque. They just changed the delay time on the start up, and reset the LED blinking on a low battery condition. Those are the ONLY changes with the x-board when comparing the code from original boards to the x-board, side-by-side. The PICs were never locked in any of their boards, so you can check this out yourself.

Now if you store the data gathered, and got the minimum string down to 8 balls or so, I could see this working, but that would take more RAM than the PIC you are using has.

Percisely why the TurboRev II uses the newer PIC that has 1K of code space, more RAM, and EEPROM (for storing table pointers), an A/D converter for feedback on the motor torque level, and real interrupts.

[Miscue]

Originally posted by WickedAirSportz
Do you want the hopper to feed fast? If so, you need to determine the optimal speed/torque for the motor (at the very least).

A very simplified form of hopper AI can be viewed like this:

The time between balls is clocked in, and an average over a period of time is recorded. Now, increasing and decreasing the motor speed is going to affect that average. So, the software can determine what the best possible speed is to allow the balls to flow the quickest.

This method alone works great, but it can not deliberately accelerate the stack of balls, although this does happen on occassion as you see a spike in the timing chart.


Miscue, you and others asked for an explanation (proof) of how the TurboRev technology works. I am providing that to you. If you intend to make smart *** remarks, then I won't waste my time.

This is not proof... extremely vague.

Replace "hopper" with "popcorn popper." This popcorn popper has an agitator connected to a motor.
.
.

Do you want the popcorn popper to pop fast? If so, you need to determine the optimal speed/torque for the motor (at the very least).

A very simplified form of popcorn popper AI can be viewed like this:

The time between kernel pops is clocked in, and an average over a period of time is recorded. Now, increasing and decreasing the motor speed is going to affect that average. So the software can determine what the best possible speed is to allow the popcorn kernels to pop the quickest.

.
.

You could replace "hopper" or "popcorn popper" with microwave, dishwasher, lawn mower, blender, etc... and it would follow the same logic. Actually, pretty much everything you have said has similar problems.

If you had explained WHY... then this template would not be interchangable. The WHY's for why a hopper, popcorn popper, etc. will be different - and are not interchangeable.

This is what's happening. You are making the square peg fit the round hole. You don't even know the WHY's yourself. What you think and say is make-believe... imaginary. I believe that you believe what you say is true - and in this there is no sense in arguing. What do you say to someone who says the earth is supported by a large tortoise? "What does that tortoise stand on?" "Oh, it's tortoises all the way down!"

Sure, you may be good in field X... but that does not make you good in field Y, which you are trying to do w/o success.

I'd stick to coding... and leave the subject of "reality" alone.

[WickedAirSportz]

If you had explained WHY... then this template would not be interchangable. The WHY's for why a hopper, popcorn popper, etc. will be different - and are not interchangeable.

One step at a time. You have to learn to walk before you can run.

I will explain why. I have already posed several questions that have gone unanswered. I am certainly not going to give out the source code as your example, I want everyone to learn something from this... which is the way I would be able to prove that I do know WHY this works.

[hitech]

Originally posted by 314159
the rom on the 12c508a is 512x12bits.... that's why i used the term words.

And you would be using the term correctly.

[manike]

Originally posted by WickedAirSportz
I have already posed several questions that have gone unanswered.

How strange, I was just thinking exactly the same thing. People might get mistaken and think you were avoiding answering the questions and posting proof...

but surely that can't be the case... can it?

Your attempts to act like a 'know it all professor' are condescending and pathetic.

Put up or shut up. How about the Turbo Rev on your new intimidator with Equalizer board... surely that would get the best possible performance out of the turbo rev

manike

[hitech]

Originally posted by manike
How about the Turbo Rev on your new intimidator with Equalizer board... surely that would get the best possible performance out of the turbo rev

Because it won't work?

[314159]

Originally posted by WickedAirSportz
One step at a time. You have to learn to walk before you can run.

I will explain why. I have already posed several questions that have gone unanswered. I am certainly not going to give out the source code as your example, I want everyone to learn something from this... which is the way I would be able to prove that I do know WHY this works.

i agree with wickedairsportz. for example, obtaining the code without knowing what it's aim is would be like trying to play sokoban without knowing the destinations. you would see a bunch of info being moved around and a bunch of bits being set....

i will play

Originally posted by WickedAirSportz
why does the TurboRev feed faster than any other aggitated hopper in existance?

first, assume that no paint is being fed, and the paddles were spinning all the time. the paint in the hopper would be continously spinning around. the paint moving around in a circle would have it's momentum traveling around in a circle in the direction of the propellers. this would probally result in skipping, bobbeling.... and resist gravities pull to feed it down.

it seems the most advantageous way to move the paddle would be just enough to ensure a couple balls go over the feed port, then abruptly stop it, just as the gun is firring, before the ball in que in the ball stack clears the senor, tripping it. then repeat it before the next estimated shot.

of course if the rules that are set up for the pic to spin the paddle make a wrong guess when to spin and stop the paddles, (it could detect this by verrifing the time the sensor should see a gap), it could spin for xxxx amount of time like the revvy does. and have the same preformance as a revvy.

this would not be a total loss, because the rule set would take this into account trying to adapt for the next shot fired.


P4ULuk, stop being retarded.

[Emagster]

wow...that was great miscue. Not that i know diddly squat about all this odd termonology...but it sounds good from what i got out of it

[cledford]

Originally posted by 314159


first, assume that no paint is being fed, and the paddles were spinning all the time. the paint in the hopper would be continously spinning around. the paint moving around in a circle would have it's momentum traveling around in a circle in the direction of the propellers. this would probally result in skipping, bobbeling.... and resist gravities pull to feed it down.

it seems the most advantageous way to move the paddle would be just enough to ensure a couple balls go over the feed port, then abruptly stop it, just as the gun is firring, before the ball in que in the ball stack clears the senor, tripping it. then repeat it before the next estimated shot.

This makes total sense - I think it would be called "optimizing the flow of balls to be fed by gravity."

Once gravity takes over the feed rate cannot exceed 14BPS per second, right?

If the above stated adaptive process works as suggested, I can see how it would insure that the balls would be suffering the minimum amount of force pushing them in a different direction from where you want them to go - but how does it speed up gravity?

Another question, regarding the source code - can't it be copy-writed or something?

-Calvin

[WickedAirSportz]

If the above stated adaptive process works as suggested, I can see how it would insure that the balls would be suffering the minimum amount of force pushing them in a different direction from where you want them to go - but how does it speed up gravity?

By advancing the position of the paddle slightly. Instead of now clearing the path, you are actually "tapping" the top ball in the stack as it falls, which accelerates the bottom ball into the breach.

That in a nutshell, is exactly how it works.

[cledford]

Thank you.

-Calvin

[WickedAirSportz]

The theory that I originally had was that it takes 'xx' ms for a ball to fall the ~.68" when sitting on top of the bolt. If the paddle could be wedged between three balls on their way down the feed tube (moving the middle ball completely away from the feed tube) so that the bolt was opening and closing as the balls were falling, you could easily exceed the speed of gravity @ the ~.68" distance because the distance would be just about double. I had no luck getting this to work, although I believe that this method is also possible (but much more dependant of the number of paddles and point of blockage).

[Butterfingers]

WAS,

Ill spell it out nice and simple for you.

WHERE IS THE PROOF!

You can theorize all you want, the truth is that your product does not half the stuff that you theorize.

WE WANT SIMPLE PROOF. A feat that you have not been able to provide us up to this point.

Here is my theory on truck flight....

"It is possible for the turbulance under the tires of a big rig to create enough lift for a truck to fly. Our brand of tires have an intracate tread patten that allows big rig flight to be possible. It is too complicated for me to explain big rig flight to you so i will redefine everything until you get sick and tierd of listening to me and take me at face value like a bunch of pawns. Eventhough I have never actually shown that I can fly my big rig I assure you that it is possible becuase my theory is sound and unlike any development in life I do not think it requires any proof."

Sereously cut the crap and either put up or shut up. So WAS. If you theory is so sound where is your proof?

THAT IS the bottom line.

Proof is not the argumentative fallacy and half arsed speculation you have been giving us, proof is a gun shooting 16 BPS as you claim with a turborev.

A quote from a wiseman:

"WAS= Wild A..ed Speculation"

[314159]

Originally posted by WickedAirSportz
By advancing the position of the paddle slightly. Instead of now clearing the path, you are actually "tapping" the top ball in the stack as it falls, which accelerates the bottom ball into the breach.

at first glance at this, i thought that the length of the feed neck was not significant, because the distance from the paddle to the eye was a fixed distance. you trigger the paddle a given amount of time after you see a ball fall, and it wacks the ball above it... right?

one day i was watching a clear revolution loader. after every string the guy fired, and at every slight pause. the revy would have a ball in the beam sensor, but there would often not be a ball on top of it. in order to inshure accurate timing of the paddle to wack the top of the ball, there must be a ball to wack (NOT GAP ABOVE THE EYE).

with the proper distance under the loader, one could get the top ball in the ball stack to stick out just slightly so that the paddle wacked it every time. with a less than optimal distance under the loader, the paddle would throw out the top ball in the stack to be wacked every time. because you do not have any provisions for adjusting the length of the feed neck in the revvy, how do you insure that there is a ball in the top of the stack to be wacked every time? do you have a set of instructions for the pic for this?

[manike]

Originally posted by WickedAirSportz
By advancing the position of the paddle slightly. Instead of now clearing the path, you are actually "tapping" the top ball in the stack as it falls, which accelerates the bottom ball into the breach.

That in a nutshell, is exactly how it works.

For the casual observer it sounds very feasible.

An excellent theory and hypothesis, in fact it’s so good I had it myself about 5-6 years ago. I take it however that you didn’t go on to prove your hypothesis like I did. I tried to prove it but actually found out that it doesn’t/can not work. I’ll explain why.

A little back ground for you. Back when WDP developed the Angel I was also talking to them about feeding technology since the new electro was firing so fast nothing could keep up with it (this was before they added a minimum time for the bolt to dwell back between shots, and that immediately solved a lot of issues). At this point I’d already been experimenting with different paddles with more and less arms and with flexible tips and been making hoppers for my own use. WDP came out (quite independently of my research) with the intelli-feed solution and used to offer kits with the lead and a new paddle with extra long and more supple arms which they hoped would help put a force on top of the balls and knock them down into the stack.

When I spoke to John Rice about this he discussed that was what he was trying to do, and so I looked into it with my test rigs.

There are a large number of reasons why it will not/ does not work. Some of the reasons are physically and some are theoretical.

Firstly, In the feed tube of the loader balls do not stack perfectly directly above each other, the column actually snakes from side to side a little and as you also appear to have observed when the stack is falling under gravity there is a small gap between the paintballs, I expect due to how each ball interacts differently with the side wall of the loader as it drops. I took picture’s of a stack falling to observe this. So even if you put force on the top ball just after they have all started dropping it will not necessarily put force on the ball below it etc… and further on down the chain. Now you may think ‘well if I accelerate the top ball fast enough I can get it to hit the next ball, to hit the next ball etc.’ until it hits the one going into the breach. The trouble is that with all lower balls being accelerated by gravity, by the time any force you can add to the top ball catches up with the bottom one in the stack… it’s already in the breech doh! Too late. You only have 60ms for it to catch up and make any difference to the feed rate.

Secondly, due to where the eye is placed in the Rev feed tube it is often possible for there to not be a ball above it. The eye detects the tube to be blocked, but the space between the main cavity and the top of the tube is not always filled. This happens quite often and means by the time the rev detects a ball to be missing the feed tube is empty enough to accept two balls. If there is no ball in that space there is no ball for your paddle to put force onto to help the stream feed.

Thirdly, in order for the paddle hitting a ball to accelerate it down it has to hit it above the centre point of the ball. If it hits the ball below it’s centre it tends to knock it up and away from feeding! With a ball in the optimal position for detection by the eye the ball that is likely to get tapped by the paddle is up in the wider part of the neck, it’s not constrained and it’s not certain that tapping it will even knock it downwards. Obviously if you tap the ball below it’s equator it’s more likely to get knocked up from the tube. If you knock it on the equator it gets’ knocked sideways. Believe it or not but years ago I attached a ball onto a spring and tapped it with paddles to see which way it would go. I found that to get it to reliably go downwards from the neck that you had to hit it at an angle less than 60 degrees from the vertical. You can see why when you think about the force vector you put on the ball and it looks like this



Thus you only have a small window in which to tap the ball to accelerate it downwards. The longest time this window will be available (if the ball is starting to move from stationary) is 29ms. If you hit it either side of that window, you will either hit it sideways or upwards or hit the ball above it upwards… if that physical window arrives when the ball is already dropping then the time window will be even smaller.

Accelerating from rest on top of the bolt into the breech a ball takes 60ms. The fastest cycling gun is the RT and it cycles in 20ms. So we will give you the benefit of the doubt and use the fastest numbers. In order to achieve 16bps you need to get the ball into the breech in 43ms. If you don’t start accelerating it in that 43ms you won’t be able to get 16bps. Obviously the sooner you start accelerating it with more force than gravity the better.

Fourthly you can only start the paddles rotating when it senses a gap. Now ideally the sensor would be poised just below the top of the ball like this such that it quickly starts the paddle. Now for the sensor to be cleared the ball is falling that 2.8mm under gravity and this will take 24ms. (each process has to start from scratch as the stack stops on the bolt each time the gun cycles) So now you have a ball that has started falling and from the total time it starts falling you must ‘tap’ it to accelerate it within 43ms. Taking that at the best case of detection that the balls are falling it will take 24ms that leaves you with just 19ms in which to tap the ball, have it accelerated and get it into the breech…

Fifthly, Considering that there are 6 arms on the recommended paddle it would need to rotate 1/6th of a rotation in 19ms in order to be able to hit the ball within the allotted window. This works out at a rotation every 0.114 seconds, and that’s 8.77 revolutions per second! It doesn’t look like the turbo rev rotates the paddles that fast at any point.

Now if you rotate the blades of the propeller that fast in order to be able to actually knock a ball down within the period it must make contact… you will just have a popcorn machine as there is not enough time between paddles passes to feed balls into the top of the tube! Now WAS does vary the speed of the paddle BUT without knowing exactly where the paddle is in it’s rotation you can’t tell when you need to have it going fast to knock the ball and when to have it going slow to allow the next ball to feed, it’s too late detect it by the eye because that is for a ball already in the feed tube being fed, you need to detect the one that is not yet at the eye. Without feedback on the paddle location it’s just not possible. I’ve tried doing this with a system where I did know where the paddle was and when it would release a ball and it still wouldn’t work very well. And obviously you don’t know where the balls are in the loader, so you have to ‘hope’ one will be in place to get tapped. In essence this is one major problem.

Sixthly, this is all in the best case scenario of ball detection! If the sensor is set up at anywhere below this then the time taken for the ball in front of the sensor to clear it is longer than the total time you have to get a ball in to achieve 16bps! Obviously the lower the sensor is below the top of the ball the less time you will have from the sensor detecting the gap in order to be able to accelerate it.

Ok still with me? Now we have two time periods that must coincide, the time in which you need to react to the previous ball dropping and the time in which hitting the ball will actually knock it in the right direction. So you have to align a window of 19ms (maximum) with a window of knocking the ball of 29ms, whilst not being certain that there is a ball available or where the paddle is to knock it! It maybe possible to get those windows to coincide BUT firstly the sensor would need to be perfectly located, the ball would need to be perfectly located (so the height of the hopper and arrangement of the balls in the feed tube is critical) and you would need to be able to hit the ball with the randomly moving paddle at just the right time.

The chances of that? I’d bet more money on walking out the door sticking my hand in the air and catching the next meteor to hit earth…

And in some cases if the eye is not at the right spot in relation to the ball then it is just flat out impossible. Due to the nature of paintballs and the random way they stack in the tube the location of the eye to the top of the tube does vary. Sometimes quite significantly (mm’s).

Originally posted by WickedAirSportz
The theory that I originally had was that it takes 'xx' ms for a ball to fall the ~.68" when sitting on top of the bolt. If the paddle could be wedged between three balls on their way down the feed tube (moving the middle ball completely away from the feed tube) so that the bolt was opening and closing as the balls were falling, you could easily exceed the speed of gravity @ the ~.68" distance because the distance would be just about double. I had no luck getting this to work, although I believe that this method is also possible (but much more dependant of the number of paddles and point of blockage).

I’ve done this also you have to actually time the release of each ball with when the breech is open and create a gap in the feed of balls long enough to cycle the bolt completely such that the ball has an initial velocity on it’s start of entry into the breech. I got it to work with an ACE’d gun and with a special loader, but only in the laboratory and at FA. I never got a practically solution that would work for semi in the field as you actually have to pre-empt a trigger pull or wait a small period from pulling the trigger to getting your shot, and that’s just a bit silly isn’t it

This will sometimes happen accidentally when using a gun with ACE, the hopper plays catch up and the gun has almost shot the feed tube empty, the catching up ball drops in so quickly you can get two shots together very fast. Trouble is if there are other balls following it they stop on the bolt and have to start accelerating from rest again.

If you could time the balls to be dropping to when the bolt is ready and just about to fire with a gap between them sufficient to cycle the bolt completely, then you could increase feed rates with a gravity loader. It’s not a reliable system though as far as I have found.

WAS, you are unlucky, it’s a good hypothesis, but unfortunately you probably found the one person that has tried it before and analysed the idea. Your system works excellently as an agitating loader, and slowing the paddles is actually often a very good thing (too many people think making them go faster is better) and I’ve always said it is a good agitating system, but it is not a force feed system and it does not work the way you claim above. You can see this just by watching a clear hopper. For it to even have a chance to work like you suggest it has to keep the feed tube absolutely full all of the time, in order to have a ball at the top to tap, and if you watch it under heavy rof you can see that it doesn’t, just like any agitator.

To be honest if I was you and someone attacked my claims and if they were valid it would be easy for me to step outside, make a video and prove them wrong immediately. But you don’t. Instead you debate, and waffle on about irrelevancies. I don’t get that. The proof is in the pudding, if it’s possible, show us. No more talk, proof please

manike

[manike]

Originally posted by 314159
at first glance at this, i thought that the length of the feed neck was not significant, because the distance from the paddle to the eye was a fixed distance. you trigger the paddle a given amount of time after you see a ball fall, and it wacks the ball above it... right?

one day i was watching a clear revolution loader. after every string the guy fired, and at every slight pause. the revy would have a ball in the beam sensor, but there would often not be a ball on top of it. in order to inshure accurate timing of the paddle to wack the top of the ball, there must be a ball to wack (NOT GAP ABOVE THE EYE).

with the proper distance under the loader, one could get the top ball in the ball stack to stick out just slightly so that the paddle wacked it every time. with a less than optimal distance under the loader, the paddle would throw out the top ball in the stack to be wacked every time. because you do not have any provisions for adjusting the length of the feed neck in the revvy, how do you insure that there is a ball in the top of the stack to be wacked every time? do you have a set of instructions for the pic for this?

Well noticed, you got your post in while I was formulating my above reply :

As I explained above this is a major issue and just one of the reasons why WAS's claims and hypothesis does not work. I'm not convinced that the distance between the eye and the paddle is even close to being correct to try and get the tap to work, but then since the whole theory is mute what does it matter?

manike

[mykroft]

WAS: The difference between the Pre-BE board(1st gen) and the BE board(2nd Gen) is the delay (implemented to counter the sunlight&sensor issue on Gem's). The X-Board, which is spins noticably faster than a 1st or second gen board, you can demonstrate this by running them side by side.

The Xboard is a different design than the earlier boards.

[Koosh]

Wait wait wait....

Doesnt WAS also sell modified impellers that don't even go over the feed tube? Aren't they supposed to help with the feed rate? IF that is true, does it just totally blow the theory out of water (again)?

[Gambit22]

Well, this is going in to the FAT. A most worthy rambling.

[Butterfingers]

the vortex impellers do in fact extend over the feed tube.

[Koosh]

DOH!

hehe... nevermind then...

[WickedAirSportz]

Now WAS does vary the speed of the paddle BUT without knowing exactly where the paddle is in it?s rotation ...

This is where you are wrong, and where most the logic comes into play. You can tell with a certain degree of accuracy where the paddles are located in reference to the feed neck by calculating the space between balls and the reaction to the motor speed. One thing that I have always stated is that for the TurboRev to work properly, you paddles arms MUST be bent down as far as possible (so that they rub the sides of the hopper). This puts the arm directly over the inlet whole, about 1/2 a balls distance from the hole itself. The WAS modified Vortex impellers do just that. If your arms are not bent down, this whole process will not work _at all_.


As far as the x-board vs standard board goes. There is no difference in the hardware, it is the exact same board. The ONLY difference is in the code. Go dump the PICs yourself. The only difference between the code is the delays were shortened with the x-board and they added a reset for the low battery indicator so that it is checked and reset periodically (instead of always flashing when the battery is low).

[manike]

Originally posted by WickedAirSportz
This is where you are wrong, and where most the logic comes into play. You can tell with a certain degree of accuracy where the paddles are located in reference to the feed neck by calculating the space between balls and the reaction to the motor speed.

Codswallop. You can only tell that a paddle is within 60 degrees of the feed neck due to the fact there are 6 paddles within 360 degrees... There is no way you can relate the speed of the balls passing the sensor with where the paddles are in their rotation.

As I pointed out, even if you knew where the paddles were, and had the balls lined up, and the eye at the right point it still won't work.

Where is the evidence?

PUT UP OR SHUT UP.

manike