Building a poor man's Time Domain Reflectometer

[Krampmeier]

Hi everybody! I thought it would be nice to introduce a project I have been working on for some time, and which may be interesting for some other members as well. Along the way, I am hoping to get to get some support at the Keysight "Test to impress" contest - more on that later on  .

Usual TDRs need expensive high-speed components to measure the pulse run time on a cable. They send a short pulse down the cable and measure the time until the reflection of that pulse comes back to the same ("near") cable end. For that, they sample the voltage on the near end of the cable with high frequency. A resolution of about 10 cm on coax cable is common for low-end devices, which corresponds to about 1 ns time resolution and 1 GHz sampling rate for the ADC. The pulses must be so short that they do not overlap with their reflection even at the shortest permitted cable length.

My approach for a super cheap, super simple TDR is different. Instead of sending a short pulse with constant duration, I send pulses with variable length, and the overlap of the reflected pulse is my indicator that the pulse length is greater than the (electrical) cable length.
The overlap of pulse and reflection can easily detected, because when that happens, the peak voltage on the cable increases significantly. A high-speed diode and a capacitor are good enough to hold the peak voltage for measurement with a DMM or the built-in ADC of a microcontroller.



I described this concept in a video for the Keysight "Test to impress" contest already, and it very easy to understand once you see the oscilloscope plots there:



Now, how to generate the pulses with variable (and well known) length? Easy! I use an ECL logic XOR gate which gets a trigger signal on both inputs. One of the two inputs is delayed by a low pass filter, so the output is only "high" for a small moment. That low pass filter consists of a fixed capacitor (actually, switcheable for range selection) and a digital 8-bit potentiometer. As the time constant of the low pass filter depends on the the resistance in a linear manner, the resulting pulse length goes also in a pretty linear fashion with the potentiometer setting.


To prove my concept, I have built a prototype. The parts cost less than 50 Euro, even in single quantities. The STM32 Nucleo board made it easy to attach the Microcontroller, and creating the firmware online with MBED worked was surprisingly convenient (even though I missed the JTAG debugging and some other features I have with the IAR compiler at work).  I suppose the whole thing could be built in quantities for less than 10 Euro, and in the size of a matchbox, if somebody really wanted.

The prototype has two ranges:

• 12 - 107 ns (approx. 1 m to 110 m, depending on cable type)
• 72 - 1028 ns (approx. 6.5 m to 1100 m, depending on cable type)

The resolution is 4 cm on the short range and about 40 cm on the long range (8 bit). However, I already have an idea how I could get the full resolution (4 cm) over the full  range (100+ m), without physical range switching. Accuracy has not yet been proven (would need a temperature chamber and a load of cables with well known velocity factors), but the repeatability of the measurements is very good, and when I connect some cables in series the results are fairly consistent as well. LAN cables (CAT5, CAT 6) seem to come with a wide range of velocity factors, so I get up to 10% error with some of these. RG58 and RG216 can be measured very well.

Here are image of my "prototpe":





You can see I did not care much about shielding, current return paths, crosstalk, impedance matching, or other important things which must be considered when doing a true HF design. The circuit works anyway, as the real "high speed" section is very small and the most important parasitic effects can be compensated in software. Of cause, there are still some oddities and the performance could surely be be improved by putting more effort on a line driver with a faster slew rate, but that is beyond the limits of my small lab at home, especially the 25 years old 40 MHz Kikusui scope.

Right now I am waiting for Keysight to put my video online at the contest site. My plan is to release the schematic, some additional comments on the interesting details and the firmware here in the forum a soon as the contest is over. Of cause, I would be glad to get some votes at http://www.keysight.com/main/editorial.jspx?cc=DE&lc=ger&ckey=2677452 from the members who like my idea (without wanting to take votes away from other forum members who also take part in the contest).

Comments are welcome!

[HighVoltage]

w2aew did a great video on this, using a simple square wave and the overlapping.
#37: Use a scope to measure the length and impedance of coax

[Krampmeier]

Yep, this video explains the theory behind it very well. But I never saw someone use the overlap to measure the cable length without using an oscilloscope (or other high-speed DAC). The sleight used by my concept is that a DC measurement is enough if the pulse duration can be controlled well enough, and I built the suitable pulse generator (with sub-nanosecond resolution) with components for the price of a fast-food menu.

[Kleinstein]

Just to measure cable length to simple setup with adjusting the pulse length might work. However this only gives one aspect of DTR - if it is about finding a defect in a cable you essentially need the curve. Also with a not so perfect system there can be multiple reflections that can upset a simple DC measurement.

So the low cost version would be to build a kind of low cost sampling scope. As the trigger source is the pulse and the signal level is relatively high this might be relatively easy compared to a full scope. Still it takes a little more than just measuring DC.

If only the first slope is what you are interested in one might still get away with measuring the delay with different trigger levels, e.g. using a DAC and a comparator. So a simple DAC (e.g. in µC) a fast comparator (likely the most expensive part). For limited resolution the µC timer might be used - though limited to something like 10 ns, unless there is an additional fine delay (some µC have this) or an analog time to analog circuit is used.

