Duty cycle - Another Math dilemma

[Ramius]

Hi All!
Okay so I have a time period of 9.9210 ms and as part of this time period a pulse width of 4.9474 ms. If you divide 4.9475 by 9.9210 you get a duty cycle of 50.1310 which is actually a percent. Using the time period and the pulse width how do you get to 50.1310 since it is actually .501310?

Thanks, Ed

[HenrikOlsson]

Hi,
It depends on how much resolution you need and can fit within your variables.
If you multiply the dividend by 1000 before actually performing the division the equation (on paper) becomes 4947.5/9.9210=498.7 then you take 1000-498.7=501.3 which is now in units of 1/10 of a percent. In PBP you aren't going to use numbers like 9.9210 so in reallity you'd need to round that off to 10 and the *1000 will be truncated to 4947. 1000-(4947/10)=506 so it's a bit off.

Another way could be to use the ** operator, 4947**6606=498, 1000-498=502, or 50.2%, a bit better.

Yet another way would be to use DIV32, it all depends on the range of the numbers, your variable size, what resolution you need etc.

/Henrik.

[Ramius]

Hi Henrik!
Thank you and I have never seen the use of the number 6606! Basically the formula I am trying to use is (Pulse Width / Time Period - Duty Cycle) /8. The tilt sensor is very sensitive to temperature changes so I am trying to be as accurate as possible. Maybe I should be attempting the calculations with Longs?

[HenrikOlsson]

Hi Ed,
Instead of dividing by 9.9210 you can multiply by 0.100796 (1 / 9.9210). The number 6606 comes from 65536*0.100796=6606.

When you do something like 4947**6605 what happens is that PBP does 4947*6505 which internally results in a 32bit value, it then takes the middle 16bits of that 32bit result and return those 16bits to you. In effect that is the same thing as dividing the 32 bit result by 65536. If we do that with pen and paper we get, 4947*6605/65536=498 which is exactly what PBP will give you.

I guess you're not actually getting the period and pulsewidth i units of milliseconds? How do you measure it and what are the actual values you get. It best to work with the raw numbers for the calculations, internally any number can mean 50% or 8ms or whatever. It's only when the result must be presented to a human that you need to convert it into "real" units like ms or percent or whatever.

/Henrik.

[Acetronics2]

Hi, Ed

may be , as you use PBP, you could remember about the maximum " pulsin " resolution that won't exceed 1µs @ 40 Mhz ...

so your numbers will be @ best 4947 and 9921 ...

from that, DIV32 or use of LONGS looks to be the decent way to get enough significant decimals ...

Alain

[Ramius]

Thanks Guys!
For some reason my 13F1320 seems to have a problem so I can not see what the math is doing yet with an ICD compile. The MAX232 works fine until I connect it to pin 9, the TX and then it stops talking! As for measuring I am using one of the greatest devices ever produced, The Saleae Logic Analyzer! I can see all the Memsic 2125 values change with temperature so I do not have 1 or more "fixed" values to use. The "duty cycle" value seems affect the accuracy more than the pulse widths. The duty cycle value varies from 498 to 504 which then gets worse when using the look up tables! Just a couple of degrees of room temperature change seems to make a big difference.