This is the other type of protocol for the Chinese calipers. This protocol has an advantage over the BCD type, because it sends both the Absolute and the Relative position of the vernier.
The Chop-Job
Practice makes perfect. this time i managed to get solder the wires without chopping any part on the caliper housing. Actually, i dismantled the whole housing and took the PCB out of it. The soldering was now very easy.
If you turn the caliper to it's back side, you will see a label with info about the screw threads. Removing this tag will reveal the 4 screws that holds the thing together. I unscrewed those screws, and the housing fall apart. Something funny: One screw is different from the other 3 screws in terms of thread pitch. I do not really know why this happens, but i marked the hole not to confuse it with the others. Do not forget to dismantle the thumb wheel as well!
On the back side, there is tag with info about screw threads
Removing this tag, will appear the 4 screws that holds the housing together
One screw has different pitch than the other three!
Do not forget to dismantle the thumb roller
The housing fall apart
Now i had easy access to the PCB
The soldering procedure was very easy
When the caliper was assembled back again, i had the wire connected without chopping the housing
Identifying the pins
Luckily, the pins are exactly the same as the ones on the caliper that i had previously experimented. You can find a complete description how i identified those pins in this page.
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 connected
to the oscilloscope
Here comes the interesting part. I connected the port wires to the oscilloscope. The protocol was this time completely different as before. This change was expected though. During this experiment, you will see two channels activated on the oscilloscope. The channel on the top with the GREEN line, comes from the DATA of the caliper. The channel on the bottom with the YELLOW line, comes from the CLOCK of the caliper.
The Clock
From this pin we can identify the transmission frequency and bit length, as well as the time between repetitions. After some tests and measurements, i found out that the signal is composed of two 24-bit binary numbers. The first number being transmitted carries the absolute position of the caliper, while the second carries the relative position. At the very beginning and the very end of the whole data transmission, there is a positive clock delay of about 30 uSec. Between the two 24-bit numbers, there is a delay of 60 uSec. The transmission frequency is aboyt 135 KHz. Finally, the data is repeated non-stop with an interval of about 180 mSec. Look at the following screenshots from the oscilloscope:
The data is composed of two 24-bit numbers and takes 470 uSec to be transmitted
Between the two binary numbers there is a delay of 60 uSec
Ath the beginning and the end of the data, there is a positive clock pulse of 30 uSec
Each binary number has 24 bits and needs 165 uSec to be transmitted
The transmission frequency is around 135 KHz
Data is non-stop repeated with an interval of 180 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
The first number sent is the absolute position and the second is the relative position
The first 3 bits should not be taken into accound when acquiring a number
In absolute position, the number when the caliper is completely closed is NOT zero!
The Data pin carries the Absolute and the Relative position of the caliper. The absolute position is referred to the caliper's fixed zero position, while the relative position is referred to the zero position that is every time set when the "Zero" button is pressed. Each position is sent via a 24-bit binary number. The number is read from LEFT to RIGHT as seen on the oscilloscope's screen. Also, for each number, the first 3 bits should NOT taken into account when reading it's value. These bits have not a regular and/or repeated pattern and they change their value without a reasonable way even without changing the caliper's vernier. So this makes the 24-bit number actually a 21-bit number, with the LSB being the 4th bit being transmitted. When a negative number is shown, then the caliper will transmit the complementary number instead.
In the case of the Absolute number, it should be noted that it does not start from number 0. This makes sense to me for a cheap construction like this caliper, because it would require the linear magnet to be placed with absolute mechanical precision to its position, so that when the caliper is completely closed, the magnetic pickup sensor would pick the number zero.
And something more. This caliper, unlike the one on the previous experiment with the BCD-type protocol, stops sending data when it is turned off.
An unexpected surprise - drawback!
During the experiment, i took several measurements and run lots of tests to double-check the results and gain repeatability. But i run onto an unexpected surprise. While taking measurements, i noticed that when the caliper was on large numbers like 60.00 mm and above, there was a slight error in measurement. This error was increasing as the number was increasing! For example, the caliper's display was displaying the number 100.00, while the binary number from the communication port was 100.60!
I spent many hours trying to understand what was going wrong. Finally, i came to the decision that the problem itself comes from the construction of the linear magnet of the caliper. I am convinced that this sensor does not have a metric step. Instead, a multiplier needs to be taken into account when calculating the result. Moreover, the communication port does not transmit the calculated number, but the raw number from the linear position.
To prove the above though, i run some experiments. For my surprise, i found indeed an adjustment value! This value is the decimal number 1.006. I am sure that this number is different from caliper to caliper. I am also sure that there may be calipers that have a metric step and therefore this number will be 1. But in my case, i need to divide this number to the number read from the communication port in order to get accurate results.
Videos
Here is a video from this caliper connected to the oscilloscope:
@Promothkumar probably you have the oscilloscope triggering wrong. You have to set the oscilloscope to trigger on the first pulse or something like that
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.....?
@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...
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.
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.
http://www.tinaja.com/glib/muse145.pdf
your experiment is too good sir, it is very helpful for my project.
@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
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.
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.
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.
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.
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.
"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)"
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)
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
consumption.
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.
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.
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.
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
noisy.
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
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?
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.
Home
Projects
Experiments
Circuits
Theory
BLOG
PIC Tutorials
Time for Science
Contact
Forum
RSS
Reddit this
HOT in heaven!
NEW in heaven!
