Prev: Write to Geneva and plead the citizens of Geneva to block the entrances to LHC.
Next: Real Estate Agents Are Taking The Power
From: George Herold on 26 Mar 2010 17:35
On Mar 26, 3:57 pm, whit3rd <whit...(a)gmail.com> wrote:
> On Mar 24, 6:31 pm, George Herold <ggher...(a)gmail.com> wrote:
>
> > > Red Lion Controls 'sub-cub' counter...
> > > Are you accounting for pile-up effects at high count rates?
>
> > Thanks Whit3rd, the 10kHz count rate won't cut it.
>
> It's about 500 kHz (that 10 kHz number was 3V worst case value).
>
> Yeah, the counter is a tad underpowered.  Most micros (the PICs
> in particular) are weak on counter functions.   Best bet is something
> with a true counter/timer module, and some preprocessing to
> take out pile-up like an up/down pre-counter.  Clock UP on input
> signal, DOWN iff nonzero, in synchrony with a local clock,
> incrementing
> the slow counter at a steady rate... a couple of stages of
> 74F193 can gobble lots of pulses fast, and disgorge at
> a compliant rate to the main counter.    Your CPU count
> is only correct after the pre-counter finishes unloading, of course.

Ahh 500kHz on the red lion... that could almost do it. I should have
looked at the specs more carefully. 1 MHz is the maximum needed count
rate and most of the time it's counting 100's of pulses a second.

You mentioned 'pulse pile-up' before, But I don't know exactly what
you are talking about. At high count rates I'll sometimes have two
pulses arriving at time's that are below the resolution of front end.
I'll just count these as one event. But you seem to be impling some
pile up at the counter. Will this be a problem at a mximum 1MHz
count rate?

Thanks,

George H.
From: John Fields on 27 Mar 2010 11:37
On Fri, 26 Mar 2010 14:15:54 -0700 (PDT), George Herold
<ggherold(a)gmail.com> wrote:

>On Mar 26, 11:58�am, Peter Bennett <pete...(a)somewhere.invalid> wrote:
>> On Thu, 25 Mar 2010 13:15:08 -0700 (PDT), George Herold
>>
>> <ggher...(a)gmail.com> wrote:
>> >Thank Bob, �my Boss has looked at a whole bunch of different
>> >commercial units from Protek, B&K, I'm not sure if we looked at any
>> >from Instek. �It looks like we are going to build our own. �At least
>> >then we know what is going on inside.
>>
>> >I was playing with a LM393 (dual of the LM339) today. �These are a bit
>> >slower than I'd like. �Any favorite compartors with perhaps a 50
>> >-100nS response time? �LM311?
>>
>> >George H.
>>
>> Have a look at Analog Devices - they have a couple with TTL or CMOS
>> outputs with 7 - 8 ns propagation delay.
>>
>> --
>> Peter Bennett, VE7CEI �
>> peterbb4 (at) interchange.ubc.ca �
>> GPS and NMEA info:http://vancouver-webpages.com/peter
>> Vancouver Power Squadron:http://vancouver.powersquadron.ca
>
>Thanks Peter, I was thinking today that maybe the spec I care about
>is the slew rate. I'd like it to get to 5V in about 100nS.. 50V/us.
>I don't think I care too much about the propigation delay. (But I
>could be wrong... I've only used the slow lm393 for switching low
>frequency stuff <1MHz.) I just don't want to miss two close together
>pulses.

---
Then what you have to decide on is the criterion which determines what's
one pulse and what's more than one, and then devise a strategy to
determine how many pulses have gone by.

JF
From: Mark Zenier on 26 Mar 2010 15:28
In article <f1426257-ef50-4545-ae17-790024fdbb6d(a)j21g2000yqh.googlegroups.com>,
George Herold <ggherold(a)gmail.com> wrote:
>
>I was playing with a LM393 (dual of the LM339) today. These are a bit
>slower than I'd like. Any favorite compartors with perhaps a 50
>-100nS response time? LM311?

Back about 25 years ago, I tried the LM311 as video amplifer to
feed a TTL input CRT monitor. More like 200 nS, as I remember.
(Replaced it with a NE592 video amp).

One of the oufits in Florida (Optoelectronics or one of their
competitors) used the LT1016(?) comparator as the input for one of
their frequency counter kit projects in Radio-Electronics magazine
back in the '80s. I think it's good for 20 nS.

Mark Zenier mzenier(a)eskimo.com
Googleproofaddress(account:mzenier provider:eskimo domain:com)

From: whit3rd on 27 Mar 2010 13:46
On Mar 26, 2:35 pm, George Herold <ggher...(a)gmail.com> wrote:

> You mentioned 'pulse pile-up' before, But I don't know exactly what
> you are talking about. At high count rates I'll sometimes have two
> pulses arriving at time's that are below the resolution of front end.

Yes, basically that's it. The pulses (300 ns) can be too close
together
for the counter to resolve, and a (say 100 kHz) counter might
need a wider pulse or spacing. 100 kHz applies to 50% duty cycle
clock, i.e. 5 us pulses, with 5 us spacing. Fast counters (74F193
does
over 100 MHz) can handle the 300 ns pulses, and down to 5 ns spaces
between pulses. The dead time of the system is then calculable,
instead of being unknown and unknowable.

The average frequency is misleading in terms of the individual random
times of pulses... and the market for 'frequency counters' doesn't
support
the timing requirements of pulse counting with appropriate
specifications.
From: George Herold on 28 Mar 2010 21:45
On Mar 27, 1:46 pm, whit3rd <whit...(a)gmail.com> wrote:
> On Mar 26, 2:35 pm, George Herold <ggher...(a)gmail.com> wrote:
>
> > You mentioned 'pulse pile-up' before, But I don't know exactly what
> > you are talking about.  At high count rates I'll sometimes have two
> > pulses arriving at time's that are below the resolution of front end.
>
> Yes, basically that's it.  The pulses (300 ns) can be too close
> together
> for the counter to resolve, and a (say 100 kHz) counter might
> need a wider pulse or spacing.  100 kHz applies to 50% duty cycle
> clock, i.e. 5 us pulses, with 5 us spacing.   Fast counters (74F193
> does
> over 100 MHz) can handle the 300 ns pulses, and down to 5 ns spaces
> between pulses.   The dead time of the system is then calculable,
> instead of being unknown and unknowable.
>
> The average frequency is misleading in terms of the individual random
> times of pulses... and the market for 'frequency counters' doesn't
> support
> the timing requirements of pulse counting with appropriate
> specifications.

OK thanks, The existing front end elecronics gives a pulse with
~100ns rise time and >300ns fall time. (Kinda crappy for a PMT,) And
I'll live with that. Most of the time the counting rates are really
low... 10's to 1,000's per second. At high rates there is some error
due to pulse overlap... we'll just ignore it.

George H.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Write to Geneva and plead the citizens of Geneva to block the entrances to LHC.
Next: Real Estate Agents Are Taking The Power