FREQ COUNTER help

It sounds like you need two counters, running more-or-less independently. One simply counts up, every photon. The other counts up every millisecond, at which time you read the current photon count (input the state of the photon counter) and subtract from it the photon count at the last one-millisecond tick; this gives you "how many photons were captured during millisecond N", so to speak. With a micro, a millisecond is like a year[1] - it'd be almost trivial to write some data-logging S/W that could keep up with that.

Good Luck! Rich [1] In microprocessor years, of course. ;-)

****__A__**** master. ;^j

Good Luck! Sandbox Moderator

Well, that is kinda what the newsgroup is for. If you're acting civilized, you can usually get decent answers, but you do need to learn to ignore the trolls. :-)

There's no stupid question, except the one that you ask three times in a row because you don't like the other answers. ;-)

Cheers! Rich

I just did a little research on photon counting, and some of it is interesting. There appear to be various applications from quantum cryptography to spectrum analysis and laser stimulated fluorescence. In general, it appears that count rates of 1 MHz to 10 MHz and higher are common, and the discriminator creates shaped output pulses of 10 to 30 nSec with similar dead times. There are plug in computer boards available to interface to the discriminator output for storage and analysis of the pulses, but you probably need a small stand-alone system. It should not be difficult to build a 16 bit binary counter that will run at up to 100 MHz. You can use a fairly accurate 1 mSec timebase in a PIC to reset and enable the counter, disable it 1 mSec later, and read the 16 bits and transmit during the second 1 mSec period.

A good reference from Hamamatsu seems to be:

Many more can be found using a dogpile search (which includes Google).

Good luck,

Paul

[addendum to previous post]

BTW, I think this thread went on a wrong tangent because what you want is not really a frequency counter (which assumes a fixed frequency), but an events counter, even though you may want to determine the frequency (as in how frequent) of photons detected in a period of time.

Paul

"Paul Taylor"

** So you have NO idea what frequency is ??

And you still don't.

Bugger off - wanker.

....... Phil

Hi martin it is going up in a rocket funded by various other university along with us from a launch pad in Norway.

So you are the troll they all keep telling me about?

"Paul Taylor"

----------------------------------------------------- Paul Taylor BSC (Hons) Electronics Technician School of Environmental Science University of East Anglia Norwich NR4 7TJ

Phone: +44 (0)1603 592502 Fax: +44 (0)1603 591327

** So this POSTURING ASS still has NO idea what frequency is.

Bugger off - Pommy WANKER .

....... Phil

As you'd know if you followed the postings on high speed logic, John Larkin our guru on that particular subject - I laid out my only ECLinPs board around 1996, as a retrofit into a TTL-based pulse generator for electron spin resonance, and lack current hand-on experieince.

All that board was doing was re-synchronising the TTL output to a

200MHz ECL clock which happend to be available in the system. The resynchronised output was converted back to TTL at the output of the board, but we still got rid of a sub-nanosecond pattern dependent jitter that had been detectable in the ESR spectra.

This gave me the credibility to go forward with a fully ECL-based pulse generator for the ESR system, for which I managed to complete the schematics (some hundred odd pages of Orcad) before the researcher found out that he was too old to be allowed to take on any more graduate students to use the ESR machine, and the whole project got canned.

The coarse timing was to have been done from a 500MHz crystal-controlled oscillator which I was going to buy from Vectron - something like this

and MC100E016 counters, while the fine timing was going to be handled by MC100E195 programmable delays (which are guaranteed to provide at least 2nsec of programmable delay variation).

The interesting bits were getting the data from static RAM into the ECL side at the necessary rate, and compensating for the horrid temperature dependence of the MC100E195

In the end I elected for automatic self-calibration, by getting the system to take a miilsecond out from time to time to generate 129 different 80MHz pulse-width modulated waveforms whose DC levels we were going to digitise to 12-bits over a microsecond or so apiece to let us wok out what the MC100E195 was actually doing at the time for each of the 128 states of the inputs, plus one measurement with a minimum delay in the MC100E195 and an extra 2nsec worth of clock delay.

The printed circuit layout was going to be interesting, but no more interesting than the layouts that I'd supervised at Cambridge Instruments for the electron beam tester in 1989-`1991, with its mix of

