Normalize TDR pulse with software

[Snake]

I want to thank everybody for their support in the other thread about <30ps pulse generator. I have at the moment a pretty fast TDR and want to improve the measurement data. There is a feature called Normalizing for TDR and this can be done in software.With normalizing you can compensate for the aberrations from the pulse source. With this feature you can also simulate the behavior of the DUT under different pulse rise-time conditions.

I studied this topic for several years and I am close to a software solution that can do this for us in real-time. It is a LabVIEW based code that can be used to capture calibration data from a short and during the real measurement it shows you the normalized waveform.

A polish professor published his code on the internet and I want to reuse it. I programmed 95% of the code and I am missing 5%. If somebody can help me to finish the program then this would be grade. I can also share the code to other users.

This is the URL to the paper: http://www.pe.org.pl/articles/2011/3/69.pdf

PS: this paper and LabVIEW code is based on papers and matlab code from picosecond

[Snake]

In my previous post I talked about the LabVIEW code for normalizing. There are two blocks I still did not finish:

- Inverse Nicolson procedure
- Special filter (Bennia-Nahman minimum phase filter) on output waveform after normalization


The filter is not a standard filter and rarely used. This makes it difficult to program. Picosecond has a free example in Matlab and explained in a paper from their website but I do not know how to program in Matlab. Can somebody help me with this?

[eurofox]

In my previous post I talked about the LabVIEW code for normalizing. There are two blocks I still did not finish:

- Inverse Nicolson procedure
- Special filter (Bennia-Nahman minimum phase filter) on output waveform after normalization


The filter is not a standard filter and rarely used. This makes it difficult to program. Picosecond has a free example in Matlab and explained in a paper from their website but I do not know how to program in Matlab. Can somebody help me with this?

The code is available in the link below.

http://www.picosecond.com/objects/HdeconV2.txt

[Snake]

Thank you for the help. This is the code I want to program in LabVIEW but I do not know how.

Somebody experience with this? You can also load Matlab in LabVIEW but there are too many errors when running this code in LabVIEW.

[eurofox]

Thank you for the help. This is the code I want to program in LabVIEW but I do not know how.

Somebody experience with this? You can also load Matlab in LabVIEW but there are too many errors when running this code in LabVIEW.

If you have experience with an high level language the math is quite well readable from a Matlab programs.

I never use the "G" language from LabVIEW but I suppose it is possible to use formulas.

I think you don't need the whole code just the part from the special filter you are looking for.

[ejeffrey]

Do you want to convert this to labview because you don't have matlab, or because you need to integrate it with other labview code?  If you have matlab available, you can use a 'matlab script ndde' in labview.  Then you can just call the existing function without rewriting it.

[Snake]

Do you want to convert this to labview because you don't have matlab, or because you need to integrate it with other labview code?  If you have matlab available, you can use a 'matlab script ndde' in labview.  Then you can just call the existing function without rewriting it.

I tried this but I did not get it working with the mathscript node. I would like to get support here. Preferable I want to program it in LabVIEW with LabVIEW blocks.

The reason I want to make everything in LabVIEW is:

- I have experience with LabVIEW
- I can fully automate all procedures (calibrate and real-time calibrated TDR waveform view)
- I can add it to the software that captures the waveforms from oscilloscope.


I am very close to a working code and it would be a waste to stop at 95%. This normalizing is the "holy grail" for TDR in my opinion

Do you know LabVIEW?

[Marco]

Looking at visually coded DSP code gives me headaches.

I'm pretty sure the inverse Nicolson procedure is simply adding the same ramp you subtracted at the start.

[ejeffrey]

I tried this but I did not get it working with the mathscript node. I would like to get support here. Preferable I want to program it in LabVIEW with LabVIEW blocks.

Does the code you have work "stand alone" in matlab?  Even if you want to get it implemented in pure labview you should try to get the existing code working so that you can test your labview implementation against the provided code.

I am very close to a working code and it would be a waste to stop at 95%. This normalizing is the "holy grail" for TDR in my opinion

Deconvolution is sometimes useful, but it isn't magic and it isn't a holy grail.  You are making the data easier to interpret, but you can't improve the SNR.  At some point you are just making the noise bigger.

[Snake]

Looking at visually coded DSP code gives me headaches.

I'm pretty sure the inverse Nicolson procedure is simply adding the same ramp you subtracted at the start.

I did try that but there was an issue. I will check it again.

[Snake]

I tried this but I did not get it working with the mathscript node. I would like to get support here. Preferable I want to program it in LabVIEW with LabVIEW blocks.

Does the code you have work "stand alone" in matlab?  Even if you want to get it implemented in pure labview you should try to get the existing code working so that you can test your labview implementation against the provided code

I am very close to a working code and it would be a waste to stop at 95%. This normalizing is the "holy grail" for TDR in my opinion

Deconvolution is sometimes useful, but it isn't magic and it isn't a holy grail.  You are making the data easier to interpret, but you can't improve the SNR.  At some point you are just making the noise bigger.

I do not have a Matlab license and I would like to use only ~5% from the example code. The problem is that I do not know how to strip all other code. If I have a flow chart of the procedure I can program in LabVIEW code. This will also speed-up the performance. My goal is 20 measurements and 20 normalized waveforms per second. This is pretty fast and will only work when I efficiently program the code in LabVIEW.


At my work I am using an Agilent TDR with normalizing feature and I like it. I can calibrate out all reflections to the DUT and see the real TDR waveform of the DUT without errors caused by the interconnect and pulse aberrations. Another major advantage is improved performance and you can see the response of the DUT for other TDR rise-times (in menu you can select almost any rise-time you want). Without this feature I need hardware filters for DUTs that cannot handle 15ps rise-time.

For my TDR application I see it as a major improvement.

[Snake]

I just checked my inverse Nicolson code and discovered the issue. During normal Nicolson procedure I calculate the ramp slope and offset I subtract from the input waveform based on the input waveform itself entering this block.

During inverse Nicolson I add the ramp but with new slope and offset values based on the waveform entering the inverse Nicolson procedure. I think it is not good to use this ramp but the original ramp from the normal Nicolson procedure (before FFT and invFFT procedures).

Now I see a waveform that seems to be closer to what I expect but I am not sure if this is the correct way. Any advice here?

I will later show the waveform after every step in my LabVIEW code. This will make it easier to discuss the issue. Are there also LabVIEW users on this forum that can read my code to check what I programmed?