I’m wondering if anyone ever take CANivore and CANcoder apart and looked at PCB.
On CANivore, there is a CAN controller printed with DADT1436,
on CANcoder website pic, clearly shown DADT1428,
on CANifier it shows DADT1428.
DADT seems to be a MCP2562 CAN 2.0 Controller from Microchip (or Atmel at the time it was designed).
For those don’t know, CAN FD is next-gen of CAN 2.0, Lower bus utilizations, Larger frames, 8Mbps vs 1Mbps…according to CTRE website.
I’m wondering how did CTRE manage these CAN FD feature through a CAN 2.0 controller chip? Is it worth to invest CANcoder and CANivore? What extra feature I would get from Phoenix Pro through the CAN FD upgrade?
Thanks for the help from XiaoBai and Mr. Hao for exposing the PCB !
Signals from all the devices on a CANivore are sampled and published to the CAN bus at the same time. Additionally, API can synchronously wait for data from multiple devices on a CANivore to arrive. This significantly reduces the latency of data acquisition over CAN.
Lower Bus Utilization
Just like in Phoenix 5, we use the higher data baud rate of CAN FD to reduce bus utilization (by around a factor of 2.3 for an 8-byte CAN frame).
Furthermore, for all Pro devices, all status signals have been shoved into 1-2 large CAN FD frames, instead of 8-12 CAN 2.0 frames. This reduces latency by minimizing the impact of CAN arbitration, and reduces bus utilization by minimizing the amount of CAN frame header data we have to transmit, all while increasing the update frequency of all status signals.
Better Fused CANcoder Support
When using the FusedCANcoder remote sensor type on a CAN 2.0 bus, we only fuse a remote CANcoder to the internal rotor during no motion. However, on a CANivore, we continuously fuse the remote CANcoder.
More Advanced Control Requests
We don’t take advantage of this in our 2023 Pro libraries, but larger CAN FD frames mean that we can create more advanced CAN FD-exclusive control requests in the future.
CANivore lets you configure devices and test code without a roboRIO. You can plug the CANivore into your computer and run a robot program in hardware-attached simulation.
For reference, all of the CTRE devices I can see have MCUs that support CAN-FD (I had to open PIC datasheets to reference this. Day ruined). However, I can’t tell if the transceivers support the higher data rate. Maybe they do? Or maybe they can run higher then their spec?
very interesting. If they’re really using DADU (MCP2562) instead of DADY (MCP2562FD) that’s surprising. The bus might work anyway at 2-5 MBPS bit rates but the specs are clearly better on the FD variant. In particular the loop delay time is marginal for bit rates >2MBit on the non-FD version. Some parts might work, others might give issues as they get hot.
I don’t know what you people are on about but what I can tell you is that with my IPEH-004022 CAN FD adapter, I must set things to 10mbps to see traffic and talk on the CAN FD bus that CTRE devices use.
These are the specific settings that must be set (please note that this photo and this entire thread are a loaded foot gun for anyone not knowing what they are doing):
OK, wow. CTRE is running CAN FD at 10 MBit FD data rate. That seems ill advised. The specs on the DSPIC only go up to 8 MBit FD rate. Heck, the CAN FD standard only recommends 8 MBit. That is really outside the specs on the transciever.
Looking into the details it is possible to configure the DSPIC to run at more than 8 MBit. Really surprised that they’re doing this. Why are they pushing it so hard?
Thanks for responding! From what I understand, is CANivore CAN FD using 64 byte data frame and 1Mbps?
64 byte as larger data frame definitely helps reducing the load on CAN Bus, does each CAN FD device only use single individual frame?
If it’s still 1Mbps, would larger data frame lower the PPS rate (packet per second)? For instance when decice TalonFX 1 is sending 64 byte frame, TalonFX 2’s limit switch is triggered and need to send urgently, does TalonFX 2 need to wait for longer period compare to standard CAN 2.0 bus at 8 byte 1Mbps?
Thank you for helping check more MCU! I don’t have all CTRE devices but seems like the new FD series are using MCU with CAN FD. however as u mentioned the problem is on transceiver, my friend tested scope with CAN FD bus and results does not seem like 10 or 8 Mbps, more like 900Kbps (considering test condition, 1Mbps). There is a possibility that somehow transceiver could run faster, but not seeing that happen so far.
We will get a FD adapter and try to see frames too, it would be interesting to see how CTRE run 10 Mbps with high consistency. Thanks for helping on test!
Did they look at the middle-end of the frame, or just the beginning? The F in FD means that the arbitration still runs at the 2.0 speeds. The idea is that you can have CANController Area Network FD-tolerant devices that just ignore the frame if the header (at normal baud rate) says it will be FD data.
is CANivore CANController Area Network FD using 64 byte data frame and 1Mbps?
does each CANController Area Network FD device only use single individual frame?
We use 64-byte data frames in Pro, v5 still uses the old 8-byte frame format. In Phoenix Pro, Talon FX and CANcoder each have one big status frame on CANController Area Network FD, and Pigeon 2 has two.
We also use a data baud rate faster than 1 Mbps. (Marshall’s tool reports our data baud rate as 10 Mbps.)
If it’s still 1Mbps, would larger data frame lower the PPS rate (packet per second)?
Since we don’t run at 1 Mbps, not necessarily. When running at 10 Mbps, 64-byte data frames actually have a higher PPS rate than even 8-byte frames on CANController Area Network 2.0.
TalonFX 2’s limit switch is triggered and need to send urgently
Just a note on this, all status frames are currently sent out periodically over the CANController Area Network bus, they’re not event-driven.
Something else I will note is that we’ve done extensive testing with our products to make sure CANController Area Network FD is robust. As an example, we’ve tested a 100-ft CANController Area Network FD bus with over 30 of our devices daisy-chained, some spaced very far apart, with status frame rates cranked up so the CANController Area Network bus utilization is around 80%. Even in this rather extreme setup, we do not see any CANController Area Network errors or data corruption in long-running tests.
Its like an old timey telephone. You hold one falcon to your ear and orchestra plays audio. You hold the second falcon to your mouth and the vibrations of your voice induce a current that gets sent out.
