Talk:CAN bus

INTEL

In response to user:ajn1 comment regarding Intel I found this PPT: http://age-web.age.uiuc.edu/faculty/qzhang/teaching/ABE425/CAN%20Bus.ppt

States Intel developed the first silicone for CAN bus in 1987... also states that CAN Bus developed by Bosch in 1986 probably the 1989 date of the BMW technical document is when it was first used / implemented and or the standard finalized. However the above PPT does not cite any source I will only consider it to be anecdotal evidence I will continue to search for a trustable source.

NMEA CAN

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)

Can CRC =

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) 

I used a binary division algorith with the data of 000000010100000000100000001b (data from the image) with a polynomial 1100010110011001b (0xC599), as descibed in the CAN standard and got 111011101010011b (0x7753), which confirms your observation.

-- Yuni 77.94.130.182 (talk) 15:08, 5 March 2018 (UTC)

Synchronous or Asynchronous?

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)

My first question about CAN is: is it asynchronous, synchronous, or both? It seems it is asynchronous -- the Bosh spec's say "The bus consists of a single channel that carries bits. From this data resynchronization information can be derived." I'm new to serial protocols, and to Wikipedia... just making sure that "asynchronous" is the correct classification of CAN... please let me know. If so, I'll figure out how to add it to the CAN article.

Its a little of both. All nodes synchronise their clocks to the last message that went over the bus.

-- Robin48gx

--Kevin Schostek

It's synchronous and broadcast (no ACKing, a message is fully sent once it's emitted). The leading edge of the synchronization bit begins automatic re-synchronization. Bits after that are counted out by time sequence, not by a seperate reference signal.

Details here [1]

-- Julian Morrison 13:33, 7 November 2005 (UTC)

in CAN specB2.0, it said "Clocking information may be derived from transitions from one bit value to the other. The property that only a fixed maximum number of successive bits have the same value provides the possibility of resynchronizing a bus unit to the bit stream during a frame. The maximum length between two transitions which can be used for resynchronization is 29 bit times."

I don't know what is the meaning of "29 bit times" and "two transitions", who can teach me.

---

This section has not been updated in years, but it is so full of wrong information and unanswered questions that I just can't leave it as is.

CAN does not include a clock in the data transmission. All nodes on the CAN network must operate at the same bit rate, and the error between each node's internal clocks must be within tolerance, for the nodes on the network to communicate. This is the same as a PC's RS-232 serial port which is considered asynchronous. Many engineers (well at least this engineer) consider CAN to be asynchronous data transmission. Freescale calls it asynchronous in this app note. On the other hand the CAN2.0 spec and ISO11898-1 discuss bit synchronization, which is what probably causes many, including the CiA in Kevin's link above, to call it synchronous. The key difference between CAN and what I call synchronous is that CAN transceivers do not synchronize their data reception by the means of a clock edge, but derive a clock by the data transmission edge. The synchronization is bit level synchronization between nodes where each node monitors the data edges and can adjust the point within the bit that it samples the data.

Synchronizing the nodes is important for two reasons:

The first is that for the CAN arbitration scheme to work, all of the nodes need to be synchronized so that they send or receive bits at the same time [2]. All nodes in arbitration must sample both their own and the other nodes ID bits at the same time.

The second is that there is definitely an ACK (Sorry Kevin but you're wrong, see Bosch's CAN 2.0 spec in the link at the start of this section). Towards the end of the CAN data frame is the ACK field. The transmitting node sends two recessive bits (binary one - passive) in the ACK slot and expects to see an dominant bit (binary zero - active) within that slot. Each node that receives a valid CAN frame is required to send a dominant bit (actively drive a binary zero on the CAN wires) within the ACK slot. The active zero overrides the passive one and the transmitting node will see an ACK. Since the transmitting node sees an ACK it knows that the frame was received by at least one node. If the transmitting node does not see an ACK it immediately re-sends the frame. If only one node is operating on the network, the first frame it sends will not be ACKed and it will immediately resend it, over and over. This will saturate the network with CAN traffic. This synchronizing ensures that the CAN receiver (who is transmitting the ACK) generates the ACK in a position that the transmitter sees it and does not rebroadcast the frame.

