Post History
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...
Answer
#2: Post edited
by
Lundin
·
2023-12-15T17:41:44Z (11 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
Lundin
·
2023-12-12T20:00:28Z (11 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.