# 1 kHz clock over long wire

I will have a wire that will run up to 1000 m with many nodes connected to it. The wire will run along a CAN bus and a ground wire and must transport a 1 kHz square wave 50% duty-cycle clock signal to each node.

I will run this from a 3.3 V microcontroller and the signal will be received by a 3.3 V microcontroller and a time measuring circuit as well.

In short, the clock will be used as a global time and the time measuring circuit will determine the time difference between an event and the clock edge. This circuit is able to measure with around 0.1ns precision. The ideal scenario is to have the clock be as precise as the time measuring circuit.

Any delay from the master to a node is measured/known and is accounted for.

What can I do to increase the reliability and stability of this wire/signal?

Because it's a very slow clock, I imagine that no extensive work has to be done and that something simple like a Schmitt trigger at the nodes would do just fine.

Here's a diagram:

To measure the delays to all nodes, the master stops all nodes from doing work (Over CAN it communicates that). Then it asks the first node to reflect the signal it will receive over the other line. All other nodes will leave the wires floating now.

The master sets its right wire high, triggering the timing circuit to start. After some delay, the signal will get to the node which will then let it through on the second line. After another delay, the master will receive it back which will stop the time circuit.

Now the master can read the time circuit value and determine the delay. When all node delays are known, the master will start the operation. All nodes will leave the return wire floating and will take the clock (master's right) wire as input.

When an event happens at one of the nodes, that will trigger the time circuit. The next pulse of the clock will stop the time circuit. We now know the time between the start of the event and the the next clock pulse. The node sends back at which clock count the event was detected and how much time the time circuit indicated. Together with the measured delays, the master will be able to get the global time of the event.

Oh, about what accuracy is acceptable: the target is 1 ns, would be happy with 3 ns and would be ok with 10 ns. Depending on the final design of the system, there might be a possibility for getting the event triggered multiple times and having the results be averaged, which would also improve the accuracy.

The actual timing isn't made by me, but by TI. TDC7200

The application is TDOA. The event times are fed into an algorithm to determine where the event originated from. The event is the detection of a radio signal (which will be a challenge as well to get as accurate as I want).

• Because it's a very slow clock It is but a 1 kHz square wave contains harmonics and those can extend up to very high frequencies (GHz is possible) provided the slopes of the 1 kHz are steep enough. Those high frequency harmonics can reflect at the ends of your cable and distort your nice 1 kHz square wave! So limit the bandwidth and terminate the cable with its characteristic impedance. Nov 1, 2019 at 9:50
• (there's way more questions to be raised here: Jitter/stability requirements for the clock, Allen dev, and a lot more: So: What's your use case for the 1 kHz clock?) Nov 1, 2019 at 10:10
• Ok, that makes the 1 kHz frequency a bit awkward; however: What's the purpose of synchronization here? How accurate do you need it to be? How do you plan to account for delay? Nov 1, 2019 at 10:19
• (by the way, please add this usage info to your question; it changes a lot of the things I considered!) Nov 1, 2019 at 10:22
• It may be easier to simplify this by doing the calculation in two steps. Have all of the nodes calculate the times of the events in a local time system with a high enough precision. Simultaneously, have the nodes use a timing circuit to quantify the behavior of the local clocks (i.e. drift). This gives you a lot of time to do clock-difference measurements and lets you post process it to remove any outliers. it also makes it easy to use test signals to calibrate your system like a movie director's clapboard Nov 1, 2019 at 20:35

So, the first problem will be that you need to drive that long cable! A 1km long piece of wire is simply a large load, and your microcontroller output will have a hard time changing the voltage on that reliably.

Think of the fact that the wire runs through its environment as a capacitor of wire to ground. So, you need a strong output driver.

You want that to drive a terminating load at the receiver that's relatively strong (so, maybe, 75 Ω to 120 Ω or something).

You'll want appropriate filtering at the receiver to extract the original clock.

You'll want cabling that is somewhat shielded, to not pick up 1000 m of radio antenna reception.

with many nodes connected to it

That means these many nodes need their own receiver. Can't put a strong terminator in each one of these (the load on the driver would get humongous), but if you don't, you'll get into terrible trouble with signal quality at these nodes.

To me, this sounds like you'd really want to build a multi-drop bus... like CAN!

Or, you'd want to receive, regenerate (Schmitt-Trigger?) and re-send the clock at every node – daisy-chaining them instead of using a linear bus.

will run up to 1000 m

Uh, that's really up the edge of what CAN still supports, at ridiculously low bit rates (and not all devices support the lowest CAN rate, IIRC; check that before you misinvest!)

Also note that for that length, you'd really want that CAN bus to run over shielded twisted pair or Coax. Ethernet cabling is cheap and can be bought on spools.

Considering your separate clock: you already have CAN; it's quite questionable you'd need to have a separate 1 kHz clock line along that: you have a way to communicate between nodes, in a manner that is way more accurate to time than a 1 kHz period, so just add a CAN-capable microcontroller to each node, and add a master that tells them regularly how many 1 kHz cycles have passed since the last clocking CAN message – the microcontrollers can then adjust an internal counter and generate a centrally disciplined 1 kHz locally.

That saves you cabling and gives you something that works remotely, if (and only if) your CAN bus runs reliably.

Other options would include adding self-designed bit-clock observers, that just observe the transmissions from your master to learn what bit clock that uses and to use that to generate the 1 kHz locally.

A 1000 m long bus with additional clocking functionality sounds like it's on the very edge of what you should be doing with a single CAN bus. I'd recommend segmenting that bus, if architecturally feasible. (Segmentation adds complexity, but it localizes faults and makes things easier to debug, often.)

At the very low baud rates that such a long CAN bus allows you to use, you might as well just go wireless and get rid of all the cabling. It's all a cabling vs hardware cost tradeoff, and restricted by the reliability you need (pro-tip: actually put numbers to that – even a wired bus isn't noise free, and you WILL need to think about what happens to your system if CAN bus packets get broken underway).

