Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Post History

60%
+1 −0
Q&A CAN BUS monitoring with a LED

I've done similar things on UART lines, but for significantly lower baudrates (9600 etc) than traditionally used on most CAN buses. It's also easier to do when you have 5V guaranteed to be well-ov...

posted 5mo ago by Lundin‭  ·  edited 5mo ago by Lundin‭

Answer
#2: Post edited by user avatar Lundin‭ · 2023-12-15T17:41:44Z (5 months ago)
  • I've done similar things on UART lines, but for significantly lower baudrates (9600 etc) than traditionally used on most CAN buses.
  • It's also easier to do when you have 5V guaranteed to well-over the LED V<sub>fwd</sub>, which the CAN lines do not necessarily live up to. For instance there are 3.3V supplied CAN transceivers designed to be within spec and yet just deliver +3.3V rather than the 2.5+1=3.5V on CANH. Also, if someone messes up the installation and mixes CANH and CANL, you may end up with a situation where one line dips and the other goes higher than expected.
  • At most baudrates and payloads, a CAN frame is too fast to cause anything but flickering at best. Notably the human eye is unlikely to tell the difference between flicker caused by repeated error frames or valid packages, so there is a chance that the LED will not even tell you if the communication is working or broken. You'd be creating some manner of crude bus load indicator. Not very useful or reliable - so I'm sensing an "XY question" - what is your actual goal with this?
  • As mentioned in other answers, a MCU pin flipping a LED or a one-shot timer IC (monostable multivibrator) would be better solutions, the MCU pin one being the cheapest and most flexible - it could PWM drive the LED for example if current comsumption matters.
  • I've done similar things on UART lines, but for significantly lower baudrates (9600 etc) than traditionally used on most CAN buses.
  • It's also easier to do when you have 5V guaranteed to be well-over the LED V<sub>fwd</sub>, which the CAN lines do not necessarily live up to. For instance there are 3.3V supplied CAN transceivers designed to be within spec and yet just deliver +3.3V rather than the 2.5+1=3.5V on CANH. Also, if someone messes up the installation and mixes CANH and CANL, you may end up with a situation where one line dips and the other goes higher than expected.
  • At most baudrates and payloads, a CAN frame is too fast to cause anything but flickering at best. Notably the human eye is unlikely to tell the difference between flicker caused by repeated error frames or valid packages, so there is a chance that the LED will not even tell you if the communication is working or broken. You'd be creating some manner of crude bus load indicator. Not very useful or reliable - so I'm sensing an "XY question" - what is your actual goal with this?
  • As mentioned in other answers, a MCU pin flipping a LED or a one-shot timer IC (monostable multivibrator) would be better solutions, the MCU pin one being the cheapest and most flexible - it could PWM drive the LED for example if current comsumption matters.
#1: Initial revision by user avatar Lundin‭ · 2023-12-12T20:00:28Z (5 months ago)
I've done similar things on UART lines, but for significantly lower baudrates (9600 etc) than traditionally used on most CAN buses. 

It's also easier to do when you have 5V guaranteed to well-over the LED V<sub>fwd</sub>, which the CAN lines do not necessarily live up to. For instance there are 3.3V supplied CAN transceivers designed to be within spec and yet just deliver +3.3V rather than the 2.5+1=3.5V on CANH. Also, if someone messes up the installation and mixes CANH and CANL, you may end up with a situation where one line dips and the other goes higher than expected.

At most baudrates and payloads, a CAN frame is too fast to cause anything but flickering at best. Notably the human eye is unlikely to tell the difference between flicker caused by repeated error frames or valid packages, so there is a chance that the LED will not even tell you if the communication is working or broken. You'd be creating some manner of crude bus load indicator. Not very useful or reliable - so I'm sensing an "XY question" - what is your actual goal with this?

As mentioned in other answers, a MCU pin flipping a LED or a one-shot timer IC (monostable multivibrator) would be better solutions, the MCU pin one being the cheapest and most flexible - it could PWM drive the LED for example if current comsumption matters.