Why my algebra fails - Numbers too large?

DiablodeMorte

Ok, Here's the situation: I have a XBC robot controller for a BotBall(Botball.org) competition that is on loan to me. I want to use its ability to act as a CMU-Cam because I don't currently have a CMU-Cam and I don't want to buy one just yet. As luck would have it, to keep teams from wirelessly communicating with their bots(and thus braking the rules) the people over at botball have included absolutely no way to communicate with the XBC serially(Ie, it can receive data through it's many ports, but aside from servos and motors, it can't push data out). Since I have some experience braking down servo PWM and using that, I thought to my self: Why not output the data as though it was a servo? Well, I did. The XBC however outputs to the servo from a range of 0 to 255. These numbers meant nothing to me so I hooked up a XBC -> BS2p40 connection and ran the data I got out through excel. See attachment for a chart. I then ran a best fit line, found x in terms of y(ie, XBC pwm vs BS2p units(us)) and ran the equation back through the BS2p40 thinking that it would spit out numbers between 0 and 255. After multiplying by a negative thinking that maybe stamps don't like negatives, I can get the BS2p to interpret up to 13, and then it restarts at 0. What am I doing wrong?

Here's the equation for the best fit line:
y = -47.77x + 15122
so, x = (y-15122)/-47.77

Here's my BS2p40 Code:

time = 100*(15122 - time)/4777
    DEBUG CR,
          DEC3 time             ' display microseconds

Is the number 15122 simply to large? or am I doing something else wrong?

Regards,

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Current Projects:
Robot Control Via Skype API - Dev Stage(50% Complete) - Total(25%)
Robot Localization Via Xbee's - Research Stage
IR Tracking with Propeller - Research Stage

Mike Green

All calculations are done with 16-bit words and that's limited to 0 to 65535 using unsigned arithmetic or -32768 to 32767 using signed arithmetic. It's possible to do multiple precision arithmetic (see www.emesystems.com) with some work or you can attach a 3rd party Math Coprocessor that can do floating point and 32 bit integer arithmetic (Parallax does carry this ... search their webstore under components).

DiablodeMorte

@Mike Green

But isn't 15122 still smaller than 65535? Maybe I don't fully understand. 15122 is the largest number my stamp should encounter

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Current Projects:
Robot Control Via Skype API - Dev Stage(50% Complete) - Total(25%)
Robot Localization Via Xbee's - Research Stage
IR Tracking with Propeller - Research Stage

Mike Green

Yes, 15122 is smaller than 65535, but other terms in that calculation are greater than 65535.
Work it out on paper.

Tracy Allen

Diablo,

It is generally possible to do this kind of problem on the Stamp by using the */ or the ** operators. That will avoid the intermediate values that exceed 65536. In this case, you have the formula

time = 100*(15122 - time)/4777

For PBASIC, rewrite it as:

time = (15122 - time) ** 1372   ' for time<=15122 going in.
DEBUG CR,DEC3 x             ' display microseconds

For example, when time=4000 going in, it will give time=232 going out. Why **1372? Internally the Stamp multiplies the term in parens (15122 - time) by 1372, into a 32 bit accumulator, and then returns the the high 16 bits as the answer. That is the same as dividing by 65536. So you get 1372/65536, which is the same fraction as 100/4777. Find the multiplier on a calculator or Excel as: (100 / 4777) * 65536 = 1372

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com