Wicked Air Sportz: Turbo Rev

[Miscue]

From http://www.wickedairsportz.com

According to Warped Air Sportz -
"So how does it work?

The TurboRev circuit board uses the <B>latest state-of-the-art microprocessor with artificial intelligence software.</B> Unlike the standard Viewloader circuitry, there is no startup delay on the first missing ball. The TurboRev board immediately activates the hopper's motor and starts feeding! As the balls fall, <B>the TurboRev's computer monitors the feed rate and adjusts the agitator motor's speed, torque, and spin duration to increase the feed rate to the maximum possible</B> given the design of the Revolution hopper!"

<IMG SRC="../~Miscue/turborev.jpg">

Now, I'm looking at this picture of the TurboRev Board. I see some capacitors, a diode, a switch, some other stuff, and a PIC 12C508A microcontroller. I'm still looking for the "latest state-of-the-art microprocessor with artificial intelligence software," that's supposed to be on there.

<B>What is the PIC 12C508A Microcontroller?</B>
It is a $4 8-pin, 8 bit CMOS microcontroller.

<A HREF="http://www.microchip.com/download/lit/pline/picmicro/families/12c5xx/40139e.pdf">Full PIC 12C508A Chip Spec.</A>

The 12C508A has 33 single word instructions, 512 words of program memory and 25 bytes of data RAM. Out of these 33 instructions, the ability to multiply or divide numbers is not present. If you want the chip to calculate 3x3=9, you can't without using repeated addition. Say you decided to use repeated addition (or subtraction if you wanted to divide), you would need some kind of repetition instruction - like 'loop.' Guess what? It's not built in, you have to make it using branching instructions.

Ok, so let's say you do this - you get to use their bit test instruction that either goes to the <B>next</B> instruction or <B>skips</B> it. Typically, the <B>next</B> instruction would be the unconditional GOTO instruction, you would want to <B>skip</B> this if you didn't want it to branch to some other part of the program. PITA PITA PITA!! Mind you, you are doing this with a severely limited number of registers - having to pass stuff around in memory is inevitable. It's kind of like having 30 people at a dinner table for 6 with 1 fork to share among them.

So basically... in order to multiply two arbitrary numbers together, I roughly estimate it to be maybe a conservative 30+ instruction process - based from my experience with other instruction sets. Lets say you wanted to simply multiply a list of numbers together - maybe 50+ instructions.

Remember, this chip only has room for 512 instructions. With this in mind - it makes you wonder where they put the <B>"artificial intelligence software."</B>

<B>"...the TurboRev's computer monitors the feed rate and adjusts the agitator motor's speed, torque, and spin duration to increase the feed rate to the maximum possible..."</B>

Now, these buzz words: speed, torque, spin duration, maximum possible - make me think of rotational kinematics, calculus, and statistical analysis. This also makes me think about what kind of numbers we're dealing with here - numbers with stuff following the decimal place. Guess what? The 12C508A does not deal with floating point numbers, only integers (whole numbers). Ok, let's say you were to give it the ability to process floating point numbers by using a scheme to represent them with integers.

Well, I actually wrote a program like this on the x86. It was a big pain. Nobody should ever have to do this unless they are being punished for lechery or given an exorbitant amount of money. Here's what such a program looks like:

<A HREF="../~Miscue/ieee.txt">IEEE addition</A>
(This isn't one of mine, I can't find it)

You think this is big for just adding two numbers? This was done with the powerful Intel x86 instruction set. It would be ridiculously HUGE... did I mention <B>HUGE?</B> using the 12C508A's instruction set.

Let's assume their hardware could actually do what they claim. They would need to have collected data to program formulas based from the data into the chip for max output. I don't see them showing any normal distribution curves, probability density function graphs, Poisson distributions... or anything. All they have is a <B>SINGLE</B> trial in which they mention average feed rates. Seems to me that they produced numbers <B>AFTER</B> the board was made, and did <B>NOTHING</B> before it was made.

Now, these are RANDOM, not CONSTANT averages. You can't make any conclusions until you've made a large number of trials and your RANDOM averages have stabilized.

And, averages can be very misleading - other data is necessary to get a picture of what's going on. For instance: Say we have Village A with average income of $7,000/year... Village B with $10,000/year. With this information, can you say that Village B is better off than Village A? What if ONE guy in Village B is making all the money while everyone else is making next to nothing? See the problem? You need an idea of what the individual case looks like.

