stretching a pulse

That's not true, though. If the pulse duration were important, that gets lost, but the pulse amplitude is often the important quantity. These reshaping techniques don't interfere with amplitude- determination downstream (though they will change the calibration a bit).

Gizmos like a Wilkinson converter are the classic 'right' way to capture a pulse amplitude, but if JL wants to use some other kind of digitizer and detector, pulse stretching in this fashion might make his preferred hardware produce more precise results.

Well, of COURSE you can. That quartz clock you measured yesterday was turned on, then you frequency-metered it, then you turned it off. That was a 'short burst', if you allow short to mean 'less than all day long'.

For really short bursts, though, the problem is (1) determine the time during which oscillation occurs (envelope detector), (2) find the values of 'w' and 'p' and 'a' which best fit the oscillator output, i.e. minimize integral_{envelope start} ^{envelope end} (osc(t) - a sin(wt + p))**2

It's not an easy problem, but computers can sift through a finite list of candidates for the variables and produce a 'best-fit' answer.

On a sunny day (Fri, 03 Sep 2010 11:06:56 -0700) it happened John Larkin wrote in :

In TV the color BURST controls a PLL to a few ns accuracy, So if you know the approx frequency, use a PLL.

Yes, but it's an LC oscillator so can drift around. We'd like to measure it and either tweak it with a varicap, or mathematically adjust other stuff to make up for it.

John

ssage

ou

es

I gather from all this that it's not a pulse you want to measure, but a burst.

----integrate----out

tive-going step.

Then the assumption is the input pulse width is less than the delay of the line. It helps to be specific here.

--
I'm intrigued...

What can you tell me about the oscillator?

Is it a free-running LC that you gate tone bursts from, or that
something else does?

Are the tone bursts all the same length?

Do they occur at regular intervals?

How accurately do you want to measure the frequency

Independent problems in the same box.

John

It's a 50 MHz LC oscillator that we'll use to generate time delays. It's held off until we get a trigger from a laser. Then we start it up and use it to measure off coarse (20 ns) time delays. Each coarse/counted time delay is followed up with an analog ramp time delay that gets us down to picosecond resolution overall. We'd normally use a fancy DSP phaselock system, flecaps and varicaps, ADCs and DACs, to discipline the LC oscillator, but we don't want to do that now, to reduce cost and complexity. We don't want to tune the oscillator at all, but just measure its frequency and do the math, to makes delays.

In operation, yes. Anywhere from, say, 400 ns to 50 us.

Not really. But they will happen fairly often.

We could live with, say, 50 PPM sort of accuracy.

My FPGA guy, Rob, thinks that, when the LC oscillator is known to be enabled, we can generate a classic counter time gate from, say, a 200 MHz xtal clock. If we know the oscillator is going to run for, say,

500 ns, we can generate a 400 ns gate within the burst, and count the edges we see. That will be a small count, around 20 ticks. We'd do that many times over successive shots until we accumulate enough ticks to get good statistics. The trick is that the counter gate width has to be stable to something like 20 ps. He thinks he can do this inside an FPGA. I think maybe he can.

If I could make the LC very temperature stable, I could just do a single long timebase frequency measurement at powerup, using the XO to make a, say, 1 second gate, and remember that result for operation. But that suggests a triggered LC oscillator with, at worst, single digits of PPM per degree C drift. Tricky, but not impossible. Just after powerup is the worst time to measure the oscillator. Later on, after it's warmed up, it will be busy, and then we'd have to do the burst measurement thing.

Ping-pong two oscillators? Messy.

John

If it wasn't, I wouldn't be shopping for a pulse stretcher.

John

I guess you can't gate a TCXO? Or multiply a stable TCXO to 500 MHz, gate the 500 MHz, then divide it by 10 to get your 50 MHz?

tm

--- news://freenews.netfront.net/ - complaints: snipped-for-privacy@netfront.net ---

It's very hard to start an XO instantly following a trigger (it's been done, by HP among others) and even harder to stop it. The quartz rings like a bell for milliseconds. An LC oscillator can be started instantly and stopped dead in a cycle or so.

We want delay resolution of 10 picoseconds, which would require a 100 GHz free-running oscillator.

Hey, the Pepper patent has expired!

Maybe we can use that. It's fiendishly clever.

John

It wasn't till the '80s that the cheapest imported TVs could use VITS/VIR

Which is bullshit, becasue the National Television Standards Commitee was created for the development of B&W Television.

You never saw a high end NTSC color television set in the US, then.

--
Politicians should only get paid if the budget is balanced, and there is
enough left over to pay them.

John Larkin a écrit :

message

Can't you use your ramp to time the oscillator on the fly and then have your ramp calibrated against a 50MHz reference oscillator?

Or better, time the difference on the fly between the reference and the triggered osc?

--
Thanks,
Fred.

John stated that in the original post, iirc. Doesn't make much sense to try stretching a pulse with a delay line shorter than the pulse width!

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal
ElectroOptical Innovations
55 Orchard Rd
Briarcliff Manor NY 10510
845-480-2058
hobbs at electrooptical dot net
http://electrooptical.net

The obvious thing to do, lock a PLL to the burst, means you have to take the measure slowly from another LC oscillator. Maybe a Foster-Seeley FM detector would be useful here. When input is out-of-range or noisy, it just holds the last value.

m -----integrate----out

e.

y n

egative-going step.

So how does this integrator not drift to the rail? I don't see any feedback, or is that something else you didn't bother to indicate in the diagram?

I was thinking along the lines of say 4 Bessel (constant delay) summed. But analog buffers may do the trick as well. 2 ns is still a reasonably fast pulse.

It only has to be an integrator for nanosecond type things--a 200 ns RC lowpass would probably work fine.

Back in the Footprints days, I had to do a real integrator, and faced just that problem--pyroelectric IR detectors produce a charge proportional to the temperature change between readouts, rather than a nice constant photocurrent. Thus they have zero response at DC, so you only see things that are moving. To make a normal-looking video, you have to integrate, i.e. apply infinite gain at a frequency where the SNR is zero. The result is a nasty random checkerboard pattern that gets rapidly worse with time.

In my case the solution was to apply a positivity constraint--people are warmer than the floor. (It would have had problems seeing the invading zombies, but that wasn't a design requirement.) I applied a slow negative ramp to the integrated data, and set any negative integral values to zero. That kept all the inactive pixels near 0, which worked fine in my application.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal
ElectroOptical Innovations
55 Orchard Rd
Briarcliff Manor NY 10510
845-480-2058
hobbs at electrooptical dot net
http://electrooptical.net