As most people know Honeywell recently discontinued production on the popular HMC5843 3-Axis Magnetometer. Honeywell replaced it with the HMC5883L which has a better resolution, larger full scale range, consumes less power, comes in a smaller package and most importantly...it's much CHEAPER in price! Needless to say I placed a backorder for the parts in December and was pleasantly surprised when they arrived yesterday. I pulled out the prototype board I had made and proceeded to mount all the components. I placed the populated board in my handy reflow oven and a few minutes later...VOILA....we had a breakout board.
I inspected the final board and didn't see any noticable bridging. I soldered on the header pins and proceeded to wire it to my Arduino. I loaded up my test sketch, which just reads the three Identification registers starting at address 0x0A, opened up Serial Monitor to see the values and...nothing. I looked over the sketch again to see if I missed something but everything looked OK. I recompiled it once more, uploaded the code again and still nothing! I then pulled the board out and went over it with a meter, once again, to verify nothing was shorting. I pulled out one of the other bare boards, compared it to my schematic and board files and everything looked right. I grabbed a higher powered magnifying glass and did a complete visual and still everything looked as it should. I then wired the device back up, verified I was using the correct logic level converters and pullup resistors and still it displayed nothing.
This time I hooked up the oscilloscope and looked at the I2C signals, thinking maybe it has an abnormally large bus capacitance and the default pull-up resistors just wouldn't cut it, but no, all the signals looked fine. At this point I started performing some lower level debugging, looking at returned values and register contents and found that the Wire library was giving me a Slave Not Acknowledging Device Address. Cool, I thought, this will be an easy fix, I probably just read the address wrong on the datasheet. I looked over the data sheet and it called out for a 7 bit address of 0x1E (8 bit 0x3C/0x3D)
which is exactly what I had in my sketch.
At this point I started going over my options and then I remembered the I2CScanner sketch over at Todbot.com. In a nutshell, it PINGS a list of device addresses and tells you which addresses get a reply. I uploaded the sketch and ran it and what do you know, it found the slave address at 0x1C (28 in decimal).
So at this point I'm thinking there is a typo in the datasheet and everyone else using it has surely run accross the same problem. I Googled around and was only able to find a couple of references to others using the device and each person was successfully using the address 0x1E, as per the datasheet.
I decided to continue on and see if anything else was diferent. I ran the first sketch again and the three address registers reported back 'H' '4' '3' which agrees with the datasheet. Consequently, I'm a bit surprised the 5883L would use the same ID as it's predecessor, one would think they would change the ID to H83. Before playing around with measurements I thought I would skim the datasheet and find out what some of the other power on Default register settings were. I wrote a sketch (HMC5883LRegisterScanner) that would automatically address each register (not using the pointer) and read back the contents and display it in Serial Monitor. I found that only Configuration Register B matched the datasheet's power on default settings. Configuration Register A (0x00), Mode Register (0x02) and Status Register (0x09) did not match the default settings.
I'm starting to wonder if the components I received are not in fact HMC5883L but something else. I looked on the top marking codes on the chips and there are two lines. The first line reads L883 which I'm guessing means HMC5883L and the second code is 2103 which is probably some type of date code. I've sent a email to the distributor to see if they have a contact at Honeywell I can discuss this with to get this issue resolved. I'll post and new info as it comes along.
Since, at the time, I had not received a reply from either Newark or Honeywell I decided to assemble another board to see if I had different results. This time when I wired up the board the I2C address was in fact 0x1E as per the datasheet. I posted the original problem I was having on the Arduino forum and user Robtillaart came up with an interesting hypothesis. Basically the difference between the two 7 bit addresses is the least significant bit which is what you would see when an IC has a separate address select pin. Unfortunately this IC does not have an external address select, but the chip itself contains a separate ASIC and magnetometer so there is the possibility of an internally wired address select pin that may have been damaged.
I ran the register scanner sketch that I used on the first board and, like the first board, the power on default register states do not match the datasheet. I decided to continue on with testing register read/writes to verify the unit was responding to commands. I was able to successfully access the Configuration, Mode, Status and Identification registers and make changes as such. Unfortunately the readings obtained from the X, Y and Z registers appeared to be either random and/or invalid. The values intermittently toggled between 0 and 255 and didn’t appear to be influenced by orientation or magnetic field presence. I repeated all the tests between the two boards and the results were almost identical with the exception of the I2C address.
I decided to, once again, consult the all knowing Google and see if anyone had similar problems. Searching around I found that there are two versions of the HMC5883, the HMC5883L and the HMC5883. Both ICs, while being the same package size, pin count and having the same register addresses seem to have different power on default register states. These register states more closely matched what I was seeing on my boards. The wiring configuration of the IC is also more closely related to its predecessor the HMC5843 in that it uses the VREN (Voltage Regulator Enable) pin which, on the HMC5883L, is not connected. At this point I thought I would try and wire up my board per the other datasheet thinking maybe I was shipped the wrong chips or they were somehow mislabeled.
While looking into how I should modify the board I just happened to receive an email from Honeywell tech support. The individual was unsure as to why the address was incorrect with my first chip but my guess is somehow it was damaged, possibly during the reflow process. The tech support rep also told me that the power on default register values in the datasheet were incorrect and what I was seeing are the correct values and will be changed in the next revision of the datasheet. He also stated that the top code markings of my chips did indicate that they were in fact HMC5883L ICs. With that mystery solved I still needed to find out why I was getting invalid data readings. I started reviewing application notes and looking at waveforms and noticed that the pulses on the SetP pin didn’t look like they were supposed to. Long story short it turns out the supposed 220nF capacitors I was using were actually mislabeled 220pF capacitors! This is a perfect example of why it’s important to have an LCR meter when using surface mount components. While reading through some application notes I noticed that it was common practice to use two 100nF capacitors in parallel instead of a single 220nF capacitor for the S/R capacitor. The reason being is that ESR seems to be the most critical aspect when it comes to the S/R capacitor so by paralleling two ceramic capacitors you can take advantage of even lower ESR properties. I posted a follow up email to tech support to see if there would be an increase in performance by paralleling both the S/R cap and or the reservoir cap. In the mean time I’m having more boards made up that have open parallel pads for both capacitors. Perhaps I’ll do some separate follow up testing with and without paralleled capacitors to see what impact there is on performance. In the mean time I can safely say the mystery has been solved!