Since CAN data is NRZ, there are only transition edges for the receiver to synchronize to. I.e. when the value of the current bit being transmitted is different than the value of the previous bit (zero-to-one, or one-to-zero). Hard synchronization occurs at the start bit and resynchronization occurs on every recessive to dominant transition after that. For the receiver to resync, the bits being transmitted must change value. Since the data being transmitted could be all zeros or all ones, CAN 2.0 and ISO11898-1 call for bit stuffing. When the transmitter detects five consecutive bits with the same value (including a stuffed bit) it "stuffs" a complimentary bit into the data stream. The receiver must then "unstuff" the bit from the incoming data stream. Bosch's CAN 2.0B specification does indeed state that "The maximum length between two transitions which can be used for resynchronization is 29 bit times". I don't know why since the same spec also calls for bit stuffing at five bits meaning that there will be at most ten bits between two recessive to dominant transitions.

To me, this means that CAN data is transmitted in an asynchronous format, but all of the nodes on the CAN network are "synchronized" to sample the transmitted data at same time.

To answer Julian's questions, a transition is when the next bit transmitted changes value from the previous bit. Two transitions means when the bit value changes then changes back. A "bit time" is the length of time to transmit a single bit, and is the reciprocal of the bit rate. A 125k bit rate is 8uS of time per bit. 29 bit times at 125kbit is 29 times 8uS, or 232uS.

EE JRW (talk) 02:13, 12 July 2014 (UTC)

I found that I had a number of misunderstandings of this subject and have edited my previous comments to correct the most glaring errors. I hope to use my new (miss?)understanding to expand the Bit timing section soon EE JRW (talk) 16:03, 1 January 2015 (UTC)

Is selective data transmission possible with CAN?

Hi

In my application 4 ECUs are connected to the CAN bus.Can I send messages selectively to one ECU and not to other ECUs using CAN?How to use mask or filters to do this?

Thanks Pearl

Any message in CAN is always transmitted in broadcast. Because the transmitter does not have any knowledge about the receivers. Any receiver have to decide by itself, if it is interested in a certain message. The filtering can be done in software or in hardware. If the filtering is done in hardware, then the manual for the filtering is the documentation of the according CAN controller. --MisterTS 19:27, 9 March 2006 (UTC)

To follow that up. CAN is broadcast only. It has no addressing like ethernet or the Internet Protocol. Instead, it has message identifiers that say "this is what's in this packet" and each & every node has to decide to process it or discard it.

I presume you have basically four equal ECUs that you wish to selectively talk to. Unless you have software control of the ECUs to put in place some kind of addressing in the identifier (such as reserving the first two bits as an ECU address) then you can't do it without isolating each ECU on it's own bus and putting a "switch" connecting all four buses that understands some addressing method. Cburnett 01:02, 10 March 2006 (UTC)

SAE J1939 (used for heavy trucks and buses) which uses 29-bit addresses, has a method of sending messages selectively to one ECU. using 8-bit ECU addresses. There is no room for that in the 11-bit addresses normally used for passenger cars. When wished, this must be placed in the payload data.--BIL (talk) 21:56, 1 January 2015 (UTC)

DaimlerChrysler Programmable Communication Interface (PCI) and CAN

Are these two bus's compatible with each other? I have seen PCI instrument cluster receiving messages on a CAN PCM. I'm not sure if the instrument cluster was compatible with both PCI and CAN or if PCI and CAN are mostly compatible.

what components (hardware and software)

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)

Bit Timing Diagram

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)

External Link

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)

Selket, I find the content behind the link interesting and valuable - I don't see a problem with the fact that it comes from a company. It's good practice of capable companies to contribute content and make it accessable for everyone. This is a good example.

  Sonia Trier, s.trier@web.de

I found some misinformation in the site: "Remark: CAN Specification 2.0 B passive implementations can’t store or transmit Extended Data Frames; CAN Specification 2.0 B active implementations can store and transmit Standard Data Frames as well as Extended Data Frames"

Question: Could you please be more specific about the misinformation?

Recommendation: List this link as a second source for CAN information:
If everybody is OK, let's list this external link as a second source for a CAN educational page. 68.236.126.218 17:59, 4 April 2007 (UTC)

Advertisement material moved from article

