Maker Pro
Maker Pro

FREQ COUNTER help

J

John Fields

Jan 1, 1970
0
Since you were the one who didn't know how rotten a simple TTL one-shot
actually is, and had to be dragged through the calculations repeatedly
until the penny finally dropped, I think you had better give up that
second bottle of chardonnay until your brain gets back into contact
with reality.

---
TTL one-shots aren't horrible, they just have potentially large
worst-case timing variations which can easily be trimmed out with a
variable resistor.

LOL, it wasn't me who couldn't tell whether the circuit was charging
or discharging the capacitor, and it wasn't me who wanted to use the
impossible-to-reach Vcc and ground for the "worst-case" scenarios
either. As far as being dragged through the calculations goes, ISTR
it was you who had to be shown, over and over, that the numbers you
were coming up with were bogus until you finally realized what you
were doing wrong. After all, It wasn't me who wrote: "Shit. I blew
it." was it?
 
K

Ken Smith

Jan 1, 1970
0
John Fields said:
Great idea! I was also thinking if the width of a single photon
event was specified, then smearing could be used to gate a fast
clock which would actually provide the edges for the counter's clock
as well as the 1ms window.

If the detector has a "dead time" neither of these ideas will work well.
The numbers can be "dead time corrected" after the fact with a little
math.
 
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.
LOL, it wasn't me who couldn't tell whether the circuit was charging
or discharging the capacitor,

I did get a little bored with the process and wasn't giving it my full
attention.
and it wasn't me who wanted to use the
impossible-to-reach Vcc and ground for the "worst-case" scenarios
either.

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.
As far as being dragged through the calculations goes, ISTR
it was you who had to be shown, over and over, that the numbers you
were coming up with were bogus until you finally realized what you
were doing wrong. After all, It wasn't me who wrote: "Shit. I blew
it." was it?

"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.
 
P

Paul Taylor

Jan 1, 1970
0
Ken Smith said:
If the detector has a "dead time" neither of these ideas will work well.
The numbers can be "dead time corrected" after the fact with a little
math.

And how could i correct the dead time ken?
 
J

John Fields

Jan 1, 1970
0
Hi John sorry for the delay in replying the thread has sort of like split of
in all direction and i have been having problems with my news server, in a
nutshell

I have bought in a photometer which in turn is connected to a bought in
pulse amplifier discriminator (pad) this is from electron tubes part AD7,
this needs to be feed into a counter to count the pulses which I am to
build, the telemetry system is already in
place which I haven't built, the bottom line is I need to count the output
from the pad which counts the sodium particles and get this count back down
to earth.

I have a 1khz gate pulse for the count and 833khz (Clock signal) for sending
out the data via the telemetry system which is already in the rocket, i need
to count upto 2 power 16 or 65536 it is expected to loose the first bit so
32768 is an excepted maximum count.

---
Something is very wrong here.

The AD7 has a pulse-pair resolution of 24ns which, AIUI, is the
minimum quiet time which must elapse between input pulses from the
PMT in order for them to be distinguished as separate events.

Now let's say that you've got a perfect system with super-duper PMT
which puts out 10ns pulses which can trigger the AD7 every 34ns.
The best you could do then, would be to have a train of pulses
coming out of the AD7 which would look like this:

->| |<--34ns
_ _ _
__| |_____| |_____| |____


Since 1ms is a million nanoseconds, the number of pulses coming out
of the AD7 in that time would be:


1000000ns
----------- = 29411 pulses
34ns

Which is fewer, even, than your new 32768 count spec.


Also, I don't know what you mean by "loose the first bit" and how
that would degrade the count by a factor of 2.
 
J

John Fields

Jan 1, 1970
0
If they were equidistant (only ever *your* assumption, not *the*
assumption), then where did your figure of 10ppm materialize from and
why would that figure need to be a "first-cut look"? Can't you take the
numbers 1e-3 and 65536 and divide them?


No wedgies here, old chap. I simply pointed out that your assumptions
were flawed and hence your post was meaningless. You're the one getting
all steamed up.

I'll leave you to post the last insult, I suspect it's your style.

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"?
 
I

ian field

Jan 1, 1970
0
Ken Smith said:
... or ...

You can use two counter circuits and toggle between them every ms. This
way you've got a little time to latch the value away.

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

YD

Jan 1, 1970
0
that is it in a nutshell, i can get it to run a 1sec gate but not 1msec?

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.
 
