We bought 2 CANivore’s for use with our swerve the next season. Our swerve has all CAN FD compatible products.
The original CAN bus works fine on the RIO. We switched the CAN bus over to the CANivore and it did not work. CANivore does connect to the rio. After some messing around we found we can connect about 5 devices at a time and any more causes it to stop working. We are using the internal terminating resistor and wago lever nuts for all connections.
What is your CAN topology like? How long are your branches?
Do you have a termination resistor on the other end of the CANivore bus? CANFD definitely needs both ends terminated to work well
From the manual:
3.1. Terminating Resistor
Inside the CANivore is a 120Ω terminating resistor which can be software enabled. This setting defaults to ON, and therefore can immediately be used to terminate one extreme end of the CAN Bus.Note: The other extreme end must also be terminated with a 120Ω resistor. We recommend soldering a 120Ω through hole resistor between the CANH (yellow) and CANL (green) wires at the extreme end of the bus.
7.3. Network Topologies
Since CAN FD is an extension of CAN 2.0, the wiring requirements are similar.
- CAN bus must still have 120Ω of termination at each extreme end.
(Note 1)- CAN bus stub lengths must be short (typical maximum of one foot).
- Daisy chaining still recommended as this reduces stub length to near zero.
In the past with CAN 2.0, teams with very short CAN buses may have been able to get some degree of success without ensuring the above requirements are met, such as with star or ring topologies. However, as transmission frequencies increase (such as in CAN FD), it is more important to ensure proper bus topology (daisy chain or short stub lengths).
Topology is standard daisy chain. Branches are 6’’ to 20’’ short for going between devices on a module and long for going between modules. Ultimately we want to shorten and clean stuff more.
Would the internal resistor on the PDP be suitable for this? I don’t know if being a non CAN FD device is a problem. Otherwise I don’t have one on hand right now.
So with a standard daisy chain, only CANFD devices (no PDP/PDH, only what you listed) and if there is a 120 ohm resistor between CANH and CANL at the far end of the bus from the CANivore, then the only other thing I can think of is maybe you have a bad connection somewhere. Bus topologies and connections that worked ok at normal CAN speed might have problems with CANFD if they’re flaky.
The PDP doesn’t work on CANFD. That’s your issue, no 120 ohm terminator. CANFD is very picky about that. The bus might work if you don’t power up the PDP, I’m honestly not sure though. Depends on how CTRE built it.
Sorry, I wasn’t very clear with my last response.
A spare PDP with termination enabled might serve as the 120 ohm terminator for the CANivore bus, only if that PDP is not powered. Or you might have issues. It depends on how CTRE built the PDP, particularly its CAN bus protections, and I’ve never tried that particular scenario.
If that PDP is powered, you will probably have issues since it is not compatible with CANFD, and the CANivore certainly will not talk to it.
If your CANivore bus is not terminated with anything at the far end, the bus will work badly or not at all. Regular CAN is more resilient to issues like poor termination and strange topologies, while CANFD is very picky due to the much higher data rate.
Of course before you get much further you will need some 120 ohm termination resistors which you can get from AndyMark, Digi-Key, and many other places.
I don’t know if this is helpful but the device I plan to experiment with, CANBed Dual, referenced this document as well:
CAN Physical Layer and Termination Guide - NI
Note my understanding is the twisting and equal wire length are very important as well. I don’t know if this is the best document because I am not an EE but it seems to explain:
Diagnosing CANBUS Communication Problems | Orion Li-Ion Battery Management System (orionbms.com)
Both are important, twisting more so than wire length matching. Even at CANFD edge rates a wire length difference of 10 or 20cm would not have a significant effect. Twisting forces external magnetic and electric fields to influence both CANH and CANL equally, and CAN uses differential signaling which uses the difference between voltages on the two wires to transmit data.
The termination resistors serve two purposes. The first is to damp out reflections caused when the signal traveling down the bus hits a discontinuity (like the end of a wire). Termination is used in most high speed data signals.
But for CAN in particular the termination resistors serve a second purpose - they are crucial to getting any data at all. CAN transceivers only drive the bus actively when sending a 0, or dominant, bit. In dominant state CANH is driven close to 5v and CANL is driven close to 0v. For a 1, or recessive, the transceivers don’t drive the bus at all and instead rely on the termination resistors to pull CANH and CANL together. The resistors have to discharge all of the capacitance of the long wires, transceivers, and any other stuff that’s on the bus, and they have to do so quickly enough so that the data is read correctly at 1Mbit for CAN and 5Mbit for CANFD.
The reason it’s done this way is so that any CAN device can start a message without damaging another. If one device tries to send a 1 and another tries to send a 0, the 0 “wins” but no damage takes place. During the arbitration phase a device trying to send a 1 but reading a 0 on the bus knows that someone else at higher priority is trying to talk and waits until the bus is free to try again.
Probably way more info than you wanted but hopefully useful anyways.
very interesting. So from a practical standpoint, is the main takeaway that the CANIvore can be used to increase overall robot CAN bandwidth, but it should only be used with devices that support CANFD? so would it be reasonable to install a CANivore and is it for swervme module motors and encoders and then use the robo rio’s can for everything else?
Yes, exactly. CTRE explicitly says that only CANFD devices will work with the CANivore (8.9 in the user manual).
The usual use case for the CANivore is to connect Falcons, CANcoders and maybe a Pigeon, sort of a “swerve drive bus,” leaving the RIO CAN for other devices
I never used it directly but I thought the CANIvore is meant to support testing without the rio or bus snooping with the rio. You can program the built-in esp32 or just use it as a bridge to USB, WiFi, or BT. However they definitely imply bus extension topology in their literature.
i think its meant for essentially the setup i mentioned above. 10 devices which all need a significant amount of data (modern SDS swerve systems) in addition to all the other robot devices is more than the robo rio’s CAN network can handle alone (my team ran into this last year), so the CANivore expand’s the system’s capability to allow for swerve+ other CAN devices to run smoothly simultaneously.
Another question I have is does supplying auxiliary power have any benefit versus powering through the USB?
Finally got a 120ohm resistor yesterday and it solved the issue. Thanks for the help.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
