FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups 
 ProfileProfile   PreferencesPreferences   Log in to check your private messagesLog in to check your private messages   Log inLog in 
Forum index » Electronix » design
FREQ COUNTER help
Post new topic   Reply to topic Page 7 of 8 [113 Posts] View previous topic :: View next topic
Goto page:  Previous  1, 2, 3, 4, 5, 6, 7, 8 Next
Author Message
Rick H
electronics forum beginner


Joined: 19 Jul 2005
Posts: 18

PostPosted: Wed Jul 19, 2006 10:24 pm    Post subject: Re: FREQ COUNTER help Reply with quote

John Fields wrote:

Quote:
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.


--
Rick
Back to top
Ken Smith
electronics forum Guru


Joined: 06 May 2005
Posts: 1727

PostPosted: Thu Jul 20, 2006 2:14 am    Post subject: Re: FREQ COUNTER help Reply with quote

In article <GFwvg.45251$OT.11790@newsfe6-win.ntli.net>,
ian field <dai.ode@ntlworld.com> wrote:
Quote:

"Ken Smith" <kensmith@green.rahul.net> wrote in message
news:e9hafp$84b$3@blue.rahul.net...
In article <12bncevgot1dm49@corp.supernews.com>,
Meindert Sprang <ms@NOJUNKcustomORSPAMware.nl> wrote:
[...]
Ok, so use a 16 bit counter which you read-and-reset every ms. You need a
VHF capable prescaler (/256 or so) and then feed it into some counter or
microcontroller with an external counter input.

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

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.

--
--
kensmith@rahul.net forging knowledge
Back to top
Ken Smith
electronics forum Guru


Joined: 06 May 2005
Posts: 1727

PostPosted: Thu Jul 20, 2006 2:18 am    Post subject: Re: FREQ COUNTER help Reply with quote

In article <e9lhr5$8l5$1@cpca14.uea.ac.uk>,
Paul Taylor <paul.taylor@uea.ac.uk> wrote:
Quote:
"Ken Smith" <kensmith@green.rahul.net> wrote in message
news:e9lgv4$gmp$5@blue.rahul.net...
[...]
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


--
--
kensmith@rahul.net forging knowledge
Back to top
John Fields
electronics forum Guru


Joined: 24 Mar 2005
Posts: 3260

PostPosted: Thu Jul 20, 2006 2:55 am    Post subject: Re: FREQ COUNTER help Reply with quote

On Thu, 20 Jul 2006 00:21:25 +0100, Rick <rik_nntp@dsl.pipex.com>
wrote:

Quote:
John Fields wrote:

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.

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

Quote:
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.


--
John Fields
Professional Circuit Designer
Back to top
Rick H
electronics forum beginner


Joined: 19 Jul 2005
Posts: 18

PostPosted: Thu Jul 20, 2006 7:53 am    Post subject: Re: FREQ COUNTER help Reply with quote

John Fields <jfields@austininstruments.com> wrote:

Quote:
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.

--
Rick
Back to top
John Fields
electronics forum Guru


Joined: 24 Mar 2005
Posts: 3260

PostPosted: Thu Jul 20, 2006 12:58 pm    Post subject: Re: FREQ COUNTER help Reply with quote

On Thu, 20 Jul 2006 07:53:47 GMT, rick H <rik_nntp@dsl.pipex.com>
wrote:

Quote:
John Fields <jfields@austininstruments.com> wrote:

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)

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

Quote:
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.
---

Quote:
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."
---

Quote:
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.
---

Quote:
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.
---

Quote:
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.

---
More thorough and less caustic would have been nice.
---

Quote:
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.

---
No, it's what _you're_ now saying. I always postulated a train of
maximum-density detectable pulses and you're only now coming around
to it while trying to make it seem like it's been your position all
along.


--
John Fields
Professional Circuit Designer
Back to top
John Fields
electronics forum Guru


Joined: 24 Mar 2005
Posts: 3260

PostPosted: Thu Jul 20, 2006 12:59 pm    Post subject: Re: FREQ COUNTER help Reply with quote

On 19 Jul 2006 08:01:31 -0700, bill.sloman@ieee.org wrote:

Quote:

John Fields wrote:
On 18 Jul 2006 19:52:49 -0700, bill.sloman@ieee.org wrote:


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.

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.

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


Quote:
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.

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

Quote:
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: "s**t. I blew
it." was it?

"s**t, I blew it" referred to a failure of attention, not of
comprehension.

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


Quote:
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.

---
Just dumb luck.
---

