Digital Linear Gauge to RS232

OK then:-
out = digitalRead(dataIn)+digitalRead(dataIn)+digitalRead(dataIn); // Tripple sampling to remove glitches

That line is totally wrong. You are doing an arithmetic operation on logical variables, what do you hope it will do?
It certainly won't debounce anything. Why do you want to debounce the input anyway, it's coming from an instrument why wold it have bad edges?

Note you are also printing a lot in a time critical routine, that will slow you down and you will miss stuff.
But more importantly as you have the hardware and I don't, what does it do when you run it?

If it's really RS232, I'd be asking what you're doing to limit input voltages above and below the AVR's supply rails.

out = digitalRead(dataIn)+digitalRead(dataIn)+digitalRead(dataIn); // Tripple sampling to remove glitches

This is the code as I found it, I couldn't figure out why it was sampled three times either, I guessed there must be something in the hardware that causes a reason for it.

what does it do when you run it?

I am waiting for a cable to arrive tomorrow, unfortunalty my boss thinks (expects) that I will plug the cable in and it will work.

If it's really RS232, I'd be asking what you're doing to limit input voltages above and below the AVR's supply rails.

Sorry, I should probably know what that is about but I don't.
Do you mean resistor pull up? I will search around and see if I can figure it out.

I guessed there must be something in the hardware that causes a reason for it.

No not at all, I know hardware and this line is just wrong.

If it's really RS232, I'd be asking what you're doing to limit input voltages above and below the AVR's supply rails

The answer is that it is absolutely nothing to do with RS232.
From the data sheet posted it is a 48 bit serial stream synchronised to a clock.

I am waiting for a cable to arrive tomorrow,

And assuming one end goes in the gauge what will you do with the other end?

unfortunalty my boss thinks (expects) that I will plug the cable in and it will work.

But you haven't even begun to write any code, all that code will do is tell you of the occasional logic level of the input, it's not fast enough to show you the whole binary stream let alone get numbers out of it.

Thanks so much for your input, maybe I should explain better my task.
We are making a machine to measure camshafts for racing engines.
This is way out of my area of knowledge but the job was given to me because I can code in VB (mostly copy and paste stuff) and no one else can do even that.

I was given three pieces of hardware:

A SerIO from sparkfun.

An Accucoder rotary encoder (incremental)

A linear digital gauge

I was able to find code examples and got the rotary encoder working and can display the output in a VB application. For me that is a big accomplishment.

I posted what is working here:

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1185064568

Now I need to do the same with this linear gauge. This linear gauge appears to be a much more difficlt problem because it sends the information in time based signals (that is about as much as I understand right now).

I can usually figure stuff out by foraging Google but at this point I wonder if this is a reasonable approach I am taking or if I would be smarter to just get a SmartCable:

but at this point I wonder if this is a reasonable approach I am taking or if I would be smarter to just get a SmartCable:

Defiantly.
I have just been having a go at trying to write something but it is difficult to synchronise the data. Once you do know where you are in the stream it is relatively easy to get the data in. But it comes out continuously so you never see the start. If I had the hardware then it might be easy to see if giving it a reset or a mode change allowed easy synchronisation but it is hard to tell.
You are way out of your depth here so go for the easy option.

You are way out of your depth here so go for the easy option.

Thanks, that's what I wanted to know.

I will just get the smartcable and be done with it.

That should save about a weeks wasted time.

Isn't the sequence 0000 [end of one value data] --> 1111 [start of data] --> 1110 [start of value] --> MS decimal digit (value < 1010) unique in the stream?

Isn't the sequence ............. unique in the stream

Yes it is from a nibble point of view but I am not sure if it is from a bit point of view. You need to consider the bit sequence in order to synchronise. So that is you need to consider what happens when you have the end of one nibble and the start of the next. However, you could be right.