[Kalvin]

For the poor hobbyists:

"Design low-cost, high-resolution time measurement app"
http://www.eetindia.co.in/STATIC/PDF/201206/EEIOL_2012JUN06_CTRL_AMP_TEST_TA_01.pdf?SOURCES=DOWNLOAD

- Accuracy 1ns or better (I have seen Microchip application note which claims accuracy of 350ps and better)
- Cost around $10

Parts used:

PIC24FJ32GA106 16bit MCU $2.12
LMH6559 Buffer $0.95 each
LT1712 Dual Comparators $3.35 each
BNC Connector $1.58 each
Misc. Components Resistors, Capacitors, etc. $1.00
Total $9.00

Microchip TDR demo:

[tggzzz]

There are other techniques, which don't cost much either. My first version is at https://entertaininghacks.wordpress.com/2015/07/27/poor-mans-homebrew-tdr-with-4cm-resolution-part-1/

I also have an improved technique with slightly better results, butI haven't finished writing them up. So little time, so many interesting things to do.

[Krampmeier]

@Kalvin: That Microchip implementation is really nice, I have not heard or read about that yet. It should have roughly the same limitations as my approach, but is more elegant and should be more stable. Thanks!

The techniqe presented by tggzz is also very creative and gives some more information about the attached cable. For me it looks like it cannot be used for cables longer than approx. 8 m (without aliasing), as the minimum frequency of the receiver is 24 MHz - correct? Very cool to calculate the pulse response from the spectrum - are you using matlab or octave, or did you implement that deconvulsion by yourself? A thought that makes me shiver... Unfortunately it does not sound like this solution is very portable...

@Kleinstein, you are right, the applications of such a simple setup are very limited compared to a "real" TDR. It cannot detect shorts at all (would just measue "infinite" length) or small mismatches (like a 75 Ohm connector soldered on a 50 Ohm cable).
I actualy did not build this for a specific purpose, but just because I thought it might be a cool idea and I can learn something. And of cause, it is useful to have a device which can tell me how many meters of cable (NYM-J, KNX, loudspeaker cable...) I still have on my drum - and this works quite well.

By the way, of cause I can get curves out of the device I built. Here is an example of a 4.10 m RG58 cable connected to one wire pair of 1.48 m LAN cable via an improvised adaptor:



One nanosecond corresponds to (approximately) 10 cm on both of these cables. We can clearly see that something is "wrong" there and even roughly get the distances.
I still wonder how it can happen that the voltage drops at about 42 and 62 ns. In theory the curve should be monotonic. If I ever get my hands on a fast oscilloscope... 

[Rerouter]

To me that looks like you have a small inductance adding at the start of the cable, then a small amount of capacitance on the other end, and clearly an open circuit cable,

http://gwdata.cdn-anritsu.com/images/gw1/products-solutions/appnotes/373-figure03.jpg?la=en-us

[Kleinstein]

If it's just to estimate/measure cable length, one can also just measure capacitance. 1 m of cable is about 100 pF - surprisingly little difference for NYM, coax or LAN.

[tggzzz]

The techniqe presented by tggzz is also very creative and gives some more information about the attached cable.

Thanks. It amused me, especially since my brother said he hadn't used Fourier Transforms since graduating (in the early 60s), and I was able to reply that I had used them last week

For me it looks like it cannot be used for cables longer than approx. 8 m (without aliasing), as the minimum frequency of the receiver is 24 MHz - correct?

It is too late at night to remember the exact figure, but there is a maximum length based on the lowest frequency, and it is also dependent of the propagation velocity (usually ~0.66c or 0.75c).

Very cool to calculate the pulse response from the spectrum - are you using matlab or octave, or did you implement that deconvulsion by yourself? A thought that makes me shiver... Unfortunately it does not sound like this solution is very portable...

I'm lazy. I wanted to learn a bit of Python, it was good for displaying graphs, had suitable numerical libraries. I used Python's numpy library, which contains an inverse FFT function ifft(...).

[coppice]

For the poor hobbyists:

"Design low-cost, high-resolution time measurement app"
http://www.eetindia.co.in/STATIC/PDF/201206/EEIOL_2012JUN06_CTRL_AMP_TEST_TA_01.pdf?SOURCES=DOWNLOAD

- Accuracy 1ns or better (I have seen Microchip application note which claims accuracy of 350ps and better)
- Cost around $10

Parts used:

PIC24FJ32GA106 16bit MCU $2.12
LMH6559 Buffer $0.95 each
LT1712 Dual Comparators $3.35 each
BNC Connector $1.58 each
Misc. Components Resistors, Capacitors, etc. $1.00
Total $9.00

Microchip TDR demo:

Microchip's CTMU isn't well known for fantastic resolution. The high resolutions timers primarily made for the ultrasonic flow meter market (e.g. the devices from ACAM and the TI TDC1000), can probably achieve 100ps resolution single shot measurement in a TDR application, and considerably better with some averaging of the jitter.