In terms of feeding balls, the individual case... average time between individual balls (among other things) is much more interesting and revealing than the average feed rates they calculated.

Basically, how they have gone about it is NOT how you conduct a proper statistical analysis.

The chip was "state-of-the-art" some time last century, claiming it has "artificial intelligence software" is a farce, it cannot process anything as complicated as was suggested, and unless they are keeping it a secret - they lack a proper statistical analysis to even begin to calculate these things even if the hardware had the ability to do so. I think what's going on is that WAS is recklessly throwing around and misusing technical terminology.

I think that they can claim this: The TurboRev starts and stops at particular times for particular durations that helps to feed balls better. Does it work a little better than the standard revy? I wouldn't be surprised and do not doubt it. Does it work the way they say it does? <B>No.</B>

Here's another question: Since when does a revy need alien technology to put a round ball into a tube?

Rocket Scientists? Bah. How about BS Artists.

-Brian Workman (Miscue)

[hitech]

I'm glad to see that you still had that (or found it). That was one of the best written posts I have ever read. Very well done.

[Miscue]

I didn't have it. I spent over an hour rewriting it. But I think I did a better job this time.

[angelKiller16]

wow, you are very good at these things. I was wondering why a loader had to be so smart to put a ball in a tube in the first place but you said it. You would be extremely usfull in my Computer VB II class I am taking.

[Miscue]

Humm, I just looked at the Equalizer board.

"The Equalizer uses the latest state-of-the-art microprocessor with artificial intelligence software to automatically adapt to the feed rate."

Sound familiar?

[Oregon_pb_]

the turbo rev was the one of the worst loaders invented, ever. It does beat a VL 200, thats about it. The battery consumtion on it is way more than the Revolution, and it doesn't feed noticably quicker.

[cledford]

Miscue,

Right about the time you called him on the AI in the turbo Rev - he realized that the AI for dwell wasn't needed after all in the the Equalizer and "took it out."

It was in the deleted thread.

-Calvin

[314159]

as far as multiplication, and division, even though there are not instructions built into the pic to implement them, you can still use bit banging to implement them (adding the features in software)

multiplication isn't too bad
;Clear all files
Multi MOVLW 0D ;0D = thirteen
MOVWF 0D ;0D = 1st count file
X0 DECFSZ 0D ;DECrement the count file
GOTO X1
RETLW 00 ;The multiplication is done
X1 MOVLW 22h ;22h = 34
MOVWF 0E,1 ;Put 22h into file 0E
X2 DECFSZ 0E ;DEC 2nd count file
GOTO X3
GOTO X0
X3 INCF 16h ;INC units file
MOVLW 0A ;Put ten in W
XORWF 16h,0 ;Is file 16h = ten?
BTFSS 03,2 ;Test the Zero flag
GOTO X2 ;No. Go to X2
CLRF 16h ;Yes. Clear file 16h
INCF 17h ;INC ten's file
MOVLW 0A ;Put ten in W
XORWF 17h ;Is file 17h = ten?
BTFSS 03,2 ;Test the Zero flag
GOTO X2 ;No. Go to X2
CLRF 17h ;Yes.
INCF 18h ;INC hundreds file
MOVLW 0A ;Put ten in W
XORWF 18h,0 ;Is file 16h = ten?
BTFSS 03,2 ;Test the Zero flag
GOTO X2 ;No. Go to X2
CLRF 18h ;Yes. Clear file 16h
INCF 19h ;INC thousands file
GOTO X2 ;Go to X2

"multiplication can be handled as sucessive additions, and division can be handled as sucessive subtractions"

http://talking-electronics.tripod.com/PIC-Theory/1-Pop-PIC-Theory-Page11.html

i don't see where you would have to multiply to do anything that the turborev advertises. next, my thoughts into how this thing works. first let me make some declerations.

1)the loader will have a max capacity of about 180 rounds.
2)you can get a pretty good idea of the amount of paint in the hopper by decrementing a running total from 180.
3)you can reliably tell when the amount of paint in the hopper is getting low, and can roughly tell how low by measuing the increasing duration of time of the lack of a ball in front of the eye.
4)when ever the hopper goes from low, to full, it has been reloaded, and reset the running total to 180.

