H48C not giving proportional, usable output (propeller)

bulkhead · 2007-10-20 09:34

I have verified that the H48C works perfectly on a BS2 with the demo program.

I'm using an H48C hooked up to pins 0-2 on a PEK board. The CS and CLK (output only on propeller) lines have 470 ohm resistors, the DIO line (input/output) has about 1.8 k ohms resistance in between the 5V and 3.3V signals. Vdd is connected to +5V. I am using the H48C object in the Object Exchange. My test program uses the prop terminal to print out (dec(...)) the x value. Here is the test program:

VAR    
CON
    _xinfreq = 5_000_000                     ' 5 MHz external crystal 
    _clkmode = xtal1 + pll16x                ' 5 MHz crystal multiplied &#8594; 80 MHz
OBJ
    acc: "H48C Tri-Axis Accelerometer"
    term   :       "PC_Interface" 
PUB main
    term.start(31,30)
    term.str(string("starting up"))
       
    acc.start(0,1,2)  'start(CS_,DIO_,CLK_):okay    
   
    repeat
      waitcnt(cnt+clkfreq/5)
      
      term.dec((acc.x))
      term.out($0D)  'next line

This set up works partially. I can get the numbers (acc.x, acc.y, acc.z, where acc is the 'H48C' object) to change when I tilt the H48C in different directions. However, here is where I am observing problems:

Observed values of acc.x :
Sitting flat: 1040
Tilt left: between -3 and-130, not consistent (jumps around)
Tilt right: 1024 to 1280, [noparse][[/noparse]gap of ~128 where no values seen], 1410 to max at 1530 (90 degrees)

Going from a couple degrees tilted right to a couple degrees tilted left brings a shift from values of roughly 1024 to -3...

Also, there is a strange gap of ~128 when tilted right.

From the H48C documentation, the ("H48C.x" - vref) /455 = g force. Vref observed on propeller is 2048, which is the same as I saw on the BS2. Tilting the H48C 90 degrees toward the right brings a change of roughly 500 counts, which ~ = 1 g force, which is correct. However, I don't know what is going on with the other side (tilting it left). There's still that gap of 128 to explain.

So why does the H48C return perfectly linear data on all axes/directions my BS2 but not on the propeller? My guess is that this is a software issue since my observations indicate numbers such as 128, 1024, etc. It could be related to representation of numbers, since in this case, the resolution is 12 bits, and longs are 16 bits. I really don't know. I've spent a while searching for posts on the H48C object, but have not found one. Has anyone gotten this object working? Is there anything I should try? Thanks.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I'm new to the propeller!

bulkhead · 2007-10-23 05:00

bump... I'm still having this problem. It works on my BS2, but not on my propeller (PEK). I looked at the H48C object code and I realized that the x, y, and z voltage is already divided by 'vref'. However, it still does not explain why the output skips certain numbers and doesnt go to +/- 1 g. Right now it is about + 1 g and -.4 g when turned 180 degrees.

I am guessing that it is a software issue. It works on the BS2, and it half works on the propeller. If it were a wiring problem, it wouldn't work at all. Has anyone used this object successfully before?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I'm new to the propeller!

bibbinator · 2008-03-21 15:08

Hi,

Did you ever figure out what was wrong?

When I run the H48C demo program on my Propeller Demo Board it doesn't seem to work correctly. The rotation is limited and the g-force doesn't seem to really change in a coherent manner.

Professionally I work for a game developer and am familiar with accelerometers found in the Wii so I understand what is supposed to happen, I just can't seem to get sensible values out of the driver/demo program.

Hints? Tips?

Thanks,

Brett

Beau Schwabe · 2008-03-21 16:46

bulkhead,
·
I apologize ... your post seems to have slipped under the radar.
·
·
can you and bibbinator·post the code that you are currently using?· I realize it's been awhile bulkhead, but I didn't see this post until today.
·

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

bibbinator · 2008-03-21 17:02

Beau,
Thanks for your post! I simply compiled and ran the "H48C Tri-Axis Accelerometer.spin" program installed with the Propeller Tool 1.06 and it doesn't seem to really work.

The cube on screen rotates only a little each way and it's movement is in all 3 dimensions even though you move it around a single axis. Just doesn't "feel" right at all.

I then created a new bit of code to see the values:

H48C.start(H48C_PIN_CS, H48C_PIN_DIO, H48C_PIN_CLK)
repeat
text.out(TV_TEXT_OUT_CLEAR_SCREEN)
' display title
vref := H48C.vref
x := H48C.x
y := H48C.y
z := H48C.z
text.str(num.ToStr(vref, num#DEC))
text.out(TV_TEXT_OUT_RETURN)
text.str(num.ToStr(x, num#DEC))
text.out(TV_TEXT_OUT_RETURN)
text.str(num.ToStr(y, num#DEC))
text.out(TV_TEXT_OUT_RETURN)
text.str(num.ToStr(z, num#DEC))

These raw values move in a way that makes more sense than the demo program, but they still seem to be limited in range. I couldn't get any of the values to be less than about 400 or higher than about 1500, but I haven't yet looked closely at the doc to see what ranges I should expect. Just doesn't seem right given I turned the board upside down and back slowly in a variety of ways.

Have you ever tried running the demo program on a Propeller Demo Board and connected as per the source file to verify it works as intended?

Thanks for your help!
Brett

Beau Schwabe · 2008-03-21 17:26

bibbinator,
·
"Have you ever tried running the demo program on a Propeller Demo Board and connected as per the source file to verify it works as intended?"
·
I did when I wrote the application... I'm not sure that I would have released it if it operated the way that you are describing.· I will have a further look when I get some time.· It could be something incompatible in code with a later release of the Propeller software, though I kind of doubt it.· I will have a look... please be patient.
·
·

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

ratronic · 2008-03-21 17:42

I get about - 440 to + 440 for x from the program from the object exchange.···· Dave

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Fix it, if it ain't broke·

D Rat

Dave Ratcliff· N6YEE

Beau Schwabe · 2008-03-22 07:54

The only thing that I can figure, is that there might be something wrong with the 3D-graphics portion of the DEMO....· Stripping the H48C down to it's bare minimum and displaying the values on a VGA monitor, everything·seems·to be working correctly.

The RAW values returned from the H48C are Vref, X, Y, and Z.· ThetaA, ThetaB, and ThetaC are derived from the RAW values.

······ ThetaA - Angle relation between X and Y
······ ThetaB - Angle relation between X and Z
······ ThetaC - Angle relation between Z and Y

Below I have attached an image that might help reference the H48C orientation sensitivity:

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

Post Edited (Beau Schwabe (Parallax)) : 3/25/2008 5:46:44 PM GMT

Beau Schwabe · 2008-03-22 22:12

Solved

Ok, so I was scratching my head over this... between mowing the lawn, painting Easter eggs, etc..
·
... Anyway.· Would you believe if I told you·that there was nothing wrong with the original code...·It's true!
·
I thought I was doing a favor, and in the original code, the returned values for X, Y, and Z have already had the Vref subtracted from them.· So the Equation:
·

[b]G = ((axis-vRef)/4095) x (3.3/0.3663)[/b]
 
          or
 
[b]G = (axis-vRef)x0.0022[/b]
 
          or
 
[b]G = (axis-vRef)/ 455[/b]

...Should actually look like this for the current object...

[b]G = (axis/4095) x (3.3/0.3663)[/b]
 
          or
 
[b]G = axis x 0.0022[/b]
 
          or
 
[b]G = axis / 455[/b]

So the numbers returned ranging from -440 to 440 should be right at about -1g or 1g

If you want the X,Y, and Z values to be without the Vref subtracted off of them, then just change the Assembly code that reads....

              mov       t3,                     Xselect                         'Get X value
              call      #DataIO
              mov       x_,                     t3
              subs      x_,                     vref_
 
              mov       t3,                     Yselect                         'Get Y value
              call      #DataIO
              mov       y_,                     t3
              subs      y_,                     vref_
 
              mov       t3,                     Zselect                         'Get Z value
              call      #DataIO
              mov       z_,                     t3
              subs      z_,                     vref_

...So that it reads...

              mov       t3,                     Xselect                         'Get X value
              call      #DataIO
              mov       x_,                     t3

 
              mov       t3,                     Yselect                         'Get Y value
              call      #DataIO
              mov       y_,                     t3

 
              mov       t3,                     Zselect                         'Get Z value
              call      #DataIO
              mov       z_,                     t3

Please let me know if you think that there are still any issues with this code.

Updated Object Exchange File

Thanks!·· Have a Great Easter Weekend!

·

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

Post Edited (Beau Schwabe (Parallax)) : 3/23/2008 5:42:00 AM GMT

bibbinator · 2008-03-23 11:24

Not quite solved! But I think I see the main problem is in the chip diagram at the top specifies +5 volts instead of +3.3V and that threw me off (your formula shows 3.3 volts but the hookup doesn't, so I assumed that the module included a voltage regulator which is doesn't seem to do?)

I don't have a scope so I can't check this all, sorry.

A. First off, are you sure your attached picture of the rotation axis is correct? On my board, it seems like the x and y axis are reversed compared to your drawing when just looking at the values change in relation to the board orientation (see below).

B. Using the latest object exchange files, downloaded and ran I get the following with the board just sitting there:

vref = 1210
x = 845
y = 845
z = 1290

Rotating the board around the y axis as depicted in your picture the x value goes down to 380 and then up to 1250 before returning to 840.

Rotating the board around the x axis as depicted in your picture the y value goes down to 350 and then up to 1250 before returning to 840.

C. Didn't make sense, so I read the datasheet and saw the operating voltage is based on 3.3v so I tried using the lower VDD voltage instead of +5V as specified in the driver file and it worked much better.

vref = 1100
x = 900
y = 900
z = 1400

Rotating the board around the y axis as depicted in your picture the x value goes down to 480 and then up to 1400 before returning to 900.

Rotating the board around the x axis as depicted in your picture the y value goes down to 450 and then up to 1350 before returning to 900.

Now it at least returns about a +/- 400 amount, and the z axis registers a 1 g force amount, but it seems that it needs the vref subtracted subtracted yet again to get a normalized value (+/- 400). This is puzzling and leaves me wondering if there's something wrong in the driver. I'll try to look through the code later (wish I had a debugger, hehe).

So, to summarize:

1. Is the picture wrong? Or the hookup diagram?

2. Is the voltage +5v wrong? Should it be +3.3v?

3. Shouldn't a driver, since it is already processing values, return values between +/- 400 (or some other sensible base like +/- 1000) instead of non-sensical offset values? (or it could just be a bug with the driver, but the intent isn't stated in the driver!) Ideally it should be documented in the header what kind of range of values is expected.

Cheers,
Brett

Beau Schwabe · 2008-03-23 14:03

bibbinator,

1) I think this is a matter of perspective and how you orient yourself to the sensor.· I repositioned the X,Y, and Z·locations of the drawing, to hopefully make more sense.
·· With reference to the white dot in front and on your left, you would be against the Z-X wall or plane.
·· If you tilt the front of the sensor down Y goes positive ; If you tilt the sensor up Y goes negative.
·· If you tilt the Sensor Right (white dot up), the X goes positive ; If you tilt the sensor Left (White dot down), the X goes negative.

·· If you·oreint the sensor for a moment·so that the Z-Y plane is the ground (white dot down and in front of you)
·· Moving the sensor side opposite of the dot to your left causes the Z value to go negative ; moving it right causes the Z value it to go positive.

2) The first page of the pdf document... http://www.parallax.com/Portals/0/Downloads/docs/prod/acc/HitachiH48C3AxisAccelerometer.pdf
··· indicates that the module contains an on-board 3.3V regulator for the H48C and page 3 of the same document indicates that it should be powered with a 5V supply.

3)·At 1g the values should be within +/-455 ... with detection up to 3g's this value can increase to +/-1365
··· These values are distilled into a formula based on information from the pdf above, and this one...
··· http://www.parallax.com/Portals/0/Downloads/docs/prod/acc/MCP320412-bitA-DConverterDatasheet.pdf
··· "Ideally it should be documented in the header what kind of range of values is expected."·- I·have updated the object to reflect this.

Thank you

·

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

Post Edited (Beau Schwabe (Parallax)) : 3/25/2008 5:51:15 PM GMT

Fred Hawkins · 2008-03-25 05:26

I've a dog that eats rocks. A H48C module, a couple leds and a squawker on her collar might just the thing....

(Plus a propeller)

bulkhead · 2008-03-25 06:00

Sorry I haven't been on the forums in a while. I think I did realize from looking at the source code that the vref was already taken into account, yet I still had problems. See this thread: [noparse][[/noparse]url]http://forums.parallax.com/forums/default.aspx?f=25&m=233645[noparse][[/noparse]\url] It was strange, but lowering the PLL multiplier to 8x (for 40MHz operation) seemed to fix the problem for me. I tested this with a simple spin program that printed out the acceleration on all 3 axes to the PropTerminal.

I can't remember if there is anything else I changed to get it to work. I've long since moved to my own version of the object written in spin code that doesn't run in its own cog (I needed cogs more than speed), so I can't say anything for sure.

I wish I could be more helpful. From now on I will better document my problems and more importantly, any progress I make on solving them.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I'm new to the propeller!

Beau Schwabe · 2008-03-25 06:35

bulkhead,

As I was chasing the error down, I increased the duration of the rise and fall times of the Clock thinking that there might be a SHIFTIN/SHIFTOUT time framing error. The minimum spec from within the ADC document has 500nS for the CS disable time. I just took that across the board, and gave an overall clock a padding of 600nS in the most recent version. Your PLL will probably work at 16x now.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

H48C not giving proportional, usable output (propeller)

Comments