[Kalvin]

For the poor hobbyists:

"Design low-cost, high-resolution time measurement app"
http://www.eetindia.co.in/STATIC/PDF/201206/EEIOL_2012JUN06_CTRL_AMP_TEST_TA_01.pdf?SOURCES=DOWNLOAD

- Accuracy 1ns or better (I have seen Microchip application note which claims accuracy of 350ps and better)
- Cost around $10

Parts used:

PIC24FJ32GA106 16bit MCU $2.12
LMH6559 Buffer $0.95 each
LT1712 Dual Comparators $3.35 each
BNC Connector $1.58 each
Misc. Components Resistors, Capacitors, etc. $1.00
Total $9.00

Microchip TDR demo:
<link to video removed in order to conserve space>

Microchip's CTMU isn't well known for fantastic resolution. The high resolutions timers primarily made for the ultrasonic flow meter market (e.g. the devices from ACAM and the TI TDC1000), can probably achieve 100ps resolution single shot measurement in a TDR application, and considerably better with some averaging of the jitter.

I haven't been using CTMU so I cannot say how well or poorly it performs. The SDR-application just take advantage of the on-chip CTMU block and it should work down to 1ns range as Microchip has demonstrated. Some application note mentioned that 350ps or better could be obtained.

Edit:
This application note states that even 3.5ps resolution ie. 0.02 inch resolution can been obtained:
http://www.edn.com/design/sensors/4433411/Use-Time-Domain-Reflectometry--TDR--for-low-cost-liquid-level-measurement--Part-III

The CTMU uses on-chip 12-bit ADC, but let's assume conservatively that the accuracy of a single-shot pulse measurement is only 6 bits. By measuring multiple pulses and averaging the results, the resolution should double when the measurement count is increased four-folds (ie. gaining one extra bit).

Making four measurements and taking the average of the results we can increase the resolution to 7 bits. Making 16 measurements and averaging the results we have gained 2 bits giving us 8 bit resolution. After 1024 measurements we have gained 5 bits giving us 11 bits of resolution. Making 4096 measurements we can achieve 12-bits of resolution. As each pulse measurement is really fast, the averaging can be increased easily to 4096 or more. Let's assume conservatively that each measurement will take 50us (the CPU can execute 500 or more instructions in that time) and we perform 4096 measurements, the total measurement time will be 200 milliseconds ie. 5 times per second.

[tggzzz]

By measuring multiple pulses and averaging the results, the resolution should double when the measurement count is increased four-folds (ie. gaining one extra bit).

In general, that kind of analysis is valid for uncorrelated random noise, not for correlated errors. But I'm sure you know that.

I make no comment on the devices used in this thread.

[Kalvin]

By measuring multiple pulses and averaging the results, the resolution should double when the measurement count is increased four-folds (ie. gaining one extra bit).

In general, that kind of analysis is valid for uncorrelated random noise, not for correlated errors. But I'm sure you know that.

I make no comment on the devices used in this thread.

Yes, your comment is very good one. I cannot say I know anything about the measurement error distribution.

I edited my posting to include the reference to an application article which claims that even 3.5ps resolution ie. 0.02 inch resolution could be accomplished.

[Kalvin]

Thought about this CTMU a bit more. It should be pretty easy to make a sampling TDR measurement device, too. The system would require an adjustable delay line. The principle is similar to sampling oscilloscopes. I guess that the budget can be still held near $10 range.

The pulse generator will feed to coaxial line to be investigated and the delay line. The CTMU and the ADC's internal sampling capacitor are tracking the transmission line voltage. After the specified delay the delayed trigger pulse will will make the CTMU to stop transmission line sampling, and start the ADC to measure the voltage of the ADC's internal sampling capacitor.

Varying the delay one can "see" the reflection voltage changing as a function of time. Performing averaging over multiple measurements the resolution can be increased. Applying some math to the results one should be able to calculate the transmission line parameters and find the locations and the values of the impedance mismatches.

Edit: The digital delay line costs at least $15, so it will break the $10 budget. For example the Microchip (Micrel) dual channel delay line can provide 5ns delay with 5ps steps: http://www.digikey.com/product-detail/en/microchip-technology/SY89297UMG/576-3706-5-ND/2242459
5ns is only good for 2 meters (6+ feet) of coax. Some additional delay tinkering would be needed for expanding the measurement range.

[Kleinstein]

There are likely easier S&H stages than using the CTMU. Anyway this still leaves the problem of having the adjustable delay line.
The advantage of the sampling system would of cause be that one can also measure the length of a cable up to a short, not just an open cable.

[Kalvin]

There are likely easier S&H stages than using the CTMU. Anyway this still leaves the problem of having the adjustable delay line.
The advantage of the sampling system would of cause be that one can also measure the length of a cable up to a short, not just an open cable.

I just went to Digikey and browsed for the programmable delay lines (see my previous post). That will bust the $10 budget.

