FREQ COUNTER help

Easily trimmd out? The resistor has got to be low enough to sink 2mA from an input at 0.8V into an output at 0.4V which is to say, 200R or less, so it needs to be trimmable down to 20R to get your 10:1 turn-down. The output impedance of a TTL output in the high state when sourcing curent is already about 20R, so this is a very dubious propostion.

Throw in that you are going to have to select your capacitor out of the E6 range - each value about 1,5 times the one below it, and life gets difficult.

And neither pots nor the time to trim them is all that cheap, and making space for the pot on the PCB as well as making sure that final test can get at the pot with a screwdriver (don't laugh = I've seen draughtspersons screw that up) doesn't help either.

Sensible people use purpose-designed monostables, if they have to use a monostable at all - when my junior engineers wanted to use bodged single gate monostables we almost always solved the problem by making the relevant bit of the circuit by clocking the data into a latch at the right time, which offers many fewer wau=ys if getting things wrong.

I did get a little bored with the process and wasn't giving it my full attention.

Vcc and ground may be impossible to reach, but they do have the virtue that it is quite impossible for the output to go higher or lower, no matter what you assume about the transistors involved - chose these as extreme values and you can at least be confident that real examples of the circuit won't behave any worse. That is what "worst case" design is all about, not clever guesswork (rather less than clever in your case) about whee the boundaries "really" lie.

"Shit, I blew it" referred to a failure of attention, not of comprehension.

My numbers weren't bogus, they merely represented more conservative (more risk-averse) choices of extreme conditions. Even when we choked the worse cases down to numbers that you'd guessed to be okay, the broad-brush conclusion stayed where it was when I started out.

It was you who didn't know that TTL outputs have a guaranteed minimum high level of 2.4V, not the 3.3V you pulled from some cockanamy web-site when you should have been reading the datasheet.

And how could i correct the dead time ken?

--- Your post and this thread actually should be part of "flag desecration"' so if you'd care to take it over there I'll be happy to reply to it.

-- John Fields Professional Circuit Designer

Rather than an insult, I'll leave you with a question. How do you propose that the input signal to the counter will be "bursty"?

Or use a C/R differentiator (spike generator) to pulse a row of D-flipflops to latch the data ready for the devcoder driver.

If the 833 kHz is the data clock, you can easily get 1 ms time-slices. In the second scheme suggested shift the data to a uC and let it chomp on the bits on the way to the modulator. You may even have space enough in a transmission slice for data from some other sensor. I assume transmission is VHF.

But first take care of the original question, what to use for a front-end in the counter.

This is not really my field. I know enough to dream up something that might be workable but the practical implentation would be a bit of a job.

- YD.

The OP is detecting photons, which turn up randomly, not regularly spaced in time.

I've just poked around on Electron Tube's website, and here's what they say on the subject of photon counting, "The maximum signal count rate required of the detector is an important specification parameter."

In my original post, I said "You need to know the maximum expected event-rate in order to determine the counter's maximum increment rate". Not identical, but the gist is the same.

Huh??????? I don't get what you mean here. Is this a suggestion of how to latch the data from the counter method I suggested or a replacement for it. It doesn't make a lot of sense to me as either.

Each pulse that happens causes the detector to be unable to see a second one for a fixed amount of time.

LiveTime = 0.001 - DeadTimeLength * PulsesSeen

RealRate = PulsesSeen / LiveTime

You've changed your argument - I originally said that two closely-spaced events (I just made the numbers up as an example) defined the ppm accuracy required of the ms timer to produce +/- 1 event accuracy per ms "time bin". You started arguing that you'd assumed they were equally spaced, but now you're saying that it's the width of the pulses from this PAD gizmo (plus the dead time) which count - which is certainly true.

Given that you know that the PAD spurts out specific pulse widths rather than impulses, why did you suggests this "smearing" approach elsewhere? It's already done by the PAD. I suppose you could further smear the pulse to the end of the recovery time, but any more than that and you'll miss the next detectable event - you'll increase the dead-time.

Given that you know the that PAD output's pulsewidth is "equisitely defined", why guess at 10ppm accuracy on the timer? The accuracy can be deduced from the ratio the pulsewidth+dead-time to the ms period.

I guess I should originally have been more thorough and said that you need to know the minimum time interval between events *that the detector can distinguish and hence that the counter can count* in order to determine the ppm accuracy. In the case that of a discriminator with memory and a dead-time, that simplifies to "what's the length of that memory of an event plus the deadtime", which is what you're now saying.

First counter I ever put on a printed circuit board worked that way - a monstable stopped you reading the counter until the last count had rippled all the way through. That was back in 1972.

Nowadays that sort of trickery is rarely necessary - though I did extend an MC100E016 based counter with an 74HCT40103 a few years back for a particularly cheap-skate customer. It cost more in design time than it could ever save in parts costs, but it was quite fun to do.

The same could be said for you, Bill.