Need help detecting 20 nanosecond wide Xray pulses as data

laser-vector

Hi,

I have a project where i need to send data via Xrays.
First things first, i am building a way to measure the bandwidth from my various configurations.

This is basically my configuration:




So to break it down:
1. Propeller sends data to an LED driver (Green Channel)
2. Xrays are created while led is on
3. a detector on the other end receives xrays (as single photon events - very narrow pulses)
4. a comparator/opamp driver then converts these pulses to a TTL 3.3vdc signal (Blue Channel)
5. the same propeller is connected to to detector and interpenetrates xray pulses as logic 1 and no xray pulses as logic 0
6. the propeller already knows what data it was sending and what data it "should" be receiving. if output does not equal input then add 1 to the error count.


ok, so the concept looks good on paper. I have made a little protoboard that does just this and it works pretty well when i connect the output straight to the input (basically pin 0 to pin 1 with a wire)

but in the configuration in the drawing i run into a real problem!
If you look closely at the blue channel it is actually a bunch of very fast (~20ns) rise/fall events.


looking even closer we see that the majority of the logic 1 is just dead space (0.0vdc)


in my spin code i wrote this little routine that loops around a few times waiting for photon events (even a single photon event will register as a logic 1 - which i know is not the best method but background noise is not much of an issue right now..)

      LoopCntr := cnt + Speed 
      Repeat while cnt < LoopCntr
        If INA[1] == 1 
          Temp := %00000000_00000000_00000000_00000001

so i have found that im getting a large number of errors because of the massive dead space in between photon events, as this loop cycles around until the clock reaches some value and then moves on i believe that the propeller is simply just missing some of the pulses and registering what should be a 1 as a 0 instead. now im not getting a 100% fail rate. and it depends much on the Speed variable. obviously the larger Speed is the more chances it has of seeing an event. even when i set the Speed variable to the smallest size possible i still get some small success rate.

NOW FOR THE QUESTION:

instead of looping around and around while hoping that there might be a pulse pulling the prop's Pin 1 high durring the time that the IF command is checking Pin 1, is there a way that in the prop to trigger on a rising edge (within a certian window of time)? or something that the pulses can set HIGH and then that later be reset and repeat??

I hope ive explained this issue thoroughly enough but if there are any question please feel free to ask!

Thank you for any help to resolve this issue.

Phil Pilgrim (PhiPi)

Sure. Use one of the counters to count rising edges or even just high inputs, then read the number of counts accumulated within the bit interval. You can then compare this to a threshold to determine whether the received bit is a one or zero.

-Phil

Mike Green

You can use one of the cog counters to count events consisting of an edge, either 0->1 or 1->0. The problem is that these events look too short. The counter is clocked by the system clock (normally 12.5ns clock pulses ... 80MHz) and an edge is determined by a change in the input pin from one clock time to the next. That's about 25ns. You could run the Propeller at 100MHz for a clock width of 10ns. That's kind of marginal. How close can these pulses be? What's the minimum pulse width? You might need some kind of external counter with an edge triggered clock input. If the pulses are far apart enough, maybe a simple pulse stretcher would work that would be triggered by the pulse leading edge and produce perhaps a 50ns or 100ns pulse that could be used reliably to trigger a cog counter.

A simple D flip-flop could be used. These usually have an edge triggered clock. The D input is tied to logic high and the clock edge loads this into the flip-flop. The Propeller would have an input pin connected to the flip-flop's 1 output and an output pin connected to the flip-flop's clear input to be able to reset it. Something like this should work.

Phil Pilgrim (PhiPi)

Mike may be right about the shortness of the pulses being an issue, especially if they are not fully "on" for their 20ns duration. You might also consider an analog pulse stretcher like this one:



The 1N4148 will switch in 4 ns. Pick values for R and C that will yield a time constant of 100 ns or more.

-Phil

laser-vector

Phil Pilgrim (PhiPi) wrote: »

Mike may be right about the shortness of the pulses being an issue, especially if they are not fully "on" for their 20ns duration. You might also consider an analog pulse stretcher like this one:



The 1N4148 will switch in 4 ns. Pick values for R and C that will yield a time constant of 100 ns or more.

-Phil

just so happened to have a 1N4148 laying around, built your circuit and got a much nicer waveform!


now my error rate is around 10% at high speed. still have to do some work and i like the idea of using the cogs counters (havnt had much experience in using them though..) but this is progress! thanks :-)