Various tools are available for developing CAN systems using these high level protocol. For example:
CANopen Configurator[3]
X-Analyser for CAN[4]
CANoe[5]
Teknewell Engineering[6]
CANalyzer[7]
CANsniff
CANgate

Should we also remove the link[8] 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)
Great software provides productivity and efficiency on the factory floors. We should keep the link.

Puzzling table

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)

Truth tables for dominant/recessive and logical AND
Bus state with two nodes transmitting   dominant recessive dominant dominant dominant recessive dominant recessive	Logical AND   0 1 0 0 0 1 0 1

OK I've sussed it. The left column and top row are the inputs and the bottom right 2*2 is the result. I'll change the table so I can understand it and if you others dislike it, revert it. -- SGBailey 19:36, 31 July 2007 (UTC)

The table is non-intuitive; Dominant is a 0 and recessive is a 1. Why? — Preceding unsigned comment added by 147.177.201.37 (talk) 12:25, 1 August 2011 (UTC)

---

This table is so confusing (and pointless) that I'm deleting it. If you are interested in what is was, here it is.

Truth tables for dominant/recessive, logical or, and logical and (for comparison)

Bus state with two nodes transmitting Dominant Recessive Dominant Dominant Dominant Recessive Dominant Recessive

Logical or 0 1 0 0 1 1 1 1

Logical and 0 1 0 0 0 1 0 1

In its place I'm adding a new table with the ID bits and contention resolution described in the text. This is my first shot at a wiki table, and I'm not very happy with it. I would be happy if someone who knows tables would improve it. Specifically, the ID10, ID9, etc. needs to have a label above them saying Node ID bit, then each column below the Node ID bit should simply be the bit number. EE JRW (talk) 00:59, 22 November 2014 (UTC)

Never mind, I eventually figured it out. I'm now happy with the new table EE JRW (talk) 17:34, 31 December 2014 (UTC)

ECU ???

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)

-I always understand ECU to mean engine control unit in the context of automotives. BMW calls it "DME" Digital Motor Electronics. —Preceding unsigned comment added by 64.238.175.105 (talk) 12:25, 24 November 2007 (UTC)

Does anyone have a reference for this? I've added the text to the page on the basis that what I've added has to be better than simply overloading the acronym without explanation, but there should probably be a citation. JacobBramley (talk) 06:19, 10 July 2008 (UTC)

- ISO11898-2 lists this in the Abbreviations Table (Section 4). User:d_rock_naut 25 July 2008

"On the other hand any official use of CAN [...]"

The article states that CAN is often used due to the low cost of CAN controllers, but then goes on to state that official uses of CAN must pay license fees to Bosch. The article does not state what constitutes an official usage.

Indeed, the CAN protocol license on the Bosch website doesn't cover use of existing CAN controllers, but is intended for ASIC developers or FPGA programmers. I can see no limitation on the use of CAN in NXP's LPC2129 microcontroller, for example, but I expect that NXP had to pay a license fee.

I suspect that the statement on the page is partially incorrect. I have no citation to back this up, but there is also no citation backing up the full scope of the existing text.

Can anyone who knows more about CAN elaborate?

JacobBramley (talk) 06:35, 10 July 2008 (UTC)

It is my understanding as well that FPGA/ASIC developers pay a license fee to Bosch. Users of CAN controllers do not. Brolin (talk) 13:25, 22 July 2008 (UTC)

As with any patent someone holds, in the whole producer/user-chain only one pays for the licence, depending on whom is infringhing the patent. Bosch has decided that anybody who distributes CAN in some kind of implementation has to pay the licence. That means, any chipmanufacturer, like Infineon, Freescale, Renesas, you-name-it, has to pay. This includes also any implementation in ASIC or FPGA. Because, e.g. Altera, does not distribute a CAN implementation, but I do so, if I implement CAN in one of the Altera chips. So I would have to pay. But anybody who uses the chips, including the one I distribute based on the Altera, does not has to pay anything.

As normally, nobody implements CAN but uses it like any other serial connection, like RS232 or Ethernet, it is free of charge. Almost nobody implements RS232 or Ethernet by himself but uses available controller chips. The very same applies for CAN. --MisterTS (talk) 14:19, 20 August 2008 (UTC)

interframe spacing

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)

Just platitudes!

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)

