Talk:CAN bus

message: I don't know anything about CAN, but I was looking into NMEA, which has recently evolved from its serial carrier roots (see NMEA 0183) to NMEA 2000, which appears to use CAN.  I'd have thought that was worth recognising.
Carry on the good work.
:Agreed. NMEA 2000 is definitely derived from CAN, since the marine engine and electrical people, rather than the more electronic (navigation, communications, etc.) seemed to drive it. Having been through the IEEE 802.4 Token Bus for manufacturing, which was eventually overtaken by 802.3, using fiber rather than coax to get around noise problems, I do take it with a grain of salt. In marine applications, I am seeing Ethernet for some of the more general purpose computer interaction, while NMEA 2000 is more for the dedicated microprocessors. 
:That ISO and NMEA standards are expensive to purchase may be a factor. IEEE seems to be moving to more of an open publication model, which the IETF always has been used. One of the reasons for the failure of OSI protocols was the cost of the documents, just to evaluate it. 
:To what extent should NMEA 2000 be integrated into this article? The lead starts off with respect to automobiles, but is not the applicability wider?Howard C. Berkowitz 01:02, 2 December 2007 (UTC)
thread_title:  NMEA CAN 

message: Hi in the koopman paper he gives the canbus crc as 0x62cc
Someone has changed this to another CRC.
could they tell me why please ? Is the koopman paper incorrect ?
(I somehow doubt it)
 -- Robin48gx
I noticed the same thing.  When I transmit the same packet from an STM32, I get a very different CRC than what's depicted in the diagram.  According to the hardware, the correct CRC is 0x7753.
 -- Omega  — Preceding unsigned comment added by 73.11.30.201 (talk) 18:36, 17 March 2017 (UTC)
thread_title:  Can CRC =

message: Is it plesiochronous ?  The data is sent at a rate with a tolerance of within say 50 ppm of a standard bit rate and since the other end is reading data, it looks for frames and bytes.  The receiver then recovers the clock rate which was implicit in the received data (from the voltage transitions and line codes? ), without being separate start/stop bits or an explicit Signal Element Timing circuit.
-- Midnight Hour  — Preceding unsigned comment added by Midnight Hour (talk • contribs) 12:30, 22 October 2014 (UTC)
thread_title: Synchronous or Asynchronous?

message: my question is what components both hardware and software would it take to create a CAN BUS between several microcontrollers or FPGAs. Where can I find such Information?
Thank you,
Jerome
:You need a CAN controller (e.g., MCP2510 by Microchip) and a CAN transceiver (e.g., PCA82C250 by Philips).  The controller gets you a logical interface and transceiver gives you physical interface.  Plus the software to interface with the controller.  You can get microcontrollers with built-in controllers and so just need a transceiver. Cburnett 22:30, 31 December 2006 (UTC)
thread_title:  what components (hardware and software) 

message: I have added a Bit Timing section to go with the diagram, but it needs a lot more text adding. Rocketmagnet 11:11, 9 January 2007 (UTC)
thread_title: Bit Timing Diagram

message: A representative of a company that maintains a CAN tutorial website asked me to add them to the external links section.  He or she did not to so his/her self because of WP:COI. I said that it should be discused rather than giving me the sole decision, so I'm posting it here.
:Question: Could you please evaluate the following link that leads to a very comprehensive CAN tutorial? http://www.softing.com/home/en/industrial-automation/products/can-bus/more-can-bus/communication/broadcast.php?navanchor=3010076
:Since I am affiliated with the company Softing I should not add this link. Instead, I would like to ask you as a neutral editor to evaluate this link and to add this link to the external link section of the Controller Area Network article if you think the link provides valuable information.
What does everyone think? --Selket 18:32, 2 February 2007 (UTC)
thread_title:  External Link 

message: Various tools are available for developing CAN systems using these high level protocol. For example:CANopen ConfiguratorX-Analyser for CANCANoeTeknewell EngineeringCANalyzerCANsniffCANgate
Should we also remove the link by 24.91.109.193 to TekNewell, which seems to be nothing more than a commercial software suite for interfacing with CAN?  --Symmetry 18:47, 4 October 2007 (UTC)
thread_title:  Advertisement material moved from article 

