Pulse Counter Hates Certain Numbers

[Cyberdragon]

I'm having a strange problem with this circuit:

http://www.rfcafe.com/references/popular-electronics/build-numeric-glow-tube-dcu-2-1970-popular-electronics.htm

(three tube Utilogic version)

The problem is that if you have the number 1255 on display, then you reset and input 1200 pulses, it always comes out exactly 455 on the display. I'm not sure what other number combinations cause this, but I've never seen this before. I'm certain it's not the code driving it either, as I've told it to count each pulse with a number output and there are exactly 1200. I have not seen any other numbers (higher or lower) do this either (so far) and inputting 1200 directly does not cause it, only changing 1255 (or possibly other numbers) to 1200. I don't think it's an interference (wire cross-talk) problem either, as it's always exactly 455, so it's some sort of logic fault.

Any ideas?

EDIT: After looking at it, it appears to be failing to reset somehow if at 1255 (I did not test this directly yet but will when I get the chance). 1255+1200=2455 So that combination of digits is somehow keeping it from clearing properly.

[duak]

Wow, blast from the past - I haven't seen RTL logic circuits for a long time.

1.) are you using the original RTL parts?

2.) how wide is the reset pulse?

It looks like the circuit is an asynchronous bi-quinary counter.  One thing to look into is that state transitions ripple thru the counter and if the reset pulse isn't wide enough, a slow flip-flop may generate a transition after the reset which clocks the following stages.

Also, I see that the the Q/ output of the 4th stage of the counter is wire-or'ed with a gate.  I don't have a data sheet for the MC791 but if memory serves it is buffered, ie. an open collector output.  I believe this prevents its state from being influenced by any load but makes the MC791 slower.  It also means that pullup resistors are mandatory on its outputs if they are to be active.

Don Lancaster wrote the "RTL cookbook" which is available at: www.tinaja.com%2Febooks%2Frtlcb.pdf&usg=AOvVaw2f0tqu9bClUeeO5aoEhgmf

Best o' luck

[Cyberdragon]

Wow, blast from the past - I haven't seen RTL logic circuits for a long time.

1.) are you using the original RTL parts?

2.) how wide is the reset pulse?

It looks like the circuit is an asynchronous bi-quinary counter.  One thing to look into is that state transitions ripple thru the counter and if the reset pulse isn't wide enough, a slow flip-flop may generate a transition after the reset which clocks the following stages.

Also, I see that the the Q/ output of the 4th stage of the counter is wire-or'ed with a gate.  I don't have a data sheet for the MC791 but if memory serves it is buffered, ie. an open collector output.  I believe this prevents its state from being influenced by any load but makes the MC791 slower.  It also means that pullup resistors are mandatory on its outputs if they are to be active.

Don Lancaster wrote the "RTL cookbook" which is available at: www.tinaja.com%2Febooks%2Frtlcb.pdf&usg=AOvVaw2f0tqu9bClUeeO5aoEhgmf

Best o' luck

Yes, it's all original, but it's Utilogic as I said. So it's not an MC791, it's an SP380A. I didn't build it, I got it from an estate sale or something (don't quite remember).

I'm driving it with an RPi through optocouplers. It has internal pullups, and the inputs are inverted (ground is 1).

The reset pulses are normally 0.1mS (same as the count pulses). It's got to be a timing issue or something, so I'll experiment with different times. Also, I'm using sleep() so it might be a problem with the Pi not firing the reset properly for some reason.

EDIT: Yep, a reset pulse of 0.1mS has no effect on the number 1255 (or 3255 with 1255 shown on the tubes). However it works when other numbers, even higher ones, are shown on the display. It just locks up with the number 1255, and apparently 1256 as well, but not 1254 or 1257 or any other numbers ending in 5 or 6.

[Cyberdragon]

After experimenting, it seems to take about 20mS to reset the numbers 1255 or 1256, compared to 0.1mS for other numbers. Is it a bad chip or poor design?

[Cyberdragon]

The old fart of a machine is innocent!

It's the damn Rasberry Pi! It's glitching with certain memory values (the numbers are stored in a global)! I'm using the exact same two functions (identical globals and locals as well) that drive the display that I used when I found the 20mS time difference. However, when I put those two functions into the code where I originally discovered the problem, and it doesn't work at all (with the two offending numbers), even with 100mS! It's like the pin (or maybe sleep() ) just doesn't even work anymore in those conditions (the 1200 comes out through print() all the way at the end of the function where it's supposed to, which is after it's told to reset the count).

Not sure what code is at fault here, whether it's Python, Raspbian, or some hardware issue. But I'll try updating Python and seeing if that fixes it (I'm on 3.4.2 currently).

[Cyberdragon]

Ok, so updating python made the code actually function at all.

But the reset seems to still be slow, I guess the chips are just old. I swapped some chips around and it seems a little better, but I may have to replace them eventually.