Home     Contact     Projects     Experiments     Circuits     Theory     BLOG     PIC Tutorials     Time for Science     RSS     Terms of services     Privacy policy  
 Home      Projects     Experiments     Circuits     Theory     BLOG     PIC Tutorials     Time for Science   

17 December 2009
Author: Giorgos Lazaridis
Digital Caliper Protocol

The Chinese-BCD protocol

The first experiment is with a Chinese caliper that transmits data using a BCD protocol. This protocol is somehow similar to the Mitutoyo Digimatic protocol, because they both send data in BCD format.

The Chop-Job

The communication port is behind a small plastic cover

The communication port of this caliper has 4 pins

I soldered 4 wires to the communication port pins

At first, i need to have easy access to the pins of the port so that i can connect the oscilloscope. The communication port of this caliper is covered with a small plastic cover at the back side, and it has 4 pins. The room was very tight. I tried to solder some thin wires without dremel work, but that was practically impossible. So, i had to remove a small piece of plastic above the 4 pins. The soldering process was now easier. I soldered the 4x0.25mm2 color wires and now i have full access to the communication port!

Identifying the pins

The very first visualization of the caliper's protocol

I found other websites with the pin-out of some calipers. Unfortunately, not all calipers have the same pin-outs. Identifying my calipers' pins though was not a hard task. Using the try-and-error method, i put the oscilloscope probe to the wires in pairs. The most-left and most-right pins gave me a straight line. Obviously, these pins are the + and -. Then, i put the ground of the oscilloscope to the negative wire, and i connected two channels to the other two remaining wires. It was not difficult to get a steady clear signal to the screen. While looking to the oscilloscope screen, i was slowly changing the caliper measurement. Then i saw that channel 2 (green) was all the time the same, but channel 1 (yellow) was changing pulses. So, channel 2 is the CLOCK of the communication protocol, and channel 1 is the DATA!

Here is the actual pin-out:

The wires that i have connect are:
  • Positive: BROWN wire
  • Clock: RED wire
  • Data: ORANGE wire
  • Negative: YELLOW wire

The communication Protocol

The caliper that i have sends data in BCD nibbles!
So, let's take a look in this protocol. The caliper is already connected to the oscilloscope. There are two channels activated. The GREEN channel is connected to the RED wire, and that is the CLOCK of the port. The YELLOW channel is connected to the ORANGE wire and that is the DATA of the port. Looking to the oscilloscope's screen, the top channel is the CLOCK and the bottom is the DATA.

The Clock

Looking at the CLOCK of the signal, it looks like that it sends 7 sets of 4 bits each, plus one long bit at the end. Each set (nibble) starts with a long bit, and then follows another 3 bits much faster. All 28+1 bits takes about 780 uSec. The long pulse takes about 59uSec, and each small pulse has a period of about 12uSec. This data series is non-stop repeated every 320mSec. Here are some interesting screenshots from the oscilloscope:

Each data series is composed of 7 4-bit nibbles plus a long pulse at the end

Each long pulse has a period of 59 uSec

Each short pulse has a period of 12 uSec

The whole series is repeated every 320 mSec

The CLOCK line sends the same data all the time (as expected to do so), even when changing the measure of the caliper.

The Data

What changes when changing the measurement of the caliper, is the DATA line. The DATA line is always LOW when the caliper measurement is 0.00mm. But there are always 5 bits at the end of the DATA with a strange behavior. I will check them later. Also, the 6th nibble (bits number 21 to 24) are always low, no matter what i change to the caliper. So, i will first work with the 5 first nibbles that makes more sense when i change the measurement of the caliper.

Before, take a look at some interesting screenshots of the oscilloscope. They show the first 5 nibbles of the DATA line, while on the bottom left corner you can see the caliper with it's measurement:

Now everything makes sense. The first five nibbles, are just the five numbers of the display! The most left nibble (bits 0 to 3) is the most right digit of the display (10-2), the second nibble (bits 4 to 7) represents the 0.1mm, the third nibble (bits 8 to 11) represents the millimeters and so on. The caliper has indeed 5 digits. I suppose that if it had 6 digits, the 6th nibble would also be active, but this one is capable of only 5 digits.