message: Can soemone explain and then fix the table in the article (copied below for reference. I understand CAN, I understand dominant and recessive, I understand the AND function. I don't understand the table - what are the columns what are the rows, why is one cell empty, why are some entries bold? -- SGBailey 19:32, 31 July 2007 (UTC)
thread_title:  Puzzling table 

message: While I can accept that ECU can stand for electronic control unit. DaimlerChrysler (as was) always used ECU to refer to the Engine Control Unit! TinyMark 20:58, 6 November 2007 (UTC)
thread_title:  ECU ??? 

message: From the article: "Interframe spacing between frames is normally 96 bits. It provides time for machines on an Ethernet network to listen and have a chance to send data"
This is obviously incorrect. The correct interframe spacing is something like 6 bits, and Ethernet has nothing to do with it.
Brolin (talk) 13:25, 22 July 2008 (UTC)
thread_title:  interframe spacing 

message: This article have some content that passes for knowledge but are really just platitudes:
"The integration testing phase requires that the “live” ECU’s be interconnected for the first time and the ultimate goal of this phase is to eliminate all causes of system behavior which may negatively impact the manufactured products reliability."
"Time constraints require efficient use of test processes, available resources and tools to ensure the highest levels of product quality are delivered at the conclusion of the integration testing phase. Testing teams must possess a means for identification and isolation of faults, along with the experience needed for quickly assessing possible root causes. The time required for actually tracking down and solving the root failure mode can often be extremely difficult and not time effective in widely distributed processes."
"Testing tools must be scalable, flexible, and integrate able to provide test coverage for all pertinent levels of the OSI model. The ideal test tools themselves must provide the knowledge and know-how of skilled engineers by identifying questionable conditions, and then using reasoning to guide the test engineer in solving the issue. The tool should also be easily configurable, comprehensive, include predefined test libraries, and provide extremely reliable measurements.."
The above quotes from this article shows a statement of goals or how things ought to be, with no indication whatsoever of how to achieve it given the difficulties faced in the CAN integration process.  
Flags for platitudes vs real knowledge are phrases such as "to eliminate all causes of system behavior which may negatively impact the manufactured products reliability" (that is a general quality goal that is not specific of CAN), "efficient use of test processes" (tell me, where is there NO need for efficient use of test processes?  What processes are those, and which apply to CAN systems integration versus other systems integration scenarios?), "Testing teams must possess a means for identification and isolation of faults" (please enlighten me; how is THAT supposed to be achieved in the context of CAN systems integration?  Do you actually know how?  Please say so!)
The last quote is really a jewel: it is an utopian tool that is supposed to do the work of the test engineer so s/he does not have to.  Does it actually exist, or it is just a figment of someone's imagination?  In absence of concrete examples of such tool, I would go for the latter rather than the former: such tool does not exist.
These platitudes are, in fact, not constrained to CAN system integration; it is common to ANY systems integration.  They add no value to this article (or any other).  I propose to strike them out and simply describe the systems integration process, if the author has no real knowledge of how to achieve such integration in the CAN context.  —Preceding unsigned comment added by Lamp90 (talk • contribs) 04:04, 1 August 2008 (UTC)
thread_title:  Just platitudes! 

message: Can someone tell me what differs CAN 2.x from previous (CAN) standards?
AFAIK CAN 2.0 introduced 29 bit IDs.
Iulian-Nicu Șerbănoiu 15:03, 20 December 2010 (UTC)
thread_title:  CAN 2.x 

message: CANBus (controller area network) alarm and tracking system infomation is availabe from [canbus.pfkelectronics.com]link title
Data communications protocol (digital codes) to control and monitor functions on most modern canbus vehicles are identified using diagnostic tools only available to trusted Dealers.
The digital canbus codes are transmitted along a two wire canbusnetwork referred to as a BUS hence the word CANBus or CAN BUS.
There are other interfaces used to get CAN codes as most manufactures will not share this information easily, if you are requiring a product that will bridge your device with a CANbus system on a vehicle you should have a look at what is already availabe first  —Preceding unsigned comment added by Gregmelson (talk • contribs) 10:56, 4 March 2010 (UTC)
thread_title:  Companies that provide vehicle CanBus products and information 

message: Although the original patents on the 1980's implementations are obviously expired, what part of the new patents still forces people to license them?  It seems that you could just not use the new features?71.196.246.113 (talk) 05:00, 19 June 2011 (UTC)
replies: text: AFAICT, the distinction will become irrelevant soon: a patent based on documents published in 1991 must also be close to expiring, if not already expired. 212.159.69.4 (talk) 19:06, 18 December 2011 (UTC)
thread_title:  Patent licensing? 

message: In the physical layer diagram nodes are labeled SG1 SG2 .. SGn. What is "SG"? Is this a German acronym? Should we replace it with ECU or Node (the terms used elsewhere in the article).  — Preceding unsigned comment added by Hobsonlane (talk • contribs) 16:15, 18 December 2011 (UTC)
thread_title: SG?

message: Can you provide a background as to why the extended identifiers were added to the standard frame, making it extended frame? Was it that 11 bits were not sufficient?  — Preceding unsigned comment added by Pc 07 (talk • contribs) 06:15, 12 June 2013 (UTC)
thread_title:  Why extended data frame? 

message: I have no idea what is the cause, but the links to other languages are gone. I see them just fine on e.g. :de:Controller Area Network, but not here. Can anybody help? Tony Mach (talk) 12:21, 18 August 2015 (UTC)
thread_title:  Links to other Languages absent (Wikidata) - Please help 

message: ISO 11898-2:2016 now exists. And from what I heard, it supports up to 12 Mbps CAN FD.  — Preceding unsigned comment added by 62.119.168.113 (talk) 08:10, 11 January 2018 (UTC)
thread_title:  ISO 11898-2:2016 

message: The article starts out with defining a CAN bus as a vehicle bus. IMHO, that's overly specific: It was developed by Bosch who certainly had vehicle applications in mind. However, it's also used e.g. in control cabinets for industrial machinery.
I'd like to update the article by saying just that: designed mainly as a vehicle bus but now also used in other environments.
Any opinions?
-- Wrev (talk) 08:58, 21 January 2019 (UTC)
replies: text: At present, it has vehicle bus as a wl in the lead. It needs to keep that. I've no objection to anything expanding on this with non-vehicle applications, but it should keep vehicle bus in the prime position. Andy Dingley (talk) 11:45, 21 January 2019 (UTC)
thread_title:  Definition as 'Vehicle bus' seems overly specific 

message: "may have as many as 70 electronic control units (ECU) for various subsystems.[7"
Is there some reasonable limit? 70 requires 6+ bits (i.e. 7 or more). Is there something else that constrains this to 70?  — Preceding unsigned comment added by WithGLEE (talk • contribs) 16:25, 8 December 2020 (UTC)
replies: text: There is no limit from the protocol. There is a limit by the transceiver used, bacause a choosen transceiver can drive only a certain amount of current and such only a certain number of nodes can be connected. The weakest transceiver defines the usable nodes in a network. There may is also limitation by the higher layer protocol used like 64 in DeviceNet, 127 in CANopen. MisterTS (talk) 19:39, 25 April 2021 (UTC)
thread_title:  How many control units can it support? 

message: This seems to be incomprehensible (in sub section Bit stuffing):
: "An incorrect is CRC used for bit stuffing illustration purposes."
What is meant (if any)? That the CRC value is invalid for the example CAN message (resulting in an error frame)? Where does bit stuffing come in (it also happens in the CRC field)?
--Mortense (talk) 19:56, 12 October 2021 (UTC)
thread_title:  Incomprehensible 

message: This article contains much technical information, but hardly any practical information on usage.  
What items on a vehicle are typically controlled by the CANbus?  What items are typically not controlled by the bus?   Do the power lines in the D plugs only power the transceivers+controllers, or do they power electrical consumers too (eg indicator light)?  
When separate power supply is required to power a device (eg full beam bulbs) is a separate plug/socket used to connect the device to power?, or do some manufacturers combine a power cable with the bus and use a beefier plug/socket so that each device only requires one male and one female connector?   
I could ask similar questions for use in elevators, escalators, and travelators.  
Thanks. FreeFlow99 (talk) 11:31, 12 November 2021 (UTC)
thread_title:  Applications 

message: "The CAN bus also takes inputs from the rain sensor to trigger the rear windscreen wiper when reversing"
For new students of CAN Bus, this could be very confusing. CAN Bus itself cannot take any input nor process informations. 2003:E5:DF11:9800:71E6:AD9A:BF7D:B57A (talk) 08:26, 6 May 2022 (UTC)
thread_title:  CAN Bus can not process data 

message: You didn't explain why you reverted me.  I thought I gave an adequate explanation of what I was doing im my edit summary.  The edit that added the clarification needed tag actually succeeded in making the whole passage far less clear to the reader. SpinningSpark 23:42, 10 October 2022 (UTC)
replies: text: I don't know what happened there.  I had no intention of making that revert.  All I can guess is the pointer just happened to be sitting on revert and something fell on the mouse. It has been one of those days.  Anyway, I reverted my revert.  Cheers. Constant314 (talk) 01:07, 11 October 2022 (UTC)
replies: text: Thanks, no problem.  I've made my own fair share of stupid mistakes on Wikipedia so I can't complain.  SpinningSpark 08:48, 11 October 2022 (UTC)
thread_title:  Clarification 

message: As I understand it, the article confuses frames (the basic units of transmission) with messages (information being communicated, via a Data Frame). Lots of references to messages should be changed to frames, among other clarifications. ★NealMcB★ (talk) 18:16, 30 December 2023 (UTC)
thread_title:  Distinguish messages from frames 

message: CAN DBC files seem to be important for working with CAN bus messages. ★NealMcB★ (talk) 18:19, 30 December 2023 (UTC)
replies: text: That's part of CANopen. It's the layer above this article, which is the physical layer.Alexceltare2 (talk) 10:38, 26 April 2024 (UTC)
thread_title:  Describe DBC files, simple databases for defining message formats, purposes, contents etc.