R

Rick

Jan 1, 1970
0
John said:
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"?
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.
 
K

Ken Smith

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

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.
 
K

Ken Smith

Jan 1, 1970
0
If the detector has a "dead time" neither of these ideas will work well.
The numbers can be "dead time corrected" after the fact with a little
math.
[...]
And how could i correct the dead time ken?

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
 
J

John Fields

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

---
Yes, but the detection time between events is limited by the
detector.

Your example of, as I recall, 100 events per nanosecond isn't
anything a PMT can resolve, so your example was, at best,
inaccurate.
---
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.

---
What you obviously missed is that the PAD issues output pulses of
identical widths for _any_ detected event and, then, when that event
dies away and there's time for the system to recover, another hit
can be detected.

That output pulsewidth added to the recovery time of the system
exquisitely defines its throughput, regardless of the spacing or
coincidence of the input photons.
 
R

rick H

Jan 1, 1970
0
John Fields said:
What you obviously missed is that the PAD issues output pulses of
identical widths for _any_ detected event and, then, when that event
dies away and there's time for the system to recover, another hit
can be detected.

That output pulsewidth added to the recovery time of the system
exquisitely defines its throughput, regardless of the spacing or
coincidence of the input photons.


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.
 
J

John Fields

Jan 1, 1970
0
You've changed your argument - I originally said that two closely-spaced
events (I just made the numbers up as an example)

---
My argument hasn't changed at all; I posited a chain of equidistant
pulses, which is the best the system can do, and you objected with
your ridiculous "bursty" hypothesis. Ridiculous because it's
certainly possible for the PMT to be hit with 100 photons in a
nanosecond, but there's no way it could resolve the hits as distinct
events.
---
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.

---
Yes, and my original pulse train was just that; a series of pulses
with widths and spacing which will allow the system to achieve its
maximum throughput.
---
Given that you know that the PAD spurts out specific pulse widths rather
than impulses, why did you suggests this "smearing" approach elsewhere?

---
I considered using the input to the PAD (the output of the PMT) as a
gate to allow a counter to accumulate fast clocks during the length
of the input, the rationale being that multiple hits would create a
wider output from the PMT. However, I found that wasn't necessarily
true and was a bad idea. That's why I replied to the op's request
for an explanation with : "I was thinking of something else."
---
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.

---
You seem to have a remarkable grasp of the obvious.
---
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.

---
Who guessed? Initially all there was to work with was the OP's
65536 pulses which he wanted to stuff into a millisecond, yielding a
period of about 1.53E-8s. That's 15.3ns, and since there are one
million nanoseconds in a millisecond, one pulse period would be 15.3
parts per million. So, in order not to miss a pulse or count an
extra pulse, the window would have to be one millisecond long with a
tolerance of less than +/- 15.3 ppm. Something like 10ppm, just for
grins.
 
J

John Fields

Jan 1, 1970
0
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.

---
Riiiight... Sure Bill, whatever you say.
---

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.

---
That's not true. Worst case design is used to determine whether a
particular design will operate within the desired limits under a
given set of circumstances which are real. By choosing Vcc and
ground as the limits, that sets the spread wider than it would
really be. Convenient on your end, since you can use that larger
spread as "evidence" that the device is improper for the
application, whether it's true or not.
---
"Shit, I blew it" referred to a failure of attention, not of
comprehension.
 
J

John Fields

Jan 1, 1970
0
---
Oops... I had intended to post this to the "flag desecration"
thread, if at all, but I clicked the wrong thing. Sorry 'bout
that...
 
Ken said:
If he doesn't, there is the option of a frequency multiplying PLL to
consider.


It doesn't need to be synchronous. Only the first stage needs to be able
to start and stop in one cycle. The rest of it can be a ripple counter.
If you wait for things to calm down after the first stage is stopped, the
rippling will finish before you read the counter.

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.
 
M

Michael A. Terrell

Jan 1, 1970
0
As for rattling Phil Allison's cage - the longer we keep him mad, the
better the chance that he will blow a blood vessel and lose his
capacity to manipulate a keyboard. This would be a rather pyschopathic
motivation if one considered Phil to be fully human.


The same could be said for you, Bill.


--
Service to my country? Been there, Done that, and I've got my DD214 to
prove it.
Member of DAV #85.

Michael A. Terrell
Central Florida
 
Top