Check this photo. This is one of the previous screen-shots with comments added. I have separate all 5 nibbles with orange lines. Also, i have the binary and decimal representation of this nibble. Note that the binary numbers that i have written, are reversed to the transmission of the signal. The BITS on the signal should be read from RIGHT to LEFT and written from LEFT to RIGHT, in order to have a normal binary number:

The strange nibble

But what about the last nibble plus the last bit? Well, this nibble has many functions. First of all, it send info for the units, if it is milliliters or inches. It also has a bit that shows if the number is positive or negative. Finally, there is also another bit, that indicates the 4th decimal when measuring in inches. This can be 0 or 5. Here are the 4 bits of this nibble, from LEFT to RIGHT as shown on the oscilloscope:

# Name When 0 When 1
0 Sign Positive Negative
1 Inches 4th decimal 0 5
2 Units Inches Millimeters

The fourth bit is always 1. Also, the very last bit in the data series is unknown. I have not figure out what is this for. It could be nothing more than a Stop Condition, similar to the I2C protocol.

I should note here that this protocol seems to have valid data on HIGH to LOW clock transition.

Bellow i have attach some very interesting screenshots from the last nibble. These are the 6 states that this nibble can take:

Units: Millimeters
Sign: Positive

Units: Millimeters
Sign: Negative

Units: Inches
Sign: Positive
4th decimal: 0

Units: Inches
Sign: Positive
4th decimal: 5

Units: Inches
Sign: Negative
4th decimal: 0

Units: Inches
Sign: Negative
4th decimal: 5


Here is a video with the caliper connected to the oscilloscope. Note that data are continuously sent over the communication port without and handshake:

And a funny video. I turn off the caliper and change its measurement. Data are still being transmitted and updated, even with the caliper turned off! I suppose that this behavior will drain the batter pretty quick

