Duty cycle - Another Math dilemma

[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.

[Ramius]

Okay so I found another 18F1320 and it does not communicate either!
Did I miss something in the code?
It may be time for new glasses!

XTILT.txt

[HenrikOlsson]

Hi Ed,
Is that all the code? I don't see a Goto Read_Force anywhere so it would run once and then weird things might occur, like stop communicating with the software ICD perhaps.

/Henrik.

[Ramius]

Okay so I have to be doing something fundamentally stupid! Just not sure what? Any ideas?


DEFINE OSC 20 'Define crystal frequency

Include "Modedefs.bas"
include "hpwm10L.pbp"
Enable Debug

#CONFIG
__CONFIG _CONFIG1H, _HS_OSC_1H & _FSCM_OFF_1H
__CONFIG _CONFIG2H, _WDT_OFF_2H & _WDTPS_8K_2H
__CONFIG _CONFIG2L, _PWRT_ON_2L & _BOR_OFF_2L & _BORV_27_2L
__CONFIG _CONFIG3H, _MCLRE_OFF_3H
__CONFIG _CONFIG4L, _DEBUG_OFF_4L & _LVP_ON_4L & _STVR_ON_4L
__CONFIG _CONFIG5L, _CP0_OFF_5L & _CP1_OFF_5L
__CONFIG _CONFIG5H, _CPB_OFF_5H & _CPD_OFF_5H
__CONFIG _CONFIG6L, _WRT0_OFF_6L & _WRT1_OFF_6L
__CONFIG _CONFIG6H, _WRTC_OFF_6H & _WRTB_OFF_6H & _WRTD_OFF_6H
__CONFIG _CONFIG7L, _EBTR0_OFF_7L & _EBTR1_OFF_7L
__CONFIG _CONFIG7H, _EBTRB_OFF_7H
#ENDCONFIG


'********************* Declaired Pins **************************

INPUT PortB.2 ' X Data is clocked on rising edge of this pin


' ** Variables **

PxRaw VAR Long ' Low part of Pulse from Memsic 2125
WxRaw var Long ' High part of Pluse from Memsic 2125
WxTRaw var long ' Total of High and low Pluse from Memsic 2125
Dcycle var Long ' Duty cycle
xGForce VAR Word ' x axis g force (1000ths)
xTilt VAR Word ' x axis tilt (100ths)
xidx VAR byte ' Table index
xmult VAR Word ' Multiplier - whole part
xfrac VAR Word ' Multiplier - fractional part
xPosNeg var byte ' ositive angle or Negative angle flag

ADCON1 = 255 ' Make everything digital (no analog)

TRISB.2 = 1 ' Make B.2 an input

Read_Force:

PULSIN PORTB.2, 1, WxRaw
PULSIN PORTB.2, 0, PxRaw

WxRaw = WxRaw * 20 ' The high part of the pulse
PxRaw = PxRaw * 20 ' The low part of the pluse

WxTRaw = wxraw + pxraw ' The total time of the pluses

Dcycle = (Pxraw * 10000) / WxTRaw

xGForce = (((WxRaw * 10000)/ WxTRaw) - Dcycle) * 8 'xGForce = ((t1 / t2) - duty) / 12.5%


Read_Tiltx: 'tilt = g x k Select tilt conversion factor based on static G force. Table data derived from Memsic specs.

LOOKDOWN2 ABS xGForce, <=[174, 344, 508, 661, 2000], xidx ' Table is in thousandths g results for 10,20,30,40 and max value degrees
LOOKUP xidx, [57, 58, 59, 60, 62], xmult 'integer lookup
LOOKUP2 xidx, [32768, 10486, 2621, 30802, 22938], xfrac 'gets fractional result
xTilt = xmult * (ABS xGForce / 10) + (xfrac ** (ABS xGForce / 10))

Check_SignX: 'Check the sign of X angle
IF (xGForce.Bit15 = 0) THEN XT_Exit ' if positive, skip correct for g force sign
xPosNeg = 0 ' If xPosNeg = 0 then the angle is negative (-)

XT_Exit:
xPosneg = 1 ' If xPosNeg = 1 then the angle is positive (+)


gosub Read_Force

[HenrikOlsson]

Okay so I have to be doing something fundamentally stupid! Just not sure what? Any ideas?

Yes, you're using GOSUB instead of GOTO.
GOSUB is used to jump to a subroutine which "ends" with a RETURN - that's not what you have.

/Henrik.