I'm helping reduce the platitudes and improve the knowledge density in other sections of this article. If I step on toes, let me know. Hobson Lane (talk) 14:52, 18 December 2011 (UTC)

CAN 2.x

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) — Preceding unsigned comment added by Iulian.serbanoiu (talk • contribs)

Requested move 1

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the move request was page moved.  Skomorokh, barbarian  10:14, 20 October 2009 (UTC)

---

Controller–area network → Controller area network — An n-dash between controller and area doesn't make grammatical sense. A hyphen would be an option grammatically, but the ISO spec name for the protocol just uses a space. --Ed Brey (talk) 20:44, 12 October 2009 (UTC)

Support — The en-dash is used for a range between numbers and should not be used to hyphenate or compound words/titles. (In this response, I use the en-dash after the word "support" to lead into my paragraph and before signing.) The en-dash is 100% being used incorrectly in the name of the article. – Keraunoscopia (talk) 21:09, 12 October 2009 (UTC)

• Support per nom. Tevildo (talk) 18:37, 18 October 2009 (UTC)

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Companies that provide vehicle CanBus products and information

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)

Patent licensing?

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)

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)

Requested move 2

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the move request was: No consensus to move to new title Mike Cline (talk) 22:59, 2 January 2012 (UTC)

---

Controller area network → Controller Area Network – This request follows the example of other wikipedia articles on technical standards and specifications for network busses. Universal Serial Bus is the closest I can think of. Title case is appropriate for the subject of this article as it is a proper noun, the name of a particular, standardized implementation of a network for controllers. A google survey confirmed this..relisted--Mike Cline (talk) 01:37, 26 December 2011 (UTC) Hobson Lane (talk) 14:41, 18 December 2011 (UTC)

• I agree, do it.--Asher196 (talk) 15:01, 18 December 2011 (UTC)
• Oppose. The standards body doesn't capitalize the name in this abstract and pluralizes it this one. The plural in particular suggests that "controller area network" can be considered a common noun. I'm not an expert on this topic and this article is badly referenced so I can't rely on usage in the article's sources to determine whether or not it's used as a common noun. Just like ISO style, Wikipedia style can differ from general usage. For example, Storage area network (a common noun IMO) is uncapitalized in Wikipedia, despite many American-English sources using capitals. I've never seen a respectable English-language source pluralize Universal Serial Bus and do think of it as a proper noun. The blogs that used "Universal Serial Buses" were referring to multiple versions of the USB standard. I also haven't seen a respectable sources treat "Universal Serial Bus" as a generic thing (a bus), but rather as describing a connector, or in the redundant form "USB bus." Also in Wikipedia, Internet protocol suite was recently moved to the uncapitalized form (though I don't think I'd have supported that move). "Open source" is rarely hyphenated in English-language sources, but it's hyphenated as a compound adjective in Wikipedia. Linguists (!) don't hyphenate word sense disambiguation. Applying style guidelines is a tricky matter. I'd be interested in revisiting the question when this article is well enough referenced to give a good sampling of reliable, high-quality sources. – Pnm (talk) 05:58, 19 December 2011 (UTC)
• Support The capitalization in ISO standards depends of who writes. For example, this other standard capitalizes Local area network [9], which Wikipedia lowercases. Anyways, this is the proper name of a specific protocol, regulated by a specific entity. --Enric Naval (talk) 23:24, 29 December 2011 (UTC)
• Oppose. If it's a specific standard, it's OK to respect the capitalization in the standard, which is lower case. It is not unusual to find it lower case in books, and very common in scholarly articles. Dicklyon (talk) 18:15, 1 January 2012 (UTC)
• Strongest possible support Every single one of the reliable sources mentioned in our the article’s “External links” uses all‑uppercase. That list includes this scholarly treatise on the subject as well as Bosch’s specification for the standard they created. It is not within the purview of mere wikipedians to second-guess how the real world applies or misapplies the English language nor endeavor to lead by example in hopes of Showing the World a New and Better World Order For English-Language Application of Proper Nouns®™©. The most‑reliable RSs spell it Controller Area Network (CAN) consistently. Wikipedia must go with the flow of the RSs. Greg L (talk) 20:15, 1 January 2012 (UTC)

  Greg, you are mistaken about those sources. I agree that it is important not to stray too far from sources; but look more carefully at those external links:

  1; yes, the originator of the term, Bosch, wants it to be capitalized; no surprise there. But it became an official standard, which is what the article is about, and the official standard does not capitalize it.

  2; if you download the PDF and look, it includes "Controller Area Networks" and a heading "Controller area network." Certainly not much support for a proper noun interpretation of a protocol name here.

  3 has it only in title and in acronym definition; no significant support here for proper name interpretation.

  4 has it only in an acronyn definition.

  5 has it only in an acronym definition.

  6 uses it in text only as "Controller Area Networks"; this can't be the name of a protocol, and suggests a generic usage.

  That's why I suggested we follow the ISO standard instead; that would seem to be the "most reliable" for an article on the standard. Other reliables sources that use lowercase, thereby suggesting that term is not accepted as a proper name, include this book, this book, and this book. It's actually harder to find books that capitalize it for an ordinary use is a sentence; almost all capitalized uses are in paper titles, headings, and acronym definition. Similarly there's no shortage of scholarly articles like this one, this one, and more, among those with lowercase usage and free PDFs online. The real proper name is CAN; there is no evidence that I can find that what CAN stands for is also a proper name. There is plenty of precedent in reliable sources to treat "controller area network" like "local area network" and "wide area network": things one makes acronyms of, but not proper nouns. Dicklyon (talk) 21:45, 1 January 2012 (UTC)

  • See my below response to Ruud. Greg L (talk) 23:35, 1 January 2012 (UTC)

