TDR (Time-domain reflectometer) concept. On the right track?

PS - I've now decided to connect the programmable delay line between the comparator output and the ICP1 microcontroller input, because it saves me having to add a buffer to drive the cable. I'll probably change to using 2 output pins in parallel to drive the cable, so that I can use a lower drive resistor than 150 ohms.

I use TDR a fair bit when using low voltage and high voltage cable fault location equipment on distribution networks.

I never even considered it as something that could be done based on Arduino/AVR uC.

Watching what you guys are doing with interest to see what you come up with.

I am stalled at the moment trying to get more/better information for the high speed counter from Micrel. They are not responding to my requests so assume they are not interested in little fish. I do have a plan B but once again I am waiting on the distributor to reply but as I only fired the requests off over the weekend I am not expecting anything for a few days yet. The link in my first post shows it being done (in a different way) using a PIC microcontroller and if all else fails I may build that instead but I prefer to 'roll my own' with less limitations / better features.

The PIC approach looks interesting, although I haven't yet found any data on how stable the constant current source is with temperature (or supply voltage). The datasheet for that PIC suggests that the purpose of that current source is to implement touch-sensitivity, rather than precision measurement.

Having seen on a 'scope how the rise time of the reflected signal is severely degraded (even by a short length of coax), I'm of the opinion that being able to adjust the comparator threshold(s) is highly desirable, so as to better locate the start of the reflection. It's occurred to me that this would also allow me to display an oscillograph of the signal on a GLCD, with the restriction that the signal can only be shown from the start up to the first maximum and then as far the first minimum.

I'm watching this thread with great interest.

Just a quick update on this…
I have abandoned the ideal of using high speed counters due to the complexity of designing/managing 2GHz signals. I have since discovered TDC chips that do all the counting for me and give the results over SPI interface.
The device is an ACAM GP22 TDC.
The resolution should also be better as we are talking >90ps and a measurement range up to 2.4us (more than enough for the length of cables I’m interested in) and possibly 4ms. I’m now waiting on PCB’s to knock together a test rig (if I can figure out how to solder a 5mm square QFN32 package). The attached drawing shows an UNO but if I uses a 3.3V arduino instead I should be able to reduce the component count.

TDR_V4.pdf (12.8 KB)

dc42: It's occurred to me that this would also allow me to display an oscillograph of the signal on a GLCD, with the restriction that the signal can only be shown from the start up to the first maximum and then as far the first minimum.

I some how missed your reply?? How do you expect to generate the graph as the resolution far exceeds arduino ADC sample rates.

Riva: I some how missed your reply??

I'm just back from holiday. The TDC-GP22 is an interesting chip! Please let us know how you get on.

Riva: How do you expect to generate the graph as the resolution far exceeds arduino ADC sample rates.

I will be relying on the assumption that for every pulse the Arduino generates, the signal appearing on the cable (comprising the transmitted + reflected signal) will be the same. By sending a lot of pulses and changing the comparator reference voltage and/or delay line time between pulses, I can build up a graph of the signal. As I will only be capturing the first transition of the comparator, at most I can construct the signal graph as far as one maximum and one minimum. Even that limitation could be overcome by delaying the start of the timer 1 clock signal from the start of the pulse.

Here is the latest schematic for my TDR (because I have just been asked for it). I still need to add a voltage regulator so that I can run it from a battery, and an LCD to display the result. The software needs to be updated because I am now using 2 pins to produce the voltage step to drive the cable, so that I can use a lower value resistor (75 ohms). This will be a better match to most cables than the 150 ohms that I was using previously.

Glad to see your progressing with the project. Once again I am waiting for parts/information, this time a solder mask for the QFN32 chip from a company in Canada though I'm tempted to order one of these as I could have it here next day and no need of a mask. I found an application note for the GP22 for using it in a laser range finder so hopefully I'm on the right track here (instead of using 2GHz clocks).

Hi, I'm doing a final year electronics project and have chosen to build a TDR for finding faults in a electric cattle fence.the resolution does not need to be that small because faults can be physically seen. the aim of the project is to speed up the process of troubleshooting an electric fence. i am considering whether I will use mBed or Arduino. I am told that the arduino uno/leonardo, etc. gives trouble when connecting through the laptop through the serial port and also posed other problems while programming when a shield was attached. Therefore i want to avoid using these. The arduino Mega was ok though. The mBed LPC1768 has a faster clock speed (96MHz) than the mega which should mean that it should give a better resolution. However i have read that the pulse-width is limited to 10us nut this is while the clock is at a default speed of 12MHz so hopefully i can get a fast rise-time out of it if i increase the clock speed. I am conscious though that i cannot find any sample code for a tdr for mbed and converting code for an arduino to suit mbed may be problematic. so i may be better off using an arduino and using external electronics to speed it up. Any advice would be greatly appreciated.

Hi,

I'm not sure what you mean by "the arduino uno/leonardo, etc. gives trouble when connecting through the laptop through the serial port and also posed other problems while programming when a shield was attached". Lots of people are using these Arduinos. If you use a Leonardo then you don't program via the Arduino serial port, you program directly through the USB port.

