Posts with «magnetometer» label

HMC5883L on the GY-80 module


In this tutorial, I will show you how to configure and extract data from the magnetometer (HMC5883L) sensor on the GY-80 10DOF module from ICStation. While there are some very good libraries on the internet which will give you full access to this sensor, I will show you what you need to know without using a library. This means that it may get a bit technical at times, but I will hold your hand along the way and provide explanations as required. I would also recommend that you watch the complete video from start to finish - as the video provides really useful information.


HMC5883L Magnetometer Datasheet:

You can find the datasheet for the HMC5883L pretty easily by searching on the internet. Here are a couple of sources:


Arduino Libraries

This tutorial does not use any external libraries.
It does use the Wire library for I2C communication.
However, there is no extra download required to access the Wire library.
If you are looking for a library specific for the HMC5883L sensor, then I would recommend one of these:

Like I said - you do not need an HMC5883L library for this tutorial. The libraries above are listed for those who wish to learn more about this particular sensor.

Arduino IDE

The Arduino IDE can be downloaded from the Arduino website. Visit the Arduino IDE download page.

I generally use the ZIP file for Windows and never seem to have any issues.
There are downloads available for all the major operating systems.



I have created a Gist for the Arduino code to configure and extract data from the HMC5883L sensor. However, I also have a GitHub repository which aims to capture the code for all of the sensors on the GY-80 module. Code for the other sensors will become available in due time. Meanwhile, have a look at the code below for the HMC5883L sensor:

This code will set all axis values to 1000 upon startup. Moving the GY-80 module around will result in a value greater or less than 1000, however, returning the sensor back to it's original position, should result in values very close to 1000 on each axis. I chose to introduce this calibration in order to avoid negative values, and I liked the fact that I could set a heading with values that were easy to remember.
The magSetting function was created to easily configure the magnetometer.
Make sure to look at the video and also the datasheet for further information about calibrating the magnetometer.
The getReadings function was created to easily retrieve the magnetometer axis data. I chose to use Single measurement mode in this tutorial.


Hooking it up:

You can communicate with any of the sensors on the GY-80 module using I2C. The HMC5883L magnetometer sensor is no different. You will need four connections between the Arduino UNO and the GY-80 module. Have a look at the diagram below for the connection diagram and table.

Fritzing diagram


Project pictures

Concluding comments

The HMC5883L sensor on the GY-80 module is quite interesting and works relatively well. There are a number of other sensors on the GY-80 module which can provide complementary positional data. At some point, I plan to come back and explain some of the other sensors on this module, but first I would like to create a real-life project using the magnetometer. So stay tuned. You may want to subscribe to my social networks or to this blog to be notified of that project when I complete it.

I would like to thank ICStation for their collaborative efforts. Their contribution was invaluable to this tutorial's existence.

If you like this page, please do me a favour and show your appreciation :

Visit my ArduinoBasics Google + page.
Follow me on Twitter by looking for ScottC @ArduinoBasics.
I can also be found on Pinterest and Instagram.
Have a look at my videos on my YouTube channel.

ScottC 06 Nov 16:20

Navigation Thing: Four Days, Three Problems, and Fake Piezos

The Navigation Thing was designed and built by [Jan Mrázek] as part of a night game activity for high school students during week-long seminar. A night-time path through a forest had stations with simple tasks, and the Navigation Thing used GPS, digital compass, a beeper, and a ring of RGB LEDs to provide a bit of “Wow factor” while guiding a group of students from one station to the next. The devices had a clear design direction:

“I wanted to build a device which a participant would find, insert batteries, and follow the beeping to find the next stop. Imagine the strong feeling of straying in the middle of the night in an unknown terrain far away from civilization trusting only a beeping thing you found. That was the feeling I wanted to achieve.”

The Navigation Things (there are six in total) guide users to fixed waypoints with GPS, a digital compass, and a ring of WS2812 LEDs — but the primary means of feedback to the user is a beeping that gets faster as you approach the destination. [Jan] had only four days to make all six units, which was doable. But as most of us know, delivering on a tight deadline is often less about doing the work you know about, and more about effectively handling the unexpected obstacles that inevitably pop up in the process.