Relative pages
  • Learn how the PS2 keyboard protocol works
  • Re-use and/or extend your molex connectors
  • Learning PICs @ PCB Heaven On-Line Book

  • Comments


      Email (shall not be published)


    Notify me of new posts via email

    Write your comments below:
    BEFORE you post a comment:You are welcome to comment for corrections and suggestions on this page. But if you have questions please use the forum instead to post it. Thank you.


  • At 17 September 2015, 19:29:11 user Steve Spence wrote:   [reply @ Steve Spence]
    • I have successfully interfaced the Mitutoyo 52 bit protocol to an arduino (Don Lancaster's stuff was wrong),


      But the pinout on the Igaging SPC (Origin series) is a question.

  • At 11 July 2015, 20:03:04 user ETH wrote:   [reply @ ETH]
    • Does anybody know a workaround for the caliper turning off after 256seconds of the same reading?

  • At 24 November 2013, 8:50:54 user mayank wrote:   [reply @ mayank]
    • hello sir,
      i want a circuit diagram for a digital caliper bcoz with your help i complete my project best...

  • At 14 January 2013, 23:07:51 user gbmhunter wrote:   [reply @ gbmhunter]
    • Thanks for this info! Always wondered what those exposed pins on calipers were for.

      And BTW, nicely laid out information/oscilloscope screenshots!

  • At 11 October 2012, 5:46:23 user Giorgos Lazaridis wrote:   [reply @ Giorgos Lazaridis]
    • @Promothkumar probably you have the oscilloscope triggering wrong. You have to set the oscilloscope to trigger on the first pulse or something like that

  • At 9 October 2012, 15:30:49 user Promothkumar wrote:   [reply @ Promothkumar]
    • Hai,
      I have a mahr vernier I need to check clock and data pulse as u told above, so I connected clock pin and ground pin with Digital oscilloscope I got 2.8 volts continues DC supply I did't get out put like you told in above. can you please explain how to connect verniers pin into oscilloscope. I connected clock pin to positive terminal of oscilloscope and ground to ground pin of the oscilloscope. Is this correct.....?

  • At 1 October 2012, 6:23:18 user Giorgos Lazaridis wrote:   [reply @ Giorgos Lazaridis]
    • @Promothkumar the code seems to be assembly indeed, but it is missing the enter character at the end of the lines. probably you have to put it yourself...

  • At 1 October 2012, 1:49:47 user Promothkumar wrote:   [reply @ Promothkumar]
    • The complete source code fount at http:www.tinaja/text/digi232.asm I can't understand this code and by using MPLAB i can't able to create .Hex file of this code. I thought that code as in assembly language.

  • At 30 September 2012, 17:46:56 user Giorgos Lazaridis wrote:   [reply @ Giorgos Lazaridis]
    • @Promothkumar where is the code? i dont see it!

  • At 30 September 2012, 17:38:41 user Promothkumar wrote:   [reply @ Promothkumar]
    • Thank you Giorgos Lazaridis, And one more doubt,

      I am using MPLAB only but for that code i can't able to create a .Hex file can you please tell me how to create a .Hex file for that code which they are given for 16F84 micro controller in this website.

      your experiment is too good sir, it is very helpful for my project.

  • At 29 September 2012, 16:34:46 user Giorgos Lazaridis wrote:   [reply @ Giorgos Lazaridis]
    • @Promothkumar It is a PIC16F84 (you may wannt go into a PIC16F88 because 84 is very old, hard to find and expensive). Any PIC programmer will do just fine. Use MPLAB as programming software

  • At 29 September 2012, 15:28:05 user Promothkumar wrote:   [reply @ Promothkumar]
    • Hello sir
      Information about chaines caliper what you are given in about is super sir it is very use full to me thank you sir.
      I am doing project in conversion of digimatic out put of chaines caliper into RS232 format. I got on circuit diagram from this website http://www.tinaja.com/glib/muse145.pdf but I need to code in that particular micro controller which they given in that circuit, they given code also but I dont know which tool they are using in that code can you help me for that coding part.

  • At 20 August 2012, 12:11:17 user Giorgos Lazaridis wrote:   [reply @ Giorgos Lazaridis]
    • @V.Vennishmuthu I'm sorry i dont do circuits on demand.

  • At 20 August 2012, 8:36:03 user V.Vennishmuthu wrote:   [reply @ V.Vennishmuthu]
    • Hello sir
      I have a mitutoyo vernier caliper with IDC10 femal cable. Now I want to convert these digimatic out put into RS232 protocol and get these datas through hyperterminal option in windows xp. Can you tell me the circuit and program for that and also tell me step by step procedure for that. Thanks in advance.

  • At 2 March 2012, 10:30:16 user Hans U. Meyer wrote:   [reply @ Hans U. Meyer]
    • Here's why the Chinese Caliper's binary output is not to scale: I designed it for Sylvac in 1982, when the small number of on-chip transistors limited the options. Hence a scale pitch of 5.08mm=0.2inch, easy to subdivide in both metric and inch with serial binary (LSB first) arithmetic logic. The same logic also calculated the serial BCD output in mm or inch for the display. The serial binary signal, common to both units, was output as an afterthought: only few people wanted it, to which Sylvac simply sold binary-to-BCD-to-RS232 adapters.

      Chinese calipers use very, very similar chips (and that's an understatement). One foundry must have modified it to output BCD instead, I think it's the ones Aldi sold in Germany. The display switch-off feature was added as a gimmick by others, as obviously there is a sucker born every minute (good marketing!).

      The moral of the story: have fun cutting jaws of Chinese calipers and selling homemade DRO kits to the DIY market! As for me, I've been there, done that, and moved on a long time ago. Calipers from Sylvac and other manufacturers (including Chinese ones) are now inductive (insensitive to coolant) and have an RS232 output with galvanic separation. Talking about this, those old directly coupled 1.5 volt interfaces are very sensitive to ESD and ground loops; I wouldn't want them on a machine tool.

      That's all for now.

  • At 12 June 2011, 21:15:16 user Boris wrote:   [reply @ Boris]
    • Hello. I want to read this data by PIC16F887. What is a better way to do this?

  • At 14 February 2010, 3:20:54 user Philip Freidin wrote:   [reply @ Philip Freidin]
    • "Have you ever bought from this site? "

      Yes, I bought about $70 worth of stuff from them 2 weeks ago.
      Some RTC (the model I suggested to you) and some high voltage supplies
      for a Nixie project I am doing. For products that are basically just
      to support hobby users, their documentation is very professional.

      As both his company and I are in California, the shipping time was
      only 2 days. Ordered Tuesday, order acknowledged Wednesday, shipped
      on Thursday, received Saturday. Obviously will take longer to ship
      to Greece. Just ask questions via the Contact page.

  • At 13 February 2010, 21:18:49 user Kammenos wrote:   [reply @ Kammenos]
    • The RTC modules looks nice, and the battery lifetime is also brilliant. Have you ever bought from this site? They use paypal cart, i suppose it is secure.

  • At 13 February 2010, 21:06:16 user Philip Freidin wrote:   [reply @ Philip Freidin]
    • "But for my application, i will use external power to either power the LCD or the micro that will convert to RS232. The same power will be used to power the caliper - that will no longer rely on batteries."

      In that case, a normal NPN transistor, driven through maybe a 10K base resistor would be a good starting point for your experimentation.

      "I will need your suggestions for a clock that i think of making, that will rely on batteries when the mains is out (this happens quite often here in Greece)"

      For battery backed up clocks, have a look here:


      at the 1362 or 1374 modules.

  • At 13 February 2010, 11:24:23 user Kammenos wrote:   [reply @ Kammenos]
    • Oh, now it makes sense. But for my application, i will use external power to either power the LCD or the micro that will convert to RS232. The same power will be used to power the caliper - that will no longer rely on batteries.

      Actually, i will attach one caliper (liner) to the spindle of a carpenter's router, to measure the height of the cutter. I will not have any problem with the power supply. I will need your suggestions for a clock that i think of making, that will rely on batteries when the mains is out (this happens quite often here in Geece)

  • At 13 February 2010, 11:15:13 user Philip Freidin wrote:   [reply @ Philip Freidin]
    • There are two issues. How much power is drawn from the caliper to
      drive the level shifter, and how much power the level shifter draws from the system it is connected to.

      The caliper battery has very limited power, so if you don't want to
      affect the caliper battery life much, you need a CMOS type load.
      For example, a CMOS chip, or the gate of a FET.

      So a FET transistor might work, although you will need very low Vgs.
      Maybe something like a 2N7000 or 2N7002.

      If you use a NPN (or PNP) transistor to sense the caliper output, it
      is easy to make it work with the voltage swing from the caliper, but
      it will draw power that is many times the normal caliper power

      The suggested chips are designed specifically for these voltage
      ranges. In my application, I also care about the current consumption
      of the system my caliper is connecting to (it also has a very small
      battery), and the suggested chips have an idle current of 0.5 uA.

      Of course, if you can find a microprocessor for which 1.4V is an
      acceptable level for logic high, then that would be a good solution.

      Most micros use VSS*0.7 for logic high, so a processor that runs at
      5V needs at least 3.5V. A processor that runs at 3.3V needs 2.3V .

      This is why I mentioned that the caliper output at 1.5 for logic
      high would be a problem.

  • At 13 February 2010, 10:43:57 user Kammenos wrote:   [reply @ Kammenos]
    • Silicon Valley... nice place to work...

      For the voltage shifting, i thought of using simple transistors. You think there will be a problem?

  • At 13 February 2010, 10:32:38 user Philip Freidin wrote:   [reply @ Philip Freidin]
    • Hi Kammenos,

      I understand your comments about secrets. I work in Silicon Valley,
      mostly for big chip companies. Lots of secrets, lots of re-inventing
      of the wheel. In my hobby work though, I try and help others if I
      can, and hope others will help me.

      As for averaging of the readings, you must calculate the averages of
      the full 24 bit numbers (as I did in my prior explanation), not just
      the low 3 bits. This is because the rest of the bits can be affected
      by the low 3 bits as it rolls back and forth over the major transition
      from 111 to 000.

      My current project (started 5 years ago, but been on hold for last
      4 years) involves reading data from calipers (obviously). As the
      voltage levels from the caliper are 0 to 1.5 volt, you may have problems interfacing them to a microcontroller, as the logic high
      may not be high enough. May I suggest that you consider the following
      parts to do level shifting (that's what I use): sn74AUP1T57 or 58.
      These can shift the caliper signals to 0 to 3.3V signals.

      All the best,

  • At 13 February 2010, 8:14:09 user Kammenos wrote:   [reply @ Kammenos]
    • Fist of all Philip, thank you for the links. Zero and Mode button! Of course!

      It looks like you've done quite a nice job yourself! Where i live (Greece), people hide their so called "Secrets" from their discoveries. Not to accuse them as they make a living from this discovery. But that is the main reason i am now on the net. I believe that there is not actually a real secret. What someone has done, someone else can do it better. The difficult thing (that could be characterized as a secret) is to thing of a problem rather than finding the solution.

      Anyway i will consider averaging the 3 LSBs. Now that i think of it again, i think you are right. Although with this cheap caliper such an accuracy would be pointless, it has to be done for the sake of the experiment. I am planning to make a PC interface or a remote LCD display.

  • At 13 February 2010, 0:31:14 user Philip Freidin wrote:   [reply @ Philip Freidin]
    • Hi Kammenos,

      Notation I will use: For a 24 bit number, the least significant bit
      (LSB) is 2^0 , and the most significant bit (MSB) is 2^23

      For point 1: I agree that the 3 LSBs are noisy, but they do have value.
      For example, if the three LSBs (2^2, 2^1, 2^0) are toggling between
      111 and 000, then the 2^3 bit is also changing as a by-product of the
      noise in the 3 LSBs. Noisy data can be improved by the square root of the number of samples that are averaged. (from DSP theory, for random noise)

      For example, if you average 4 measurements (add four 24 bit numbers, and then divide by 4 (down shift by 2) the new number will be twice
      as accurate as before. In this case the 2^2 bit (of the average)
      will be less noisy than the separate measurements. This is just
      normal DSP type signal processing, not specific to your caliper data.

      The reason the 3 LSBs are noisy, is that the measurement process is

      For point 2: By weight of bit, I am referring to how you interpret the binary data. For example, the binary number 1100 has bit weights of 8, 4, 2, 1, giving a decimal value of 12. For the data from the caliper, the LSB has a weight of 1/20480 inches, the next bit is 1/10240 inches, etc for each bit being a weight of double the bit to the right. Just normal binary interpretation, with a conversion factor to a physical quantity (distance).

      I just collected some data from one of my Chinese calipers. I have seen several different data formats beyond the two you have seen. My current caliper outputs 2 x 24 bits, absolute then relative, at 76 KHz. Crazy stuff is the relative data (second set of 24 bits) are all inverted.

      Here is the data, with the caliper reading 6.0000 inches
      Data sampled on clock falling edge.

      Data is received LSB first: 000111111111100001111111
      Re-arrange as MSB on left: 111111100001111111111000
      Invert all bits: 000000011110000000000111
      Show as HEX: 0 1 E 0 0 7
      Convert to decimal: 122887
      Divide by 20480: 6.00034 inches

      Caliper only shows 0 or 5 in 4th decimal place, so this dislays
      on caliper as 6.0000

      Here is some confirming info:


      And here's something I wrote 5 years ago:


  • At 12 February 2010, 22:33:41 user Kammenos wrote:   [reply @ Kammenos]
    • Hello Philip,
      For point 1: I am not quite sure if these bits really mean something. The resulting number is accurate (except this 1.006 thing) w/o reading these bits.

      For point 2: What do you mean by "weight of bits"? And also, for example i measured 100mm (3.937 inch) and got the result from the port 100.6mm (3.961 inch). How did you came to this 1/20480?

  • At 12 February 2010, 22:06:58 user Philip Freidin wrote:   [reply @ Philip Freidin]
    • Nice article. With regard to the accuracy issue in the last section,
      you may want to try the following:

      1) Don't throw away the LSBs, instead average the readings to reduce
      the noisyness.

      2) Your article didn't indicate how you are interpreting the weight
      of the bits. I believe the units are 1/20480 of an inch.
      i.e. when the caliper is measuring 2 inches, the transmitted value
      is 40960. Maybe this accounts for the error you are seeing.

    reddit this Reddit this

     HOT in heaven!

    NEW in heaven!

    New Theory: AC electric motor working principle

     Contact     Forum     Projects     Experiments     Circuits     Theory     BLOG     PIC Tutorials     Time for Science     RSS   

    Site design: Giorgos Lazaridis
    © Copyright 2008
    Please read the Terms of services and the Privacy policy