Building a poor man's Time Domain Reflectometer

[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.