Member Since: April 20, 2008

Country: United States



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

  • Being a troll is not my really my thing. My observation, however, running the 328p at 16MHz on 3.3V is just a little out of spec, isn’t it? Not that you can’t overclock a bit and see what happens. You’d need at least 3.78V by my math to run within spec at 16MHz. That said, you could use a 3.8V regulator (TPS70938DBVT or similar) to make the processor happy at 16MHz and still be within absolute maximum voltage for uSD cards (in the range of 4.6V). Still though, the uSD card would be running above it’s nominal high voltage of 3.3V.

    My motivation is using a configuration like this in more extreme environments where high (and low) ambient temperatures and humitidy are prevalent. This makes running the components within spec a bit higher priority for reliability.

    Another solution could be to substitute something like a ATxmega32E5 for the 328p which will run happily up to 32MHz on 3.3V

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

No public wish lists :(