What are commonly used bit rates?
The most used industrial CAN protocols are using:
- DeviceNet: 500, 250, 125 kbit/s
- CANopen: 1000, 800, 500, 250, 125, 50, 20, 10 kbit/s
For determining the timing register contents see at: CAN Bit Timing Calculator
Bit rates are programmed by specifying the values of some CAN controller registers, commonly called “bit timing” registers. The time base is typical derived from a quartz oscillator. Although very flexible, not all bit timings are possible. For a successful communication, the nodes at the network should agree on a bit-timing within a certain accuracy. We suggest to use a maximum tolerance of the generated bit frequency of 0.1%. The best would be to use a oscillator frequency of multiples of 8 MHz. (16 or 24 MHz) Using other frequencies is asking for trouble. For a more detailed description application notes from Philips and Bosch are available.
Note that some newer transceivers, like Philips TJA1050, do not support the slower bit rates. Check the data sheet.
One method to solve the problem using the correct bit rate in a network is CAN Auto Baud
The configuration of the CAN bit timing is described e.g. at :
Cyrilla Jane Menon email@example.com: One of the important elements in setting your bus speed is the percentage sample point. I believe J1939 recommends a %sample point in the range of 80-85%. This means with only 8 tqs the percentages you can construct are 75% (6/8) or 87.5% (7/8). If you chose 16 tqs, then you could also construct 81
Ed, asking if :BTR = 0x1C03 for the Fujitsu is correct, because http://www.fme.gsdc.de/pdf/bitmixer-v1-1.exe says: “RSJ too wide or SP too close to edge”.
This should not only be related to Fujitsu. This very popular setting of bit timing registers is also used with Intel's 82527, Infineon Controllers -
the new TwinCAN uses this too, Philips SJA100 and more. 0x1c means you have a relation of 14/2 with 16 samples per bit, sample point a 87.5 %.
These values are used by CANopen and DeviceNet and are proofed.
Sampling point location is a compromise between signal quality and cable length.
You like to know what the difference between Bit Rate and Baud is?
John Dammeyer explains it:
The term baud rate has historical significance when it was used to describe the Baudot code for teletype transmission. Way before computers, teletypes were entirely mechanical and the presence or absence of current in the loop energized a relay.
In order to start the decoding sequence of character transmission a current was applied to the loop for a single bit time: the start bit. This would close a solenoid that would start a motor turning a shaft. After that the successive bits (5) would arrive in time to trigger 5 other solenoids which would cause an ultimate decoding into an uppercase, numeric or control character. After the last data bit a couple more bit times were required for the motor and shaft assembly to return to the home position. These bits were called stop bits.
Hence with the 5 bit baudot code, the total number of transmitted bits was 8. With the advent of better teletypes and computers additional bits were added to support the entire ASCII (7 bits) or EBCDIC (8 bits) codes. Computer UART chips only required one stop bit time to move the data from the receive register to the holding register before they were ready to receive another character.
The defacto standard for the term a BAUD then became commonly known as 1 start bit, 7 data bits with or without parity (but still a place holder) and one stop bit for a total of 10 bits per character. To determine the character rate when someone says the device operates at 9600 baud then means you just divide by 10 and get 960 characters per second. However, someone could be sending 8 data bits, one parity bit and two stop bits in addition to the start bit. I make that 12 bits in total so it's really only 800 characters per second but it's still called 9600 baud.
That's probably why you now see many people using the term baud rate to describe CAN bitrate. (not me). I'd prefer to see the term BAUD remain as the bit rate for single character UART based transmission. Especially since CAN sends packets with IDs and CRCs and bit stuffing so the term BITRATE is more appropriate. IMHO.
Having said all that. Inside the CAN processor the bit is divided into smaller time intervals called Time Quanta (Tq) but the bit rate is the inverse of the time taken to transmit the smallest bit time. The bit timing registers inside the CAN device allow you to set from 8 to 24 Tq per bit. The CAN bit stream is NRZ or Non Return to Zero so there is no embedded clock for the receiver to synchronize on.
This means falling and rising edges are used to synchronize the receiver. But since the internal clocks of other nodes may be operating at slightly different frequencies the CAN processor has the ability to change the number of Tq within a bit using a value called SJW. It allows a +/- Tq adjustment for a single bit to bring the clocks back on time. The CAN processor also allows you to set where within the bit you can sample to test for a high or a low and whether you sample it once or 3 times.
But back to your original question. The bit rate (20 kbps for example = 50uSec) is the time it takes for one bit and all nodes on the bus need to be using this bit rate. However, one CAN node may use 8 Tq while another may use 24 Tq to decode this bit. One may sample at the 75% point (Tq 18) while another may sample at 83% of the bit (Tq 20).
See also wiki:WikiPedia/Baud