Reading Digital caliper with Arduino

[chucketn]

I'm trying to follow along with the development of the code. Can either Ed or Arvid post the entire code you're using at this point?
As the weather is cool again this week end, I'm going to reorganize my desk and get back into playing with this project.
And to make sure I'm on the same page, you are using the cheap HF Calipers, right?

Chuck

[arvidj]

The latest code I posted is in post #99. I believe that is what Ed is currently using.

[arvidj]

For the first data bit I simply put in a 0 or a 1 ... 00000000 or 00000001 into the buffer.


For each data bit after that I shift what I have left ... 00000000 or 00000010 ... and then OR in a 1 if need be ... 00000001 or 00000011

Next bit [assuming there was a 1 in the previous bit] ... 00000001 or 00000011 shifted becomes 00000010 or 00000110 and after the OR ...

When you look at the 24 bit string it would be exactly like the scope trace with time going from the [left] high order bits to the [right] low order bits.

Only getting a "Ready" is strange. That suggests that the interrupt does not increment the capturedBurstCounter. That's strange because it should be incremented ... assuming nothing is going wrong with the timing ... based on the clock transitions and has nothing to do with the data line.

Maybe I should take a drive up there and we do this in real time 

[EdK]

The scope shows timing with the least significant bit on the left since the least significant bit is sent first from the digital caliper.

Ed

[EdK]

Oh, and I ended up not going into work this morning. Now I wish I had and brought the hardware with me. We could have tackled it together and probably made some good progress.

Ed

[arvidj]

I guess it doesn't really matter as the interrupt is simply trying to capture the bit stream without any thoughts as to what it means. It will be the responsibility of the program loop to, at its leisure, take the captured bit stream and peal the bits back off the captured stream as flags and nibbles and digits and ... to determine what the information is and format it for human consumption.

As long as the interrupt and the program loop agree on how the bits are put into the captured stream we will be good.

[EdK]

(03-28-2015, 09:30 AM)arvidj Wrote: I guess it doesn't really matter as the interrupt is simply trying to capture the bit stream without any thoughts as to what it means. It will be the responsibility of the program loop to take the captured bit stream and peal the bits back off the captured stream as flags and nibbles and digits and ... to determine what the information is.

As long as the interrupt and the program loop agree on how the bits are put into the captured stream we will be good.

I agree Arvid and it's more work to shift right so it's best to keep it simple inside the ISR. Either way, we should be seeing some data.

Last evening I used the ISR to set a dataAvailable flag and then polled that flag in the main loop. When the flag was set I'd read the data line and store it into an array of bytes. Once I had 24 bits I'd send the array to the serial monitor and I was seeing the correct data bits but the data pattern was shifting within the 24 bits.

Ed

[EdK]

(03-28-2015, 09:06 AM)chucketn Wrote: ...
And to make sure I'm on the same page, you are using the cheap HF Calipers, right?

Chuck

Chuck,

Here's the calipers I'm using. I think yours are 4" whereas mine are 6" but it's likely they use the same circuit board inside them.
Does yours turn off if it sits with no activity after a time? Mine does and I can see that being a problem. Unlike the one Rick Sparber talked about in the PDF when mine times out and shuts off, when you turn it back on it reads as zero not where it was when the power was shut down. So the protocol is the same as what Rick wrote but the behavior is different.

Ed

   

[chucketn]

My bad on the code request. I totally spaced the scroll on the code window... Got it now, and will load it in a bit(no pun intended).
Chuck 9

[EdK]

The interrupt was not running. This needs to be changed:

attachInterrupt(CLOCK_PIN, clockTransitioned, CLOCK_TRANSITION);

To this:

attachInterrupt(INTERRUPT_NUMBER, clockTransitioned, CLOCK_TRANSITION);

With this define:

#define INTERRUPT_NUMBER 0

The attachinterrupt takes the actual interrupt number as a parameter rather than the pin number the interrupt is acting upon. It's a little confusing because the Arduino Due uses the pin number whereas the rest use the interrupt number.

I meant to point this out earlier but forgot.

But, that doesn't fix the data not displaying problem.

Ed