Sparko4Marko

Member Since: April 20, 2008

Country: United States

Profile

Bio

Proud to be an American - again…

Role

Sr. Research & Development Engineer

Organizations

Society of Naval Architects & Marine Engineers

Programming Languages

C, C++, Mathematica

Universities

Centralia College, Seattle University, University of Washington

Expertise

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

Interests

Boats, Planes, Trains & Automobiles

  • Product DEV-11168 | about 2 years ago

    For something a bit more generic check out:

    https://sites.google.com/site/projectstruix/projects/isp

  • Tutorial - Adventures in Low Power Land | about 3 years ago

    A shameless plug…
    You can build your own ISP, for this project and other Atmel chips. Tutorial link below.
    https://sites.google.com/site/projectstruix/projects/isp

  • News - Rock Bottom Power | about 3 years ago

    A shameless plug…
    You can build your own ISP, for this project and other Atmel chips. Tutorial link below.
    https://sites.google.com/site/projectstruix/projects/isp

  • Product DEV-10039 | about 3 years ago

    Sample Code? Why Yes, Yes there is…
    Check out this link, then links to docs and code there.
    http://www.skpang.co.uk/catalog/product_info.php?products_id=706
    Am I dreaming, or does this look eerily familiar??

  • Product SEN-09156 | about 4 years ago

    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 - gmail.com

  • Product SEN-09156 | about 4 years ago

    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.

  • Product SEN-09156 | about 4 years ago

    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.

  • Product SEN-09156 | about 4 years ago

    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.

  • Product GPS-08975 | about 4 years ago

    • What happens when that little battery goes dead?
      Good question. I found this out the hard way.
      The battery appears to be a “batcap” (but I could be wrong - wouldn’t be the first time! :-). It charges when there is power to the device and will hold a charge for a good long while with power off, maintaining the settings from software commands having been sent (like change the baud rate, 1hz update rate, etc…)
      If the device is without power for a long time, it will reset to the default settings that have been programmed into the EEPROM. If the EEPROM has not been updated by software command, the default will be the factory settings.
      I made the mistake of programming this GPS to accept a particular (slower) baud rate on one (faster) microcontoller, to use with another controller that had the slower maximum baud rate. A month went by and I had a hard time figuring out why the GPS wouldn’t talk to the controller anymore - the batcap had died and the unit powered up with the faster default settings.
      Lessons learned - I should know better!
      Lesson 1 - Don’t assume the (GPS) hardware will hold its settings unless they are put into EEPROM.
      Lesson 2 - Don’t get fancy with swapping hardware between projects.
      Lesson 3 - Keep special setups a software thing - done each time the unit is powered up.
  • Product GPS-08975 | about 4 years ago

    TDMA,
    For the connection, I have used a common right angle header strip - broken off to 5 pins, then soldered to the pads on the unit.
    For mounting, there is always double sided tape, stuck to the processor shield, then to the PCB (crude, but effective). The “proper” way would be to use stand off posts in the corners and fasten to the PCB - or make a square hole for the antenna, then fasten directly to the PCB.

No public wish lists :(