[Kalvin]

Edit: The digital delay line costs at least $15, so it will break the $10 budget. For example the Microchip (Micrel) dual channel delay line can provide 5ns delay with 5ps steps: http://www.digikey.com/product-detail/en/microchip-technology/SY89297UMG/576-3706-5-ND/2242459
5ns is only good for 2 meters (6+ feet) of coax. Some additional delay tinkering would be needed for expanding the measurement range.

About the delay tinkering: Maybe a simple RC could be used to create some additional delay. The delayed pulse is fed into a RC-filter which causes the pulse delay. Varying the C will vary the delay. The variable C could be possibly implemented placing few suitable capacitors to microcontroller's I/O-lines. Making the I/O-line floating (hi-z) disconnects the unused capacitors. Making all capacitors floating effectively disables the extra delay feature. Making the relative capacitors values as powers of two, one can create some nice delay increments.

I do not know how well this concept would work, just an idea creating simple delays on a budget.

[tggzzz]

The system would require an adjustable delay line. The principle is similar to sampling oscilloscopes.

Consider time-to-digital (TTD) devices.

[Kleinstein]

One way to create pulses with a variable delay would be using two slightly different clocks (e.g. 10 MHz and 10.001 MHz), and synchronizing flipflops with these two. This way the phase shift and thus the delay is slowly moving from 0 to 100 ns, more delay could be added by the µC. The good thing is that the delay is predictable when the frequency difference is known / measured, and the zero point is caught.

[coppice]

One way to create pulses with a variable delay would be using two slightly different clocks (e.g. 10 MHz and 10.001 MHz), and synchronizing flipflops with these two. This way the phase shift and thus the delay is slowly moving from 0 to 100 ns, more delay could be added by the µC. The good thing is that the delay is predictable when the frequency difference is known / measured, and the zero point is caught.

Using 2 slightly different clocks can be pain, because the phase relationship between them is uncontrolled. Using a FET to switch a cap that nudges a crystal is a better behaved approach. Wherever you are when you switch that cap, you know the next cycle of the clock is going to behave well.

[Kalvin]

One way to create pulses with a variable delay would be using two slightly different clocks (e.g. 10 MHz and 10.001 MHz), and synchronizing flipflops with these two. This way the phase shift and thus the delay is slowly moving from 0 to 100 ns, more delay could be added by the µC. The good thing is that the delay is predictable when the frequency difference is known / measured, and the zero point is caught.

How about using a PLL with adjustable phase difference so that the edges will lock with specified time delay. Then only one reference oscillator is needed and the PLL's VCO will lock to the reference with specified phase offset ie. delay.

[Krampmeier]

Nice to see how the ideas are coming in!

Of cause, it would be nice to derive the delay from a crystal oscillator for stability, but my experience with the simple R-C lowpass is not too bad. Instead of a capacitance decade, I use a digital potentimeter (AD8400), which gives 8 bits of resolution for the delay (or pulse width, in my application). It looks like this now.