100k ECL and Gigabit Logic GaAs where the coarse clock ran at 800MHz.

--
Bill Sloman, Nijmegen

--
Nope. 

He needs one counter to accumulate the photon events and another to
generate the count enable for the photon counter, plus some glue
logic for the clear and the data read/latch (maybe).

It's doubtful whether he could generate the time base for the enable
with just a µC since he needs something with an accuracy of around
10ppm to generate the enable window in order to get the +/- 1 photon
resolution he's looking for.  Maybe less than 10ppm, that's just a
first cut look at it.

No, Phil isn't a troll - who are people who posts stuff that they expect to generate controversy.

Phil is just some kind of sociopath with a very short fuse. Once he gets irritated, he keeps on flaming the object of his irritation for the most minor of imagined faults.

Sadly, his abuse is unoriginal and repetitive. Ignore him. He won't go away, but you won't waste the time responding to an intellectual black hole.

--
Bill Sloman, Nijmegen

Cheers for that bill, any way i don't seem to be progressing to far on this build ,i have tried using various counters ect which works fine at 1hz gate pulse im unsure on where im going wrong.

--
Pretty impressive for someone who stumbled over a simple TTL
one-shot.

But, I guess, there's always many a slip 'twixt the cup and the lip.
;)

** Got that right at least.

All the rests was just another load of f****ng bollocks from a demented, grossly autistic arrogant old fool.

Peeeukeeee.

........ Phil

It seems that he has got to deal with the output from an Electron Tubes

pulse-pair discriminator which produces TTL pulses with a pulse pair discrimination of 24nsec (whatever that means exactly). I've gone after Electron Tubes for a detailed data sheet, but I'm not too optimistic - when I worked for EMI Central Research in 1976-79 back when Electron Tubes was part of the EMI group, I had an interaction with them the ended up with me giving them my translation of a very comprehensive German paper on photo-multiplier linearity that they hadn't even heard about.

Their web-site is now so incompetently set out that I can't find out if the reference ever got into their advice on photomultiplier linearity - it certainly hadn't the last time I looked.

Assuming that the pulse-pair resolution means what I think it ought to mean, Paul's counter won't have to deal with photon pulses narrower than about 12nsec or occuring at a higher frequency than 41.7MHz.

In order to avoid problems from "pulse pile-up" the physicists who devised the experiment probably set up the system for a maximum average count rate of about 2MHz - the photons are almost certainly going to appear at random intervals, and if the amplifier discriminator has a dead time of 24nsec, the change of getting two photons within a 24nsec period (and missing the second one) will be about 5%, at an average rate of 2MHz which is manageable and correctable.

So Paul has to count up to 2000 events over a 1msec interval - a 12-bit counter should be good enough (4096 counts). You could use three

74AC163 4-bit synchronous counters or 74ACT163

configured as in Figure 2 in the data sheet.

As has been mentioned elsewhere, he'd probably want two pairs of counters, one to do the counting in even milliseconds, to be read out in odd milliseconds while the other counts up in the odd milliseconds and is read out (and cleared) during even milliseconds.

If I were to do this I'd probably try and do the whole thing in a Xilinx Coolrunner II programmalbe logic part. As programmalbe logic goes, these are relatively low power parts, with more than enough bistables to realise a pair of 12-bit counters while fast. enough to handle the 24nsec pulse-pair discrimination.

I've not used them, though I've got 17 of them in a cupboard somewhere

- that was the minimum I could buy, and then I got stuck for totally unnecesary UPS delievery charges ...

They ae in-circuit programmable (and re-programmable) and the programming software could be downloaded from the Xilinx web-site the last time I looked.

--
Bill Sloman, Nijmegen

What are the part numbers and web links to the photometer and pad?

How do you know that the emission of these photons isn't bursty - nothing for a while, and then 100 in a nanosecond? If that's the case, your 10ppm guess is hopeless. You need to know the *maximum* expected event-rate in order to determine the counter's maximum increment rate and in order to know the accuracy of the ms clock required for +/- 1 photon "resolution".

--
Rick

Hi Fred the photometer isn't supplied by me so im unsure on the full spec as for the pad it is from Electron tubes Type AD7