But in the context of the question the original poster knows so little about programming that trying to talk him through this process is not going to be an easy matter. This is because there are other considerations, like transferring the data to the PC and sorting out exactly what frame he has (I understand there are four different types but the data sheet doesn't make it clear) To be pragmatic what he is really after is a result rather than the learning experience.

By the way MS decimal digit (value < 1010) is not the biggest value it is 1001 = (9 is the largest digit).

The sequence is in any case 000011111110 - i used nibbles for clarity and to be aligned with the data definitions.

Decimal digits are =<1001 and <1010, aren't they? :slight_smile:

I agree that the original poster had a long way to go and an unfair (to me) pressure but perhaps (hopefully) the thread becomes of use to someone else.

BR

ps. I missed the four types of data frames in the data sheet. Where are they mentioned?

To be pragmatic what he is really after is a result rather than the learning experience.

Thanks for your interest in my problem.

I am making a machine that measures a camshaft.
I need to measure the cam to get information about the design of the current cam is so that I can compare the original design to the new design.

The machine uses two input devices; a rotary encoder and a linear gauge.

The idea is that I will rotate the cam (attached to the rotary encoder) and then for each position of rotation I send the value through the serial port to a VB program that I wrote.

This much I have working.

The next challenge is triggering the linear gauge to measure the position of the cam follower each time the rotary encoder changes value.

I would really prefer to do this with the Arduino if possible but it looks like code for reading this kind of device is very specialized and complex.

There are devices called smart cables that might do what I need, I will find out today, they are about $200 I think.

they are about $200

Ouch!

I suppose it's not so bad if you are using some one else's money. However, if you want to have a dabble I could finish off that code for you tonight and you can see if it works.

If you think you can do it, I will gladly pay you for your efforts.

Grumpy_Mike

Thanks a million for that, as soon as the cable gets here I will try it.

Until then I will try to learn something from your code, it is way over my abilty to write something like that but given enough effort I can probably understand what you are doing there.

OK I say I was doing something wrong, not delaying until the clock went high again so I deleted the old post and I have put this instead.

//Simple Ono Sokki Reader


// Pin Declarations
int dataIn = 11;   // Pin 2 from the guage
int clockIn = 12;  // Pin 2 from the guage
int modeOut = 10;  // Pin 5 from the guage
int resetOut = 13;  // Pin 4 from the guage
// wire up pin 1 from the guage to ground

// Variables
byte inputValues[13]; // place to put the input from the guage
unsigned long time = 0;
unsigned long timeStart = 0;
int out = 0;


void setup() {
  // Pin Set Up
  pinMode(dataIn, INPUT);    
  pinMode(clockIn, INPUT); 
  pinMode(modeOut, OUTPUT);
  pinMode(resetOut, OUTPUT); 
  digitalWrite(modeOut, HIGH);
  // Reset the guage (this might not be necessary)
  digitalWrite(resetOut, LOW);
   delay(30);  
  digitalWrite(resetOut, HIGH);

  Serial.begin(115200);
  Serial.println("Ready: ");
}


void loop(){
  getReading();
  for(int i=3; i<13; i++) { // print out the results
  Serial.print("Step ");
  Serial.print(i+1);
  Serial.print(" ");
  Serial.println(inputValues[i],HEX);
  }  
}
void getReading() { // reads 12 nibbles from the input on rising edge of the clock
  byte val=0, inputBit =0;
  boolean notFound = true;
  // try to syncronise to incomming streem looking for 0xFE
  while(notFound) {
  while(val != 0x7f) {
   while(digitalRead(clockIn) == LOW) { } // do nothing until clock goes high
   inputBit = digitalRead(dataIn) & 0x01;
   val = (val << 1) | inputBit;
   if(inputBit == 0) val = 0; // reset if it is zero
   while(digitalRead(clockIn) == HIGH) { } // do nothing until clock goes low
  }
  // look for last bit in first two nibbles
   while(digitalRead(clockIn) == LOW) { } // do nothing until clock goes high
    inputBit = digitalRead(dataIn) & 0x01; 
   if(inputBit == 0) notFound = false; else val = 0;
   while(digitalRead(clockIn) == HIGH) { } // do nothing until clock goes low
  }
  // now get the data
  for(int i=2; i< 13; i++){
    inputValues[i] = getNibble();
  }
}

byte getNibble(){
  byte val = 0, inputBit = 0;
  for(int i=0; i<4; i++){
      while(digitalRead(clockIn) == LOW) { } // do nothing until clock goes high 
    inputBit = digitalRead(dataIn) & 0x01;
    val = (val << 1) | inputBit;
       while(digitalRead(clockIn) == HIGH) { } // do nothing until clock goes low
  }
  return(inputBit);
}

Thanks for the update, the cable just arrived, I am going to wait until everyone goes home so I can have peace and quiet, get some diet coke, some cold pizza, a soldering iron and have some real fun.

Grumpy Mike,

Huge progres!!

First I think where the code says:

int dataIn = 11;   // Pin 2 from the guage
int clockIn = 12;  // Pin 2 from the guage

There was a typo and you meant Pin 3 from the gauge

int dataIn = 11;   // Pin 3 from the guage
int clockIn = 12;  // Pin 2 from the guage

When I connect and run it the serial monitor continuously scrolls the following:

Step 4 0
Step 5 0
Step 6 0
Step 7 0
Step 8 0
Step 9 0
Step 10 1
Step 11 0
Step 12 0
Step 13 1

Moving the measuring probe changed the values of Steps 4 through 9 between 1 or 0 values.
Is that what you were expecting, should it be returning digits from 0 to 9?

Thanks so much for your help!

should it be returning digits from 0 to 9?

Yes

OK spotted it. Stupid mistake. Replace:-
return(inputBit);

with return(val);

Thanks now it returns the following

Ready:
Step 4 0
Step 5 0
Step 6 0
Step 7 0
Step 8 0
Step 9 8
Step 10 5
Step 11 0
Step 12 0
Step 13 F
Step 4 7
Step 5 E
Step 6 2
Step 7 B
Step 8 F
Step 9 F
Step 10 2
Step 11 F
Step 12 F
Step 13 F