Member Since: April 20, 2008

Country: United States



Proud to be an American - again…


Sr. Research & Development Engineer


Society of Naval Architects & Marine Engineers

Programming Languages

C, C++, Mathematica


Centralia College, Seattle University, University of Washington


Machine control & instrumentation, CFD, Marine Engineering & Small Craft Design


Boats, Planes, Trains & Automobiles

  • There were two types of spectators at Casey’s jet turbine demonstation: Those that wanted to be closer and those that wanted to be far away. Looks like far away prevailed.

  • There were two types of spectators at Casey’s jet turbine demonstration: Those that wanted to get closer and those that wanted to be far away. Looks like far away prevailed!

  • For something a bit more generic check out:

  • A shameless plug…
    You can build your own ISP, for this project and other Atmel chips. Tutorial link below.

  • A shameless plug…
    You can build your own ISP, for this project and other Atmel chips. Tutorial link below.

  • Sample Code? Why Yes, Yes there is…
    Check out this link, then links to docs and code there.
    Am I dreaming, or does this look eerily familiar??

  • Flare,
    Assuming your numbers are correct, the first thing I notice is that your data retrieve rate is substantially slower that your sample rate. You will lose data if you don’t keep up with the sample rate.
    I would suggest - and I’m no expert on inertial navigation - but slow down your sample rate to a more modest value - say 200Hz or 400Hz.
    I assume you are leaving CPU overhead to do something useful with the data once you have it - and keep up with the sample rate. If your number crunching is limiting your data retrieval rate to 400Hz, then your sample rate on the accelerometer should be about half that (200Hz) to avoid Nyquist aliasing.
    That said, if your power supply is clean and you are communicating with the device, that’s 90% of the battle. The rest is software.
    Check your FIFO mode (reg 0x38) and watermark/overrun bits (reg 0x2e). If you are set to FIFO mode, you may just be reading the same 32 bytes over and over.
    If you still need help, send me your setup code. mdlougheed - at -

  • Funny you should mention Kalman filtering…
    I couldn’t find anything specific in the datasheet, but one approach could be to use the specified +/- 0.5% full scale nonlinearity. This would give you a linearly increasing error band with higher accelerations - sort of a “bow tie” shape with zero error assumed at zero g (freefall). You would be assuming higher error at higher accelerations.
    The device operates in two modes - a “locked” 4mg/LSB, independent of scale and a ratiometric mode that I would assume is as good as the stability of your power supply. In either case, this is another uncertainty to be quantified.

  • contd.
    4. After a power-on reset, the device will be in standby mode (not taking data). Do all your configuration first (i.e. data rate, g-range etc), then tell the device to start measurements by setting the D3 bit of the POWER_CTL (0x2D) register. The device WILL NOT take measurements until you tell it to do so.
    4a. If you tell the device to stop taking measurements by resetting the D3 bit of POWER_CTL, the X, Y & Z Accelration registers will retain the last values they contained.
    4b. Repeating - the device may appear dead if you do not tun on the measurement mode.
    4c. MOST OF THE REGISTERS DO NOT NEED CONFIGURATION FOR SUCCESSFUL BASIC OPERATION. For grins - after proof of life by a successful read of the DEV_ID register, try just issuing a 0x08 value to the POWER_CTL to turn on measurements and read the X,Y & Z accel registers.
    I am using the SparkFun LCD-08625 as a controller which has I2C built in. I had this part operational in under an hour - figuing in the time it took to address the wait state problem above.
    No worries.

  • This is definitely a RTFM part. RTFM then RIA (Read it again!). Having said that, it is not that difficult to get running in I2C mode.
    Here are a few hints:
    1. Make sure the SDO and *CS lines are tied high to set the primary I2C address and I2C mode respectively.
    2. Search for and read the UM10204 I2C-Bus Specification and User Manual.
    2a. The section on computing the proper I2C bus pullup resistors is most valuable.
    2b. I used 3.3k ohm buss pullups for my project. Enough to use both the 100kHz standard and 400kHz fast data rates while accounting for a fair amount of open air bus wire(furrball) capacitance.
    3. For whatever reason, during the single and multi byte read cycle, you may need to add a time delay to your code after sending the register address and waiting for the device to ACK before sending the restart/read mode command. My code would hang up the device until I added a short delay (ACK status fetch).
    3a. This device is really sensitive to hanging up in I2C mode if you FUBAR the communications. This will require a full power disconnect and restart - A simple soft reset will not do.

No public wish lists :(