The first real problem to solve was the beeping itself. “Beep faster as you get closer to the destination” seems like a simple task, but due to the way humans perceive things it’s more complex than it sounds. We perceive large changes easier than small incremental ones, so a straight linear change in beep frequency based on distance doesn’t work very well. Similar problems (and their solutions) exist whether you’re controlling volume, brightness, or just about anything else that humans perceive. Instead of encoding distance as a beep frequency, it’s much more effective to simply use beeps to signal overall changes: beep noticeably slower as you move away, but beep much faster as you get close.

A “piezo” buzzer that was assumed to have no significant magnetic field, but in fact contained a magnet.

The other interesting problems were less straightforward and were related to the digital compass, or magnetometer. The first problem was that the piezo buzzers [Jan] sourced contained no actual piezo elements. They contained magnets – which interfered with the operation of the digital compass. After solving that, still more compass problems arose. When testing the final units in the field, the compass readings were not as expected and [Jan] had no idea why.

After careful troubleshooting, the culprit was found: the AA cells on the other side of the circuit board. Every AA cell has a faint (and slightly different) magnetic field, and the proximity and placement of the cells with respect to the magnetometer was causing the deviation. Happily, the fix was simple once the problem was understood: calibrate the compass every time new batteries are inserted.

If you’re interested in the Navigation Thing, check out the github repository. And on the topic of actual piezoelectric devices, piezos are implemented in a variety of clever ways. There are even piezo transformers and piezo vacuum pumps.

Filed under: gps hacks, misc hacks

Wireless Water Meter Monitor Watches Waste

It’s no secret that hackers like to measure things. Good numbers lead to good decisions, like when to kick your wastrel teenager out of a luxuriously lengthy shower. Hence the creation of this wireless Arduino-based water meter interface.

We’ll stipulate that “wireless” is a bit of a stretch. Creator [David Schneider] chose to split the system into two parts – a magnetometer and an Arduino to sense impulses from the water company meter, and a Raspberry Pi to serve the web interface. The water meter is at the street rather than in his house, so the sensor is wired to the Pi with some telephone cable. But from there the system is wireless.

[David] goes into some good detail on the sensing problem he faced, which relies on detecting the varying magnetic field due to the spinny-bits inside the flowmeter and cleaning up the signal with the Arduino; he also addresses aliasing errors that occur when flow rate approaches the sampling rate of the magnetometer.

We like the fact that there’s a lot of potential to leverage this technique to monitor other processes with rotating magnetic fields. And like this optically coupled gas-meter monitor, it’s not invasive of the utility’s equipment either, which is a plus.

[via reddit]

Filed under: green hacks, home hacks

Visualizing Magnetic Fields In 3D Space

[John] is working on his PhD in experimental earthquake physics, and with that comes all the trials of becoming a PhD; tuning students into the cool stuff in the field, and demonstrating created after 1970 to his advisers. One of the biggest advancements in his line of work in the last 30 or 40 years is all those sensors you can find in your cell phone. The three-axis magnetometer in your phone is easily capable of measuring the Earth’s magnetic field, and this chip only costs a few dollars. To demonstrate this, [John] built a 3D compass to show off the capability of these sensors, and have a pretty light show for the undergrads.

The magnetometer [John] is using is just a simple I2C magnetometer that can be found on Adafruit or Sparkfun. It’s not really anything special, but with a little bit of code, [John] can read the magnetic field strength in the x, y, and z axes.

Having a microcontroller spit out a bunch of numbers related to the local magnetic field just doesn’t seem fun, so [John] picked up two neopixel rings – one inside the other, and set 90 degrees out of plane with each other. This turns his magnetometer and Arduino setup into a real 3D compass. With this device, the local magnetic field can be visualized in the x, y, and z axes. It looks cool, which is great for undergrads, and it’s a great demonstration of what you can do with small, cheap electronic sensors.

