Pulse sense circuit

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know enough about about microcontrollers to get myself into trouble, and almost nothing about analog circuits.  I'm working on a project to read from 1 to 4 electronic gauges, but I need to be able to determine which of the gauges are attached to the system.  These are battery powered gauges so none of the interface lines are active unless the gauge is transmitting data except for one.  The gauges pulse the data request line about 10 times per second.

 

To ask the gauge to send data, you pull this line to ground and I'm assuming when it detects a missing pulse it starts to send data.  What I'm looking for is some way to use this pulse train as a signal when a gauge is attached.  What I'd like is a circuit that would source or sink 5V so I can tie it to one of my µP inputs that would signal when the pulse train was there and continue to signal for approximately a second after the pulse train was removed.  I'm thinking of the latter condition as the upper bound of the button press time used to pull the line low to request the gauge to send data.  I don't want the button press to be misinterpreted as the gauge being disconnected.

 

I've got an idea that a 555 timer as a pulse stretcher might work for this.  Set the timer up for a 1-2 second pulse, and use the signal from the gauge to keep "refreshing" the timer.  Any analog gurus out there want to help me with such a circuit?

Cheers,

Tom

Last Edited: Sat. Mar 14, 2015 - 01:27 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Tom,

 

It is Saturday morning here and obviously my brain is working on weekend-time/power. I don't follow your explanation. Correct me where appropriate.

 

So each gauge has a line "A" that the gauge pulses as per your oscilloscope capture. You want to know when these pulses are present.

 

The request for data sent to the gauge by "something external" is pulling the pulsed data line low for X time.

 

If the above is correct... how about a retriggerable monostable with a timeout of your 2 seconds that triggers on the positive pulses from the gauge. The output of the mono could drive an LED to indicate the presence of the gauge. (4 monos, 4 leds, 4 gauges connected). *Noting Kartman's comment about your signal size, put a couple of NPN transistors in front of the mono trigger input*

 

Have the second half of the mono package (eg CD4098) triggered by your "data request push button". The /Q output of this mono pulls the gauge's "A" line low via a diode (anode connected to the "A" line, cathode to the /Q).

 

Does that sound about right?

 

Can draw if needed.

 

Cheers,

 

Ross

 

Ross McKenzie ValuSoft Melbourne Australia

Last Edited: Sat. Mar 14, 2015 - 02:31 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your pulse is only 1.5V according to the scope trace. The trig on a 555 is 2/3vcc if my memory is correct. This might make vcc a bit low for a 555 - you would need to check specs. I gather this is further to you previous posts with mititoyo calipers. There's been a bit written about these on the interwebs and some by a good friend of mine - google fliptronics.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Ross - thanks - that's a good summary and about what I was thinking with the '555.  I'll give it a try this weekend.

@Kartman - On Fliptronic's site the only thing that comes up is his battery FAQ.  I've also found a Dan Lancaster article that is filled with inaccuracies and nothing at all on the operation of the REQ line.  Do you have anything particular you can point me to?

 

Also thanks to both of you for pointing out the need to amplify the REQ line.  I had thought that might be the case.

Cheers,

Tom

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Ross,

 

The gauges have five lines, DATA, CLK, RDY, and REQ, and GND.  The first three are outputs with the external device providing the pullup.  These lines are then pulled low by the gauge for transmission.  In reality the RDY signal is a pushbutton on the gauge that just shorts RDY to ground.  The external device can request data at any time by pulling the REQ line low (killing at least one pulse in the pulse train) at which time the gauge begins transmission.  The external device should monitor the RDY line and if it drops low, it should then send the REQ signal.

 

My guess is the µC on the gauge is waking up every 100ms, turning on the pullup on the REQ pin, reading the pin level, and then turning the pullup off.  If the level was high, the controller goes back to sleep.  If low, it transmits the measurement data, then sleeps.  Their power management is very good because these things seem to run forever on a single SR44 cell.

 

As you may have seen from some of my previous posts, I'm making a keyboard wedge to dump the readings from four gauges into an Excel spreadsheet.  Right now, I always send four numbers substituting NaN if a gauge is not attached.  If I could determine it the gauge cable was connected or disconnected, then I could condense my output to only those gauges connected and use NaN only when there is a reading error.

Cheers,

Tom

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If the signal goes to a µC anyway, the logic way would be using the µC to decide if the pulsetrain is still there.

If it needs to be some kind of "analog" Hardware, something like a NE555 (or newer replacement) would be the way to go. The level may need some kind of Adjustment or Amplification - possibly just running a LMC555 at 3-4 V instead of 5 V. The µC may detect the 3-4 V signal as well.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kleinstein,

 

I had thought about this earlier, but the only way I could figure out how to implement it was to connect the REQ line to an external interrupt and use that as a watchdog to keep resetting a GaugeActive flag that was periodically (~1/sec) cleared by a timer interrupt.  I wasn't sure about this route because of the resources (4 external interrupts and a timer).

 

It now looks like I need a timer for another issue, and the chip I will probably use, the ATmega32U2 does have 8 external interrupts, so I will probably reconsider this route.  The external hardware route does have the downside of pushing me closer to my 100ma USB limit as well.

Cheers,

Tom

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

After playing around using a rising edge external interrupt to sense when a gauge was connected, I thought I had it worked out.  Unfortunately when I tried some of my older gauges, I found out they have the REQ line high at 1.5V constantly.  Now I'm stumped trying to come up with an algorithm that would work regardless of the gauge type connected.

Cheers,

Tom

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tom,

 

I think your...

In reality the RDY signal is a pushbutton on the gauge that just shorts RDY to ground.

...should read

In reality the REQ signal is a pushbutton on the gauge that just shorts REQ to ground.

Otherwise I am lost.

 

Cheers,

 

Ross

 

Have just spoken with an engineer friend of mine who produces an interface for Mitutoyo calipers. ( http://daps-tech.com.au/mitutoyo... ) He is going to supply me with a tech document that may help you... or he can do you "a deal" on one of his units. cheeky

 

 

Ross McKenzie ValuSoft Melbourne Australia

Last Edited: Sun. Mar 15, 2015 - 01:57 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Ross,

 

The RDY signal is a pseudo signal from the gauge.  You press a button on the gauge to take a data reading.  That button grounds the RDY signal.  The data collection device is supposed to watch the RDY line and if it goes low, then it is supposed to pull the REQ line low to actually request the data from the gauge.  The RDY signal is really just a remote button on the gauge.

 

My plan is to watch each of the RDY signals and if one is received, I plan on requesting data from that gauge only.  I also plan on having a button on my device that would act as a collective ready signal and when it was asserted, my device would pull all four REQ lines low causing each of the gauges to send a data packet.

 

Does that make sense?

Cheers,

Tom