Personally: I'd not try to build my own bus system. For long haul, high-node count, people use use-case optimized field buses like PROFIBUS or EtherCAT, or just: Plain Ethernet! You can segment Ethernet with cheap Ethernet Switches, you can, but don't have to, run loss-safe protocols like TCP/IP on top of it, cabling with connectors is super cheap, it's well-tested.

So, your applications seems to be coordinating MCU times: That's definitely more of a job for periodic CAN messages than a 1 kHz clock. If you need accuracy, you might want to look at internet protocols like NTP and think about how to adapt them for a CAN system (the trick really is just having a roundtrip-measuring two-way exchange once in a while).

• PTP is a lot lesser-known than NTP, but is specifically designed for Precision Timing. It might be overkill, though, since you typically get sub-microsecond accuracy on a good network, which is probably 3 orders of magnitude more than the OP needs. However, even cheap switches now support PTP (it's not required but if the switch supports PTP, the accuracy is even better), and since it is also used in telco, robotics, and industrial automation, I would expect it to be supported in Ethernet switches for industrial and/or outdoor use as well. Nov 2, 2019 at 18:47
• @JörgWMittag if you click through to the discussion under Dave's answer: OP wants 0.1–3 ns of accuracy. PTP isn't even remotely achieving that. Nov 3, 2019 at 0:25

You really need to think hard about what you really mean by "simultaneous".

Over a span of 1000 meters, the concept does not extend down to the sub-ns regime. Heck, it would take a light pulse more than 3000 ns to traverse that distance, and an electrical pulse would take more like 5000 ns over an ideal transmission line. Your unshielded wire is going to be even slower than that because of the R-C delays created by the loading of all the nodes along the way.

Using GPS receivers at each node would at least get you down to the tens-of-ns range.

• Comments are not for extended discussion; this conversation has been moved to chat. Nov 1, 2019 at 13:16

Have you considered sending a sine wave and using a comparator at the receiving end to reconstruct a squarewave?

at 1km, not much of a squarewave will remain as all the higher frequency components will be attenuated due to the transmission line

• That would be a possibility, yes. But I'd have to generate the sine wave then... But a pwm signal and a capacitor should be able to do that job, but it'd keep the mcu quite busy. Nov 1, 2019 at 9:45
• @Geoxion the sine wave will generate "itself", as JonRB explained, when you attenuate out the high frequencies: Just pass your 1 kHz clock through a low-pass filter that cuts off above 1 kHz but below 3 kHz. Nov 1, 2019 at 9:53
• exactly, so it is better to generate such a sinewave in a more controlled fashion. There are many ways to create a sinewave, and quite a few wouldn't need mcu time. My advice would be at the point of generating the sinewave, locally change to a squarewave and use that signal. This will ensure the generating unit see's a similar phaseshift to the other units (due to the filtering). Also 1km... make sure you have a decent drive output since there will be a fair amount of capacitance
– user16222
Nov 1, 2019 at 9:56
• If "all the higher frequency components will be attenuated", there is no need to generate a sine wave in the first place - the transmission line will effectively do that for you. Of course, this will not apply to the "many" nodes which are physically close to the master. Nov 1, 2019 at 14:15
• Surely any noise -- and a 1km cable can be a very large antenna -- will translate into jitter if you're trying to reconstitute a timing signal from a sine wave and a comparator. Sub-ns resolution off a 1kHz signal means sub-ppm precision. Isn't the slow clock speed a detriment, not an advantage, in this scenario? Nov 1, 2019 at 19:22

If you have twisted pair wiring available, then you could simply use CAN transceivers (beware of the timeout feature) or RS-485 transceivers for the signal. They will certianly add some propagation delay, but it should be fixed.

Well 1000 m is quite a distance which provides significant capacity and inductance in the wires on top of impedance. If you apply 1 kHz square signal on one end the signal on other end will not look like square impulse at all.

It is pure physics -- take impedance, capacitance, inductance of the cable per meter and multiply by length of the cable.

There are various methods to overcome portion of the problem but usually it increases the cost of the project.

Did you ever look into opto-fiber signal transmission solution?

It is not too sensitive to radio interference, no inductance/capacity effects and propagation of the signal is close to 300,000 km/sec. Of course signal attenuation over such distance is not avoidable.

This clock signal IMO is needed for anything. Just broadcast CAN message with the current time stamp periodically. It will sync the nodes and will be the source of the internal clocks calibration data

Remember that the nodes will not be perfectly synchronized (even if you have your clock signal) as the signal will travel between the farest nodes > 3usek