• Question Is this a generic class of networks (as local area network) or a specific type of bus (as Universal Serial Bus)? The lead is a bit ambiguous on this. —Ruud 23:11, 1 January 2012 (UTC)
  • Specific type. It is a particular standard for a particular microcontroller bus. My best friend is an über expert in this stuff and has done it since the dawn of the digital controller age (back before the 8051). The term refers to *a particular one* and is always properly uppercase because the term refers to a particular bus invented by Bosch—just like Intel’s invention of Universal Serial Bus (USB), which is a particular one. If you take a class or seminar on CAN, like here from Embedded Systems Academy, it is A full-day hands-on training class about the Controller Area Network (also known as CAN bus or CANbus). Now…

    The job of any good encyclopedia is to educate its readership on a particular subject and properly prepare them for their continuing studies elsewhere. We do no reader a favor by mangling the spelling from the way all industry insiders and experts always spell the term.

    I note that this article originally used the correct spelling and an RM attended by just two individuals changed it. Wrong; the article had been correct from when it was first created in 2003 (by editors who understand this stuff) through 2009 when those two editors at the RM patted each other on the back and said “Good show—by all means.”

    What we’ve got here now is editors who are active in how the English language should properly do this or that but who have next-to-zero experience in this particular discipline. And, like always, everyone who has an opinion has a voice on Wikipedia. That observation may offend, but Wikipedia does have a policy called Competence is required. In short, this RM is properly settled not by nose count, but by the strength and weight of the arguments. Just because someone desires that something be different in the world, does not make it incumbent that Wikipedia allow itself to be exploited as a vehicle to change reality to what some think is better. Greg L (talk) 23:35, 1 January 2012 (UTC)

    I would be the first to agree to capitalization if the sources all did that. As I pointed about above the defining standard does not, and I linked several books and papers that do not, from among the ones visible on the web; I can link more. And for the record, I am not incompetent; I have worked on systems that send proprietary data around cars on CAN bus; but we never referred to it as Controller Area Network, which is the origin of the CAN name, but essentially generic in itself. Even the course link that Greg gives uses the term only once, in introducing the acronym. A few sources actually introduce the acronym with lowercase controller area network, suggesting that they specifically wanted to avoid giving the impression that Controller Area Network is the name. As for the first RM above, it was fix a bizarre mis-punctuation; the change to lowercase was done back in 2008. Dicklyon (talk) 23:57, 1 January 2012 (UTC)

    • Bosch’s specification for CAN 2.0 is here. Usually, the document writes of “CAN.” But “Controller Area Network” is written three times. This is by Bosch now, and all three times it is all uppercase. This is exactly like Intel’s Universal Serial Bus. Notwithstanding that even RSs like Microsoft, here sometimes goof and spell it universal serial bus doesn’t mean that we should latch onto that as an excuse because it is properly “Universal Serial Bus” and even Microsoft can get it right on occasion. Greg L (talk) 00:09, 2 January 2012 (UTC)