[edit]

0.1% error rate at 7Kbs

ElectricAye

I might be wrong about what you're asking for here, but I once used a comparator with a latching circuit to effectively keep the pulse "alive" long enough for the Propeller counter circuits to "see" it. Would something like that help? I think the comparator chip I used was AD8561

http://www.analog.com/static/imported-files/Data_Sheets/AD8561.pdf

Rayman

Looks to me like you just need a 10X increase in the RC time of your filter and you'll have it... I'm not sure you need the diode...

Phil Pilgrim (PhiPi)

Yes, you do need the diode. Otherwise, lows in the input would pull the voltage down; and, since the duty cycle is <50%, you'd never reach Vdd/2.

-Phil

localroger

If you are looking for single very short pulses separated by enough baseline to run some code, WAITPEQ / WAITPNE will let you respond with 1 prop clock accuracy to signals as short as 2 prop clocks long. If you need even more speed the counters can indicate that a pulse occurred, but not necessarily its exact timing. The WAITPxx trick falls apart if you have trains of pulses, because once you have to run at least a few prop instructions to record the CNT and set up for the next pulse.

Rayman

Phil, I don't know... Usually photodiodes are capacitively coupled, so the lows would do nothing...

Phil Pilgrim (PhiPi)

Ray,

The output of the photodiode amp is buffered:

laser-vector wrote:

4. a comparator/opamp driver then converts these pulses to a TTL 3.3vdc signal (Blue Channel)

So it's driven both ways.

-Phil

kuroneko

Sorry, I just don't get the concerns re: pulse-width. If we have a 20ns pulse I expect it to be visible to waitpxx or counters. Edge detection works by latching the current value and shifting it through a 2 bit shift register. The pin history is then used for counter enablement (A₁ vs A₂). The only issue I can see is pulse frequency.

What am I missing here? Should I finish my coffee first?

Phil Pilgrim (PhiPi)

Kuroneko,

You're right, assuming that the pulses are square and are always high enough long enough to guarantee catching at least one clock. It's not clear from the scope traces, though that they're square, which means that they might not be higher than Vdd/2 for more than 12.5 ns. Of course, this perception may just be a bandwidth limit of the scope itself.

But, yes, if they're honest 20 ns digital pulses, they do not need to be stretched.

-Phil

Mike Green

The problem is that 20ns is roughly 3/2 of a clock cycle and the edge triggering is done by sampling the input in two successive clock cycles at around the same point in the cycle. If the input is 0 in the first cycle and 1 in the second cycle, you've got a positive edge, etc. If the edge occurs late in the 1st cycle and the pulse finishes early in the 2nd cycle, you might miss it.

Phil Pilgrim (PhiPi)

Mike, are you sure about that? As long as the pulse is guaranteed to straddle at least one clock interval (i.e. > 13 ns, say), it has to get sampled high at least once. And a low sample followed by a high sample is all that's required to signal an edge. Um ... right?

-Phil

Rayman

Sounds like he needs the filter before the TTL buffer then...

kuroneko

Mike Green wrote: »

If the edge occurs late in the 1st cycle and the pulse finishes early in the 2nd cycle, you might miss it.

Sorry, I don't follow. One system clock cycle fits comfortably into the 20ns pulse with about 4ns to spare each end (assuming a usable 20ns pulse re: Phil's comment). I get either one active (sample) edge or two of them seeing the pulse. One is enough for what is required.

Mike Green

I was looking at the scope traces and there was a little slope to them. They're not straight up and down, maybe the rise time is a nanosecond or two. I don't know where the switching threshold is. That might shorten the effective width of the pulse. There's still enough time for the counter to catch the edge before the trailing edge comes along, but it's tight. Maybe it'd be better to run the Prop at 96MHz or 100MHz to have another 20% margin. I get a little squeamish when things get both fast and tight. I like some slop available for mistakes and misunderstandings.

Phil Pilgrim (PhiPi)

Mike, it was that slope that was bothering me, too; so I guess we're on the same page there.

-Phil

Rayman

I still think the photodiode signal should be low pass filtered (just a capacitor and resistor) before the TTL converter. This will also make the system less susceptible to noise...

Phil Pilgrim (PhiPi)

There are a lot of options that would work to make the pulses wider. Mike's clocked pulse extender is one, as is a retriggerable one-shot.

-Phil