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).
Answer
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).
No comments:
Post a Comment