Measuring a known pulse width range with the HCS08

[FC]

Hello,

Need advice in measuring a pulse which can vary from 100us to 10ms from an ultrasonic sensor.  The difficulty is when the second captured timer value is less than the first (overflow occured) in order to compute the pulse width.  Should the timer be reset after each edge rather than using a free running counter?

Ex.

First input capture value = 0xFF00

Second input capture value = 0x0060

Timer clock = 4MHz

TMOD = 39999 (subtract 1 cycle for overflow)

[FC]

Hello again,

Due to the HCS08QG8 operating at 3.3V, interfacing to 5V systems can be annoying.  For example, this particular sensor operates at 5V, so a seperate power supply will be needed.  But, the pulse sense ouput is TTL level, so a simple voltage divider will be needed.  A 2:1 ratio should work fine using 100k and 50k resistors.

Perhaps the divided voltage shoud be fed into a buffer (op amp with unity gain) or a more robust analog interface?  Unfortunately, analog is needed, but hopefully minimal. 

I wish the HCS08QG was 5V tolerant.

[bigmac]

Hello FC,

Yet another way of achieving the required level shift is to use a suitable N-channel MOSFET.  The TTL sensor output would connect to the gate of the MOSFET, the drain would connect to the MCU, and the source would connect to ground.  You might also need to provide an external pull-up resistor at the drain, if the internal pull-up within the MCU does not provide sufficient current for adequate switching speed (low to high).  Of course, you would also need to take into account the polarity inversion of the signal at the MCU pin.

Regards,

Mac

Message Edited by bigmac on 2006-12-2201:07 AM

[FC]

Thanks for the replies. 

The sensor can be set to activate at 10Hz which gives plenty of time to calculate the distance.  It can be externally triggered as well.  This is good project for the HCS08.

[rocco]

Duh . . . I forgot about the Frequency-Locked-Loop.

You don't need a special oscillator at all. You did ten years ago, when I had to do this type of thing.

You can program the FFL to give you almost any frequency you need from standard oscillators.

Anyway, it looks like you don't heed it. Mac's mult/div approach sounds like the way to go to me.

[FC]

Thanks,

Using a modulo of 0xFFFF is better.

Here is another question,  the pulse width is proportional to the distance the sensor detects.  Once the pulse width is determined, it needs to be dvided by two to remove the return echo time.  Knowing the speed of sound in air, the distance can be computed. But, this involves multiplication/division and may take too many CPU cycles for the HCS08.  If a lookup table is used, it can only hold limited distance values.

The sensor has a fairly linear output.

Any comments?

[bigmac]

Hello FC,

What is the interval between transmit pulses, i.e. the reading update period?  Presumably it must be somewhat greater than 10ms - perhaps a good choice would be 16.384ms, the timer overflow rate, provided the required transmit pulse width is not too large.  Can I assume that this will be less than 100 microseconds?.  This way, the transmit pulse would actually always have a known starting point, and this might simplify things.

To calculate the corresponding distance will obviously require more than a divide by 2 - the factor required will depend on the distance units you require to display.  This would best be handled using integer arithmetic, by first multiplying by a suitable integer value, and then dividing by another integer value.  You should avoid any temptation to use floating point calculations.  With integer operations, I would suspect that there would be adequate time for the reading update, with an update period as suggested above.

It is not clear whether you intend to use assembly or C programming.

Regards,

Mac

[bigmac]

Hello FC,

If you wish to stick withTimer clock = 4MHz, I would suggest you leave TMOD at the default value of 0xFFFF.  This will give a timer overflow period of 16.384ms, and easily allow for a maximum delay measurement period of 10 ms.  The timer will increment each 0.25 us.

Using Rocco's figure of 331 m/s for the speed of sound, this would give a one-way distance of 0.041375 mm for each timer count interval of (both-way) delay.

Now, if you were to resolve the distance measurement to the nearest 0.1mm, this would need a multiplying factor of 0.41375 for the count value, and this may be closely represented by the integer quotient 12 / 29.

The following code should give the measured distance to 0.1mm resolution, with reasonable accuracy, and should not require too much time to execute.

word delay_count;

dword dist;

dist = delay_count * 12L;

dist /= 29;

This method would also work for other distance units, provided the required multiplier can be sufficiently accurately represented by an integer quotient.

Regards,

Mac

[rocco]

Hi, FC:

One (somewhat ugly) option I have used in the past is to tailor the clock frequency to the application.

What units do you need to measure in?

If you needed to measure in millimeters, and you used 331 meters/second as the speed of sound, you would have 0.1655 mm/microsecond (after the divide by 2). Since that equates to 6.042 microseconds per millimeter, a clock period of 0.755 microseconds would make your timer count in 1/8 millimeter increments. No math required, unless you wanted to remove the fractional portion, which would require three right-shifts.

You could do this in millimeters with a 2.648 MHz, 5.296 MHz, 10.592 MHz or 21.184 MHz oscillator. You would need the appropriate formula for feet, inches or cubits. You would most likely need a programmable oscillator to get the correct frequency.

just another off-the-wall suggestion.

[joerg]

Hi FC
Dividing by two is a simple shift right operation!

Try it!

Saluti Joerg

[rocco]

Hi, FC:

If there a reason why you set the modulo register? I see that it's giving you an overflow every 10 milliseconds, but do you really need that? Could you live with an overflow every 16.384 milliseconds?

If you leave the modulo register at its default, you can ignore the issue of which one was greater. If you do a 16-bit subtract, the answer will be correct, regardless of when the timer overflow occurs.

As per your example:

First input capture value = 0xFF00
Second input capture value = 0x0060

If you subtract the first edge from the second:

 0x0060
-0xFF00
_______
 0x0160

The answer is the correct number of counts between the two edges.