• lowercase I'm in the industry. I stopped capitalising it when I realised I was copying the name from official specs and having to add the capitalisation myself. The reason "anyone in the industry" capitalises it is only because no-one ever calls it "controller area network", it's always called CANbus (and variants) with the acronym form. Andy Dingley (talk) 00:11, 2 January 2012 (UTC)
  • It’s not as you write. Embedded Systems Academy writes (and this is the whole and reliable truth): A full-day hands-on training class about the Controller Area Network (also known as CAN bus or CANbus). And Bosch’s specification for CAN 2.0 is here. Greg L (talk) 00:20, 2 January 2012 (UTC)
    • First one's a training house, who endemically over-capitalise because it makes things sound More Important. Second one is German, and German sources also have an inherent tendency to capitalise nouns, particularly compound nouns. You'll note from Bosch though that for every full version of the name, there's a dozen where it's CAN. Could one imagine IBM ever doing the same thing? Andy Dingley (talk) 00:40, 2 January 2012 (UTC)

    Sorry if my statement "uses the term only once, in introducing the acronym" was slightly misleading as to the form; but I'll stick to it for the principle of why they capitalized. Ah, but you weren't talking to me; sorry. Dicklyon (talk) 00:25, 2 January 2012 (UTC)

  • Shouldn't we move this to CANbus in that case? That would avoid both the ambiguity of this being a specific kind of bus/network and the, as usually little more than time-wasting, spelling debate. —Ruud 00:22, 2 January 2012 (UTC)

    I think that would be a good idea; or CAN bus, whichever is more common or more standard. N-grams suggest CAN bus. – Dicklyon (talk) 00:25, 2 January 2012 (UTC)

    • That’s fine with me. Whatever we do, we should make sure we take the time to look at how the insiders in this industry truly and most authoritatively handle it. If there are multiple ways, it wouldn’t hurt to be up front and say Controller Area Network, also known as CAN bus or CANbus. We don’t have to have perfect consistency and crystal clear, zero-ambiguity even within this discipline if none truly exists. I just have no patience for wikipedians who seek cross-project consistency and try to push Good Ideas©™®, like how our “Gravimetry” article ought to say The gravity gradient (variation with height) above Earth’s surface is about 3.1×10⁻⁶ s^–2 because reciprocal seconds squared has SI purity and achieves consistency across the project (and we are a publishing house and can have our own house manual of style, yadda yadda). This violation of Technical Writing 101 is amazing to me because the entire discipline of gravimetry—from NASA and their satellite measurements to boots on the ground with spring-based gravimeters—always write it The gravity gradient (variation with height) above Earth’s surface is about 3.1 µGal per centimeter. We always do our readers a service by using the vernacular truly used in the field without prejudice against the true facts. Greg L (talk) 00:40, 2 January 2012 (UTC)

      True, such cases need to include alternative forms in parens. Not being into gravimetry, I didn't know what a Gal (unit) was, but the pure SI units would also probably confuse me. Not that I'm arguing for (ft/sec/sec)/ft, but some us grew up on that, too. Hey, that would also be 3.1E-06. Dicklyon (talk) 01:13, 2 January 2012 (UTC)

      Oppose. But I don't mind a move to CANbus or CAN bus; in that case, if/when expanded in the article text, it should be lower-cased. Tony (talk) 01:31, 2 January 2012 (UTC)

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Requested move 3

Why was this closed during so much active discussion?--Asher196 (talk) 23:27, 2 January 2012 (UTC)

Would you like me to revert the close and reopen? --Mike Cline (talk) 23:33, 2 January 2012 (UTC)

We seem to have converged nearly on CAN bus. Either move it that, reopen it to see if we agree, or make a new one for that. Dicklyon (talk) 23:37, 2 January 2012 (UTC)

The cleanest thing will be for someone to open an RM to CAN bus. This allows everyone to weigh-in on that title specifically. --Mike Cline (talk) 00:00, 3 January 2012 (UTC)

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the move request was: page moved. Vegaswikian (talk) 06:24, 10 January 2012 (UTC)

---

Controller area network → CAN bus –

Seems like the best option on the basis of the discussion above. Tony (talk) 00:40, 3 January 2012 (UTC)