[John] put up a screencast of a talk he gave at the American Geophysical Union meeting last year. You can check that out below.

Filed under: Arduino Hacks
Hack a Day 21 Jun 18:00

MagnID – Sneaky New Way of Interacting With Tablets

New magnetic tech dubbed “MagnID” is being presented this weekend at Stanford’s annual TEI conference. It is a clever hack aimed to hijack a tablet’s compass sensor and force it to recognize multiple objects. Here is a sneak peek at the possibilities of magnetic input for tablets.

Many tablets come with some sort of triaxial magnetic sensor but as [Andrea] and [Ian]’s demo shows, they are only capable of passing along the aggregate vector of all magnetic forces. If one had multiple magnetic objects, the sensor is not able to provide much useful information.

Their solution is a mix of software and hardware. Each object is given a magnet that rotates at a different known speed. This creates complex sinusoidal magnetic fields that can be mathematically isolated with bandpass filters. This also gives them distance to each object. The team added an Arduino with a magnetometer for reasons unexplained, perhaps the ones built into tablets are not sufficient?

The demo video below shows off what is under the hood and some new input mechanics for simple games, sketching, and a logo turtle. Their hope is that this opens the door to all manner of tangible devices.

Check out their demo at Standford’s 9th annual “Tangible, Embedded, Embodied Interaction” this January 15-19, 2015.

Filed under: handhelds hacks, tablet pcs hacks

Fitting a sphere

Today I had to write a program to fit a sphere to a bunch of points that were supposedly near the surface of a sphere, but were noisy and sampled in a very biased way.  Since this is obviously not a new problem, I started out doing web research.  but I didn’t look for fitting a sphere, but for fitting a circle, since that is a simpler related problem.

I found a lot of papers, including several review papers, on how to fit a circle to a bunch of points.  The “obvious” method is to  do a least-squares fit to minimize the distance between the points and the circle, minimizing , where is the radius and is the center of the circle.  Unfortunately, that is a difficult problem to solve, and even numerical methods require a lot of iterations to get decent solutions.  What most people do is to change to a slightly different problem that optimizes a different fitness function.  For example, Kåsa’s method minimizes .

There is a very nice, but very formal, presentation of the methods in a paper by Vaughn Pratt from 1987: Direct Least-Squares Fitting of Algebraic Surfaces.  This paper introduced Pratt’s method, which was later slightly improved to make Taubin’s method. I did not read these original papers (other than skimming Pratt’s paper).  Kåsa’s paper (A curve fitting procedure and its error analysis. IEEE Trans. Inst. Meas. 25: 8–14) does not seem to be available on-line.  The IEEE digital library is missing the whole 1976 year.

I did find a recent paper that does careful error analysis of both the geometric approach and several of the algebraic approaches (including the most popular ones: Kåsa, Pratt, and Taubin):

Ali Al-Sharadqah and Nikolai Chernov
Error analysis for circle fitting algorithms
Electronic Journal of Statistics
Vol. 3 (2009) 886–911 ISSN: 1935-7524 DOI: 10.1214/09-EJS419

This paper shows that Taubin’s method is theoretically superior to Pratt’s which is theoretically superior to Kåsa’s (having less essential bias), and gives a very weak example showing it is also tru empirically.  More interestingly, it also gives a “hyperaccurate” algorithm that has less bias even than Taubin’s method.  I did not read the error analysis, but I did read the description of their Hyper algorithm and the implementations of it that Chernov has on his website.

Since I needed Python code, not Matlab code, and I needed spheres rather than circles, I spent a few hours today reimplementing Chernov’s Hyperfit algorithm.  I noticed that the basis suggested by Pratt for spheres, , was a simple modification of the one used in both Pratt’s paper and Chernov’s paper for circles, .  I decided to generalize to dimensions, and use the Numpy package in Python for all the matrix stuff.  I hope I got the generalization right!

From starting to look for papers until getting the code working was about 6 hours, but I had lunch in there as well, so this felt like pretty speedy development.  I’ve released the code with a Creative Commons Attribution-ShareAlike 3.0 Unported License, and would welcome corrections and improvments to it.