Quote:
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.

---
Yup, mea culpa.

But, Madam, in the morning I'll be sober and you'll still be ugly.


--
John Fields
Professional Circuit Designer
Back to top
John Fields
electronics forum Guru


Joined: 24 Mar 2005
Posts: 3260

PostPosted: Thu Jul 20, 2006 2:28 pm    Post subject: Re: FREQ COUNTER help Reply with quote

On Thu, 20 Jul 2006 07:59:23 -0500, John Fields
<jfields@austininstruments.com> wrote:

Quote:
On 19 Jul 2006 08:01:31 -0700, bill.sloman@ieee.org wrote:


John Fields wrote:
On 18 Jul 2006 19:52:49 -0700, bill.sloman@ieee.org wrote:


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.

---
Oops... I had intended to post this to the "flag desecration"
thread, if at all, but I clicked the wrong thing. Sorry 'bout
that...


--
John Fields
Professional Circuit Designer
Back to top
Bill Sloman
electronics forum Guru


Joined: 12 May 2005
Posts: 1080

PostPosted: Thu Jul 20, 2006 5:32 pm    Post subject: Re: FREQ COUNTER help Reply with quote

Ken Smith wrote:
Quote:
In article <1153139085.236239.262300@35g2000cwc.googlegroups.com>,
bill.sloman@ieee.org> wrote:

Paul Taylor wrote:
Hi i am presently trying to build a counter that counts freq upto 65536 Khz
in less than 1 msec is this possible also has any one any ideas to where i
should start thanks in advance for your help.

Obviously enugh, a counter driven at 65536kHz - I presume you mean
65.536MHz - will accumulate 65536 counts in one millisecond.

If he doesn't, there is the option of a frequency multiplying PLL to
consider.

A 16-bit wide synchronous counter capable of running at 66MHz isn't
entirely trivial.

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.

--
Bill Sloman, Nijmegen
Back to top
Rick H
electronics forum beginner


Joined: 19 Jul 2005
Posts: 18

PostPosted: Thu Jul 20, 2006 9:14 pm    Post subject: Re: FREQ COUNTER help Reply with quote

John Fields wrote:

Quote:
On Thu, 20 Jul 2006 07:53:47 GMT, rick H <rik_nntp@dsl.pipex.com
wrote:

John Fields <jfields@austininstruments.com> wrote:

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)

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

So a scenario that the detector can't deal with is ridiculous, rather than,
say, a failure of the detector or counter to be able to count all the
events you might like it to count.

