Yet another fast edge pulse generator

[Gerhard_dk4xp]

No, they are not expensive.
€2.12   qty 1, for the complete divider to 20 GHz, 0603 size all together.

<   https://www.digikey.de/product-detail/de/susumu/PS1608GT2-R50-T1/408-2049-1-ND/7035422   >

regards, Gerhard.

(and I disagree on the micro USB.)

[Mr. Scram]

Those are blatantly hipster USB connectors!

Usb C is supposedly more sturdy, but the proof is in the pudding.

[Converter]

This resistive splitter is way lower cost than I expected.

https://www.minicircuits.com/WebStore/dashboard.html?model=ZFRSC-183-S%2B

And I recently bought some at a ridiculous price, so there was no point for fuss.

[Langston]

A few more data points. :)

Just got one of Leo's lovely little 40ps pulser's this morning. 50Ω terminations used.

Scopes:

1. Tektronix 2445
2. PicoScope 5244B with and without ETS engaged

NOTE: After I made this post I learned that 0.35 should have been the factor used for both my analog and digital scopes. See the following posts for the "why" on that.

[MrW0lf]

2. PicoScope 5244B with and without ETS engaged

Any specific reason to use 0.45/RT not 0.35/RT for calculation?

[Langston]

Any specific reason to use 0.45/RT not 0.35/RT for calculation?

Ignorance probably! :)

My background is audio and I'm a bit of a newbie in this realm. From what I've read up to the point of my post yesterday is that it was appropriate to use 0.35 with analog scopes and 0.45 with digital. This of course is not very satisfying because the "why" isn't addressed. And then last night I found some articles by Tektronix and Keysight that not only addressed the "why" but made sense and of course the sources are pretty reliable. I particularly liked "the rule of 5's".

This kind of thing is approximation of course, but now it seems that 0.40 and 0.35 may be the better numbers to go with. The higher number is to be used with analyzers that employ maximally flat low pass filters in their design (generally digital domain > 1GHz) and the lower number is used < 1GHz where Gaussian low pass filters are generally employed. Based on this, I can see where the digital vs. analog scope thing came from, but the filter roll-off rate gets to the heart of the matter.

Keysight's article is excellent:

https://literature.cdn.keysight.com/litweb/pdf/5989-5733EN.pdf

[2N3055]

AFAIK, picoscope should have Gaussian response, in which case 0.35 would be correct..

[MrW0lf]

BTW this is stellar example of ETS usefulness. There is difference even at 1GSa/s, despite wfm looking entirely plausible and well reconstructed. And when you enable 2 channels still should have 20GSa/s on both, while with RTS you drop to Nyquist (practical) minimum and lose all detail.

[Langston]

AFAIK, picoscope should have Gaussian response, in which case 0.35 would be correct..

I'm sure you're right. I just watched all the Pico Tech tutorials and one specifically used the 0.35 coefficient when discussing the 5000 series models such as I have. I also threw out a question to Pico Tech's support about the low pass filter employed and I'm a bit incredulous of the answer that it "...is not based upon a any intentionally designed filter."

Full context:

Hi,
The bandwidth states that the output remains within -3dB of the peak voltage (which is the standard specification for our PicoScope range). This is not based upon a any intentionally designed filter. The input stage of the PicoScope 5244D (the currently available model) in general has a rolling off effect of signal bandwidth (as do all electronic circuits at the extremes of their operation). So it starts a gentle roll-off quite early on, but remains within the spec right across the stated bandwidth range. It is very common for oscilloscope manufacturers to rely on the natural performance of their analogue circuitry to define the bandwidth of the scope.
Regards,
Pico Technical Support Team

As a card carrying member of Dave's "Young Player" crowd, I put together the following summary of rise time and bandwidth and would love corrections as needed, thanks!

Bandwidth and Rise Time Math

BW = (1/RT) * 0.35 for scopes < 1GHz due to Gaussian LP filters
BW = (1/RT) * 0.40 for scopes > 1GHz due to Maximally Flat LP filters
RT = (1/BW) * appropriate coefficient per LP filter type

Net Bandwidth:

BWn = 1/√((1/BWa)^2 + (1/BWb)^2)
Example: 70.7MHz = 100MHz scope with a 100MHz probe

Net Rise Time:

RTn = √(RTa^2 + RTb^2)
Example: 2.8ns = 2ns scope measuring a 2ns signal

Rule of 5's:

To minimize measurement error, it seems that this rule applies across the
board: scope BW 5x signal, scope RT 1/5th signal, sample rate 5x BW, etc.

[jpb]

AFAIK, picoscope should have Gaussian response, in which case 0.35 would be correct..

I'm sure you're right. I just watched all the Pico Tech tutorials and one specifically used the 0.35 coefficient when discussing the 5000 series models such as I have. I also threw out a question to Pico Tech's support about the low pass filter employed and I'm a bit incredulous of the answer that it "...is not based upon a any intentionally designed filter."

This is probably right for most lower frequency scopes in the sense that the 0.35 arises from a simple R in with a C to ground. The 0.35 is actually ln(9)/2.pi if you do a simple calculation based on such a circuit (the 9 comes from a 10% to 90% rise). The input circuit is probably not primarily designed as a filter.

[Leo Bodnar]

I can't recall where exactly I got 0.45 coefficient from but quick search produces:
"It's 0.35 but in reality it's 0.45 or more..."
"0.45 is new 0.35..."
etc...

I'd rather see the coefficient written as 0.4±0.05 or just 0.4 - in many natural sciences the default rule is that if some value is written as 0.35 or 0.40 with no stated error the last digit is assumed to be significant, i.e. implied estimated error is 0.01 or less.

To [an old] physicist BW ≈ 0.35 / t_R really means more of a BW = (0.35±0.01) / t_R
If you have not used slide rule or log tables in anger then it probably does not irk you.

