Athlon II Or Phenom II: Does Your CPU Need L3 Cache?
Page 1: L3 Cache: How Important Is It To AMD?
Page 2: 1, 2, 3: Cache Levels
Page 3:Athlon II X4 And Phenom II X4
Page 4:Test Setup And Efficiency Considerations
Page 5:Benchmark Results: Synthetics
Page 6:Benchmark Results: 3DMark, Games
Page 7:Benchmark Results: Productivity
Page 8:Benchmark Results: Audio/Video
Page 9: Performance Index And Conclusion
It makes sense to equip multi-core processors with a dedicated memory utilized jointly by all available cores. In this role, fast third-level cache (L3) can accelerate access to frequently needed data. Cores should not revert to accessing the slower main memory (RAM) whenever possible.
That’s the theory, at least. AMD’s recent launch of the Athlon II X4, which is fundamentally a Phenom II X4 without the L3, implies that the tertiary cache may not always be necessary. We decided to do an apples to apples comparison using both options and find out.
How Cache Works
Before diving deeper into our tests, it’s important to understand some basics. The principle of caches is rather simple. They buffer data as close as possible to the processing core(s) in order to avoid the CPU having to access the data from more distant, slower memory sources. Today’s desktop platform cache hierarchies consist of three cache levels before reaching system memory access. The second and especially the third levels aren’t just for data buffering. Their purpose is also to prevent choking the CPU bus with unnecessary data exchange traffic between cores.
Cache Hit/Miss
The effectiveness of a cache architecture is measured by its hit rate. Data requests that can be answered within a given cache are referred to as hits. If that cache doesn’t contain the sought data and must pass the request on to subsequent memory structures, this is a miss. Obviously, misses are slow. They lead to stalls in the execution pipeline and introduce wait periods. Hits, on the other hand, help sustain maximum performance.
Cache Writes, Exclusivity, Coherency
Replacement policies dictate how room is created in a full cache for new cache entries. Since data written into a cache eventually has to be available in the main memory, systems can either do this at the same time (write-through) or mark overwritten locations as “dirty” (write-back) and execute the write once the data is wiped out of the cache.
Data on several levels of cache can be stored exclusively, meaning that no redundancy exists. You won’t find the same piece of data in two different cache structures. Alternatively, caches can operate in an inclusive manner, with lower levels guaranteed to hold the data found in higher-levels (closer to the processor) of cache. AMD’s Phenom works with an exclusive L3 cache, while Intel follows the inclusive cache strategy. Coherency protocols take care of maintaining data across multiple levels, cores, and even processors.
Cache Capacity
Larger caches can buffer more data, but they also tend to introduce higher latency. Since cache also consumes large amounts of a processor’s transistors, it is important to find a viable balance between transistor cost and die size, power consumption, and performance/latency issues.
Associativity
RAM entries can either be direct-mapped, meaning that there can only be one position in a cache for copies of main memory, or they may be n-way associative, which stands for n possible positions in the cache to store data. Higher associativity (up to fully associative caches) provide the best caching flexibility because existing cache data doesn’t have to be overwritten. In other words, high n-way associativity guarantees higher hit rates, but it introduces more latency, since it takes more time to compare all of those associations for hits. Ultimately, it makes sense to implement many-way associativity for the last cache level because there’s the most capacity available, and searching beyond that would send the processor out to slower system memory.
Here are some examples: The Core i5 and i7 work with 32KB of 8-way associative L1 data cache and 32KB of 4-way associative L1 instruction cache. Clearly, Intel wants instructions to be available quicker while also maximizing hits on the L1 data cache. Its L2 cache is also 8-way set-associative, while Intel’s L3 cache is even smarter, implementing 16-way associativity to maximize cache hits.
However, AMD follows another strategy on the Phenom II X4 with a 2-way set-associative L1 cache, which offers lower latencies. To compensate for possible misses, it features twice the memory capacity: 64KB data and 64KB instruction cache. The L2 cache is 8-way set-associative, like Intel's design, but AMD’s L3 cache works at 48-way set associativity. None of this can be judged without looking at the entire CPU architecture. Naturally, only the benchmarks results really count, but the whole purpose of this technical excursion is to provide a look into the complexity behind multi-level caching.
About the author
Most Popular
Latest in Components
The Latest On Tom's HardwareFreeIMU: an Open Hardware Framework for Orientation and Motion Sensing
FreeIMU is an ongoing research project which aims to design Open Hardware 9/10 DOM/DOF Inertial Measurement Units as well as easy to use Orientation and Motion Sensing libraries, built on top of the Arduino platform.
The goal of the FreeIMU Framework is to simplify the development of projects based upon the most powerful and new consumer grade inertial, magnetic and pressure sensors.
The main application of FreeIMU is orientation sensing: by reading the data from the various sensors is possible to compute precisely the orientation of FreeIMU in the space. Recent boards also feature an high resolution barometer allowing to precisely track the device altitude. This can be useful in many applications: human-computer interaction device prototyping, flying machines, robots, human movement tracking and everywhere orientation sensing is a key aspect.
As FreeIMU breakout the sensors interrupt pins, it's also possible to detect per axis single and double taps, free fall as well as activity or inactivity. This makes FreeIMU a very good choice for Human-Computer devices prototyping. Interrupts pins are also very useful if you are into interrupt based reading of the sensors, useful to develop high frequency interrupt based sensor reading.
Video presentation of FreeIMU
Older video presentations: , .
A true Open Hardware project
FreeIMU is a true Open hardware, released under the CC-BY-SA. You are free, actually encouraged, to use it for any purpose, to study and modify its designs, to make your own copies of FreeIMU and even sell your own FreeIMU based hardware. But, you will have to share your designs based on FreeIMU keeping attribution and sharing them using the same libre license.
On FreeIMU repository (see development section below) and from the downloads on this page, you have access to everything you need to build your own FreeIMU board. You have access to the schematics, the PCB designs and even the bill of material so that you can build your own FreeIMU.
Moreover, FreeIMU has been designed using , an excellent libre PCB design software, so you don't have to rely on proprietary software to study or modify FreeIMU.
Getting FreeIMU
An assembled, tested and ready to use FreeIMU board can be bought from:
Viacopter.eu
(available!)
SDModel.it
(available!)
Flyduino.net
(sold out)
The FreeIMUs boards bought from the above shops financially support the project. The boards have been produced and
by reasonably paid workers in a safe environment in respect with European and Italian laws.
Build your own FreeIMU
If you have SMD soldering experience (or if you are up for experimentation) you can build your own FreeIMU. From the downloads below you have access to all the designs needed to have your FreeIMU PCB manufactured.
You can get cheap PCB with awesome quality from
and order the various components needed from you favorite electronic distributor: the Bill of Materials (BOM) files will tell you exactly which components you'll need for your FreeIMU.
The are various ways of soldering the board. If you only need a couple of boards done, tack flux, solder wire and hot air reflow station are enough to build your boards (Remember not to use hot air over the pressure sensor). See
for good instructions. In case you are building more units, an SMD stencil with solder paste is the suggested method.
In case you need help, just post a comment below.
FreeIMU versions
FreeIMU version 0.1
WARNING: Discontinued due to the phasing out of the HMC5843.
FreeIMU v0.1 is the simplest FreeIMU available. It contains the ADXL345 accelerometer, the ITG3200 gyroscope and the HMC5843 magnetometer, their respective capacitors and an additional 10uF capacitor to help keeping the power to the sensors stable. It doesn't have any voltage regulator nor any level translator so it needs to be connected to a 3.3V power source and the I2C level signals have to be 3.3V. When used on a 5V microcontroller, an I2C level converter and a voltage regulator are needed.
FreeIMU version 0.2
WARNING: Discontinued due to the phasing out of the HMC5843.
FreeIMU v0.2 has the same sensors (ADXL345, ITG3200 and HMC5843) and size of v0.1 but I added an integrated voltage regulator () and a logic level converter (). With these components it's extremely simple to use FreeIMU v0.2 on 5V boards like 16MHz Arduinos, just connect FreeIMU to the 5V, GND, SDA and SCL on Arduino and you are ready to go!
IMPORTANT: in version 0.2 sent to production there is a bug in the drill size of the connectors. The drill hole should have been 0.04" while it is actually 0.032". Consequence of this is that only rounded pins will fit inside the drill and standard squared pins won't fit. This is not really a problem as the big oval pad makes actually possible to use 90 deg squared pin arrays using the pad as a smd connector. The Kicad sources above and the gerbers marked with "Fixed" have this issue fixed. However they haven't been tested on production so double check them before send them to fabrication.
FreeIMU version 0.3
Changes to the MultiWii software to use FreeIMU as sensor board. Lines marked with "-" are the original code which has to be replaced by the lines with "+". This can be done automatically using the
FreeIMU version 0.3 replaces the accelerometer and magnetometers used in v0.1 and v0.2 with the ADXL346 as accelerometer and the HMC5883L as magnetometer. The gyroscope is still the ITG3200. FreeIMU v0.3 integrates a voltage regulator (MIC5205) and a logic level translator (PCA9306) as well as all the pullups resistors needed.
FreeIMU version 0.3.1
FreeIMU v0.3.1 is a minor revision of FreeIMU v0.3. There have been some corrections in the silkscreen and the footprint of the HMC5883L have been made slightly bigger to make assembly easy. Everything else is just as in FreeIMU v0.3.
FreeIMU version 0.3.5
FreeIMU 0.3.5 is a small (22x20 mm) 9 degrees of measurement IMU MARG sensor featuring the , the
FreeIMU 0.3.5 also has two additional subversions, FreeIMU 0.3.5_MS which features the
high resolution pressure sensor and the FreeIMU 0.3.5_BMP which features the .
FreeIMU v0.3.5 has an integrated voltage regulator () allowing you to plug it from 3V3 to 16V providing you 80mA of current which you can use to chain it to other 3V3 sensors or devices. By using the MIC5203, no tantalum caps are used in the whole design. Tantalum is not a good idea
The board has integrated 2K2 pullups resistors (which can be enabled or disabled by means of a solder switch) but doesn't have an integrated logic level converter. We decided to not include the LLC (which is present in my FreeIMU
and ) as it adds considerable complexity in the design and schematics without being strictly necessary. In fact, given a properly configured software, it's a redundant part. Moreover the upcoming development of many 3V3 based control boards (eg: Multipilot 32) makes adding an LLC not a very far-seeing choice.
The IMU board is however compatible with my
which can be stacked above the IMU, so that you can easily add the LLC protection keeping the amount of additional wires at the minimum.
The board, a part from the usual power and I2C connectors, breaks out the interrupt pins for all the three sensors. This should empower software developers to design interrupt based sensor reading and sensor fusion algorithms (opposed to the currently common polling based approach) which should provide possibility to shorten the cycle path of our algorithms.
FreeIMU version 0.3.5_MS
FreeIMU v0.3.5_MS is a variation of
which features the , the , the
high resolution pressure sensor.
The board comes with a voltage regulator () and 2K2 pullups optionally disabled by using of a solder switch.
FreeIMU version 0.3.5_BMP
BOM just as v0.3.5_MS just replace the MS5611-01BA with the BMP085 (Digikey 828-1005-1-ND)
FreeIMU v0.3.5_BMP is a variation of
which features the , the , the
pressure sensor.
The board comes with a voltage regulator () and 2K2 pullups optionally disabled by using of a solder switch.
FreeIMU version 0.4
FreeIMU v0.4 features the
gyroscope+accelerometer, the
The magnetometer is attached to the AUX I2C bus of the MPU6050 thus allowing it to be read directly by the MPU6050.
FreeIMU library
FreeIMU can be easily used on Arduino compatible boards using the Arduino FreeIMU library which implements sensor fusion MARG orientation filter enabling you to do easy and straightforward orientation sensing.
Install the libraries as explained in the
section Contributed Libraries.
The FreeIMU library now supports all the versions up to v0.4. By default it's configured to be used on v0.4. In order to use on different boards, open the file FreeIMU.h and uncomment the correct version of your board.
The FreeIMU library also supports the following 3rd parties boards:
Sparkfun IMU Digital Combo Board - 6 Degrees of Freedom ITG3200/ADXL345 SEN-10121
Sparkfun 9 Degrees of Freedom - Razor IMU SEN-10736
Sparkfun 9 Degrees of Freedom - Sensor Stick SEN-10724
Sparkfun 9 Degrees of Freedom - Sensor Stick
DIYDrones ArduIMU+ V3
Generic MPU6050 Breakout boards (eg: GY-521, SEN-11028 and other MPU6050 wich have the MPU6050 AD0 pin connected to GND.)
Note for FreeIMU v0.1 and 0.2 users: from April 2011 the default magnetometer configuration is for HMC5883L. In order to use the library with HMC5843 (v0.1 and v0.2) edit the file HMC58X3.h and uncomment the line #define ISHMC5843.
FreeIMU Processing Programs
The FreeIMU library comes with Processing visualization demos. In order to use them, Download and install . Copy the folders within the processing folder of the FreeIMU library archive into your Processing sketchbook.
Remember to change the Serial port address in the Processing code to match the address used by arduino on your system.
Ports to Other platforms
hair [dot] nair [at] gmail [dot] com. Author notes: 1. assumes a 6MHz crystal is attached and x4PLL internally, so Fosc = (6x4)/2 = 12 Mhz 2. trivial to use the internal FRC oscillator, instead of FNOSC_PRIPLL in the
configuration words, use FNOSC_FRCPLL. This will give you Fosc = (8x4)/2 = 16MHz, but of course with less precision. 3. transmits ascii quaternion data at 38400baud.
This does slow down the sampling rate.
Without the quaternion print, the code completes in less than 10mS, so the sampling rate is exactly 100Hz as set by the timer.
processor by
hair [dot] nair [at] gmail [dot] com. More details and possibility to contact the author on the FreeIMU community .
Have you ported the FreeIMU library to other platforms? Please
and I'll list your work here!
Calibration
is available. The software is currently in alpha state, however many people are already using it.
The calibration, when properly executed, drastically improve the orientation sensing performance of the FreeIMU framework. If you are experiencing drifting or inconsistent results, your sensors may need to be calibrated using the Calibration GUI.
There is now a , which has been set up to become the central point of interaction between users of the FreeIMU framework. This is the place where you can get help, join others in developing new features, discuss IMUs applications and much more.
Previously we used
as well as comments on Fabio's website for supporting users, however we decided to create an ad-hoc website to facilitate information gathering and collaboration between people.
Development, Bug Reports and Suggestions
Development of FreeIMU boards and libraries can be followed on
which also hosts our software and hardware repository.
Suggestions or bug reports can be made on the , in the .Previously bug reports were posted on the
but that's not used anymore.
FreeIMU repository holds all the various library sources as well as design files and schematics. Everything is revisioned meaning that all the changes are logged and annotated.
The contents of the repository are available using Bazaar (bzr) with the command:
bzr co lp:freeimu
Never used bzr before? Not a big deal, it's very similar to git, svn or others. You may wanna have a look at the
to have an overview of the commands available or read .
Alternatively, in case you have problems setting up bzr on your system, you can simply get the latest repository contents from . The resulting file is a .tar.gz archive which can be opened with the excellent
under Windows. Mac and Linux users shouldn't have problems opening such files.
The files on the repository can also browsed from a browser . A list of recent changes is available .
FreeIMU users videos
Here some videos made by FreeIMU users on their projects using FreeIMU.
flies like crazy with FreeIMU on his quadcopter.. check out the triple flip!
testing indoor FreeIMU v0.4r3 on one of his quadcopters.
stress test FreeIMU v0.3.5_MS on one of his quadcopters.
uses FreeIMU on his VTOL EDF Tricopter powered by the
Danilo Del Console uses FreeIMU in a 2 wheels self balancing robot.
uses FreeIMU for a camera stabilization system.
with his super fast implementation of the AHRS algorithm capable of displaying the rotating cube at 333Hz with FreeIMU! Great work!
Marchino65 with his first test with FreeIMU and the FreeIMU library on Arduino. The cube is spinning pretty good!
in his first flight with FreeIMU on his very young quadcopter project called Simplo.
774354 reads
Someone pls help. I need the code to test the IMU. (In the 3D Cube form) If anyone will to help me. I really appreciate all of your help as i need it very urgently. So please, help me? and best is the library as well. My email is mingjie928 [at] hotmail [dot] com
I'm trying to gather some differences between MPU6050 and FreeIMU.
I am the (happy) owner of 4 NAVSPAR arduino GPS boards. When I did buy the board out a kick start project it seems promesing
A high speed processor 100mhz 32 bit integrating a arduino and GPS chip. I did also buy the sprakfun 9df sensor stick to conect it. But at that time a was not aware of the different nature of the NAVSPAR processor.
Now I facing the problem of the conversion of the arduino software to the NAVSPAR platform or bying a other arduino board. This last option will save my a lot of time but than i missing the nice high speed NAVSPAR processor
I need some advice how to proceed best? or perhaps someone did the job olready!
i have a CSV file with IMU data. I need gui to process that. I need to draw a line/path of my imu. has anybody an Idea?
Hallo, I need help in processing TXT file with data type from:
It is Python collected data from my Samsung! I need to get point cloud or Vector cloud (better) so I can draw it in 3d in AUTOCAD (x,y,z
will be ok). I just cannot translate
the data into the points. PLEASE help!
Thanks and have nice day!
Hello Everyone,
I am trying to run the altitude example in the free IMU download on this page. I am using an Arduino UNO with a 6Y-86 FreeIMU chip. I downloaded all the libraries included into my sketchbook. I was able to compile and download it to the Arduino without any errors.
After downloading, I looked used the serial monitor tool and i only get junk values that look like noise.
Has anyone else experienced issues getting altitude information like this? Or does anyone know what can help my problem?
Any help would be greatly appreciated.
I am trying to do this with an Arduino Fio and the MPU 6050 breakout board supplied by SparkFun. I have run processing and it is showing the cube and it moves but it is going exceptionally slow. Also, has anyone found a solution for the Yaw Drift?
Dear Fabio,
we already had contact some time ago. I work an a dance multimedia project and use your FreeImu to measure the head movements of the dancer (.
I have two FreeImu devices:
1) FreeIMU v0.3.5_MS, from Fabio, (19.11.2011)
2) FreeIMU v0.3.5 BMP, from ViaCopter (12.1.2012)
The 0.3.5_MS works perfectly. Latetely I testet the backup device (0.3.5 BMP) in case the first one breaks. The following problem occurs:
The magnetometer of this device has kind of a delay. You turn the device into another orinetation. The magnetometer reacts. Once it is in the new position it needs sometimes until 3-5 seconds until it shows the right heading. Basically it moves too far and is slowly moving backward. The first device doesn't react this way. Could you please help and tell me what the difference could be?
Thanks for any hint,
PS: do you have an old v0.3.5_MS to sell... I need to habe a working backup as soon as possible. Our show ist on the 19. of september.
You write but, Fabio is not here. He passed away in January 2013
Yes, I recently found it out.
Very sad. Amazing guy.
I have the MPU9150 breakout board, trying to get the roll pitch yaw program working as we are doing a design project to make a UAV.
Problem is when uploading the rollpitchyaw program it gives the errors: MPU60X0.h: No such file or directory and MPU60X0 does not name a type.
All the libraries are in the right place, there is #include I2Cdev.h and 6050.h.
I have also gone into FreeIMU.h and uncommented the Gen 6050 breakout.
Can't figure out what's wrong, thanks for your help!
Hi Fabio, did you think using the MPU-9150 in the future?
Hi everyone and thank you Versano for writing this great library.
I've been experimenting with my IMU for a couple of months while trying to build a quadcopter from scratch. I have noticed that it was quite complicated to analyze Roll, Pitch, Yaw, roll rate, distance from ground, automatic corrections, etc so I decided to create .
The main difference with other libraries I've found out there is that you can plot multiple series on multiple viewports using different Min and Max values on each viewport.
I hope this will help many of you and I'd love to get your feedback.
I'm feeling so sad when I knew Fabio has gone. He gave us lots of help, and didn't want any returns, even I didn't ask any question to him, didn't post any reply before, but I read a lot, and knew him a perfect guy.
Right now, It seems there's no one hosting the website anymore as spam letters growing. And I'm afraid the website will be shut down months or years later, then Fabio will be lost forever.
So, can anyone give some help to continue hosting the website? I know its possible that no one knows Fabio's account name and password, and I still wish someone, his friend, his student or his family, could contact us to continue hosting this, at least, to delete the spam letters.
I?m interested in FreeIMU v0.4, but i?ve just seen the tragic new about Fabio. So, what can we do now? I have seen another board in ebay:
It is significantly cheaper, and has the same sensors. The pins are the same, only one is different, in this module is DRDY instead INTM.
What do yo think? Could be this board compatible with FreeIMU libraries?
If anyone knows where I can find another solution, please let me know.
I was taking a look at the code and I didn't understand why does it invalidates a measurement if one of the axis is zeroed. I guess it should only invalidate a measurement if all axis are zeroed, right? This is being done to both magnetometer and accelerometer measurements and I was wondering if it isn't throwing away good measures this way.
Fabio has passed away,my condolences to his family.
look here for more info
Re: GPS integration
Postby Sharkcopter >> Fri Dec 28,
I am very saddened to tell you that Fabio Varesano, the manufacturer of FreeImu died on Christmas Day.
He was only 27 years of age.
This morning we attended his funeral.
I remember him as a friend with a great desire to try and help others.
Sharkcopter
Joined: Fri Feb 24,
RIP Fabio! Gohai
Hello Fabio,
I'm using the FreeIMU v4 after calibration with the tool you've created.
The results are much better now but I'm still getting some drift.
I was thinking, since I have no use for Yaw measurements - is it possible to ignore the Yaw and get better results for pitch and roll?
Thank you for your excellent work!
Fabio have you updated the library ? Is the current version on this page the one from bazaar ?
My email for contacting me it is on my website.
I just soldered a FreeIMU board, for testing with Teensy 3.0.
At least one user reported an issue with 16 vs 32 bit integer pointers in the code.
I'll investigate soon.
While soldering, I noticed C303 is shown as 2.2 nF on the schematic, but 10 nF on the bill of materials.
Maybe it doesn't matter, but thought it might be helpful to mention?
Hey Paul, nice to see you around here! Big fan of your work!
While soldering, I noticed C303 is shown as 2.2 nF on the schematic, but 10 nF on the bill of materials. Maybe it doesn't matter, but thought it might be helpful to mention?
It will work with both of them.. however, we are currently using 2.2nF in the FreeIMU boards that we produce. Specifically, it's PN: KAT2A Digikey: 478-1354-1-ND. I fixed the BOM to avoid confusion.
I just soldered a FreeIMU board, for testing with Teensy 3.0. At least one user reported an issue with 16 vs 32 bit integer pointers in the code. I'll investigate soon.
Awesome! The Teensy 3.0 looks like an excellent platform for running the complex FreeIMU library math! It would be great if you could share your ported code, I'm sure pe-)
For any further questions or if you need my help during the porting, jump to the !
Sorry for bad english - I'll use the Google translator
Now I'm busy porting your code atmega128a3.
Faced with such a problem:
at standard
# define twoKpDef (2.0f * 0.5f) / / 2 * proportional gain
# define twoKiDef (2.0f * 0.1f) / / 2 * integral gain
watch drift YAW / - 13grad, PITCH / -1, ROLL / -2 for 1-2 minutes
with decreasing
# define twoKiDef (2.0f * 0.01f) / / 2 * integral gan
The situation is getting better, but the problem does not disappear.
The cycle time for my 32MHz CPU frequency is obtained:
my3IMU.getQ (q) ~
microseconds
my3IMU.getYawPitchRoll (ypr) ~
microseconds
Thank God now though such a result is available (all day I suffer with constant drift in all directions), but it would be better - IMU is going to introduce a code of my port on MultiWii atxmega
So for my senior design group we are building a thrust vectoring system for a rocket motor during flight. We are using the FreeIMU to read the flight path of the vehicle and will send any corrections to the vanes in the rocket exhaust. I am an Aerospace Engineer so I have very little experience with electronics and coding them.
My main question is what does the FreeIMU output the sensor data as? Is it in that quaternion or as something else? If its in the quaternion, how does one convert this into the raw values so that yaw, pitch and roll can be found?
I appreciate any help. I have a little programming background in Matlab and Fortran but I am just lost when I look at your processing code to get the yaw, pitch, roll values from the FreeIMU.
We are using an Arduino Uno R3 as our board which will be controlling 4 servos which will rotate the vanes in the rocket exhaust.
Hey Josh, may I ask you to post your question on the new FreeIMU Community website?
Greetings from Vancouver Island Canada.
Lawn bowling is quite popular in Canada.
I would like to instrument a lawn bowling ball with the FreeIMU that you are/have developed.
There is quite a bit of skill involved with lawn bowling,ie. smooth release, no bounces, no wobble, correct speed etc.
The bowling balls are about 5"in diameter and are weight "biased"to curve either right or left, depending on the release orientation.
I would like to use the FreeIMU on a Arduino nano board with bluetooth or zigbee wireless communications with a laptop.
I would like to show the ball's trajectory, speed, curve, deceleration, calculate and show the lawn "speed", wobble, bounces etc.
This would be
agreat tool for training people.
The final instrument package would need to be small to fit inside a bowling ball.
Software devolpment would be difficult.
Do you think it can be done?
Any suggestions would be appreciated.
It's not an easy development but an IMU can surely be helpful for this kind of training. I can ensure you that the math involved won't be easy and probably results won't be as good as you hope.
The rolling path and speed can be tracked quite precisely, see my
project, however it will be pretty hard to track the ball in the air during the launch...
I would suggest you to get a FreeIMU an doing some tests and see how it works before going more serious with the project.
Please join the community at
Hi, I am using the arduIMU v3 from dydrone. I am trying to read roll pitch and yaw but it looks like it is displaying a bunch of wrong data that do not have anything to do with roll pitch or yaw, no matter how I vary the positions of my board. actually even when I don't move the board at all the values for yaw keep increasing until they reach a certain value and then go down again. and same thing happens for the roll and the pitch. what could be a possible reason for the readings that I am getting? and what would be a fix for that.
I'm wanting to implement the work you have done with the MS5611 into my OSD system for my model aircraft.
I'm trying to run your MS5611BA_Altitude sketch and am having trouble compiling it on a Arduino UNO.
These are the errors I'm getting
(see below) ~
Can you or maybe someone else help?
Thank you in advance,
MS561101BA_altitude:36: error: 'MS561101BA' does not name a type
MS561101BA_altitude.pde: In function 'void setup()':
MS561101BA_altitude:51: error: 'baro' was not declared in this scope
MS561101BA_altitude:51: error: 'MS561101BA_ADDR_CSB_LOW' was not declared in this scope
MS561101BA_altitude:56: error: 'MS561101BA_OSR_4096' was not declared in this scope
MS561101BA_altitude.pde: In function 'void loop()':
MS561101BA_altitude:62: error: 'baro' was not declared in this scope
MS561101BA_altitude:62: error: 'MS561101BA_OSR_4096' was not declared in this scope
Compiling fine here. You have to install the library to your Arduino library folder before being able to compile that program. The FreeIMU library section above includes instructions and references on how to do so. Also have a look to the INSTALL.txt file in the distribution.
Thanks Fab,
Got it compiled no errors :)
I'm using this MS5611 board from these folks
It looks like it is a MS
Is there something I need to modify in the code to see some type of output in the serial monitor?
Right now I am not seeing anything.
I feel like I'm getting close and am looking forward to seeing some numbers :)
Thanks again,
I'm very new to using sensors and have some basic questions to see if FreeIMU (or ArduIMU) would be suitable for the application I have in mind.
I'm hoping to be able to measure the change (in degrees) of the yew and pitch during a short forward movement (about 6-12 inches over about 0.1 to 1.0 seconds) parallel to the x-axis of the device.
I'd need to determine the start and end of the forward movement (the end may be abrupt - a collision).
Also, the device may be oriented in different rolls during this movement and would need the same yew and pitch result regardless of its roll orientation (it could be laying flat, upside down or on its side during the movement).
I think this application of the device is a simple case and issues regarding 'drift', calibration, etc. may not come into play.
Do you agree?
Would FreeIMU be suitable?
Would a simpler device, such as only an accelerometer/gyroscope, be sufficient for my needs?
Thanks in advice for your comments.
Appreciate the comments thus far.
Let me try to explain the application better.
The device would be a training aid attached to the butt end of a pool (billiards) cue, the x-axis parallel with the cue but it may oriented on the top, side, etc. of the cue stick.
When a player shoots the cue tip is paused near the ball (the 'set'), the cue is drawn back and stops momentarily (the 'pause') then stroked forward to strike the ball (the 'finish').
The player's objective is to keep the cue movements straight along it's axis, so the tip finishes at the same place as it was at the set and with minimal lateral (yaw) variation during the stroke (pitch changes during the stroke are normal and acceptable).
On a very hard forward stroke the cue may be moving up to about 25 mph, though only for about 6 to 12 inches.
Can an IMU (or hopefully a device with fewer sensors) be able to
measure the straightness of the stroke?
Can some of the difficult programming you are using for more typical IMU applications be avoided?
I'm a novice and only familiar with C and Java programming.
I'm hoping to get some guidance before buying things I don't need and going down the wrong paths when experimenting.
Thanks again for any comments.
If the device is stationary for a short period of time, such as one second, at the beginning and end of the movement, I think you could use only an accelerometer. The problem with accelerometers is they are noisy. That is why accelerometers are combined with gyros: the combination reduces noise. But if your device is stationary, you can take a few hundred readings from just an accelerometer, average the readings, and get reasonable results. Of course, a complete IMU such as the FreeIMU will give more accurate results, but you might not need that level of accuracy.
No, you can't do what the original poster asks only with an accelerometer. He wants to measure the changes in degrees on the yaw and pitch during forward motions. Unfortunately, you can't measure yaw from an accelerometer only. You need a complete IMU for that.
I wouldn't say that this is a simple application tough. Depending on how fast the motion is, you may get good or bad results. You may wanna do some tests and see how it goes.
I'm using FreeIMU 0.4 with Arduino for a while.
Now I'm porting the FreeIMU library to an ARM platform (Energy Micro).
I'm modifing the sensor driver to always use the I2CDev lib.
Since your code is C++ with only stadard types, I want to only have I2CDev to get modified (concentrate I2C implementation)
Could you integrate my modifications ? Always using I2CDev lib enable to get only I2CDev be modified to handle Arduino and EFM32 platform.
Hi Guz, thanks for using FreeIMU and for willing to help.
Unifying the I2C access routines is something that the FreeIMU library badly needs. It's been on my todo list for quite some time, but still not been able to do so. So, any help you could give would be much appreciated.
However, I always found i2cdevlib unreasonably bloated.. too many functions, calling too many subfuctions.. we are using microcontrollers, not writing Java webapps.
I would suggest you to have a look at the i2c implementation used by the MultiWii project (lines 150 to 260 from
) .. this looks to me as very efficient and elegant. Probably, I would have simply wrapped that code into a CPP object and go with that.
Interested in hearing your thoughts.
So I'll look that code and port it into a C++ class.
I'll try to make that class portable from Arudion to EFM32 platform.
I'll port drivers to use it and to be generic (any platform).
Thanks! I appreciate it. Please use the latest code from the repository as starting point.
Unfortunelately, I'm using windows so get the latest version from launchpad isn't easy.
Could you please send me a Zip with latest sources.
I'll modify them and post back to you these.
Just use the
version of the library. I didn't make any changes to it in the last week. Thanks for your help.
getting the real world acceleration :) just need to know the g range now
If you are using a FreeIMU v0.4, then the default range for the accelerometer is +-2G .. if you want to change this, you can call accgyro.setFullScaleAccelRange(X) where X can be MPU6050_ACCEL_FS_2, MPU6050_ACCEL_FS_4, MPU6050_ACCEL_FS_8, MPU6050_ACCEL_FS_16 respectively for +-2, +-4, +-8 and +-16 G.
I know how to apply kalman filter to an ANALOG ACCELEROMETER read all about it from starlino and instructables.
How do I use it in a DIGITAL ACC....I need to get real world acceleration in G's for my project...
what more should be done to the raw values from ADXL345 to get Kalman filtered values
Fabio please help.....have been trying this for a week now
float S=0.0078;//scale factor to convert from raw acc data to g
rawAcc[0]*=S;
rawAcc[1]*=S;
rawAcc[2]*=S;
float[] g= {
0.0, 0.0, 0.0
g[0] = 2 * (q[1] * q[3] - q[0] * q[2]);
g[1] = 2 * (q[0] * q[1] + q[2] * q[3]);
g[2] = q[0] * q[0] - q[1] * q[1] - q[2] * q[2] + q[3] * q[3];
float[] dynAcc= {
rawAcc[0] - g[0], rawAcc[1] - g[1], rawAcc[2] - g[2]
Now that values I'm getting are:
quaternion=
[1] -0.4581384
[2] 0.8866772
rawAccleration (now in g I hope);
[0] -0.1248
[2] -0.9906
dynamic acceleration=
I was curious if you've tried using the DMP of the MPU6050 directly? I was wondering if you'd get better fusion of the acc, gyro, mag that way. Or perhaps both DMP and Mahony's DCM?
Actually, I just realized that the MPU6050 is not capable of fusing data from an external magno. Lame, bad marketing.
But the 9150 should be capable of doing that and it has a magno integrated as well. So I'm hoping their DMP can do some pretty stable fusion (temperature bias integrated too!)
Do you have any plans to integrate MPU9150 into a v5 FreeIMU? I'd love to get one ASAP.
I haven't been able to source the MPU9150 anywhere yet.. if you see it around let me know.
Personally, I'm not a big fan of DMP.. slow and obscure.. the algorithms used on the FreeIMU are better and allows you to reach much faster frequencies.. I guess the DMP is phones/tablets stuff for lazy programmers.
Popular content
Advertising