Problem: I want a way to display a time interval that can be photographed as part of a test fixture. I'm trying to convey a time value, which can vary from fractions of a microsecond to seconds.
Ideas:
The value that I'm trying to convey can vary over a large dynamic range, but it will always be a "round" number. For example, it might be 10 milliseconds, or 85 microseconds, but it will never be 10.85 milliseconds. Therefore, I really only need a couple of digits to convey the value, plus something to convey the metric time units. Using a two digit LED display, including decimal points, together with a three additional LEDs representing microseconds, milliseconds, and seconds, I can convey 99 seconds down to 10 nanoseconds. For example, here's every decade of 85 from seconds to hundreds of nanoseconds:
85 seconds
8.5 seconds
.85 seconds (850 milliseconds)
85 milliseconds
8.5 milliseconds
.85 milliseconds (850 microseconds)
85 microseconds
8.5 microseconds
.85 microseconds (850 nanoseconds)
.08 microseconds (80 nanoseconds)
Normally, the precision of a number is expressed in the number of significant digits with which is it written. For example, 85 microseconds +/- 10 nanoseconds would be written as 85.00 microseconds. But here, since there are only two digits, the precision needs to be explicitly stated, rather than conveyed in significant digits. Since the timing resolution is independent of the scale, there will probably just be a note on the fixture to the effect of "All times are exactly as stated, +/- 10 nanoseconds."
Because the display is intended to be photographed at any possible exposure time, it needs to be static, with all active LEDs on at all times. It can't be a multiplexed display, the way you'd normally drive a large number of LEDs, because at exposure times shorter than the refresh rate of the complete display, you would only see portions of the display lit in the photo. With 2 digits of 7 segments each (14 LEDs), plus decimal points (two or three* LEDs), plus three time scale LEDs, that's a total of 19 or 20 LEDs that need to be driving simultaneously.
*Why would I want the third, rightmost decimal point? It is not specifically needed, but since the middle and leftmost decimal point locations are so integral to conveying non-full-digit values, it might be useful to explicitly include both leftmost and rightmost so there is always a decimal place on and it is not unclear where it resides:
85 milliseconds displays as 85. milliseconds, to explicitly differentiate it from .85 and 8.5 on the display. This also indicates another problem with this scheme, however, because virtually all 7-segment displays include the decimal point at the right side of the digit. (HEY! A survey of Digikey attempting to verify that assertion turns up this part:
It includes a "Left Decimal Point" and "Right Decimal Point" on the same digit, suitable for use as my leftmost digit. The dual-decimal point feature is sufficiently unusual that it doesn't appear to be mentioned anywhere in the description of the part on the Digikey website... If this or some other dual-decimal point digit is not sufficient for my needs, I'm going to end up having to improvise a left-most decimal point, or I could just add a third digit, and then only ever have right decimal points, but also 7 more LEDs, and a higher explicit precision display. I think I'll make that decision based on other considerations, like brightness, size, color, etc.
Anyway, to make the 19 or 20, or possibly 27 LEDs statically illuminated, I'll need 27 output bits, so I'll probably just drive them directly using a 74AC164 serial in / parallel out shift register. (If I end up wanting to drive my display electronics at 5V but still have a 3.3V MCU driving everything, I might end up instead using a 74ACT164, which requires a 5V supply, but has TTL input switching levels, meaning that my 3.3V inputs would have more margin. Though, really, even 74AC should work fine at 5V with 3.3V inputs.
No comments:
Post a Comment