Note: The diode is there to suppress the pulse which occurs on the falling edge of the trigger line (PA4). It does not work perfectly, but good enough for my purpose.
With a small modification, the analog delay would be used to add an small delay (let's say, with 0.1 ns resolution) to a larger delay, which is generated by the µC. 255*0.1 ns = 25.5 ns, so f the µC can generate precise delays with the resolution of  something like 20 ns, we'd have the full resolution at infinite range. It could look a bit like that:

[rx8pilot]

This looks like a fun project - just wanted to join in so I get notices now.  Carry on.

I did some experiments after watching W2aew videos and have an actual daily use for the technique if I made one. I love practical projects that I can use after the learning is done.

[Krampmeier]

I just did some quick soldering and a program change, and the method with the addition of a delay from the controller and the analog circuit does seem to work. Unfortunately, the mbed online compiler seems to create a very slow code, despite using #pragma Otime.
Because of that, the smallest possible delay from the controller is about 120 ns with my program, even though the µC should be running at 100 MHz. No idea why a simple port access is so slow. Maybe I can find a way to get better resolution.
Edit:
That was easy, mbed also supports direct access like GPIOC->BSRR = (1<<9);. I'll try to integrate the new technique into my firmware tomorrow and to some tests.

[TerraHertz]

For interest, here's a simple cable pulser I did back in 1986. The idea was to generate a short pulse (adjustable from 0 to 20nS duration), and ALSO to be able to make the driver output go tristate at an adjustable time.

The result is that if driving into an unterminated (or shorted) cable, you can watch the pulse bounce back and forth between the ends for quite a few bounces. It's fun.

I still have it, it still works. But atm the only scope I have handy is only 100MHz, which really can't see the result.

[Krampmeier]

@TerraHertz: Wow, sweet! I like that schematic! Looks like my idea is not that new 
Do I understand it correctly that you use the transistor to drive the "High" (12 V) and the S03 open collector NAND to drive the LOW?

I finally managed to get consistent software-delays from the STM32F4, starting at zero and in increments of 40 ns. The pipelined architecture of this processor makes it a bit hard to get such small delays, as the execution time of an instruction depends on the context. I had to tweak it a bit...  See code below.

I am still working on the consistency of my analog delays though. Seems like sometimes they get shorter when I adjust the digital pot one bit up - I hope that strange non-linearity is just a software bug. But in general the whole thing is working quite fine already, be it as a TDR or the heart of a pulse generator.

By the way, my video on has finally been uploaded by Keysight, so if someone wants to support me in the contest, it's "Johannes R."...

Code: [Select]

if(iDigitalDelayCycles == 0)
{
    portTriggerPort = TRIGGERLINES_BOTH;
}
else if(iDigitalDelayCycles == 1)
{
    GPIOC->BSRR = (1<<9);
    GPIOC->BSRR = (1<<9); // 40 ns of extra delay
    GPIOC->BSRR = (1<<9);
    GPIOC->BSRR = (1<<1);
}
else if(iDigitalDelayCycles == 2)
{
    GPIOC->BSRR = (1<<9);
    GPIOC->BSRR = (1<<9); // 80 extra delay
    GPIOC->BSRR = (1<<9);
    GPIOC->BSRR = (1<<9);
    GPIOC->BSRR = (1<<9);
    GPIOC->BSRR = (1<<9);
    GPIOC->BSRR = (1<<9);
    GPIOC->BSRR = (1<<1);
}
else if(iDigitalDelayCycles == 3)
{
    GPIOC->BSRR = (1<<9);
    __NOP();
    GPIOC->BSRR = (1<<9); // 120 ns of extra delay
    __NOP();
    GPIOC->BSRR = (1<<9);
    GPIOC->BSRR = (1<<1);
}
else
{
    GPIOC->BSRR = (1<<9);
    __NOP();
    __NOP();
    __NOP();
    for(uint32_t i = 3; i < iDigitalDelayCycles; i++) // 40 ns each cycle
    {}
    GPIOC->BSRR = (1<<1);
}


[Krampmeier]

Not sure if anybody is still interested, but I would like to write down some of my findings.
Implementing the digital delay was a bit more tricky than expected, I had some more modifications. The strangest thing is that the delay of a loop cycle seems to be an odd number, not constant, and with an average of something like 41.546 ns. See attached image...
40.0 ns would make perfect sense to me, as the MCU is running at 100 MHz and 4 processor cycles sound reasonable for increasing a variable, doing a comparison (subtraction and zero flag check), and a conditional jump. How could it happen that I am getting weird non-constant fractions of processor cycles? Or is it all the non-linearity of my oscilloscope? I use the cursors for the measurements by placing them on the edges of the pulse (50% level) manually.
Funny thing is, I'd need a DSO with way more than 1 GS/s to get the same timing resolution as my 40 MHz analog scope seems to offer.

Of cause, the horizontal speed of my analog oscilloscope is not 100% spot on, but I calculated a correction factor using my frequency generator. The error of the oscilloscope seems to be consistent over the used ranges, so I can easily compensate that error before doing any other calculations.
I also checked the MCU clock input speed, which is 8 MHz spot on (constant phase shift vs. function generator @8 MHz).
Any ideas on how to resolve this?

Another big issue is the analog delay circuit. It is not as easy as I first thought: The delay time set by the digital potentiometer is not entirely linear. There are "jumps" of up to 2 ns when several least significant bits of the set value toggle, like 95->96 (0b01011111 -> 0b01100000). It took me a while to find that. If the cable length is close to the position where such a "jump" happens, the lenght is measured incorrectly. This also explains the small sawtooth spikes in the plot is showed in post #6.
I think the reason for this is the internal structure of the digital pot. It seems like the bits directly represent the internal switches of a BCD-type resistor decade, and I am seeing the effect of the capacitance of the open internal switches (FETs). The bloody thing is rated to 600 kHz...
However, this should be rather easy to solve, either by writing a small compensation algorithm or brute force: adding a 256-value table to the program.

[Kleinstein]

Using the CPU timing was OK with a 8051, PIC16 or AVR programmed in ASM, but it's not a good idea for an ARM based µC programed in C. The higher grade ARMs use caches and similar, so that the speed is not that predictable and the C-compiler may not produce the same code if things around (e.g. registers used) change. Big trouble can come from interrupts that might cause extra delays.

For accurate timing one should not use the speed of CPU running a program but one of the timer / PWM units and maybe the DMA. You might still run into the problem of starting 2 timers together so that program delay enters - but at least this would be a one time event and might need a measurement/check of the delay. So I would use 2 PWM units from one timer to output slightly different values.

The µC internal PLL might need correct initialization, that can depend on the frequency used, to give a stable clock. There can be poorly working combinations with a wobbly clock.

[Krampmeier]

I know that the delays I get this way are not predictable, so I tested it with the oscilloscope. No matter what, the delay should always be multiples of clock cycles, or not?
I am not using any interrupts or timers, btw. They are no use if I need nanosecond timing.

I thought that the MBED compiler took care of the inizialisation of the clock system correctly for me already... I have gone the hard way using the IAR compiler at work, where I have to set up everything manually in the code, but MBED is supposed to make it quicker and easier by obscuring what really happens (a bit like Visual Basic).

[Kleinstein]

With caches in the M4 based µC the runtime can be different, depending on what happened before, e.g. from where a subroutine was called. Also parallel running parts like DMA might have an influence. In any case the time should be a multiple of the system clock. It can get tricky with different clocks for the IO part and the µC - especially if they are not simple multiples. In this case there might be an additional synchronization to the IO clock.

Interrupts are to slow for delays in the 10 ns range, but the PWM output of the timers should be they way to go. I don't know about the STM32, but they should allow for rather short and very stable delays / pulses.

Usually the compiler should take care of the initialization, but I am not sure about the PLL, as this depends on the external clock.

[Krampmeier]

Kleinstein, I think you are right. I went through a lot of tweaking and I still could not get the digital delays right to the last nanosecond. The GPIO pins should be using the same clock (AHB1, 100 MHz) as the CPU core, but something is just weird about the fractional and inconsistent delays I am getting. Thank you for pointing out the additional taps I may have run into later, possibly on a different processor with an even more complex clock system. Microcontrollers are not what they used to be...

Using the PWM is a great idea. MBED does not support such a fast PWM on itself, but it does all the timer initialization for me and I just need to modify the right registers directly to get 20 ns resolution. Now it is easy to the the intermediate values with the analog delay. I will continue with the circuit shown in the attached schematic. The analog delay is substracted from the pulse width the controller generates, so the generator goes down to zero (or what the ECL logic gate can deliver).
A first quick test shows that it is basically working.
Thank you again for pointing me into the right direction!

[TerraHertz]

@TerraHertz: Wow, sweet! I like that schematic! Looks like my idea is not that new 
Do I understand it correctly that you use the transistor to drive the "High" (12 V) and the S03 open collector NAND to drive the LOW?

Yes. Though the pulser High is 5V, not 12V. See the diode to the transistor base?
Also the High is short circuit protected.

I'd try it with my HP 54121T 20GHz scope, except the input of that is +-2V max. So it would have to be via an attenuator, and that spoils the fun of watching a pulse bounce back and forth between two open ends of the coax, which this gadget allows.

I finally managed to get consistent software-delays from the STM32F4, starting at zero and in increments of 40 ns. The pipelined architecture of this processor makes it a bit hard to get such small delays, as the execution time of an instruction depends on the context. I had to tweak it a bit...  See code below.

As others have pointed out, it's hopeless trying to get accurate timing from software in a complex processor where you can't turn off pipelining, caching and interrupts.
You'd be better doing that part in analog; ramp vs software controlled level with fast comparator, or something like that. Too bad that simple way I used to get an adjustable 0 to 20nS pulse length isn't easily converted to software control.

Btw, one of the project ideas on my list (when I ever get my workshop finished 'enough') is a little device to directly measure and display co-ax cable impedance. I have an idea for a _really_ simple circuit to do it, driven by one of the tiny cheap CPUs.  Not using software timing!
For novelty really, also all those old bits of co-ax cable that tend to be lying around with no or illegible markings.

[rew]

Krampmeier, I haven't read everything, but a few searches did not tell me what CPU you're using on your nucleo.

For what you're doing, the STM32F334 is EXCEPTIONALLY suitable. The good news is that there is a nucleo for that processor.

With the F334, you won't be having trouble with analog circuits to time the pulses. You just have the CPU output a pulse of the required length. The resolution is about 217 ps. That comes to cm cable length resolution.

My next plan would be instead of measuring THAT you get a reflection overlapping with your pulse, you measure the area of the overlapping pulse. Then by doing ADC on the analog "area" you get resolution better than the steps in the pulse that you can generate. In principle, a resistor and capacitor added to your current threshold circuit should do the trick. If then after hitting the "we have overlap" point you can manage to take say 5 more pulses before the analog stuff overflows, you would get analog readings of 130,230,330,430, then you know that the step-size of a single pulse is 100 analog readings and that the overlap first happened 1.3 pulse stepsizes before the first time you detected it. (and that the 0.3 overlap was too small to trigger the detection of overlap).

Anyway. These ideas seem simple now, and will surely run into problems when you try to implement them. Good luck!

[Krampmeier]

Hi, rew, thanks for sharing your thoughts. Getting 217 (or so) ps resolution from a µC sounds great. This is as good as I can get with my analog delay now. I will have to check if that special timer can be used to control the GPIO pins directly or if the separate GPIO clock gets in the way.

I am currently using a STM32F411RE. I bought that one when I still thought would settle for using the analog delay only. I tried using the PWM periphery for generating digital pulses in the 20 ns grid now (as Kleinstein suggested), but on my oscilloscope it looks like these 20 ns per bit are not consistent. Quite similar to what I was getting when using NOPs or other dummy instructions for the delay. The diagram shows the controller's output "high" time, in front of the analog stuff.

I already tried to compensate for my oscilloscope's timing errors by using individual correction factors for each data point. I got the correction factors by measuring my frequency generators's output, which should be accurate within 2ppm. As I have a 10 MHz generator only, this does not work for times shorter than 100 ns though.
I will have to take the circuit to work tomorrow, try to get hold of one of those high-end scopes during lunch break, and check if the F411's PWM is really that messed up. After that, I can decide if I need to switch controllers or just have to put more mistrust into the cursor measurements I do with my scope.

[Krampmeier]

Did some more investigation now. My measurements were not that far off after all the error compensations. Long story short, the controller is running with a core clock of 96 (instead of 100 MHz) only, so the longer pulses can easily be explained. The pulse width at the µC output pin also has an offset of 0.75 ns, so all pulses are a bit too short. As expected, they get even a bit shorter after the first XOR gate which is used as a level shifter from 3.3 V to 5 V.
I added a re-initialization of the PLL to my program, and I tried with PLL values for 100 MHz core clock I got from the STM32CubeMX program (see attachment) and the slightly different values http://stm32f4-discovery.com. No change. Even more strange, the SystemCoreClock global variable contains the correct speed (96 MHz) even though the PLL is set differently. The 8 MHz input clock ist correct.

My PLL init looks like this (based on code I found on the net):

Code: [Select]

pll::pll(uint32_t iBypass)
{
  HAL_RCC_DeInit();  // we have to reset the clock settings !
  RCC_ClkInitTypeDef RCC_ClkInitStruct;
  RCC_OscInitTypeDef RCC_OscInitStruct;
 
  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_LSI|RCC_OSCILLATORTYPE_HSE;
  if (iBypass == 0)
  {
    // External 8 MHz clock on OSC_IN
    // You have to add X3 8MHz
    // C33,C34 18pF 0603
    // R35,R37 0R 0603 or use wire
    RCC_OscInitStruct.HSEState            = RCC_HSE_ON;
  }
  else
  {
    // External 8 MHz xtal on OSC_IN/OSC_OUT
    // Works only on Nucleo with programmmer still connected!
    RCC_OscInitStruct.HSEState            = RCC_HSE_BYPASS;
  }
  RCC_OscInitStruct.LSIState = RCC_LSI_ON;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
  RCC_OscInitStruct.PLL.PLLM = 8;       // should give 100 MHz clock, but gives 96 MHz. No idea why.
  RCC_OscInitStruct.PLL.PLLN = 400;
  RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV4;
  RCC_OscInitStruct.PLL.PLLQ = 4;
  HAL_RCC_OscConfig(&RCC_OscInitStruct);
 
  RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_SYSCLK|RCC_CLOCKTYPE_PCLK1;
  RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
  RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV2;
  HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_2);
  SystemCoreClockUpdate();                                                 // update SystemCoreClock var
}
I'd really like to know what is going on there...