[jpb]

I can't recall where exactly I got 0.45 coefficient from but quick search produces:
"It's 0.35 but in reality it's 0.45 or more..."
"0.45 is new 0.35..."
etc...

I'd rather see the coefficient written as 0.4±0.05 or just 0.4 - in many natural sciences the default rule is that if some value is written as 0.35 or 0.40 with no stated error the last digit is assumed to be significant, i.e. implied estimated error is 0.01 or less.

To [an old] physicist BW ≈ 0.35 / t_R really means more of a BW = (0.35±0.01) / t_R
If you have not used slide rule or log tables in anger then it probably does not irk you.

The 0.45 arises where the "filter" characteristics fall off more sharply which I think is the case for higher bandwidth scopes (1GHz and above). The nice thing about a simple RC model is that you can calculate things analytically and come to ln(9)/2.pi which appeals to me but of course the gross approximation is in assuming that the scope input can be modeled by a simple RC circuit.
Here is a Teledyne Lecroy blog on the subject:
http://blog.teledynelecroy.com/2018/02/transmission-lines-part-ii-more-on.html

[2N3055]

Type of filter is sometimes clearly defined in specs for every scope :

Keysight MSOX3104T - 1GHz / 450 psec risetime - / 0.45  (Brickwall, min 2.5GS sample rate))
Lecroy Wavesurfer 10 - 1GHz / 350 psec risetime - / 0.35 (Gaussian, min 5GS sample rate)

But general rule is that you need circa 5x oversampling if you use Gaussian filter on input. If it is less than that, probably brickwall..

It is not connected so much with high bandwidth in scopes but more with oversampling ratio to avoid aliasing..

[BradC]

Mine arrived. Thanks Leo!

Now to turn it into a ghetto TDR (which is what I bought it for).

(edit). Just applied the 20MHz filter and got 17.4ns ~20Mhz and the 100MHz filter and got 3.6ns ~97Mhz (using the 1/R * .35) approximation.
So the filters *do* work after all!

[bullestock]

One suggestion: could you please share the protocol specs to configure it? A Windows program is very inconvenient for someone not using Windows. It should be very easy to implement in Python, at least for simple command-line usage.

I'll try putting something together. You can only adjust output level and inversion, so it's not very exciting.
Leo

Any progress on this?

[Leo Bodnar]

Thanks for the reminder. We'll see if we can put it together this coming week.
Thanks
Leo
Update: we have plenty of BNC model in stock and a few SMA and 2.92mm available. 
SMA and 2.92mm versions are still assembled manually so they are not always available off the shelf, please keep this in mind if you intend to snipe one.

[MrW0lf]

PicoScope 6404D 500MHz

Two pulsers attached, original <50ps BNC and ~30ps Oz version with negative going pulse / SMA / EXT trigger. Rise time wise no difference whatsoever. Magenta is BNC, Lime is SMA. EXT trigger is however very useful. First I cranked it to 25MHz for DeepMeasure to work at 200GSa/s (it needs full cycle), then set to 1MHz to enable single and only case of settings when fft(derivative(x)) works.

RT wise no surprises 0.35/603ns~=580MHz.

[Converter]

Two pulsers attached, original <50ps BNC and ~30ps Oz version with negative going pulse / SMA / EXT trigger. Rise time wise no difference whatsoever. Magenta is BNC, Lime is SMA.

You need to use a bandwidth ten times more to try to find differences.

[MrW0lf]

You need to use a bandwidth ten times more to try to find differences.

Thanks for good TEA excuse Now I need a sampler just to see that difference But actually still bit surprise because SMA one is negative going so I had to apply DC offset and tune amplitude a bit, plus it has two adapters and sits on different channel. Still pixel-to-pixel overlap if sync timing & settings.

[Leo Bodnar]

Sorry, python control app is still in the works It's not a priority so it gets pushed around a bit.  Maybe Christmas is the best time to finally nail it.

Some news: I have made a few custom modded versions with 100ps pulse keeping existing 10MHz pulse train. 
I found that 80ps-1000ps pulse width is possible using existing PCBs.

This year the pulsers went to NASA, European Space Agency, Facebook, Tektronix, Rohde & Schwarz, many other T&M manufacturers and test labs.
We are in a good company, guys!

Leo

[Berni]

Sorry, python control app is still in the works It's not a priority so it gets pushed around a bit.  Maybe Christmas is the best time to finally nail it.

Some news: I have made a few custom modded versions with 100ps pulse keeping existing 10MHz pulse train. 
I found that 80ps-1000ps pulse width is possible using existing PCBs.

This year the pulsers went to NASA, European Space Agency, Facebook, Tektronix, Rohde & Schwarz, many other T&M manufacturers and test labs.
We are in a good company, guys!

Leo

That is a very impressive track record there.

Looks like deep down we all need to know how fast our scopes truly are.

By the way what is the intended use for that 100ps wide pulse?

[Leo Bodnar]

By the way what is the intended use for that 100ps wide pulse?

I do not know the details, this was a specific request from an R&D customer.
Leo

[Tom45]

This year the pulsers went to NASA, European Space Agency, Facebook, Tektronix, Rohde & Schwarz, many other T&M manufacturers and test labs.

Facebook?

Anyway, congratulations on your pulser's success. It's good to see that it has been "discovered" by such a wide range of customers. Far beyond just the TEA aficionados.

[Leo Bodnar]

Cheers, Tom. FB have hardware divisions.
Leo

[WastelandTek]

Yes, congratulations Leo.  I was in this thread pretty early on and it seemed then like you felt this was just a side project.  Instead it looks like it turned into a real product for you.

I don't have anything particularly fast in my shack, but it is sure nice to have a reference pulse I can rely on.