Of course, after all this buildup, you are probably wondering why I needed to fit a sphere to points—that is not a common problem for a bioinformatician to have.  Well, it is for the robotics club, of course.  They’ve been having a lot of trouble with the magnetometer calibration and heading code, so we decided to try doing an external calibration of the magnetometer, which has an enormous arbitrary 3D offset.  By waving the magnetometer around in different orientations (which means tumbling the ROV once the magnetometer is installed), we can sample the magnetic field in many orientations, though far from uniformly.  The center of  the sphere fitted to the readings gives us the 3D offset for the magnetometer.

My son and I tested it out with Python code and Arduino code that he had written to get the data from the magnetometer to the laptop, and the magnetometer readings do seem to be nicely centered around (0,0,0) after we do the correction.  We’re still having trouble using the accelerometer to get a tilt correction to give us clean compass headings, but that is a problem for tomorrow morning, I think.

Tagged: Arduino, circle fitting, magnetometer, NumPy, Python, sphere fitting

Sensor board for underwater ROV

Since I had bought the robotics club an I2C accelerometer and magnetometer, I decided to make a new PC board for them to mount the accelerometer, the magnetometer, and the pressure gauge on the same board.  I don’t have the SMD soldering skills to solder all the chips onto one board, and I already had breakout boards for the accelerometer and magnetometer from Sparkfun, so I decided just to put connectors for those breakout boards onto the back of the pressure sensor board.  (The back, because the pressure sensor on the front has to be stuck through a hole in the dry box and glued in place.

The new boards are tiny (1.05″ × 1.425″), so I decided to try BatchPCB (which has pricing by the square inch) rather than (which has fixed pricing per board, up to a fairly large size).  The price from BatchPCB was $10 per order plus $2.50/square inch plus $0.90 for shipping, so ordering 3 copies of the board (though I only needed one), cost me $22.12, substantially less than a single board from, which is $33 plus $17.30 shipping and handling per board (plus an extra $50 if your board has multiple boards on it).  The 4pcb price is lower if your board is bigger than about 15.76 square inches, so even my HexMotor boards (at 12.44 square inches) would be cheaper from BatchPCB.  If you get multiple boards from on a single panel and cut them apart yourself, the breakeven point is about 35.76 square inches for a single design (so three HexMotor boards from a single panel is cheaper than from BatchPCB). For multiple designs on a single panel, the deal is better: for 3 different designs, a total of 27.04 square inches would make the cheaper way to go.

If you want a copy of the board, you can order it from BatchPCB, or pick up the Eagle files from my web site and order copies from elsewhere.  I’ve put the HexMotor Eagle files on line also, but not put them on the BatchPCB site.  I should probably upload them there sometime.

Bottom line: BatchPCB is better for small numbers of tiny boards, but is better for larger boards and multiple designs.

The BatchPCB orders came back quite quickly (12 days from order to delivery by mail), though I had been worried because their design-rule check, which they say takes minutes had taken about 8 hours.  The problem was that each check takes a few minutes, but they had hundreds in the queue over the weekend, and it took a full day to clear the queue.

I had less trouble soldering the pressure gauge this time (this was my second attempt at soldering surface mount devices).  You can see in the pictures above that the results are much cleaner than in my first attempt.

The robotics club has tested the pressure sensor on the new board (using their own code on the Arduino) and it seems to work ok,  have drilled the hole in the dry box for the port, and glued the sensor board in place using superglue.  It seems to be waterproof (at least down to 1 foot—we’ve not tested in deep water yet).

Related articles

Tagged: accelerometer, Arduino, BatchPCB, magnetometer, pressure sensor, Printed circuit board, ROV, SparkFun Electronics

Magnetometer and accelerometer read simultaneously

In Learning to Use I2C and Magnetometer not fried, I talked about interfacing the MAG3110 magnetometer and MQA8452Q accelerometer to an Arduino.  For both, I’m using breakout boards from Sparkfun Electronics.

I  checked today that there are no problems when I connect both devices to the same I2C bus.

The first test was very simple: I put both the breakout boards into a breadboard and wired them together, then tried running each of the programs I’d written for the chips separately. Result: no problems—worked first time.

I then tried merging the programs (cleaning up any naming conflicts) so that both could be run from the same code.  After a few typo fixes, this also worked fine

I think I’m now ready to hand over the software to the students to use for their robot.

I still need to put the i2c.h, i2c.cpp, and accel_magnet code in some public place for others to use (perhaps on github? maybe on my web pages at work?) [UPDATE 2012-jan-31: I have put the libraries and the sample code for the accelerometer and magnetometer at]

One thing that is still missing is doing tilt correction for the compass heading.  Since the ROV is not expected to remain level (the accelerometer is intended to be used in a feedback loop to adjust the pitch, with anything from -90° to +90° being reasonable), getting a good compass heading requires rotating the magnetometer readings into the horizontal plane.  Only one of the students in the robotics club has had trigonometry or matrix math, so I’ll have to work with him to get him to figure out how to do the tilt correction. It may be simplest conceptually  to compute pitch and roll angles first, then rotate twice, rather than trying to do the whole tilt correction in one step (especially since the Arduino does not have matrix libraries).

Related articles

Tagged: accelerometer, Arduino, I²C, magnetometer, robotics, SparkFun, SparkFun Electronics

Magnetometer was not fried

MAG3110 breakout board by Sparkfun

In Learning to Use I2C, I talked about the difficulty I’d been having getting the MAG3110 breakout board from Sparkfun to work, and my fears that I had burned it out by running it overnight at 5v (instead of the rated 3v).  I suspected that my problem was really a software problem, but debugging the software when I was afraid that the hardware was fried seemed like an exercise in futility.

I bought another of the breakout boards from Sparkfun (they’re only $15), and soldered on a header yesterday.  The code failed in almost exactly the same way with the new (presumed good) part as with the old (presumed fried) part, so I was convinced that the problem was indeed in the software.

I spent half of yesterday and most of this morning carefully rewriting the library of I2C interface code.  I was starting with example code from Sparkfun for the MMA8452Q accelerometer, which I had generalized to handle other I2C devices.

The library worked fine with the accelerometer, so I thought it was ok, but it did not work with the magnetometer. I added a lot of error checking (making sure that the microprocessor was in the expected state after each I2C operation), and found that things were not working as expected. The extra error checking made it much easier to diagnose the problems. I had to re-read the I2C documentation in the ATMega328 datasheet several times, to make sure that I had all the details right (I didn’t, of course). The documentation in that data sheet is better than several of the tutorials I’ve seen on line, and is both thorough and comprehensible in describing the interface.

I did not implement all features of the I2C  interface—in fact, I have a rather minimal implementation that uses polling rather than interrupts and assumes that the Arduino will always be the bus master.  Those assumptions are fine for most Arduino projects, which just use the I2C bus for talking to a handful of peripherals, but sometime in the future I may need to make a more complete set of code that can handle multiple masters, the Arduino as a slave device, and interrupts rather than polling and waiting for operations to finish.

Because I was more interested in simplicity and robustness than speed, I rewrote the code so that transactions were finished (and appropriate status checked) before functions returned.  With these changes I found that the STOP condition was not happening, despite being requested.  All other operations on the bus are checked with the TWINT bit  of the TWCR register and the upper bits of the TWSR register, but determining that STOP has completed requires checking the TSWTO bit of the TWCR register. The code I had started from just checked the TWINT bit for the other operations, and had a fixed timeout that was too short—it did no checking at all on the STOP state, just adding a fixed delay.

Once I got the STOP timing cleaned up (and earlier, making sure to send NAK when reading the last byte), everything worked fine.  The accelerometer code  had probably worked ok because there were enough delays after stops that the stops completed, even though I had not checked to make sure.  With the fixed code, even the magnetometer that I thought I had fried seems to work ok.

The interface for the students in the Robotics Club is fairly simple (much simpler than the standard “Wire” library):

// Read one register
uint8_t i2cReadRegister(uint8_t i2c_7bit_address, uint8_t address);
// Read num_to_read registers starting at address
void i2cReadRegisters(uint8_t i2c_7bit_address, uint8_t address, uint8_t num_to_read, uint8_t * dest);

// Write one register
void i2cWriteRegister(uint8_t i2c_7bit_address, uint8_t address, uint8_t data);
// Write num_to_write registers, starting at address
void i2cWriteRegisters(uint8_t i2c_7bit_address, uint8_t address, uint8_t num_to_write, const uint8_t *data);

I suppose I should check that there are no problems when I connect both devices to the same I2C bus, before handing this over to the students to use for their robot.

I should also put the i2c.h and i2c.cpp in some public place for others to use (perhaps on github? maybe on my web pages at work?). It is really a shame that does not permit code-like files as pages.

Related articles

Tagged: accelerometer, Arduino, i2c, magnetometer, robotics, SparkFun, SparkFun Electronics

Learning to use I2C

For the Santa Cruz Robotics Club, I’ve bought three sensors for their underwater ROV: a magnetometer, an accelerometer, and a pressure sensor.

Originally, we were going to an ADXL335 accelerometer (with a breakout board by Adafruit Industries) and an MPXHZ6250A pressure sensor (no magnetometer), for which I designed a small PC board, but once the specs for this year’s mission came out, we saw that they wanted us to determine compass headings for a “sunken ship”, so it seemed a natural thing to add a magnetometer to the hardware.  After looking at what was available, I chose the MAG3110 breakout board from Sparkfun, because it provided a triple-axis magnetometer for only $15.

The MAG3110 is an I2C interface, which means we need only 2 wires to hook it up (and the wires can be shared with other I2C devices).  If we are going to all the trouble of figuring out an I2C interface, I figured we might as well use it for the accelerometer as well, so I got a MMA8452Q breakout board from Sparkfun also.

I decided to do a simple test program for the I2C parts before handing them over to the robotics club, so that they could be sure they had working parts.  It was a good thing I did, because I spent more than an entire day trying to get the parts to work.  I finally gave up on the “Wire” library from the Arduino website, and tried using the i2c.h file from Sparkfun (example code linked to from the accelerometer web page).  I got that working and rewrote the library as a proper .h and .cpp file, so that it could be installed as a normal Arduino library, adding some of the utility calls that had been buried in the MMA8452 demo code.

The MMA8452Q code was working fine, so I tried using the same i2c library for the MAG3110 magnetometer.

I had gotten MAG3110 working with the Wire library, but running at 5v (I’d not noticed that it was a 3.3v part—rather, I thought I’d checked that it was a 5v part, but I was wrong).  I’d left it powered at 5v all night, and I think I burned it out, as it was quite warm in the morning.  Today, I can read and write the registers of the MAG3110, but the xyz values are not coming out reasonable at all—I frequently get the same values (like 0xF9F9)and 0x1DF9), independent of the orientation. If I read all the registers, a lot of them come out as 0xF9 or 0x1D.  Even the WHO_AM_I register (which should be 0xC4) often comes out 0x1D.  I seem to get intermittent correct values for registers, but mostly bogus values.

I’ll feel stupid if I order another part and it turns out to be a software bug, but I’m pretty sure the chip is fried.  But I guess it is time to do another Sparkfun order. (I owe them some business, after calling them for the replacement photointerrupter.)

Incidentally, I tried finding a usable pressure sensor with an I2C interface, but it doesn’t look like anyone is making them except for barometric pressure ranges for dry gases.  I suppose Freescale will eventually come out with a full range of I2C pressure sensors, but my guess is that will be a long time coming, as the automotive and industrial applications have a pretty long product design cycle (unlike consumer electronics, which is driving the barometric pressure sensors).

Tagged: accelerometer, Adafruit Industries, Arduino, magnetometer, robotics, SparkFun, SparkFun Electronics