Another interesting thing is the analog delay circuit. I measured a couple of values and with a 5 GS/s scope I finally got a reasonable resolution and repeatability of the values. The pattern looks quite interesting - see second attachment. I only compensated the large spikes in software so far. Now I suppose I'd better go for another solution if I want to get true sub-ns resolution. Will have a look...

[texane]

Hi,

thanks for sharing the project. Is there a place where I can obtain all the materials
(schematics, code, data) at once ? I would like to reproduce it, probably on a smaller
MCU than the Nucleo board.

Thanks !

[Krampmeier]

Hi, the projet is not finished, as I plan to replace the digital potentiometer with all it's annoying parasitic effects by something else. Maybe I can use a PWM generated DC voltage to control a varicap (very non-linear as well, would need to create some kind of approximation) or just pre-charge my timing capacitor to a certain level (there'd be a veritable mathmatical model for that).
If I started the project all over again, I'd probably use a MCU with the High Resolution Timer, as suggested by rew. Now I have to get a better resolution than that to justify my combination of digital and analog delay
However, I will put the files for the current status of the project right here into the attachment. The schematic is drawn in eagle.

[Gavin Melville]

I haven't made a TDR for a while, but you might try a wide range VCO.   Generate the pulse on the rising edge, sample on the falling edge. 1 MHz gives 1 usec etc.   Use a synth to phase lock the VCO, or drive it with a A2D and measure the frequency.  I used a D latch as the sampler, and a 2N2222 in Avalanche mode as the cable driver. If anyone is interested I can dig up schematics.