all you would have to do now is to have a lookup table with values of how fast to spin the paddle when a given amount of balls remain, do the math before hand to calculate the most advantageous speed to spin the padle at. these values can be easily accessed by doing a computed jump (loading the address of the table into the working regester, and adding the position of the table you want to jump to, and moving the result to the program counter.

i am not saying that this is how they made the turborev board, but their claims are very possible.... (i have never used or seen one of their loaders, so they may indeed suck, not worked as claimed...)

[Miscue]

Well, thanks for copy/pasting that... it's nice to see that my estimate of approx 30 instructions was pretty darn close.

My comments on their lack of publicized research and a statistical analysis besides their hokey bps table was in anticipation of the mentioning of a look-up table which would be based upon results stemming from such an analysis... which I believe I mentioned in some form in the deleted thread on PBN but decided to omit this time because it would provide unnecessary precision in making my point clear.

<B>"maximum possible"</B>

"Maximum possible" is a pretty strong term. This tells me that nothing can surpass it. Using a look-up table, they are limited to discrete values stored in a small, limited number of memory spaces, missing intermediate values. I would argue that a board capable of real-time calculation, limited only by the precision allowed by memory could at least match and possibly exceed their board's max output. But like I said, I don't see why a revy needs 'alien-technology' in the first place.

<B>"artificial intelligence software"</B>

I've made it clear that the chip cannot make calculations on its own. In the case of a look-up table, the chip makes trivial decisions in a mechanical manner. If this is AI, then I claim my microwave oven to also have AI software. It has different settings for different foods, providing a predetermined amount of cooking power for each situation.

For "rocket scientists," they seem to be pretty loose with their terminology, and make a lot of claims w/o supporting evidence/data. This is the point I was after.

Here's another thought: How fast it can feed, and how fast a ball gets into the gun are two different things. How does this revy handle bursts... playing catch-up? What's the average bps of a 3-5 round burst on the gun with a ball stack? What effect does a ball stack have on long bursts? From all indications, it was "designed" to win continuous feed... dump your hopper into a guppie contests. Why don't they talk about these things?

[314159]

Originally posted by Miscue
In the case of a look-up table, the chip makes trivial decisions in a mechanical manner. If this is AI, then I claim my microwave oven to also have AI software.

everything a computer does can be rewritten as a yes or no question. i read this article once, it focused on if ai was inteligent, or just good programming.

(note: i haven't tried the turbo rev)

[314159]

2)if you don't start with a full hopper, or if you don't reload with a full hopper no harm done. you could also alter the objective of the program from a couple posts up, program it to keep an eye out for the eye to start getting longer than average delays. if the delay is longer than average, then the paddle is spinning to fast and flicking the balls around so that they will not settle in the feed neck. and slow down the speed of the paddle. this would be more tollerant to errors than the first idea of keeping a running count.

3)you don't have to store the lookup table in the ram, you can store that in program memory, you have to take up 1 ram location for the value that is fetched from the table. and i ram location to keep the running total. 23 bytes left.

4)then the motor encounters resistance and you shorten the life of the motor in the revvy .

to get rid of the random feed rate kick in the pants, you could do the check on 5 sequential times that the eye is not reading a ball. if they are over the programmed threshold, preform XXXX action.

it is possible to tell when the hopper is reloaded from a low hopper, the feed time would decrease. (have you ever noticed the noise your revvy makes when it gets low, the motor spins longer than average. this can be measured by the microcontroller, as the time the eye dosen't see a ball. when it is over a certan threshold, it could set the hopper verry low flag or something) when more paintballs were dumped in, the revvy would stop making the noise it does when it gets low (measurable on the eye). (this might better yet, lead to a low hopper led).

additional assumption, if more than x # of rounds are fired without the hopper getting low, it can be assumed that the hopper was topped off, and the counter can be reset to something like 100 or 120. (better yet, put a sensor on the hopper door)


i think that it is possible with good programming to do what they say. (note: i do not know if they use good programming, their product may indeed suck, or not suck), (personal opinion: spend a couple more bucks and get a halo b if u need the feed rate)

[Miscue]

Originally posted by 314159

1)the loader will have a max capacity of about 180 rounds.
2)you can get a pretty good idea of the amount of paint in the hopper by decrementing a running total from 180.
3)you can reliably tell when the amount of paint in the hopper is getting low, and can roughly tell how low by measuing the increasing duration of time of the lack of a ball in front of the eye.
4)when ever the hopper goes from low, to full, it has been reloaded, and reset the running total to 180.