What resolution do you require? You will find several different approaches described earlier in this thread, including:

  1. My very simple TDR using an Arduino and a high-speed comparator. Resolution is limited to 62.5ns (about 15 to 30 feet depending on cable type) using a standard 16MHz Arduino, although by migrating the design to a 20MHz standalone atmega328p, you could improve this to 50ns (about 12.5 to 25 feet).

  2. A modification to my TDR design which adds a variable delay line, improving the resolution to 1ns or better.

  3. Riva's idea for a TDR using the GP22 chip. This is a very nice looking chip and should provide very high resolution.

Well when we were learning code with the leonardo last year we kept on having to plug the usb in and out and change the serial port say from com3 to com11 and even when you got the program to upload, it might not work the next time. as far as i know last years class also had problems with the uno and possibly the duememilanova that delayed their progress but they werent as bad as the leonardo. so the lecturer said to use the mega because they were able to get that going easier last year. the lecturer also recommends the mbed because they are much easier to use. Practically a resolution of 15 feet would be adequate because if you just had the general area of the fault, you could visually inspect the wire in that area and if there is a post in the area then you can tell that the post is the cause of the fault. I was also thinking about being able to change the pulse width of the transmitted signal.So the smallest pulse width would be used first to scan the immediate area then you would toggle up through increasing pulse widths to scan further out the fence line. i have read that increasing the pulse width can make the position of faults clearer because the energy of the signal is dissipated as it travels through faults.

t00158713: I was also thinking about being able to change the pulse width of the transmitted signal.So the smallest pulse width would be used first to scan the immediate area then you would toggle up through increasing pulse widths to scan further out the fence line. i have read that increasing the pulse width can make the position of faults clearer because the energy of the signal is dissipated as it travels through faults.

My TDR design uses a step function, not a pulse. The advantage is that there is only one edge to be reflected and detected. If you use a pulse, then you need to try to work out whether each of the received steps are reflections of the leading or the trailing edge of the pulse.

Yes, that sounds like it would make things simpler. Does your design just send out a single rising edge?
If so I would imagine that the range would be large enough. Any idea what is the maximum length of cable you can test?
An elerctric fenceline would be several kilometres long. I would not need to test the entire fence as i could travel out farther with the faultfinder. However there are a lot of joinings which would dissipate the signal so a large range is desirable for my TDR.

t00158713: Yes, that sounds like it would make things simpler. Does your design just send out a single rising edge?

It sends out a series of pulses, however the trailing edge of the pulse doesn't occur until after the reflection has been detected. Between pulses, it adjusts the threshold on the comparator, so that it can search for the reflection. You can find the details earlier in this thread, in message http://forum.arduino.cc/index.php?topic=183770.msg1365676#msg1365676. In my revised design at http://forum.arduino.cc/index.php?topic=183770.msg1402815#msg1402815 I've added some protection for the microcontroller and the comparator. I also added the delay line, but you won't need that because you don't need higher resolution than the basic version provides. Note that the software needs modifying for that version, because it uses 2 output pins in parallel to drive the cable.

PS - I suggest you start by determining the impedance of your electric fence and the speed of signal transmission in it. To measure the impedance, generate a pulse from an Arduino, feed it into the fence through a resistor, and look at the size of the initial step on an oscilloscope. To determine the speed, short the fence to ground a known distance away (at least 100') and measure the time to the reflected pulse on the oscilloscope. See http://forum.arduino.cc/index.php?topic=180925.msg1342078#msg1342078 for what you should see (the last 2 pictures were taken using a step).

I presume the electric fence is single-wire. What are you going to use as the ground connection? Are there other non-electric wires in the fence that you can rely on to be continuous, or will you have to use an earth spike?

When you say joinings, what do you mean? Just another length of wire, or multiple wires joining to one point?

Thanks for the advice. I will have to use a ground spike(the fence is single wire and is earthed near the energiser/fencer with a long probe going into the ground). The joinings in the fenceline include 'junctions' where the path splits in two. If there is a fault in one or both of the paths after a junction then the TDR would not be able to tell which path the fault(s) come from. Therefore you would have to test each path individually to find out where the fault is. I wonder if it would be possible to map out all distances between the junctions on the fenceline and then pinpoint the location of the fault on the map using the following method. Say you would expect a junction on 'path 1' 50 metres after the first junction and junction on 'path 2' 30 metres after the first junction. Then if the TDR reads a fault 20 metres out from the first junction and then a junction 50 metres out from the first junction then you know the fault is on 'path 2'. Then you coud display on an LCD the map of the fence with 'path 2' flashing in red to show there is a fault there. The TDR would probably have to be fixed near the energiser for this unless you could tell it where on the map you are. The main problem with this idea however is that after a few junctions the signal might be dissipated. I will first build the TDR and see if it would be possible after that.

You will also get a reflection from every junction, which will make it difficult to locate a fault after a junction.

What sort of faults are you looking for: open circuit wire, short circuit to ground, or both? A junction will look like a short circuit (i.e. the reflected pulse is inverted), but with lower amplitude than a dead short. So detecting an open circuit after a junction may be easier than detecting a short circuit after a junction.