[texane]

Thanks for sharing ! I will have a look and let you know if I make any
progress.

Cheers !

[Krampmeier]

Looks like the forum software ate the attached schematic, so here it is again...
V3 is what I plan to use as a better analog delay circuit. The DC voltage will be generated by PWM. There should be a logarithmic relationship between voltage and pulse length, which is a it inconvenient, but the resolution should be pretty good. We'll see.

@Gavin, I heard this suggestion before, so I think it must be some kind of reasonable way to get accurate pulse lengths, but the whole idea of my circuit is to get a good result without any high-speed or expensive stuff. I don't want to mess with a 10 GHz VCO and PLL, and such fast sample-and-hold circuits, or pay the price for them.
Nevertheless, your schematics would be an interesting source of knowledge.

[Kleinstein]

The PLL does not need be special / fast. Even a 74HC4046 can be used to phase shift a 10 MHz clock, to get ns resolution.
Just an 10 MHz VCO and an XOR gate should work too.

For the sample an hold part, there are options without so special parts:
1) Schottky Diode bridges
2) use a ECL D-Flipflop as a triggered comparator

[Krampmeier]

Sorry for pulling this old thread up again, I just wanted to write a follow-up as the project is finished now.
As the delay times I got with the digital potentiometer were everything but a linear function of the pot setting, I tried a fixed resistor and abused a suppressor diode as a varicap. The DC at the diode was generated by a PWM from the controller. The resulting relationship between the PWM setting and the delay time looked like a logatithmic function, so I improvised a (more or less) generic curve fitter in Ovtave (Matlab clone) to get the transfer function parameters from the measured values.
That basically worked, but the "analog delay" time was rather long compared to the adjustment range, so it took some tweaking and in the end I was not very happy about how sensitive the whole circuit was to extenal influence (capacitive coupling to everything around it). No surprise considering the spider-web like setup, and I was to cheap to do a proper PCB layout.