What happens when you reload. What happens if you don't start with a full hopper? Assumptions...
You got words 0-255 to store both your main program and all your table information. The remaining 256 words are for sub-routines. You want a look up table, you wanna keep track of stuff, and have this really cool program that can do it all? Where's all this stuff going to go?

What about when the hopper is full and the balls don't have much room to be agitated? What happens when it randomly feeds quickly/slowly? Does it know when you reload?

I can guarantee you that the TurboRev does not and/or cannot do these things... let alone is there a need for this in the first place.

[314159]

Originally posted by Miscue
You got words 0-255 to store both your main program and all your table information. The remaining 256 words are for sub-routines. You want a look up table, you wanna keep track of stuff,

the reason that this is said, is that the instructions can move 8 bits at a time. just dealing with the 8 least significant digits of the program counter limits you to within the first 256 memory locations. if you add a couple lines of code, you can get around this limitation by writing to the high bites of the program counter

Originally posted by Miscue
What about when the hopper is full and the balls don't have much room to be agitated? What happens when it randomly feeds quickly/slowly? Does it know when you reload?

I can guarantee you that the TurboRev does not and/or cannot do these things... let alone is there a need for this in the first place.

it all has to do with how creative your programming is, i have an electronic board running on a pic, about 250 words of memory (not exactly a byte, a little longer) and a couple bytes of ram. this is with 5 16 bit timing variables, and other bells and whistles. assembly language can be extremly efficent.

[Miscue]

Originally posted by 314159
2)...if the delay is longer than average, then...

Then you can subtract 30 from 512... just to be able to divide... let alone produce an average. Delay? So now it must also keep track of time... something extra = more code.

4)then the motor encounters resistance and you shorten the life of the motor in the revvy .

Subtract available instructions from your subroutine section to fit the routine that evaluates motor resistance. Subtract available instructions from the main section to run an ongoing loop that continually calls the motor resistance subroutine.

to get rid of the random feed rate kick in the pants, you could do the check on 5 sequential times that the eye is not reading a ball. if they are over the programmed threshold, preform XXXX action.

This thing runs at 4Mhz right? Add additional code to check the ball every x clock cycles, every x ticks off the RTC, or whatever scheme you have in mind. Bottom line = more code.

it is possible to tell when the hopper is reloaded from a low hopper, the feed time would decrease. (have you ever noticed the noise your revvy makes when it gets low, the motor spins longer than average. this can be measured by the microcontroller, as the time the eye dosen't see a ball. when it is over a certan threshold, it could set the hopper verry low flag or something) when more paintballs were dumped in, the revvy would stop making the noise it does when it gets low (measurable on the eye). (this might better yet, lead to a low hopper led).

Averages, thresholds, etc... lots of code.

additional assumption, if more than x # of rounds are fired without the hopper getting low, it can be assumed that the hopper was topped off, and the counter can be reset to something like 100 or 120. (better yet, put a sensor on the hopper door)

Um... ok. Add what, 150 lines of code to do this?

i think that it is possible with good programming to do what they say.

Agreed! But not with that chip. What you would need is a magician... not a programmer.

[314159]

at 4mhz the pic can operate 1 million instruction cycles per second, all instructions take 1 instruction cycle extept thoes that write to the program counter.


"4)then the motor encounters resistance and you shorten the life of the motor in the revvy ." is not electrical resistance, it is resistance on the paddle from going around hitting the balls.

implementing a rtc on a pic is not that bad. you just configure a timer to overflow every 100th of a second. when that timer overflows, it triggers an interupt. you stick all your code in the interupt handiler (< than about 10,000 processor cycles) and then go into a endless loop, something like "loop goto loop" and then the main code is stepped through every 100th of a second.

the way i am thinking of you would not need to multiply and divide in the program, just testing if variables fall into certain catagoies, and act accordingly. a stupid program, but a lot less intensive than calcuating on the fly.