Harbor Freight Caliper Data Format

Friday, July 5, 2013

Last week I started putting together the new firmware that will allow the MSP430 Launchpad version of the digital readout to read a mix of different scales and calipers. My last post discussed the needed hardware changes and touched on the high-level requirements. With the adapter board build and tested I was able to start investigating the data formats used by the small collection of calipers I was able to put together. Using my trusty Open Logic Sniffer I was able to identify two different protocols. BG Micro Digital Indicator used the 48 bit protocol described in the excellent article "Chinese Scales" by Shumatech. Surprising none of the other calipers used this protocol.

Instead of two 24-bit streams separated by a short interval, the calipers sent a single 24-bit stream split into six niblets of 4 bits each. Additionally the transfer rate was almost 20 times slower, compared to the 48-bit scale. Whereas the latter transferred the data at close to 80 KHz, the former used a leisurely rate of less than 4 KHz.

Harbor Freight calipers sent the data using six 4-bit niblets

After some research I came across an article at robotroom.com where David describes a similar protocol called BCD 7, that uses seven 4-bit niblets. Each of the first six niblets is used to represent a decimal digit from 0-9 and the last unit contains the metadata about the position. After some experimenting I was disappointed to discover that the protocol used by the calipers was different. Searching the internet didn’t turn up much useful information so I was left with no other options but to reverse engineer the protocol.

Side note: BCD stands for "Binary Coded Decimal". Using this scheme each decimal digit is represented using a 4-bit niblet. For example, decimal number 256 (or 2^8) in binary is 10000000. In BCD format it would be 0010, 0101, 0110 (2,5,6). Negative numbers are represented using as 2’s complement. This format is less compact than the straight binary representation but is easier to understand for humans (I guess as easy as a stream of ones and zeros can be to understand).

At that point the large portion of the firmware was functional so the controller could read the raw stream into a 32-bit integer and send it to the UART. All I had to do was place a breakpoint at the appropriate place and start moving the caliper around. Right away I noticed that everytime the screen is zeroed out the data stream reads all "0"s. This had to mean that unlike the rest of the scales the calipers transmit only the relative position. To investigate further I started writing down the position indicated on screen and the raw stream coming from the caliper into a table similar to the one shown below.

Output Stream Reading Units  
000000000000000000000000 0 mm
001001100000000000000000 1.0 mm
111100100000000000000001 1.0 mm
010000000000000000000000 0.02 mm
100000000000000000000001 0.0005inch
101111000000000000000000 0.2 mm
000010000000000000000001 .008 inch
010000000000000000001000 -.02 mm
010000000000000000001001 -.001 inch
001000000000000000000001 0.002 in

Table 1: Raw data output from a caliper

A careful look at the results show a some clear patterns:

  • The last bit of the stream indicates the "inch" mode when it's set and "mm" when it's not.
  • The 21-st bit indicates the negative number. In contrast the rest of the scales that use the "complement of two" representation.
  • The calipers appear to be sending the least significant bit first, since small readout values change the first bits of the stream.
Armed with these discoveries I decided to take a closer look at the bits, first in "mm" and then in "inch" mode. The results are shown in the table below.

Binary Value Decimal Reading Units  
0000000000000000000000000 0 mm
000000000000000001100100100 1.0 mm
00000000000000000000101010 0.1 mm
0000000000000000000000011 0.01 mm
0000000000000000000000102 0.02 mm
0001000000000000000000102 -0.02 mm
1000000000000000000001004 0.002 in
1000000000000000000010008 0.004 in
1000000000000111110100002000 1.000 in
1000000000000111110100012001 1.0005 in
1000000000001111101000004000 2.000 in
1001000000001111101000004000 -2.000 in

Table 2: "Normalized" data

The data suggests that in "mm" mode the position is sent in 100s of a millimeter using straight binary encoding for both positive and negative numbers. In "inch" mode the caliper uses 2000 ticks per inch (i.e. the position is reported in 1/2 thousandths). Based on these finding I was able to start working on the firmware design, which will be covered in the next post.

Side note:I wasn’t able to determine if the 22nd and 23rd bits have any meaning. Additionally there is no evidence that all of the first 20 bits are used. Using 16 bit the caliper can measure to a bit over 65 cm or 32 inches. For the DRO it’s irrelevant since I’m using 32-bit signed integers (in order to accommodate the 24-bit scales); otherwise a 16 bit integer should be enough for most situations.

8 comments :

  1. Hi Yuri. Nice, clear article. I see some ternary has crept into the third row of Table 2 (a binary value ending in 2010!).

    ReplyDelete
    Replies
    1. Oops, messed it up while editing the HTML; it's fixed now.
      Thanks for letting me know.

      Delete
  2. yuriy,
    Would you mind having a look at this,I built your first revision of the android DRO, but am having issues with the scales reading correctly as shown in the video. I also just got a ti msp430 just haven't switched things over yet. If you have any ideas on what going on with my scales please let me know I'd greatly appreciate it.
    https://plus.google.com/photos/105206655918179724860/albums/5897662396434192241?authkey=CLqjtIKy8dulcQ
    chris.hathaway1313@gmail.com

    ReplyDelete
    Replies
    1. Sent you an email a minute ago...
      Thank you

      Delete
  3. do you have the full instructions for the arduino version. . i cant seem to find them anymore .. joerooney@online.ie

    ReplyDelete
  4. HiYuriy
    Can you direct me to the arduino code to just read the Chinese digital scales. This is my beginnings into understanding both the arduino codes and the Protocol used by the digital calipers.
    Thx in advance

    ReplyDelete
  5. Yuri, I have been trying to find an output cable for Harbor Freight calipers to PC that will read into Excel or Filemaker Pro for a friend. I use Mitutoyos but bought them in the 1980s when they were way less expensive than they are now and have always been able to send data to my laptop. Do you or any of your readers make this like this for sale?

    ReplyDelete
  6. Hi I have check several caliper, the 7bcd protocol is for the cheaper caliper, the board on caliper generaly has no crystal.

    ReplyDelete

Except where otherwise noted, this work is licensed under
Creative Commons Attribution-ShareAlike 3.0 Unported License.
Creative Commons License