What is the limiting factor for a CAN bus to exceed 1Mbps bandwidth?What is the maximum bitrate supported in...
How could a planet have most of its water in the atmosphere?
Power LED from 3.3V Power Pin without Resistor
What happened to Ghost?
Stark VS Thanos
When and why did journal article titles become descriptive, rather than creatively allusive?
Is it cheaper to drop cargo than to land it?
Visa for volunteering in England
Transfer over $10k
How to assert on pagereference where the endpoint of pagereference is predefined
Is there a QGIS plugin that reclassify raster symbology based on current extent?
Why is the SNP putting so much emphasis on currency plans?
Entropy as a function of temperature: is temperature well defined?
If an enemy is just below a 10-foot-high ceiling, are they in melee range of a creature on the ground?
How did Arya get back her dagger from Sansa?
CRT Oscilloscope - part of the plot is missing
Game of Life meets Chaos Theory
Why do freehub and cassette have only one position that matches?
Was the ancestor of SCSI, the SASI protocol, nothing more than a draft?
Problems with numbers (result of calculations) alignment using siunitx package inside tabular environment
How to avoid grep command finding commented out strings in the source file?
Floor tile layout process?
Selecting a secure PIN for building access
I caught several of my students plagiarizing. Could it be my fault as a teacher?
Is it appropriate to refer to God as "It"?
What is the limiting factor for a CAN bus to exceed 1Mbps bandwidth?
What is the maximum bitrate supported in the Can Bus?CAN bus bit timing with 16 MHz crystalSending CAN protocol data(1Mbps) via serial portCAN bus troubleshooting. How?Kvaser Leaf Light CAN BUS Simulator problemsCAN bus TVS diode/EMI for motorcycleCAN Bus Debug MCP25625 CAN to SPI to USB (MCP2210)Interoperability between regular and single-wire CAN busHigh speed CAN configurationHow to calculate bus load of CAN bus?CAN bus bit timing STM32F7 (bxCAN)
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
$begingroup$
Why can't CAN baud rate increase beyond 1Mbps
can
New contributor
$endgroup$
add a comment |
$begingroup$
Why can't CAN baud rate increase beyond 1Mbps
can
New contributor
$endgroup$
$begingroup$
Depends on standards and drivers used. There are faster versions but there are other differences,
$endgroup$
– Sunnyskyguy EE75
3 hours ago
$begingroup$
My question is why can't we achieve higher speeds like upto 100Mbps using CAN?
$endgroup$
– Vinay Veeramaneni
3 hours ago
$begingroup$
Ignition and RF Immunity and delay contention on the bus
$endgroup$
– Sunnyskyguy EE75
3 hours ago
$begingroup$
Check: What is the maximum bitrate supported in the Can Bus
$endgroup$
– Huisman
2 hours ago
add a comment |
$begingroup$
Why can't CAN baud rate increase beyond 1Mbps
can
New contributor
$endgroup$
Why can't CAN baud rate increase beyond 1Mbps
can
can
New contributor
New contributor
New contributor
asked 3 hours ago
Vinay VeeramaneniVinay Veeramaneni
162
162
New contributor
New contributor
$begingroup$
Depends on standards and drivers used. There are faster versions but there are other differences,
$endgroup$
– Sunnyskyguy EE75
3 hours ago
$begingroup$
My question is why can't we achieve higher speeds like upto 100Mbps using CAN?
$endgroup$
– Vinay Veeramaneni
3 hours ago
$begingroup$
Ignition and RF Immunity and delay contention on the bus
$endgroup$
– Sunnyskyguy EE75
3 hours ago
$begingroup$
Check: What is the maximum bitrate supported in the Can Bus
$endgroup$
– Huisman
2 hours ago
add a comment |
$begingroup$
Depends on standards and drivers used. There are faster versions but there are other differences,
$endgroup$
– Sunnyskyguy EE75
3 hours ago
$begingroup$
My question is why can't we achieve higher speeds like upto 100Mbps using CAN?
$endgroup$
– Vinay Veeramaneni
3 hours ago
$begingroup$
Ignition and RF Immunity and delay contention on the bus
$endgroup$
– Sunnyskyguy EE75
3 hours ago
$begingroup$
Check: What is the maximum bitrate supported in the Can Bus
$endgroup$
– Huisman
2 hours ago
$begingroup$
Depends on standards and drivers used. There are faster versions but there are other differences,
$endgroup$
– Sunnyskyguy EE75
3 hours ago
$begingroup$
Depends on standards and drivers used. There are faster versions but there are other differences,
$endgroup$
– Sunnyskyguy EE75
3 hours ago
$begingroup$
My question is why can't we achieve higher speeds like upto 100Mbps using CAN?
$endgroup$
– Vinay Veeramaneni
3 hours ago
$begingroup$
My question is why can't we achieve higher speeds like upto 100Mbps using CAN?
$endgroup$
– Vinay Veeramaneni
3 hours ago
$begingroup$
Ignition and RF Immunity and delay contention on the bus
$endgroup$
– Sunnyskyguy EE75
3 hours ago
$begingroup$
Ignition and RF Immunity and delay contention on the bus
$endgroup$
– Sunnyskyguy EE75
3 hours ago
$begingroup$
Check: What is the maximum bitrate supported in the Can Bus
$endgroup$
– Huisman
2 hours ago
$begingroup$
Check: What is the maximum bitrate supported in the Can Bus
$endgroup$
– Huisman
2 hours ago
add a comment |
3 Answers
3
active
oldest
votes
$begingroup$
It can. Meet CAN-FD.
Why was a new protocol needed? CAN is a multi-master bus with arbitration and error reporting. These features limit the data rate based on the cable length, since it takes a certain amount of time for the signal to make a round trip between the two farthest nodes. That, along with backwards compatibility requirements, led to CAN-FD.
Classic CAN at 1 Mbps is limited to a 40-meter bus length. (In practice, I think it's lower due to stray capacitance.) At 100 Mbps, you'd be lucky to have even half a meter of usable bus length, which is not enough for automotive and industrial applications.
$endgroup$
add a comment |
$begingroup$
It's because the CAN 2.0B standard did not specify any higher in order to reduce hardware costs and still meet the various requirements of the standard (like distance and noise immunity). It's not a technical barrier.
The standard was written that way probably since they deemed the extra speed unnecessary for the intended application, and specifying a higher speed needlessly would increase the cost of all the hardware supporting the standard when the capability would be underutilized.
If the standard is written that way, few IC manufacturers will bother trying to exceed it since there's no point. It's not really a technical barrier.
$endgroup$
add a comment |
$begingroup$
From Controller Area Network Physical Layer Requirements
CAN is an open collector technology – the protocol could not work otherwise. This means that the recessive state of a CAN transceiver is not actively driven. The termination resistors together with transceiver input capacitance and cable capacitance create an RC time-constant discharge when an actively-driven dominant bit on the bus transitions to an un-driven recessive bit. For signaling rates greater than CAN's 1Mbps, a technology that actively drives the bus in both states such as RS-485 is required to facilitate the bus transitions required for high-speed signaling rates.
Ultimately, the answer to the question is how the CAN protocol is implemented at a physical level. Change that protocol and a higher data rate can be used.
From Understanding Microchip’s CAN Module Bit Timing
... the CAN protocol implements a non-destructive bitwise arbitration scheme that allows multiple nodes to arbitrate for control of the bus.
Therefore, it is necessary for all the nodes to detect/ sample the bits within the same bit time. The relationship between propagation delay and oscillator tolerance effect both the CAN data rate and the bus length.
Two masters on either end of the CAN bus must be able to communicate and arbitrate which one has the bus, while each are on the bus at the same time.
If the bus length is 30m, the time it takes to propagate the signal over the bus is: $$t_{BUS} = 30m @ 5.5 ns/m = 165ns$$
Assuming the input comparator delay is $t_{CMP}$ = 40ns and the output driver delay is $t_{DRV}$ = 60ns for all devices.
The round trip time for a bit on the physical bus will be:
$$t_{PROP} = 2(t_{BUS} + t_{CMP} + t_{DRV}) = 2 (165ns + 40ns + 60ns) = 530ns$$
$$TQ = 530ns/6 = 88.33ns $$
$$t_{BIT} = 10times TQ = 883.3ns $$
$$ f = 1/t_{BIT} = 1 / 883.3ns = 1.13MHz $$
The maximum rate is governed by bus length, line capacitance, connected nodes and the drivers selected by the protocol. In principle at 30m, CAN could do 1.13Mz if everything was perfect.
Longer the bus, the slower the data rate. But a shorter bus would mean a higher rate. CAN bit rate vs Bus length:
Both referenced documents go into this at greater length.
$endgroup$
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
return StackExchange.using("schematics", function () {
StackExchange.schematics.init();
});
}, "cicuitlab");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "135"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Vinay Veeramaneni is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f436117%2fwhat-is-the-limiting-factor-for-a-can-bus-to-exceed-1mbps-bandwidth%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
It can. Meet CAN-FD.
Why was a new protocol needed? CAN is a multi-master bus with arbitration and error reporting. These features limit the data rate based on the cable length, since it takes a certain amount of time for the signal to make a round trip between the two farthest nodes. That, along with backwards compatibility requirements, led to CAN-FD.
Classic CAN at 1 Mbps is limited to a 40-meter bus length. (In practice, I think it's lower due to stray capacitance.) At 100 Mbps, you'd be lucky to have even half a meter of usable bus length, which is not enough for automotive and industrial applications.
$endgroup$
add a comment |
$begingroup$
It can. Meet CAN-FD.
Why was a new protocol needed? CAN is a multi-master bus with arbitration and error reporting. These features limit the data rate based on the cable length, since it takes a certain amount of time for the signal to make a round trip between the two farthest nodes. That, along with backwards compatibility requirements, led to CAN-FD.
Classic CAN at 1 Mbps is limited to a 40-meter bus length. (In practice, I think it's lower due to stray capacitance.) At 100 Mbps, you'd be lucky to have even half a meter of usable bus length, which is not enough for automotive and industrial applications.
$endgroup$
add a comment |
$begingroup$
It can. Meet CAN-FD.
Why was a new protocol needed? CAN is a multi-master bus with arbitration and error reporting. These features limit the data rate based on the cable length, since it takes a certain amount of time for the signal to make a round trip between the two farthest nodes. That, along with backwards compatibility requirements, led to CAN-FD.
Classic CAN at 1 Mbps is limited to a 40-meter bus length. (In practice, I think it's lower due to stray capacitance.) At 100 Mbps, you'd be lucky to have even half a meter of usable bus length, which is not enough for automotive and industrial applications.
$endgroup$
It can. Meet CAN-FD.
Why was a new protocol needed? CAN is a multi-master bus with arbitration and error reporting. These features limit the data rate based on the cable length, since it takes a certain amount of time for the signal to make a round trip between the two farthest nodes. That, along with backwards compatibility requirements, led to CAN-FD.
Classic CAN at 1 Mbps is limited to a 40-meter bus length. (In practice, I think it's lower due to stray capacitance.) At 100 Mbps, you'd be lucky to have even half a meter of usable bus length, which is not enough for automotive and industrial applications.
answered 2 hours ago
Adam HaunAdam Haun
17.1k33377
17.1k33377
add a comment |
add a comment |
$begingroup$
It's because the CAN 2.0B standard did not specify any higher in order to reduce hardware costs and still meet the various requirements of the standard (like distance and noise immunity). It's not a technical barrier.
The standard was written that way probably since they deemed the extra speed unnecessary for the intended application, and specifying a higher speed needlessly would increase the cost of all the hardware supporting the standard when the capability would be underutilized.
If the standard is written that way, few IC manufacturers will bother trying to exceed it since there's no point. It's not really a technical barrier.
$endgroup$
add a comment |
$begingroup$
It's because the CAN 2.0B standard did not specify any higher in order to reduce hardware costs and still meet the various requirements of the standard (like distance and noise immunity). It's not a technical barrier.
The standard was written that way probably since they deemed the extra speed unnecessary for the intended application, and specifying a higher speed needlessly would increase the cost of all the hardware supporting the standard when the capability would be underutilized.
If the standard is written that way, few IC manufacturers will bother trying to exceed it since there's no point. It's not really a technical barrier.
$endgroup$
add a comment |
$begingroup$
It's because the CAN 2.0B standard did not specify any higher in order to reduce hardware costs and still meet the various requirements of the standard (like distance and noise immunity). It's not a technical barrier.
The standard was written that way probably since they deemed the extra speed unnecessary for the intended application, and specifying a higher speed needlessly would increase the cost of all the hardware supporting the standard when the capability would be underutilized.
If the standard is written that way, few IC manufacturers will bother trying to exceed it since there's no point. It's not really a technical barrier.
$endgroup$
It's because the CAN 2.0B standard did not specify any higher in order to reduce hardware costs and still meet the various requirements of the standard (like distance and noise immunity). It's not a technical barrier.
The standard was written that way probably since they deemed the extra speed unnecessary for the intended application, and specifying a higher speed needlessly would increase the cost of all the hardware supporting the standard when the capability would be underutilized.
If the standard is written that way, few IC manufacturers will bother trying to exceed it since there's no point. It's not really a technical barrier.
answered 2 hours ago
ToorToor
2,026215
2,026215
add a comment |
add a comment |
$begingroup$
From Controller Area Network Physical Layer Requirements
CAN is an open collector technology – the protocol could not work otherwise. This means that the recessive state of a CAN transceiver is not actively driven. The termination resistors together with transceiver input capacitance and cable capacitance create an RC time-constant discharge when an actively-driven dominant bit on the bus transitions to an un-driven recessive bit. For signaling rates greater than CAN's 1Mbps, a technology that actively drives the bus in both states such as RS-485 is required to facilitate the bus transitions required for high-speed signaling rates.
Ultimately, the answer to the question is how the CAN protocol is implemented at a physical level. Change that protocol and a higher data rate can be used.
From Understanding Microchip’s CAN Module Bit Timing
... the CAN protocol implements a non-destructive bitwise arbitration scheme that allows multiple nodes to arbitrate for control of the bus.
Therefore, it is necessary for all the nodes to detect/ sample the bits within the same bit time. The relationship between propagation delay and oscillator tolerance effect both the CAN data rate and the bus length.
Two masters on either end of the CAN bus must be able to communicate and arbitrate which one has the bus, while each are on the bus at the same time.
If the bus length is 30m, the time it takes to propagate the signal over the bus is: $$t_{BUS} = 30m @ 5.5 ns/m = 165ns$$
Assuming the input comparator delay is $t_{CMP}$ = 40ns and the output driver delay is $t_{DRV}$ = 60ns for all devices.
The round trip time for a bit on the physical bus will be:
$$t_{PROP} = 2(t_{BUS} + t_{CMP} + t_{DRV}) = 2 (165ns + 40ns + 60ns) = 530ns$$
$$TQ = 530ns/6 = 88.33ns $$
$$t_{BIT} = 10times TQ = 883.3ns $$
$$ f = 1/t_{BIT} = 1 / 883.3ns = 1.13MHz $$
The maximum rate is governed by bus length, line capacitance, connected nodes and the drivers selected by the protocol. In principle at 30m, CAN could do 1.13Mz if everything was perfect.
Longer the bus, the slower the data rate. But a shorter bus would mean a higher rate. CAN bit rate vs Bus length:
Both referenced documents go into this at greater length.
$endgroup$
add a comment |
$begingroup$
From Controller Area Network Physical Layer Requirements
CAN is an open collector technology – the protocol could not work otherwise. This means that the recessive state of a CAN transceiver is not actively driven. The termination resistors together with transceiver input capacitance and cable capacitance create an RC time-constant discharge when an actively-driven dominant bit on the bus transitions to an un-driven recessive bit. For signaling rates greater than CAN's 1Mbps, a technology that actively drives the bus in both states such as RS-485 is required to facilitate the bus transitions required for high-speed signaling rates.
Ultimately, the answer to the question is how the CAN protocol is implemented at a physical level. Change that protocol and a higher data rate can be used.
From Understanding Microchip’s CAN Module Bit Timing
... the CAN protocol implements a non-destructive bitwise arbitration scheme that allows multiple nodes to arbitrate for control of the bus.
Therefore, it is necessary for all the nodes to detect/ sample the bits within the same bit time. The relationship between propagation delay and oscillator tolerance effect both the CAN data rate and the bus length.
Two masters on either end of the CAN bus must be able to communicate and arbitrate which one has the bus, while each are on the bus at the same time.
If the bus length is 30m, the time it takes to propagate the signal over the bus is: $$t_{BUS} = 30m @ 5.5 ns/m = 165ns$$
Assuming the input comparator delay is $t_{CMP}$ = 40ns and the output driver delay is $t_{DRV}$ = 60ns for all devices.
The round trip time for a bit on the physical bus will be:
$$t_{PROP} = 2(t_{BUS} + t_{CMP} + t_{DRV}) = 2 (165ns + 40ns + 60ns) = 530ns$$
$$TQ = 530ns/6 = 88.33ns $$
$$t_{BIT} = 10times TQ = 883.3ns $$
$$ f = 1/t_{BIT} = 1 / 883.3ns = 1.13MHz $$
The maximum rate is governed by bus length, line capacitance, connected nodes and the drivers selected by the protocol. In principle at 30m, CAN could do 1.13Mz if everything was perfect.
Longer the bus, the slower the data rate. But a shorter bus would mean a higher rate. CAN bit rate vs Bus length:
Both referenced documents go into this at greater length.
$endgroup$
add a comment |
$begingroup$
From Controller Area Network Physical Layer Requirements
CAN is an open collector technology – the protocol could not work otherwise. This means that the recessive state of a CAN transceiver is not actively driven. The termination resistors together with transceiver input capacitance and cable capacitance create an RC time-constant discharge when an actively-driven dominant bit on the bus transitions to an un-driven recessive bit. For signaling rates greater than CAN's 1Mbps, a technology that actively drives the bus in both states such as RS-485 is required to facilitate the bus transitions required for high-speed signaling rates.
Ultimately, the answer to the question is how the CAN protocol is implemented at a physical level. Change that protocol and a higher data rate can be used.
From Understanding Microchip’s CAN Module Bit Timing
... the CAN protocol implements a non-destructive bitwise arbitration scheme that allows multiple nodes to arbitrate for control of the bus.
Therefore, it is necessary for all the nodes to detect/ sample the bits within the same bit time. The relationship between propagation delay and oscillator tolerance effect both the CAN data rate and the bus length.
Two masters on either end of the CAN bus must be able to communicate and arbitrate which one has the bus, while each are on the bus at the same time.
If the bus length is 30m, the time it takes to propagate the signal over the bus is: $$t_{BUS} = 30m @ 5.5 ns/m = 165ns$$
Assuming the input comparator delay is $t_{CMP}$ = 40ns and the output driver delay is $t_{DRV}$ = 60ns for all devices.
The round trip time for a bit on the physical bus will be:
$$t_{PROP} = 2(t_{BUS} + t_{CMP} + t_{DRV}) = 2 (165ns + 40ns + 60ns) = 530ns$$
$$TQ = 530ns/6 = 88.33ns $$
$$t_{BIT} = 10times TQ = 883.3ns $$
$$ f = 1/t_{BIT} = 1 / 883.3ns = 1.13MHz $$
The maximum rate is governed by bus length, line capacitance, connected nodes and the drivers selected by the protocol. In principle at 30m, CAN could do 1.13Mz if everything was perfect.
Longer the bus, the slower the data rate. But a shorter bus would mean a higher rate. CAN bit rate vs Bus length:
Both referenced documents go into this at greater length.
$endgroup$
From Controller Area Network Physical Layer Requirements
CAN is an open collector technology – the protocol could not work otherwise. This means that the recessive state of a CAN transceiver is not actively driven. The termination resistors together with transceiver input capacitance and cable capacitance create an RC time-constant discharge when an actively-driven dominant bit on the bus transitions to an un-driven recessive bit. For signaling rates greater than CAN's 1Mbps, a technology that actively drives the bus in both states such as RS-485 is required to facilitate the bus transitions required for high-speed signaling rates.
Ultimately, the answer to the question is how the CAN protocol is implemented at a physical level. Change that protocol and a higher data rate can be used.
From Understanding Microchip’s CAN Module Bit Timing
... the CAN protocol implements a non-destructive bitwise arbitration scheme that allows multiple nodes to arbitrate for control of the bus.
Therefore, it is necessary for all the nodes to detect/ sample the bits within the same bit time. The relationship between propagation delay and oscillator tolerance effect both the CAN data rate and the bus length.
Two masters on either end of the CAN bus must be able to communicate and arbitrate which one has the bus, while each are on the bus at the same time.
If the bus length is 30m, the time it takes to propagate the signal over the bus is: $$t_{BUS} = 30m @ 5.5 ns/m = 165ns$$
Assuming the input comparator delay is $t_{CMP}$ = 40ns and the output driver delay is $t_{DRV}$ = 60ns for all devices.
The round trip time for a bit on the physical bus will be:
$$t_{PROP} = 2(t_{BUS} + t_{CMP} + t_{DRV}) = 2 (165ns + 40ns + 60ns) = 530ns$$
$$TQ = 530ns/6 = 88.33ns $$
$$t_{BIT} = 10times TQ = 883.3ns $$
$$ f = 1/t_{BIT} = 1 / 883.3ns = 1.13MHz $$
The maximum rate is governed by bus length, line capacitance, connected nodes and the drivers selected by the protocol. In principle at 30m, CAN could do 1.13Mz if everything was perfect.
Longer the bus, the slower the data rate. But a shorter bus would mean a higher rate. CAN bit rate vs Bus length:
Both referenced documents go into this at greater length.
answered 1 hour ago
StainlessSteelRatStainlessSteelRat
3,946821
3,946821
add a comment |
add a comment |
Vinay Veeramaneni is a new contributor. Be nice, and check out our Code of Conduct.
Vinay Veeramaneni is a new contributor. Be nice, and check out our Code of Conduct.
Vinay Veeramaneni is a new contributor. Be nice, and check out our Code of Conduct.
Vinay Veeramaneni is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Electrical Engineering Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f436117%2fwhat-is-the-limiting-factor-for-a-can-bus-to-exceed-1mbps-bandwidth%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
$begingroup$
Depends on standards and drivers used. There are faster versions but there are other differences,
$endgroup$
– Sunnyskyguy EE75
3 hours ago
$begingroup$
My question is why can't we achieve higher speeds like upto 100Mbps using CAN?
$endgroup$
– Vinay Veeramaneni
3 hours ago
$begingroup$
Ignition and RF Immunity and delay contention on the bus
$endgroup$
– Sunnyskyguy EE75
3 hours ago
$begingroup$
Check: What is the maximum bitrate supported in the Can Bus
$endgroup$
– Huisman
2 hours ago