• Yes – Dicklyon (talk) 16:13, 6 January 2012 (UTC)
• Support. Doen't solve the capitalization question, but solves the title question. – Pnm (talk) 19:44, 6 January 2012 (UTC)

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

SG?

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)

Why extended data frame?

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)

Requested move 4

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: not moved. Jenks24 (talk) 13:08, 11 July 2014 (UTC)

---

CAN bus → Controller Area Network – Most commonly known as CAN or Controller Area Network and secondarily as CAN bus, CAN Bus or CANbus. CAN is normally expanded in technical documents and WP:NCA discourages acronyms in titles in these cases. As per WP:NOUN we capitalize the title if the subject is is a proper noun. Previous lengthy discussion about how the subject is or is not capitalized in sources is not directly relevant. If you don't like the caps, please provide justification for CAN as a common noun. Relisted. Jenks24 (talk) 13:12, 3 July 2014 (UTC) ~KvnG 18:31, 25 June 2014 (UTC)

• Support (in principle, no worries about caps) - generally we avoid acronyms unless the acronym is actually better known than the spelled-out form (USB, DVD) Red Slash 23:43, 25 June 2014 (UTC)
• Oppose over-capitalization – Per book sources, lowercase is common, and caps are not necessary, therefore per MOS:CAPS, it should be Controller area network if we don't like the acronym. Please review previous move requests. Dicklyon (talk) 00:02, 26 June 2014 (UTC)

  I think WP:NOUN not MOS:CAPS is what's directly applicable here. Examples of how capitalization is handled for similar topics can be found here: All pages with titles containing protocol ~KvnG 14:19, 26 June 2014 (UTC)

  WP:NOUN supports MOS:CAPS by saying "Use lowercase, except for proper names." "Controller area network" is not a proper name, though the name of the protocol, CAN, may be. Dicklyon (talk) 23:49, 26 June 2014 (UTC)

  I gather you are thinking controller area network is akin to local area network. My argument is that Controller Area Network is a specific and singular network technology akin to Fiber Distributed Data Interface. ~KvnG 14:35, 27 June 2014 (UTC)

  Independent of how specific it is, the official protocol name seems to be CAN bus, and many sources, and especially better edited sources like books, interpret "controller area network" as generic, and set it in lower case. That's usually all the evidence we need to conclude that caps are not "necessary" per MOS:CAPS. Dicklyon (talk) 15:24, 27 June 2014 (UTC)

  So because the name is CAN bus, we should call it controller area network? Typical wikipedia. Andy Dingley (talk) 16:27, 27 June 2014 (UTC)

  No, but if you want to call it that, at least don't over-capitalize; stick with MOS:CAPS. Leaving it at CAN bus is a fine alternative; I was just saying where it would go "if we don't like the acronym". Dicklyon (talk) 16:48, 27 June 2014 (UTC)

  @Dicklyon: If the technology is most commonly referred to as CAN bus, then I'm happy to have this move proposal rejected. I've reviewed the references and external links cited in the article and find that 11 refer to it as Controller Area Network (CAN), 2 refer to it as CAN Bus and 2 acknowledge that both terms are used. ~KvnG 20:32, 27 June 2014 (UTC)

  @Sbmeirow: directly above here is my evidence that Controller Area Network (CAN) is the WP:COMMONNAME. ~KvnG 14:10, 8 July 2014 (UTC)

• Oppose - because need more discussion and analysis of other "bus" article naming methods before a vote, instead of playing "article name" Ping-Pong. See the template below. • Sbmeirow • Talk • 09:02, 26 June 2014 (UTC)

  Naming used by other articles has little bearing. What's of primary concern here is what is the name the technology is most commonly known by in the references. If it is CAN or Controller Area Network, the article should be "Controller Areas Network". If it is CAN bus, CAN Bus or CANbus, then the existing title ("CAN bus") is good. (This is not to be confused with the capitalization use in the references. Capitalization is a WP:MOS issue not a naming issue and does not necessarily follow the references.) ~KvnG 14:19, 26 June 2014 (UTC)

  uhhhhh, naming of other articles certaining does have bearing, otherwise there wouldn't be numerous guidelines on Wikipedia about the topic. I've seen numerous variations for "CAN" in magazine articles, datasheets, online articles, blogs. No matter what you pick, someone will whine about it not being their preferred way of naming it. This mess revolves around the original group not choosing a better name that didn't have an acronym that is identical as another common word. I'm not 100% opposed to renaming the article, but I am opposed to renaming it every couple of years. That why I'd rather have a longer discussion about the pro's and con's of each name, then try to flush out which one is best. Once we are done, then we could vote on it, and archive the entire discussion for future reference when someone wants to rename it again. • Sbmeirow • Talk • 23:59, 26 June 2014 (UTC)

  That sounds reasonable but it doesn't appear anyone took the initiative to start that discussion. I read through the previous discussion before opening this RM and I decided to take a different approach and I encourage you to not get caught up in the means and support the move if you believe it is an improvement to the existing title. ~KvnG 14:35, 27 June 2014 (UTC)

