I'm writing software for a project that sends data to me using a CAN bus. The software runs fine in small test scenarios with 3-4 bus members, however with increasing members the bus sends data with very high addresses and new (non hexadecimal) data I haven't seen before:
First and last 4 frames for reference
(1541503830.323881) can0 011#008955EA0AC30AC8
(1541503830.412314) can0 030#0A770A8E00100000
(1541503830.412758) can0 61F#0A770A8E00100000
(1541503830.413049) can0 69F#0A770A8E00100000
(1541503830.413889) can0 **00C480A7**#0A770A8E54707FF3
(1541503830.414182) can0 **09014E9F**#0A770A8E54707FF3
(1541503830.414464) can0 **029D3E9F**#0A770A8E54707FF3
(1541503830.414753) can0 **1A7D3E9F**#0A770A8E54707FF3
(1541503830.415040) can0 **1A7D3E9F**#0A770A8E54707FF3
(1541503830.415329) can0 **1A7D3E9F**#0A770A8E54707FF3
(1541503830.415618) can0 **1A7D3E9F**#0A770A8E54707FF3
(1541503830.415904) can0 **1A7D3E9F**#0A770A8E54707FF3
(1541503830.416192) can0 **1A7D3E9F**#0A770A8E54707FF3
(1541503830.416475) can0 **1A7D3E9F**#0A770A8E54707FF3
(1541503830.416764) can0 **1D3E9F0F**#0A770A8E54707FF3
(1541503830.417872) can0 030#0A770A8E0FF30FF5
(1541503830.466440) can0 031#0A7D54580A8E0A99
(1541503830.514830) can0 008#0000000000000000
(1541503830.520243) can0 032#0000000000000000
Here I see way too high addresses. Other unknown data:
(1541503837.081060) can0 020#0AC20AF90AE10ACC
(1541503837.081271) can0 020#0AC20AF90AE10ACC
(1541503837.081478) can0 020#0AC20AF90AE10ACC
(1541503837.081689) can0 020#0AC20AF90AE10ACC
(1541503837.082138) can0 448#**R4**
(1541503837.133876) can0 01F#**R4**
(1541503837.135442) can0 03C#0AC20AF9
(1541503837.135886) can0 0DF#0AC20AF9
(1541503837.136202) can0 75F#0AC20AF9
(1541503837.136781) can0 65F#0AC20AF9
I don't think 0x448 is used by us, also non hexadecimal data?
I need a direction to work on, am I looking at faulty hardware, or are these specifics of the CAN protocol I'm not yet aware off?
The data was logged using candump -L can0 on Linux, socket can as driver and a standalone MCP2515 as CAN interface, connected via SPI. The other members also use the MCP2515 however directly soldered on PCB.
Additional data logged with candump -e -d can0:
can0 02F [8] 00 04 00 FA 00 02 00 00
can0 010 [8] 0A BA 0A F3 0A D8 0A CD
can0 011 [8] 00 88 55 C1 0A B6 0A AC
can0 012 [8] 00 01 00 02 00 10 00 00
can0 08812DD7 [8] remote request
can0 1FF7D75F [8] remote request
can0 1EFAEBFF [8] remote request
can0 1FFBFBDF [8] remote request
can0 0FEF7FFF [8] remote request
can0 1BFFFDFF [8] remote request
can0 1FEFFDFF [8] remote request
can0 1FEFFDFF [8] remote request
can0 1FEFFDFF [8] remote request
can0 1FEFFDFF [8] remote request
can0 1FEFFDFF [8] remote request
can0 1FEFFDFF [8] remote request
can0 1FEFFDFF [8] remote request
can0 1FEFFDFF [8] remote request
can0 1FEFFDFF [8] remote request
can0 1FF7FFFF [8] remote request
can0 1FFFFFFF [8] remote request
can0 008 [8] 00 00 00 00 00 00 00 00
can0 009 [8] 00 00 00 00 02 58 00 00
can0 00F [8] 00 04 00 00 00 10 00 00
can0 030 [8] 0A 71 0A 82 0F F4 0F F1
-- snip --
can0 02F [8] 00 04 00 FA 00 02 00 00
can0 010 [8] 0A B4 0A F3 0A D6 0A CD
can0 011 [8] 00 89 55 A8 0A B5 0A A5
can0 012 [8] 00 01 00 02 00 10 00 00
can0 1FFFFFFF [8] remote request
can0 5BD [1] remote request
can0 6DF [1] remote request
can0 008 [8] 00 00 00 00 00 00 00 00
can0 009 [8] 00 00 00 00 02 58 00 00
can0 00F [8] 00 04 00 00 00 10 00 00
can0 030 [8] 0A 8C 0A 91 0F F0 0F F2
Best Answer
What you see looks like remote frames: it's a feature of the CAN bus which allows to transmit certain frames on request rather than periodically. Simply put, a regular frame is transmitted by a single node, first ID, then length, then data. With a remote frame, the node which wants the data transmits the frame ID and length plus a special bit (RTR), and waits for the node which handles that frame to transmit the actual data.
448#**R4**means that a node has requested the remote frame with ID of 448 and DLC of 4, but nobody on the bus volunteered to supply the data.