In the end I went back to using the digital pot and used a table for the analog delay times. I had to use a scope at work in order to measure the delay for all 256 settings... Pulse length resolution is 0.2 to 0.5 ns now (not constant, due to the non-linearity and non-monotony of the potentiometer in this application). Pulse lengths goes all the way from few ns to how-long-you-want with good accuracy and resolution.

I tested the finished prototype with the cables I had at hand, and it measured up to 17 m (RG-174, I think) with reasonable accuracy (about 0.5 m at 17 m). Resolution is few centimeters, as expected.
It did not give a result when connected to a 100 m drum of RG-316. The reflection came back weakly and seemingly with some dispersion. It was still visible in the "graphical" output via the UART. It may be possible to do automatic measurements up to this length with better software. I was using just a simple threshold.

For those still interested, I'll attach the final files (and the curve fitter) here. Feel free to use them as you like. Maybe someone has another idea about what to do with such a simple precision high-resolution pulse generator?

Note: I had to remove the MBED library files from the firmware archive because of the forum's size limitation, but the TDR related stuff is all there.

[iarakis]

Hi,

Krampmeier, do you think that your STM32F4 microcontroller based design could be useful to develop a distance read leak controller (locator). As far as I know, this is one of TDR applications using parallel conductors that are "shorted" by the leak liquid. 


ie:
https://es.aliexpress.com/item/An-Ying-original-designed-safety-protection-device-locating-water-leak-detector-water-leak-controller-rs485-output/1000001419845.html?spm=2114.43010508.4.32.kM801Z

with leak sensing wire:
https://es.aliexpress.com/item/ANYING-good-quality-water-leak-detection-equipment-for-water-leak-detecting-water-sensing-cable-addressable-water/1000001400828.html?spm=2114.43010708.4.4.aJSWJw

I worry about signal attenuation along the conductor. Could you give me a piece of advice so as to use your measuring principle?

Thanks!!

[iarakis]

Could anybody help me?

Thanks!

[Krampmeier]

Hello, Iarakis,

sorry for the late reply! This is a very interesting system, I never thought about using TDR for this. I don't think that my "poor man's TDR" concept will work for this application though.
First, my device can detect opens only, no shorts. This cannot easily be changed. You'd have to use a different circuit concept.
Water has a poor conductivity, so there won't be a very strong reflection as well. I think it will be pretty difficult to detect the water location along a wire pair using TDR.

I suspect that the system you found uses a different approach. I suppose that one bare (non-insulated) wire is an resistance wire. In the end of the cable there will probably be a plug which connects it to an insulated copper wire. If a current flows through this loop, there will be a voltage drop along the resistance wire, and the electrical potential along this wire will be proportional to the distance from the connection point.
The "sense wires" will be non-insulated as well. When the water connects the sense wire to the resistance wire, the voltage at the sense wire will indicate where these connection (water) is.

I hope this helps. This concept should be much easier to implement than a TDR.

Best,

Krampmeier

[iarakis]

Thank you very much. I will keep on researching.

[iarakis]

Could you recommend me any implementation for the resistance wire method you mention? A Wheatstone bridge perhaps? A operational amplifier?
Thanks

[eduardoG26]

I have found some documents on the web of people using TDR to detect moisture level. Search for TDR and Bartling or Trebbels.

[Krampmeier]

Sorry for responding so late. An implementation would be pretty simple - the easiest way would be connecting the "sense" wire to an ADC directly. Of cause, one could put a voltage follower (opamp) in between, and some input protection, filtering, and so on, but the basics are simple and easy to implement.
I have created a drawing for clarity in case my description of the principle was not sufficient.