• CAN bus - COMMONNAME. Controller area network would be particularly inappropriate. Andy Dingley (talk) 00:15, 27 June 2014 (UTC)

  @Andy Dingley: can you provide evidence that CAN bus is the WP:COMMONNAME. The links from the article indicate that Controller Area Network (CAN) is more common (see my response to Dicklyon above). ~KvnG 17:12, 7 July 2014 (UTC)

  Can you provide evidence that it's not? • Sbmeirow • Talk • 21:49, 7 July 2014 (UTC)

  Here is some pretty good evidence for the predominance of CAN bus being most common. Dicklyon (talk) 03:51, 8 July 2014 (UTC)

  @Dicklyon: that's interesting but in the references I examined, the first incidence is spelled out ("Controller Area Network (CAN)") and the references following use the acronym ("CAN"). The articles that use "CAN bus" use it repeatedly. If you look up "CAN" in the Ngram viewer you find that it is a giant because it is also used for other purposes. The Ngram viewer just counts total instances and is not intelligent enough to give accurate results given the way "Controller Area Network" and "CAN" is used in the references I've examined. ~KvnG 14:10, 8 July 2014 (UTC)

  Certainly you wouldn't want to use n-grams to look at just CAN. But it does show that "CAN bus" is much more common than "Controller Area Network", and also that the lower-case form is not uncommon. I agree with you that "Controller Area Network (CAN)" is very common, since people typically capitalize when forming acronyms. That and the common appearance in titles and headings and tables explain much of the caps usage. The rest is by people who think of it as a proper name or prefer to capitalize it for emphasis, but that doesn't make a case that we should do the same, in light of MOS:CAPS. Dicklyon (talk) 03:21, 9 July 2014 (UTC)

  I think you may have missed my point. Sources that use "CAN bus" use that phrase for all instances. Sources that use "Controller Area Network" use that once and then use "CAN" for further instances. My point is that n-gram viewer blindly counts instances and is not necessarily going to give an accurate comparison in this case. ~KvnG 13:45, 9 July 2014 (UTC)

---

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Links to other Languages absent (Wikidata) - Please help

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)

ISO 11898-2:2016

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)

Definition as 'Vehicle bus' seems overly specific

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)

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)

Add section describing Single Wire CAN Physcal Layer (SAE J2411)

The SAE J2411 specification (no mention in Wikipedia, at the time of writing), specifies a Single Wire (plus ground) physical layer for the CAN bus.

Single Wire CAN bus driver ICs and devices are already widespread in use.

References

• SAE J2411 reference
• Single Wire CAN Network for Vehicle Applications – SAE J2411 – Standard

the diagram titled Low-Speed Fault-Tolerant CAN Network. ISO 11898-3

It looks like the nodes are connected randomly, sometimes h to l and sometimes h to h.

How many control units can it support?

"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)

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)

Incomprehensible

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)

Applications

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)

CAN Bus can not process data

"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)

Clarification

@Constant314: 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)

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)

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)

Distinguish messages from frames

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)

Describe DBC files, simple databases for defining message formats, purposes, contents etc.

CAN DBC files seem to be important for working with CAN bus messages. ★NealMcB★ (talk) 18:19, 30 December 2023 (UTC)

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)

New lead

I wrote a new lead section, summarizing what I think are the key points about CAN. Left in the old lead, it contains more dense information.  Burt Harris (talk) 23:14, 2 November 2024 (UTC)