# Thread: SiLabs F350D Compass Protocol

1. ## SiLabs F350D Compass Protocol

About a year and change ago, I purchased Silicon Labs F350D reference board Compass.

Alas, they're rather unforthcoming with the protocol. I finally spent all night [sigh] reverse engineering the protocol. I'm not 100% on everything, but I've got enough to be useful.

57.6kbit/N/8/1

Send it 0x11

9 bytes of data.

2 bytes: Degrees (Hex)
1 bytes: .Decimal of Degrees (Hex)
2 bytes: Temperature (Note 1)
1 bytes: X-Inclination (Note 2)
1 bytes: Y-Inclination (Note 2)
1 bytes: A status message? Still haven't decoded
1 bytes: A checksum of some type. Still haven't decoded it.

Ok - here's where it gets funky.

Note 1 - Temp.:
Let's take an example of my data The two bytes for the temp are 86 2D. We know it's 81.3 degrees. But that's 34,349! This took me forever to figure out...

Let's look at it in binary: 1000 0110 0010 1101
The first bit of the first byte is deg F/deg C (0 = C, 1 = F)
The first bit of the second byte is the sign (0 = +, 1 = -)

So let's re-write it now: 000 0110 010 1101 = 14 bits for temp. 1100101101 = 813d 813 / 10 = 81.3. Woot! All temps are multiplied by ten to lose the decimal.

Ok, Note 2 is similarly funky:

Note 2:

Inclination X/Y

Ok, in the example I'll use below, my inclination bytes were 0d 84.

In binary:

0000 1101
1000 0100

First bit is the sign in each. 0 = +, 1 = -
7 bits from each for the inclination.
X = 000 1101 = 1101 = +13 degrees
Y = First bit is signed! 1 = -
Y= 000 0100 = 100b = 04 = -4 degrees

Now let's just run through an actual example I got back:

01 34 02 86 2D 0D 84 1F EA

01 34 = 308 degrees
02 = 2
----------
308.02 degrees

86 2D = 1000 0110 0010 1101 = Fahrenheit 000 0110 0010 110 1101 = Fahrenheit 000 0110 +sign 010 1101 = 1100101101b [+Fahrenheit] = 813 / 10 = +81.3 deg F

0D = 0000 1101 = + 1101b = +13 degrees X-inclination
84 = 1000 0100 = - 0100b = -04 degrees Y-inclination

Some byte I don't understand - probably a status
Some checksum/crc byte I'm still working on.

whew!

What kind of idiot company puts out a reference board without available documentation on the protocol?!!? [At least that I could find]

How many other people bought them here?

2. ## Re: SiLabs F350D Compass Protocol

Good grief.. that makes my head hurt..Good analysis by the way..
Gary

3. Abacus
Join Date
Sep 2009
Posts
3
Rep Power
0

## Re: SiLabs F350D Compass Protocol

I'm sorry to hear that you had difficulty obtaining information about the protocol for our F350D Compass Board. This product was intended more as a demonstrator vehicle than as a reference board so, unfortunately, the documentation is a little thin. I am not sure if you found the tools we have on our website to support this board:

https://www.silabs.com/products/mcu/...CompassRD.aspx

If you go to this address, there is a link a little way down the page called "Compass demo software". Click on that and you can download a zip file that contains the documentation and source code for this board. When you choose to install the files, they will be copied to your hard drive. The path to the source code then will be:

C:\Silabs\MCU\Digital_Compass_RD\1.Firmware\compas s_uart.c

You should be able to find what you need in the source code.

Please let me know if you have any trouble installing the files or if you need any other information or support. I'll be glad to help you the best I can!

John Pavelka
Silicon Labs
Engineering

4. ## Re: SiLabs F350D Compass Protocol

Second - wow. What do you know! The source is right there. I checked a couple directories in the installation and decided that there wasn't source code - I didn't expect to find it where it is. My apologies - I stand corrected.

Looks like I did a pretty good job on the reverse engineering though. I now see how the checksumming works, and I'll update my post with that. The status code also becomes apparent - and I was correct in how it was formed. So that's at least a bit offsetting for the major faux pas, right?

Thanks again for pointing out my error. That makes it a bunch simpler.

As an aside - this is an excellent pre-built device for roboticists. With a rough inclinometer, a pretty darned good 3D compass, and even a "freebie" temperature sensor, it's worth every penny and then some! Thanks for making it available in sample quantity.

5. Abacus
Join Date
Sep 2009
Posts
3
Rep Power
0

## Re: SiLabs F350D Compass Protocol

No problem -- I'm glad to hear that information was helpful for you. We are always excited to see the creative ways people use our products and glad to hear that the compass board is working well for you. Please let me know if you need anything else in the future. We will be glad to help you out.

John Pavelka
Silicon Labs
Engineering

6. ## Re: SiLabs F350D Compass Protocol

Now that you mention it...

I haven't studied the datasheet on your CP2101, but do you think the impedance is high enough that I could grab the TTL RX/TX from the MCU without lifting the TX/RX legs on the CP2101? (That way I could leave the USB intact for PC interface if needed later, but still interface the board to other MCU's for post-processing and acquisition) I don't see the TTL serial brought out to the debug header [P04/P05], but it looks like there are enough NC pins on the debug header that it could just be greenwired (pins 8 & 10 from Rev 0.1 schematic).

Note: At own risk, not seeking endorsement, not my first rodeo, etc - just looking for an opinion.

Thanks again!

7. Abacus
Join Date
Sep 2009
Posts
3
Rep Power
0

## Re: SiLabs F350D Compass Protocol

I checked with our applications team about your question. They told me that the output drivers on the UART transmitter pins for both the CP2101 and the F350 are around 35 ohms, so they are difficult to overdrive with another output. Also, overdriving can damage the pin.

The "unused" pins on the debug header probably should not be used. They may be connected to GND, +3.3V, or USB VBUS inside the USB serial adapter. They get labelled as no-connects on our datasheet, but that is just to indicate that the customer should not connect them to anything. They may still be "active" and connecting to them could trigger a response from other circuits on the chip.

I hope that helps. Please do let me know if you need anything else.

Thanks again.....John

John Pavelka
Silicon Labs
Engineering

There are currently 1 users browsing this thread. (0 members and 1 guests)

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•