Duty cycle - Another Math dilemma

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

[Ramius]

Thanks, easy to fix. I still can not get the math to come out right!

[HenrikOlsson]

Hi Ed,

(I'm answering your PM here since it related to this thread.)

Lets see if we can get the numbers straight on paper as a first step, then we'll move on to PBP.

According to the datasheet for the MXD2125 accelerometer (is that the one you're using). The formula is g=(T1/T2-0.5)/12.5%

The dutycycle of the output signal is 50% at 0g, that's where the subtraction of 0.5 comes from.
12.5% is the sensitivity of the device, it varies the dutycycle of the output signal 12.5% per g.

At +1g the dutycycle is 50+12.5=62.5%, the numbers becomes (0.625-0.5)/12.5% = 1g
At -1g the dutycycle is 50-12.5=37.5%, the numbers becomes (0.375-0.5)/12.5% = -1g

12.5% is the same as dividing by 12.5/100 which is the same as dividing by 0.125 which is the same as multiplying by 8.

According to the datasheet the acceleration at 30° is 0.5g which corresponds to a dutycycle 56.25% (50% is zero g, the output swings 12.5% per g so 50+6.25), lets run those numbers on paper:
(0.5625-0.5) * 8 = 0.5g

It all seems to work out on paper - wohoo!

What to do in PBP (before continuing I must point out that I haven't actaully tested this, hopefully I haven't messed it up too badly....):
I see from your posts that you're now using LONGS which makes it a bit easier. Let's try with your 0° numbers first.
Obviously we cant just do 4927/9867 (the numbers you gave for 0°) because that will result in a number less than 0 which is not of any use to us. What we can do though is to multiply the T1 time by say 10000.

T1 VAR WORD
T2 VAR WORD
Duty VAR LONG
g VAR LONG

' Number for 0°
T1 = 4927
T2 = 9867

Duty = (T1 * 10000) / T2   ' Duty will now be 4993
g = (Duty - 5000) * 8    ' g will now be -56 which is equal to -0.0056

HSEROUT["Acceleration is: ", SDEC g/10, "mg",13]

Now, in your PM you said that at 30° your values are 4535/9578 but that only works out to a dutycycle change of about 2.65% when you really should be getting around 6.25%. However you also say that the result of 4535/9578 is 0.4491 which isn't the case so something seems to be wrong with your numbers there.

But lets for the cause of the exercise use some the theoretical numbers corresponding to 30°, 0.5g, 56.25% dutycycle

T1 = 5625
T2 = 10000

Duty = (T1 * 10000) / T2   'Duty will now be 5625 (56.25%)
g = (Duty - 5000) * 8   ' G will now be 5000 which is equal to 0.5G

HSEROUT["Acceleration is: ", SDEC g/10, "mg",13]  ' should print 500mg

That's the acceleration part, when that works I suspect you want to convert the acceleration value into an actual angle....

/Henrik.

[Ramius]

Hi Henrik!
Thank you and I finally got that the duty cycle is a "fixed" number assumed to be at 50%. According to the information about the device, each device can have a zero duty cycle of from 48.7% to 51.3%. My experience has been that at a room temperature of about 72 degrees F, my device has a measured duty cycle of 49.93%. However as the room temperature increase or decrease so does the zero point duty cycle! So if the submarine is sitting on a table at the park with an air temperature of 72 degrees F then 4993 works. Put the sub in water where the water temperature is 65 degrees F and 4993 is no longer valid. Originally the thinking was to measure and calculate the duty cycle however this method does not work as you first must be at an known zero degrees of tilt.

Best Wishes, Ed

[HenrikOlsson]

Hi Ed,
Is the dutycycle at various temperatures repeatable? I mean, you say that 0° at 72F is 4993 and 0° at 65F it's xxxx, are those numbers repeatable from time to time or is 4993 one time and 5006 another?
If they are repeatable then all you need is a temperature sensor (which I suspect you have anyway) and a bit of more math....

Mount the tempsensor in very close proximity to the accelerometer, set the accelerometer exactly level and leave it there. Then, using a hairdryer or whatever measure and plot the dutycycle vs temperature over the range you expect to use it and see what comes out. If you're lucky you'll get a linear realationship between temp and dutycycle which is very easy to compensate for in software. If it's not a linear relationship that too can be compensated for - not as easily though.

If you're very amibitious repeat the test at 30° tilt and see if the relationship is the same.

/Henrik.

[Ramius]

Hi Henrik!
Just an update, it turned out I had a bad sensor! Got a new one and it seems to work fine!