This is a very simple breakout board for the popular HMC6352. Remember the KISS mantra? We really enjoy the simplicity and ease of use with the HMC6352. If you need simple, clean, degree resolution compass heading, this is the way to go.
Supply current : 1mA @ 3V
Documents:
This skill defines how difficult the soldering is on a particular product. It might be a couple simple solder joints, or require special reflow tools.
Skill Level: Noob - Some basic soldering is required, but it is limited to a just a few pins, basic through-hole soldering, and couple (if any) polarized components. A basic soldering iron is all you should need.
See all skill levels
If a board needs code or communicates somehow, you're going to need to know how to program or interface with it. The programming skill is all about communication and code.
Skill Level: Competent - The toolchain for programming is a bit more complex and will examples may not be explicitly provided for you. You will be required to have a fundamental knowledge of programming and be required to provide your own code. You may need to modify existing libraries or code to work with your specific hardware. Sensor and hardware interfaces will be SPI or I2C.
See all skill levels
If it requires power, you need to know how much, what all the pins do, and how to hook it up. You may need to reference datasheets, schematics, and know the ins and outs of electronics.
Skill Level: Noob - You don't need to reference a datasheet, but you will need to know basic power requirements.
See all skill levels
We welcome your comments and suggestions below. However, if you are looking for solutions to technical questions please see our Technical Assistance page.
No reviews yet.
I purchased two of these and have them running on two separate Mega 2560s each powered by usb. I am running the example basic sketch provided by Sparkfun on both. They each return heading values that are different when oriented in the same direction. They can be off as much as 20 degrees off depending on the orientation. It is essential for my project that they be in sync. Any suggestions on how to correct?
Im sorry. On the above. I purchased the HMC6343 and will post this on that page
This is an awesome chip. Works out of the box on the arduino! See great example: -sparkfun-compass-and-arduino
@SpikeUK -- the text appears to be correct -- the datasheet says that the PLCC itself is 6.5mm on a side. Also the headers are almost always on 2.54mm (0.1") centers, and that would also sync with the text and not the picture. Whooda thought...
Unfortnately the price of the board is twice the cost of the chip from Digikey (1@$30, 25@$20). For $30+risk_of_failure it looks interesting, but $60 is sadly a stretch.
Looks like fun though.
Hi! I want to use the HMC6352 for a project with Arduino Micro. Previously I tested with Arduino UNO and it worked perfectly. But for some reason it is not compatible with the Micro. Does someone know why? Thanks!
The Micro does have the I2C pins in a different location (D2,D3 instead of A4,A5). Make sure you are using the correct pins. If you are still having problems email techsupport@sparkfun.com
Hi, have one problem with this board, please need help, use this sensor with a arduino UNO y work very good, but use a PIC 877, or 4550 o 30F and don't work. I don't know why.
I come from Vietnam, how much when I order from Vietnam
The price is the same no matter where you order from (you can change the currency displayed though in the upper right hand corner of the page). As for shipping that depends on the method you choose. Add the item(s) to your cart and hit checkout, you should see a list of all available shipping options and their prices.
If I am using this near a metal sided building how far from the building to I need to be so that the building will not influence the accuracy?
I've a little Arduino library for hmc6352
Hi, the datasheet is for people that does not know how I2C works! If you have a GOOD i2c periferal, you know that when you WRITE, address is shifted left and 0 is placed 2^0 and if READ then 2^1 = 1. So this would cause a huge mess if you know how i2c is implemented and do not pay attention to this detail.... So the Address for the device is not 42 or 43 IT IS 0x21. Then write or read will shift left the command bit....
Og course, if you use libs already designed.. the work has been done already...
Wired this up okay (to Mega, using pins 20, 21 and 3.3V). Although I read about user calibration (also mentioned in the video) in the data sheet, and in some threads I even see mention of auto-calibration I see no explicit instructions here or on the Bildr tutorial. Simple, clean - but only if you know how to calibrate it?
I've got one of these devices here and when I query EEPROM address 0 to verify the slave address I get either 05 hex or FF hex (verified with a protocol logic analyzer). I fear the device is hosed but is there any way to perform a factory reset on this thing?
I could use some help. I've got this chip plugged into an Arduino and was happily receiving values, but recently my program stopped working. The compass constantly returns values in the range of 1900-1700. I've gone back to the example program specified here with no change in the values it's returning. Is there any ideas as to what's happened.
Note this is powered directly off USB so power shouldn't be an issue.
Hi,
I've been buying these little compasses, and have begun noticing something when testing them. For the tests I have mounted them to a board, they are held in place with foam tape, and are interfaced with an arduino, which records their time and direction every 4 seconds. I rotate them 90 degrees every 4 seconds, and record their readings. For some of the modules i seem to be seeing a spreading of readings. Most of the readings clump together, however there seems to be a lag in measurement for some of the modules. Anything after the first 90 degree rotation produces a compounded error where they seem to lag by a few degrees each measurement until they reach 360, (where they measure about 270 degrees) however the next rotation to 90 degrees is fairly accurate, and the spreading then occurs for subsequent rotations. Does anyone have any ideas as to what may be causing this? I want to investigate this issue, but I have no idea where to begin looking.
I have two of these and both do this (after calibration, on a flat surface, no external disturbances): I do a measurement in direction X: compass indicates 126 degrees After that I do a measurement 6 meters further in the same direction: compass indicates 119 degrees.
WHY??? Does anyone know why there's a difference of 7 degrees in a distance of 6 meters?
are you positive it isn't rotating 7 degrees in that distance of 6m? 7 degrees is a very small amount, the slightest vibration could cause a change of 7 degrees
I'm planning to mount two HMC6352's on my Boe Bot, one on the fixed part and one on the steerable part. They will both be connected to the same I2C bus. Should I remove the pull-up resistors from one of them?
You're correct that generally you want only one set of pullup resistors per bus. In this case, because the pullup resistors are 10K, you could leave both sets in and the bus would still work with the resulting 5K resistance, but don't go much lower than that (4.7K is typical for low-speed I2C use). Don't forget to change one of the HMC's I2C addresses so you can talk to them separately on the same bus (see the datasheet). Good luck!
Thanks. Mike. I was about to mount it on the vehicle and didn't want to get in on wrong. Thought maybe the arrow had to point forward or something. :)
How do I make use of the "N" and arrow printed on the board ?
That's 0 degrees on the chip. When the arrow is aligned with North, the output will be 0 degrees. When the arrow is pointed East, the output will be 90 degrees, etc.
Does this work when in tilt?
This part does not have an integrated accelerometer (to determine "down"), so it needs to be kept flat, or you should use an separate accelerometer to eliminate the error.
I recently purchased and received the HMC6352 breakout board module from Sparkfun. I created a library of routines to access and control the HMC6352 for my CCS C compiler and PIC18LF2620 running at 19.6608MHz at 3.3VDC.
In monitoring the activity on the I2C bus showing interactions from the PIC to/from the HMC6352 module, my logic/protocol analyzer shows all writes to the device to be correct and acknowledged by the module but all read accesses from the device respond with 0xff. The read command and data are correctly "ack'd", though, so the addressing to the device appears to be correct. I've tried to send the "wake" command to the device (which was correctly "ack'd") and followed it with a read eeprom address 0 (the default I2C address). The address responded with 0xff. I've tried to send a different mode command (to RAM and to EEPROM) but subsequent reads of the RAM mode register (0x74) always show 0xff. ALL read requests from the device respond with 0xff. I've tried running at 5.0VDC but get the same responses.
Has anyone else run into this problem or know if there's some other initialization that needs to be done to the device?
Thanks.
Finally got mine working pretty well. I also tried reading EEPROM location 0x00 to get the slave address, known to be 0x42 and initially got 0xff, but I guess a lot of things could give you that. One thing to remember if you write parameters and then want to read, you must first do a Start with R/W bit clear. Follow the i2c address & R/W bit with your parameter(s). Then do a Stop, then another Start, this time with R/W bit set and do as many reads as the protocol calls for. (Two, in the case of the 'A' command, which it the typical way to read a heading.)
I'm using an ATtiny4313. It doesn't have a TWI (I2C) module, so I'm using bit-banging code written by Peter Fluery and tweaked a tiny bit for my MCU. The Fluery code is in assembler and designed to assemble in-line with a GCC 'C' project.
Once I got it going I had a heck of a time with it being wildly inaccurate and not repeatable. Finally moved my test set-up outside on a wooden table with a wooden lazy susan on top, to allow rotation. I used a level to keep the table and lazy susan reasonably level. I'm finally getting where I see what I think is decent accuracy and repeatability. At least at the four points of the compass, I'm seeing the same reading at each rotation to the same marked point.
I think the need to be level is a pretty big deal (up to 2 degrees error for each 1 degree of tilt per the data sheet). And steel in the area is too. I'll have to find how how close I can be. I'd like to put this thing on the aluminum boom of my ham beam antenna and let it report the heading. But the tower itself is steel and so may have an effect.
Back to code - be sure to put in delays >= the times that the data sheet says it takes to do certain operations. I also added a routine to make sure the SCL line is high before I send a request. Per I2C standards, a slave can pull it low to force the master to wait until it's ready.
Nick
Hi,
When you read the EEPROM, you do: START, Send Address, Send 'r', Send #00, STOP; then to read, do you send a 43? or read the bus?, ex. START, Send 43, Set-Rx ,Read Bus, STOP? I just don't understand this part. Thanks.
Dann
It's possible to set the "North" to a different position? Thanks
I loved this board until now. It reads only 180.1 to 180.9. Anyone else have this problem? Bizzare because it was working fine. Calibration doesn't work. Half of the pulse in the oscope looks a bit jittery so I'm not sure if this thing is fried. Any suggestions?
I'm getting something a bit similar-- only reading -0.10 degrees--no change at all....I think it broke....but I'm not really sure
From the datasheet: "Exposure of the HMC6352 to magnetic fields above 20 gauss (disturbing field threshold) leads to possible measurement inaccuracy or “stuck” sensor readings until the set/reset function is performed."
Have you tried performing a calibration?
yes i did--turns out the board had a short underneath the chip. I sent it back to sparkfun and got a refund for another one. Are you having problems with the board or has yours worked mostly fine?
I also tried the HMC6352 BOB with a SNAP RF100 (3.3v) micro and had I2C read problems. I then used it fine with a BasicMicro Nano 18 (5.0v) micro and never determined the problem. I just tried the HMC6352 BOB with a Parallax Propeller QuickStart board (3.3v) and it failed. So I connected the Propeller (3.3v) to the HMC6352 BOB (5.0v) via a BOB-08745 Level Converter using the two Tx bi-directional interfaces for SDA and SCL and it worked fine (compass must be on a jumper away from the breadboard). I retried the SNAP RF100 (3.3v) micro and got it to work with and without the level converter by increasing the i2cRead function's 'retries' argument to 10. I did not characterize the exact number of retries that will work. I went back to the Propeller, using a logic analyzer this time, and determined that the HMC6352 object that I was using put the 6ms delay in the wrong location (between sending the $43 Read and reading the 2 byte heading on the I2C bus). The Propeller worked fine with 3.3v and no level converter after I moved the delay. Go figure :) I've revised this comment several times and this is my last since I now have successfully used the HMC6352 with a BasicMicro Nano18 (5.0v), Synapse SNAP RF100 (3.3v) and Parallax Propeller QuickStart (3.3v w/o level converter and 5.0V w/level converter).
how do i interface this with lpc 1769 using lpc xpresso and get the display on oled like : http://www.embeddedartists.com/projects/lpcxpresso-hmc6352.php
I have a HMC6352 compass. It is connected to PIC18F4520. I get the compass readings and send them to MATLAB through Xbee wireless modules. Frequently, the compass stops working and I2C code of PIC is suspended suddenly and consequencly an error is generated in MATLAB. I caliberated the compass repeatedly. the compass readings are: 272.7 290.8 278.8 276.1 277.6 282.7 284.1 276.4 285.6 270.6 and so on, It looks noisy and unstable although I mde a caliberation for the compass Does anybody have suggestion to overcome this stunning and suspension of the compass ???
I didn't check all the comments below, but I was wondering if you guys have been using the HMC6352 library http://mbed.org/users/aberk/libraries/HMC6352/lijrmf/docs/classHMC6352.html#_details
I was trying to interface this module with a beagleboard via expansion(1.8v-3.3v level) board. The problem is when I write 'A' - 0x41 to the module I can't get an ACK back. Then the reading result are all 0x00. Does anyone knows how to interface this tiny module with a Linux based system?
The compass module works well with Arduino. The Beagleboard works well with I2C EEprom and temperature sensor.
Thanks!
Updating: I just figured out what's happening by analyse the I2C bus.
This HMC6352 will only work with 100KHz I2C clock, which was mentioned in the datasheet too. Beagleboard running a 400KHz I2C on i2c2 by default, the kernel has to be re-compiled to modify the speed.
The believe the MBED example has an error for the I2C pins. The source code shows p9 and p10 for SDA and SCL, while the table shows 28 and 27 for SDA and SCL. I suppose either pair can be used, for both pairs are I2C. donde
Before I buy this, what's the difference between this one and the less than half this price costing HMC5883L? Hte latter is actually in stock...
Any idea when this will be available again?
I've been playing with this chip all day and have read the data and run the calibration routine but the chip doesn't seem to give linear output and is off by as much as 20 degrees at some points on the compass. At 357 degrees the readout goes all over the place. Does anyone have this chip working on a PICAXE ?
I'm having the same symptoms working with a UBW32 (PIC32MX 4xx series) and I've not a clue what to do about it. Anyone have any thoughts?
Mine is mostly accurate but when it gets near other electronics, the reading can sometimes be off. Most likely there is a disturbance field nearby causing the compass to give somewhat inaccurate readings.
Depending on how you are using it, checks can be added in the software to at the very least notice if the reading seems to be jumping around.
This thing is plug and play
what else can I say?
Used the Bildr Tutorial
Can this be used to tell when the device is horizontal?
not really
Hi everyone, I'm trying to use one of these as part of my final year project at uni but I'm having some serious trouble getting it to behave properly. When I try to read the heading, the first byte only varies between 0 and D and the second byte is always FF. These values do not change in any meaningful way when I rotate the device to face in different directions.
As far as I can tell, I'm following the spec. sheet but so far, no joy. My signal sequence is:
Start, Address (42), Command (41), Stop, wait 6000us, Start, Address (43), read byte 1, read byte 2, Stop
Can anyone tell if I'm doing anything particularly stupid?
Thanks,
Andy
I just read the chip docs, the address 42hex is for reading data and address 43 hex is for writting data. The data is in binary.
The pin descriptions on the data sheet seem to suggest that it supports SPI as well as I2C, but there isn't any other reference to it anywhere. Can anyone clarify this?
Thanks
Can anyone tell when will this product be in stock again?
Hi I am really new to microcontroller programming. Could anyone give me some tips on where to start to get a microcontroller to read a sensor such as this magnetometer? After hooking up the pins correctly, what would I need to do in terms of coding? My microcontroller is this:
http://www.sparkfun.com/products/9980
and I am using MPLAB C Compiler.
Thanks
So, I am interfacing this with a SNAP RF100 board. It's a 3.3v device. I bought four of these modules, and two of them failed to respond with an ACK when I did an I2C write to them. The third responds with an ACK between each byte of a write, but when I do a read, it sends the address with the read bit set, and the compass never starts clocking out data. If I try to do another write everything is hung until I reboot the compass board.
It feels like the compass isn't able to pulse the SDA line either well enough or quickly enough for my micro not to give up on it.
I note that many people seem to have had trouble with the presence / value of the pullups on this board. I've turned off the on-micro pullups (and tried them on as well), but I'm nervous about desoldering things on this board given that I've already had trouble getting two of them to respond at all.
Any ideas on what I could try next?
Thanks!
Tim
6/29/2012, I did not have the missing ACK problem TimWhite experienced but my SNAP RF100 failed to respond to the i2cRead called on the HMC6352. After incorrectly assuming it might be SDA/SCL levels, I finally fixed my problem by increasing the i2cRead function's 'retries' argument to 10. I did not characterize the exact number of retries that will work, I just tried 1 and 4 which both failed, then 20 which worked and then 10 which worked. FYI, I do a 10ms delay between the i2cWrite to the HMC6352 to request it read the heading and the i2cRead to read the HMC6352's response. The HMC6352 datasheet says it takes 6ms to get the heading but I just used a state machine with a 10ms hook to synchronize the i2cWrite and i2cRead.
This compass is works really well, I was attemping to put other devices on the two wire bus and it was not working. Removed the pullups with a soldering iron and a keen eye. Now I can have a compass and a i2c eeprom. :)
Hi! I think I finally get my compass to work with a PIC18F4550. But the meassure I'm getting changes by even 3 degrees up and down when leaving the chip still. is this normal? or should I check the calibration? I really need a better performance. thanks a lot
Can you please help in getting the compass work with PIC18F
Thank you
I think my problem was something to do with not having a common ground, as I have everything running off of one power source now and it works. The PC was acting as a common ground through the two data links, I believe. From what I can tell the compass has to share a common ground with the board it is sending data to.
I have an odd problem. Someone who's a bit smarter than me can probably figure this out pretty quickly.
I initially began testing this compass on an Arduino clone (Freeduino MaxSerial). I used the code here: http://recombine.net/blog/article/49/hmc6352-sparkfun-compass-and-arduino and it worked fine. I then incorporated it into my ArduPilot code and I was still using the Arduino board for 3.3 power since I didn't have a circuit yet, though data now comes through the ArduPilot. Now, I've found, the compass does not send out data unless the Arduino (Not the ArduPilot!) is connected to the PC via Serial, even though data is being read by the ArduPilot board. The second the serial cable is removed, it stops sending data. The second the serial cable is added again, it sends data again. Alternate sources of power do not work, it only works with the 3.3v on the Arduino attached to a PC.
Can anyone tell me what's going on? What about whether or not the Arduino is attached to a PC affect the 3.3v power and the compass's ability to send data?
Proposal for next revision of this board:
Please make pads for the CA1, CA2, CB1 and CB2 pins available on the board!
According to the data sheet, resistors can be connected between CA1 and CA2 pins and CB1 and CB2 pins to reduce the sensitivity of the device.
I plan to use this device as a weather-sealed rotary encoder (have a permanent magnet on an axle that rotates above the chip). I think I am having issues with the magnetic field from the magnet being too strong for the device, and adding resistors between the above pins might have been able to solve my problems.
How did it turn out ERL? Did you ever get it to work?
I LOVE THIS COMPASS. :)
Hey, guess what? --Sparkfun was nice enough to add the pull-ups on the board. --This I think, is the "Picaxe problem". I removed the 4.7k's from my board and we are good to go. Now that I have used it, it seems to be very stable, simple and good.
Has anyone solved the Picaxe problem with the first byte coming in as a 255 and the second byte either not changing or going between 0 and about 80 or so? I have found this question in a lot of forums --Have not found an answer. BTW, I am getting 255, 66 as my two byte values and when you put them back into a word value you get 17151. These values do not change each time I ask for them.
Great part! works quite well with decent sensitivity & accuracy. Obviously affected by tilt, but still useable.
Btw, the price on this part has gone down...bought mine for $65 about a year ago!
I dont want to buy the HMC6343 Tilt Compensated, the price is very high; how is the HMC6352 affected by tilt?
blah.. i'm using the supplied code with a mega.
vcc 5v, sda to 20, scl to 21.
getting:
Current heading: 0.00 degrees
Current heading: 0.00 degrees
Current heading: 0.00 degrees
Current heading: 0.00 degrees
etc..
help?
Well, pin 20 is SDA and pin 21 is SCL, Vcc should be between 2.7V and 5V. If the wiring example sketch doesn't work:
http://wiring.org.co/learning/libraries/hmc6352sparkfun.html
Then there could indeed be some manufacturing defect with your board.
If you would like, contact techsupport@sparkfun.com. We can test the item for you.
I've been looking everywhere but can't find a USB Compass on the market. How difficult would it be to connect this module to a Windows PC via USB?
...Could I just wire this to a USB-I2C interface and connect via serial port?
...Does SparkFun sell the parts I need to make this project happen?
Yes and Yes. I'm not sure if we have a device that will directly convert I2C to a USB, but you can use a microcontroller.
So according to the description, I'm supposed to be able to use this in a 5v system, and so I did. got some nice heading readings for about 30 seconds, then "poof", puff of smoke and gone it is. quadruple checked all wiring, and everything is good, 5v is regulated and reads 4.94v on my meter. anyone have a clue why it could blow up like that? should I use 3.3v instead?
do i need a level converter when connecting it to pic16f877A microcontroller which works on 5v??
and are there already pull-up resistors on the break out board??
No, yes.
Could i use this directly with the Arduino Duemilanove, it says it uses 3 V so thats bad i guess.
But Azayles mentions that i could run on 5 V is that true?
Would it be possible for you to use the 3V3 line coming off the Duemilanove?
5V works fine.
"2.7 to 5.2V supply range"
It looks to me as if this breakout already has two pullups installed already. I'm using this with the Lego NXT which needs 82K pullups, I hope I won't have to desolder the two resistors installed. Can anyone verify about the pullups?
Well I finally just used my head (and a multimeter) and found out that yeah, it looks like there might be pull-ups installed. Would any of the SparkFun people be willing to upload the schematic/Eagle file just so that I could make sure? Because I'd really rather not desolder them just to find out that they weren't pull-ups. Thanks.
Sorry for the confusion, those are pull-ups on the I2C lines. Schematic's up now.
Thank you very much! I just love open source! Go SparkFun!
Is this just the board, or the board and the module?! kinda confused.
Question: anyone know if this REQUIRES 3V on the SDA and SCL lines? the datasheet is terribly ambiguous.
I've got it working on a Parallax BS2 chip with 5V logic. Think it uses Vcc as reference so it's compatible with 3.3V and 5V.
the source code by baragans,is that for PIC?
Excellent little board-- super-simple interface & very low jitter.
Is there a problem with the images on this page? The text suggests that this PEC is 15mm by 15mm. Whereas two of the three images show it as being about twice that size.
I bought one recently and can confirm the PCB is 15mm x 15mm.
Also the solder mask is red now, not green :P