> -- Here's one of the many, many issues: Each click of the Geiger counter
> is a very narrow spike. A son of a glitch. That's very unlike anything
> a serial port was designed to handle. If you have 1000 events per
second
> with a nice 50/50 duty cycle, the serial port can handle it fine, but
> if you have even a few events per second consisting of spiky clicks
> you're gonna lose events.
Here's a trick for you. One of the commercial GM detectors I have
generates a clean 10 us TTL-level pulse for each detected event. That's
very short. To use their software you connect the pulse output to the
DE9 serial Rx pin. How can that work? Well, they set the port to 8N1 at
115200 baud and do a read. Each GM pulse then becomes a byte and you
simply time and count the arrival of bytes. Counts aren't lost even if
the program is slow to respond because the OS has generous buffers for
terminal IO.
This trick works because a 10 us wide pulse looks like a 115200 baud
(8.6 us) start bit to the serial port. So each pulse becomes one more
byte of data to be read by the program. The downside is that there is
effectively 9 bit frames of dead time (78 us) per pulse but the GM tube
has dead time too so maybe this isn't a problem. This
pretend-its-a-start-bit technique can easily handle continuous or
erratic pulse rates of many thousands per second.
I realize serial ports are out of fashion, but I find them quite simple
and versatile. I use them by the hundreds in my lab.
Obviously for nanosecond time stamping or mega sample per second capture
rates you'd want a fancier solution.