Mindsenors CAN Splitter

[Ari423]

From everything I've read and understand about CAN, the bus was designed to be used in series, not parallel. According to some other posts by knowledgeable people that I can't find right now because I'm on mobile, using a star topology can introduce noise and bad things into the network and is generally not recommended. Especially considering any good CAN device should have the CAN leads physically connected so the signal is passed through even if it fails. Can someone correct me on this or is this product pretty useless?

[Jaci]

Originally Posted by Ari423

From everything I've read and understand about CAN, the bus was designed to be used in series, not parallel. According to some other posts by knowledgeable people that I can't find right now because I'm on mobile, using a star topology can introduce noise and bad things into the network and is generally not recommended. Especially considering any good CAN device should have the CAN leads physically connected so the signal is passed through even if it fails. Can someone correct me on this or is this product pretty useless?

Honestly, it doesn't make a huge difference.

The CAN bus is, well, a bus. The bus is two wires (CAN-Hi and CAN-Lo) that are connected by a termination resistor (120 ohm) on each end. The CAN-Hi and CAN-Lo signals are equal but opposite, as shown below, so that, when twisted together, they reduce the effects of interference and data corruption.



The termination resistors are put in to prevent signals from 'bouncing back' or 'echoing' inside the bus, such that signals are not repeated or misread.

With this knowledge, you should be able to see what the purpose of these termination resistors are, and why CAN exists in a bus (every 'node' on the network can read and write). You should also notice that the bus is mostly arranged in parallel. See the circuit diagram below.



Something you should notice is that, because of this, it doesn't really matter where you attach a CAN device. You can do it either along a single line, branching off (kinda like a highway), or a single point that branches out to multiple other devices, like a star, with a termination resistor at the end.

Something you should note is that this isn't a true star topology. The RoboRIO has an inbuilt 120 ohm resistor on its CAN bus, which means there must be a 120 ohm resistor on the other end. This functions like a bus, with any devices branched off in a 'star' pattern also belonging to the bus. Despite them all being connected at a single point, it's the same thing as using a bus, but bringing all the connection points closer together. It looks like a star, but in reality it is a bus. The actual name for this arrangement is 'high speed CAN'.

A TRUE star topology is different from a bus in that it doesn't use a termination resistor at all. Instead, it relies on the combined resistance of all of its members. By the ISO 11898-3 spec, the overall resistance should be about 100 ohms, but never less. The actual name for this arrangement is 'low speed, fault tolerant CAN'. This name is misleading as normal CAN is fault tolerant for if devices go down (e.g. an SRX carks it), but the star topology is fault tolerant if a physical connection is severed. You can read more about the differences in this wikipedia document, under 'Architecture'.

All the images in this post were taken from this page.

[Al Skierkiewicz]

Guys,
This has been discussed many times here on CD. The CAN buss is essentially a transmission line with terminations at both ends. The terminations serve to reduce reflections along the line. On an FRC robot, the lines are fairly short and individual reflections may or may not cause interference on the buss as a whole when set up in a star topology. However, do not carry that forward to non-FRC designs in the future.
Any failure in the transceiver circuitry that would short the buss would affect all devices on the buss. Only opening the buss affects those device(s) down stream.

[FrankJ]

Keep in mind the FRC application is not "low speed fault tolerant". FRC Can is running at 1 Mb/sec. The recommended maximum stub length is 1/3 meter (roughly 1 foot). This thread discusses why not to use star topology by people way more knowledgeable than me.

Here is a TI white paper on the CAN physical layer

[Jared Russell]

If I were selling this product, I'd probably update my product page and/or my page about CAN networks to at least mention that if a star topology is used, the stub lengths should be kept as short as possible to minimize the risk of reflection interfering with communications.

Debugging a flaky CAN network is one of the least fun "learning opportunities" in FRC. Having done so in the past, I'd personally be hesitant to deviate from a linear bus without a good reason, and in that case I'd try to keep my deviation as small as possible.

[cbale2000]

We ran our robots CAN in Star Topology last year and didn't have any issues with it. The only problems we did run into were related to wiring and not the network itself (and the wiring issue was fixed when we went through and properly soldered all the connections).

Having previously had a robot where a single faulty CAN connection disabled the entire robot for the match on several occasions (courtesy of ineffective quick-disconnects) I can say I definitely don't mind the redundancy in the system. I'd much rather loose a collector or a single drive motor than have the entire machine parked in the middle of the field for a whole match.

[ollien]

Originally Posted by cbale2000

We ran our robots CAN in Star Topology last year and didn't have any issues with it. The only problems we did run into were related to wiring and not the network itself (and the wiring issue was fixed when we went through and properly soldered all the connections).

Having previously had a robot where a single faulty CAN connection disabled the entire robot for the match on several occasions (courtesy of ineffective quick-disconnects) I can say I definitely don't mind the redundancy in the system. I'd much rather loose a collector or a single drive motor than have the entire machine parked in the middle of the field for a whole match.