Let's remind ourselves exactly what your "maximum throughput" pulses look
like, as described a couple of posts ago: "65536 pluses were spaced
equidistantly in a window 1.0 pulse or minus something millie seconds
wide."
You've imposed a requirement on the PAD to spurt out pulses exactly every
1/65535ms. I don't think it will be that accommodating. If the pulses are
shorter and you're still sampling at 1/65536 ms, you'll fail to detect some
pulses. If the pulses are longer, you'll sometimes double-clock on a
single event pulse. Both scenarios give you a miscount.
In fact, the only way to get it right is to make sure that the clock you're
gating is going to transition EVERY time the PAD happens to pulse. If that
means sampling more often than 1/65536ms and that the counter MAY overflow
in any given ms, then so be it. If that means sampling less frequently
than 1/65536ms and that the counter WILL NEVER overflow in any ms period,
then so be it. The point being, of course, that you must adjust your clock
to the maximum event rate, not hope that the maximum event rate just
happens to be related to your clock's bit-width and the reporting interval.
Accounting for the maximum event rate (albeit the maximum at the PAD
output, which I hadn't reckoned with before) is what I've being saying all
along.


Quote:
---

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

Fair enough.

Quote:
---

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,

Nope. 65536 comes from the maximum count from the counter (which is
presumably 65535), it does not come from the period of the pulses from the
PAD. If you hypothesise 1/65536ms pulses in order to determine the ppm
accuracy of the ms clock required for 1 event accuracy, you've blown it,
because the actual maximum rate from the PAD may be slower (in which case
your tolerance is too tight, but obviously that's okay) or faster (in which
case your tolerance isn't tight enough).

Quote:
yielding a
period of about 1.53E-8s. That's 15.3ns, and
since there are one million nanoseconds in a millisecond,

what was that about me stating the obvious!?

Quote:
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.
---

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.

---
More thorough and less caustic would have been nice.

Caustic replies emerge from being called an a*****le. Being English, I prefer
the term "arsehole".


Quote:
---

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.

---
No, it's what _you're_ now saying. I always postulated a train of
maximum-density detectable pulses and you're only now coming around
to it while trying to make it seem like it's been your position all
along.

Trouble is, you define maximum density (see 2 or 3 of your posts ago) in
terms of the 1ms reporting period and in terms of the bit-width of the
counter. Better tell the PAD your assumptions.


--
Rick
Back to top
Michael A. Terrell
electronics forum Guru


Joined: 24 Mar 2005
Posts: 2291

PostPosted: Thu Jul 20, 2006 9:25 pm    Post subject: Re: FREQ COUNTER help Reply with quote

bill.sloman@ieee.org wrote:
Quote:

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
Back to top
John Fields
electronics forum Guru


Joined: 24 Mar 2005
Posts: 3260

PostPosted: Thu Jul 20, 2006 9:29 pm    Post subject: Re: FREQ COUNTER help Reply with quote

On 19 Jul 2006 02:46:44 -0700, bill.sloman@ieee.org wrote:


Quote:
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.

---
When not having to deal with some of the less-than-human lifeforms
infecting this forum, Phil often comes into his own and offers
outstanding advice, I've found. YMMV.


--
John Fields
Professional Circuit Designer
Back to top
martin griffith
electronics forum Guru


Joined: 06 May 2005
Posts: 1098

PostPosted: Thu Jul 20, 2006 10:11 pm    Post subject: Re: FREQ COUNTER help Reply with quote

On Thu, 20 Jul 2006 21:25:02 GMT, in sci.electronics.design "Michael
A. Terrell" <mike.terrell@earthlink.net> wrote:

Quote:
bill.sloman@ieee.org wrote:

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.

Phil is fun, his verbal/keyboard skills are somewhat limited when it
comes to adjectives, he does needs some lessons in subtlety, wit and
sarcasm, and Bill seems to know a lot more than me, as does that Jim
dude from Az, and despite significant differences in political
philosophy I'm happy to see what any of them has say about technology.



martin
Back to top
Bill Sloman
electronics forum Guru


Joined: 12 May 2005
Posts: 1080

PostPosted: Thu Jul 20, 2006 11:03 pm    Post subject: Re: FREQ COUNTER help Reply with quote

John Fields wrote:
Quote:
On 19 Jul 2006 02:46:44 -0700, bill.sloman@ieee.org wrote:


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.

---
When not having to deal with some of the less-than-human lifeforms
infecting this forum, Phil often comes into his own and offers
outstanding advice, I've found. YMMV.

On his chosen subjects he is pretty good, but he does degenerate into
snarling rage remarkably quickly, and he remains incensed for
remarkably long periods.

--
Bill Sloman, Nijmegen
Back to top
Bill Sloman
electronics forum Guru


Joined: 12 May 2005
Posts: 1080

PostPosted: Thu Jul 20, 2006 11:06 pm    Post subject: Re: FREQ COUNTER help Reply with quote

Michael A. Terrell wrote:
Quote:
bill.sloman@ieee.org wrote:

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.

But I said it first. You have to invent your own abuse if you want to
get any brownie points.

And I don't show much sign of blowing a blood vessel.

--
Bill Sloman, Nijmegen
Back to top
Google

Back to top
Display posts from previous:   
Post new topic   Reply to topic Page 7 of 8 [113 Posts] Goto page:  Previous  1, 2, 3, 4, 5, 6, 7, 8 Next
View previous topic :: View next topic
The time now is Wed Nov 22, 2017 12:48 pm | All times are GMT
Forum index » Electronix » design
Jump to:  

Similar Topics
Topic Author Forum Replies Last Post
No new posts Freq response of SB Audigy Abstract Dissonance Basics 3 Tue Jul 18, 2006 3:49 pm
No new posts speaker freq response David McDivitt Basics 20 Fri Jul 14, 2006 6:09 pm
No new posts High-speed counter for frequency counter project Ben Jackson design 10 Wed Jul 05, 2006 12:50 am
No new posts FS: Original Heathkit frequency counter manuals Al Schapira Repair 0 Wed Jun 21, 2006 3:30 pm
No new posts Fastest counter? eromlignod design 25 Fri Jun 02, 2006 7:31 pm

Copyright © 2004-2005 DeniX Solutions SRL
Other DeniX Solutions sites: Unix/Linux blog |  Unix/Linux documentation |  Unix/Linux forums |  Medicine forum |  Science forum  |  Send and track newsletters


Powered by phpBB © 2001, 2005 phpBB Group