Mindsenors CAN Splitter

[ollien]

Looks like MindSensors just put up a CAN Splitter. It looks great, because if one CAN device goes down, all other CAN devices don't go down. Has anyone used a similar product (or wiring method that emulates it)? How well do they work?

[Tom Line]

CAN bus is a passthrough circuit. Having a device die will not take down the chain. While a star topology is possible with a device like this, it is not recommended.

[Lireal]

I believe that this wiring method is called star topology. There has been a couple threads you can search for with more in depth details. Basically, it offers no extra benefits in terms of reliability with SRXs, because the wires of each color are soldered to the exact same location, and there are communication issues that come up with star topology. Here is one thread for reference: https://www.chiefdelphi.com/forums/s...d.php?t=132323

[ollien]

Originally Posted by Tom Line

CAN bus is a passthrough circuit. Having a device die will not take down the chain. While a star topology is possible with a device like this, it is not recommended.

I should have been more precise. If we have a chain A-B-C-D, and B goes down, C and D will be inaccessible.

Thank you for your advice regarding the start topology!

[R.C.]

Originally Posted by ollien

I should have been more precise. If we have a chain A-B-C-D, and B goes down, C and D will be inaccessible.

Thank you for your advice regarding the start topology!

It shouldn't go down unless the wire is physically cut and or missing from the chain. Someone correct me if this is wrong, but the way the Talons are designed the wires are physically soldered to the same pad. We've had a few times where a talon went out but the rest of the bus worked fine.

[Jaci]

Originally Posted by ollien

I should have been more precise. If we have a chain A-B-C-D, and B goes down, C and D will be inaccessible.

Thank you for your advice regarding the start topology!

CAN works in parallel. If you open up an SRX (speaking from experience), you'll find that both the in and out CAN wires are soldered together, and then onto the board.

Green and Green are soldered together, then soldered to a pad on the board. Yellow and Yellow are soldered together, then soldered to a pad on the board.

[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

[frcguy]

If I understand this product correctly it's essentially implementing a risky and not recommended way of connecting CAN devices (star topology) that basically offers no benefits over a normal CAN connection and it costs $25.

Is there something I'm missing or is this just a an all-around bad idea?

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

[bobbysq]

Originally Posted by frcguy

Is there something I'm missing or is this just a an all-around bad idea?

I don't think you're missing anything. This thing is straight-up useless for FRC.

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

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