Hm. I'm curious as to why you didn't run into reflection issues like others have been suggesting (in both this thread and the other). How long were your wire runs?

[FrankJ]

Originally Posted by ollien

Hm. I'm curious as to why you didn't run into reflection issues like others have been suggesting (in both this thread and the other). How long were your wire runs?

Keep in mind that this is rarely works/doesn't work scenario. Below a certain level it will not show up at all. Then it is a noisy line. You start losing packets. CAN is fault tolerant so they get re-transmitted. Once again you may or may not notice. Especially if you don't have a lot of traffic on the bus. Next you start getting quirky non repeatable issues. That might get attributed to other things.

[cbale2000]

Originally Posted by ollien

Hm. I'm curious as to why you didn't run into reflection issues like others have been suggesting (in both this thread and the other). How long were your wire runs?

All of the Talons we used (about 10 total) were more or less their uncut stock length (with the exception of two which had ~6" extensions soldered on). All other CAN devices (PCM, Rio, PDP, etc.) were connected with CAN wires between 6"-12" in length. We also only used one set of wires from each CAN device (the second set from the Talons were bundled up with zip ties, kept as spares in case the main set broke).

The setup used the standard CAN termination with the roboRio and the PDP with no additional resistors added.
All CAN devices were wired to a pair of grounding bars (one for each color wire) we ordered from McMaster and connected using ring terminals. Also, if I remember correctly, the total bus useage was around 60% (though that may have changed as programmers added features).

[ozrien]

Using a star network generally creates more problems on CAN bus than it will solve, and we do not recommend it.

Please read pages 35-37 of the Talon SRX User's Guide.

http://www.ctr-electronics.com/talon...ical_resources

[Ether]

Originally Posted by ollien

Hm. I'm curious as to why you didn't run into reflection issues like others have been suggesting (in both this thread and the other). How long were your wire runs?

Originally Posted by cbale2000

All of the Talons we used (about 10 total) were more or less their uncut stock length (with the exception of two which had ~6" extensions soldered on). We also only used one set of wires from each CAN device (the second set from the Talons were bundled up with zip ties.

I'd love to put a scope on those wires and see what the signal looks like at the nodes.

[cbale2000]

Originally Posted by Ether

I'd love to put a scope on those wires and see what the signal looks like at the nodes.

Not sure if we have a scope that works, but assuming we did, how would you go about doing that? Just connect one probe to green and the other to yellow?

Originally Posted by ozrien

Using a star network generally creates more problems on CAN bus than it will solve, and we do not recommend it.

Please read pages 35-37 of the Talon SRX User's Guide.

http://www.ctr-electronics.com/talon...ical_resources

Does Star topology assume both yellow and green wires are connected to the same hub? If that's the case this is not what we did. Our Topology actually looks similar (in my opinion anyways) to the "master cable harness" topology except rather than using a cable we used two busses, one for each color wire.

[marshall]

Originally Posted by cbale2000

Not sure we have a scope that works, but assuming we did, how would you go about doing that? Just connect one probe to green and the other to yellow?

Not quite but close. You will need a DSO-style scope that can help you look at the signals and do some analysis on them with looking for noise.

I actually think a better idea would be to use some of the tools now available via Linux for looking at the CAN bus for timeouts and retransmits (I believe you can do this on the RoboRIO in code too). I suspect you're going to see more errors with a star topology.

We actually have a scope that can do this and if I had time then I'd like to but I don't honestly have the time to dig into it. If there is a team in NC that wants to do it then I'll volunteer the scope for the research but they would need to come out to our space to use it and bring the necessary test setups with them.

[Ether]

Originally Posted by marshall

...a better idea would be...

It's a good idea, but it's not better, just different.

Depends on what you're trying to accomplish.

You'll need a piercing probe with that DSO to look at the signal at the SRX.

[asid61]

After going through the TI whitepaper (which only briefly mentions stub length and doesn't explicitly mention the words "star topology" at all, although it was a good read), running star topology doesn't seem too bad.
The main problem with stubs seems to be that the lack of termination resistor can cause reflections. The solution is to simply make the stubs no longer than "1/3 of the line's critical length" to make the reflections unnoticeable to the line.

This is explained in the following passage:
"The critical length of a bus line occurs at the point where the down-and-back propagation delay (tprop(total)) of a signal through a line equals the transition time(tT) of a signal (the greater of the rise or fall times). Network Critical Length = tT = tprop(total) Therefore, a typical CAN driver may have a 50 ns transition time, and when considering a typical twisted-pair transmission line prop delay of 5 ns/m, the down-and-back delay for one meter becomes 10ns/m. The critical length becomes 5 m (50 ns / 10ns/m = 5 m), and the max un-terminated stub length for the network is 1/3rd of the critical length, or 5/3 m (1.67 m)."

I'm not sure what the transition times or propagation delays are for a regular FRC system, but just judging from their example (which seems reasonable) a star topology should be more than doable; at the very least, it's not an all-around bad idea or straight-up useless. Does anybody (maybe from CTRE) have firm numbers for propagation delay and transition times?