Caliper communication problem.

I have just recently purchased three new 6 inch calipers from a supplier in china. The price was very low but they look and seem to work just like the older calliper I already had. Although all of my caliper look virtually identical to the ones I see both in the Nerdkits tutorial and the once on the web page http://www.shumatech.com/support/chinese_scales.htm ,I had a lot of trouble when it came to communicating with the new calipers. I was not able to get any satisfactory reading off my newer Chinese callipers. I tried to follow the detailed instructions and code provided in the Nerdkits tutorial but could not get any results. I have no access to an oscilloscope or a logic analyzer but suspected that my calipers where not producing a data /clock stream as described in the tutorial.

My solution

I decided to try and get a visual representation of the data and clock streams produced form the calipers using the Nerd kit and a PC. I wrote a simple code for the micro that would repeatedly pole the clock and data inputs on the micro. I considered using an interrupt but I am very new to this and did not have any idea how to get and record the relative time that each interrupt occurred. I wanted record the relative time that has passed since the last change, every time ether the clock or the data changed. I could store the state of the clock and the data pins in an array variable. I also recorded the number of static reads that were made between changes to the same array variable. The results (array contents) are then sent to the pc on the serial connection for a detailed analysis and plotted. I brought the data into MS Excel and use a simple VBA routine parse it appropriately. To get a clear visualization of my calliper’s communication protocol I used a excel spreadsheet chart.

My findings

My calliper do not send a protocol anything like what is I was expecting. It was clear that I was getting 6 sets of four bits followed by a longer period of low state on both the data and clock pins, before the pattern repeated. It was also apparent the data should be read on the falling edge of the clock. After playing around with numerous caliper reading I realized that my calipers are not sending an absolute position only a relative position is available i.e. I can only read where the calipers is relative to the last zero point not to any fixed position (unfortunate). Furthermore the data send changes when the unit is changed on the calipers display. i.e. the data sent from the calipers changed totally when the calliper display was showing mm or inches even when the position had not moved. Using a VBA routine I displayed the bit state of the data on the falling clock pulse for each reading. After looking over a few of these readings it was clear how to interpret the data stream in order to read the calliper position.

This is what I have discovered about the data stream on my calipers.

A 24 bit data and clock stream. Presented as six sets of four short pulses then a much longer period of quite where both clock and data are low.

Bit 0 thru 19 are the relative position of the calliper (high data state =0). mm100 or inches 2000

Bit 20 is the sign of the position low state is negative high state is positive

Bit 24 is the unit of the position low state is inches, high state is mm

Pulling the Clock or the data pins high has no discernable effect on the data stream. Therefore I have not discovered any way to reset the reading zero position other than using button on the calliper (again unfortunate). I have not discovered any other mode for these calipers.

I am very new to both C and micros. At times I struggle to accomplish simple changes to existing code. I certainly do not suggest that this is the best or even a good approach or well constructed code. But I was able to get satisfactory results. I am now able to read the calliper positions into the pc providing feedback on the Z,Y,Z axis for a project I am working on. In fact I have a number of questions about my own code regarding timing on the loops. In order to get the results that I have I had to make some of the loops much longer than in the original Nerdkits calliper code that I modeled from. I really do not understand how I could estimate the real time values for the code to execute hence I don’t have any idea of the actual time values for my data only the relative number of sampling loops between readings. I believe that the data timing will be accurate as far as sequence of event goes but is not really linear. More code is executed each time there is a change in the pin state then when it is static therefore there should be some additional time value added to each reading to compensate for this delay. I don’t even know if this is a significant amount of time I suspect not. It may have an effect on the relative length of the X axis on the chart. for example at times when it may appear that two changes occurred very close to the same time i.e. clock change then a data change this time interval will in fact be somewhat longer do to the code executed to record the array variable. This time would of course be present for each reading but relatively most significant on very short intervals. This is my code to fill an array with calliper data and clock pulse reading. Note there is no direct real time measurement only the number of sampling loops that are taken between changes. This code will be triggered by the first rising clock edge after a period of quite.

    uint16_t rb=(PINB & 6);         // first read, both clk and data     clk will be high
    int v;
    uint16_t x[200];// large enough for a least two full data sets 
    int c=1;
    int i;

    x[0]=(rb<<13) ;          // move read to MSB to make room for loop count data
     uint16_t attempt_counter=0;
    while(attempt_counter<=16383)// keep the loop count under 14 bits that are available 
     {
           v=0;
           while(v<= 8) //delay timer for reading data bits
             {                    // this loop is only required to keep the number of loops within     
                                   //the 14 bits available to store the count on long periods of quite
                                   // loop can be omitted for faster sampling rate.
                 NOP;
                 v=v+1;
               }
            if((PINB & 6)!=rb)      // check for change in clk or data
  {
  rb=(PINB & 6);          // reset to changed pin state
   x[c]=((rb<<13)+attempt_counter); // set array variable to pin state + attempt count
    attempt_counter=0;                    // could add a constant to attempt_counter to adjust 
                                                               //for additional time used in this code??
   c=c+1 ;
          }

    if(c>199)            // array is full
    attempt_counter=64000;

           attempt_counter=attempt_counter+1;
        }

If anyone is interested I could send the entire code that also reads and output the calliper position.

Anyone else that is experiencing trouble getting readings from a calliper may have a calliper with an alternate data communication protocol and this information may be of some help. I have liked a photo of two of my callipers. The top one uses the protocol explained in the Nerdkits tutorial it has a 12inch scale. The lower one uses the protocol described here it has a 6 inch scale. I have also linked a number of images captured from the excel charts displaying the data and clock pulses produced from the callipers.

caliper display calliper photo

-0.04 mm 24 bit data cycle.

0.00 mm 24 bit data cycle.

0.128 inch 24 bit data cycle.

-1.000 inch 24 bit data cycle.

0.000 inch two full data cycles including the quite period between them. Can make out much here except for the relative length of the data cycle to the quite period.

You might not have a oscilloscope but you certainly made a nice digital logic analyzer.

Nice work I am impressed.

Ralph