Hi to all.
I'm looking for a simple solutions like the one of this thread https://forum.allaboutcircuits.com/threads/2-led-logic-probe-for-can-bus.119597/
I just want to know if at the moment this is the best solutions or is there any better.

As the TS of the mentioned post I only need to know if Can Bus is present or not.

 

Seems to me a CAN transceiver with the Tx input tied high to output a recessive level would make an ideal bus monitor. The Rx pin could trigger a oneshot to provide an LED indicator. This would not be too helpful on a bus that was idle most of the time.

 

I'm workin' on it,
this is something that I'd like to have myself.
.
.
.

 

Seems to me a CAN transceiver with the Tx input tied high to output a recessive level would make an ideal bus monitor. The Rx pin could trigger a oneshot to provide an LED indicator. This would not be too helpful on a bus that was idle most of the time.

So, your idea will be more easy than the one on the mentioned post?

 

Seems to me a CAN transceiver with the Tx input tied high to output a recessive level would make an ideal bus monitor. The Rx pin could trigger a oneshot to provide an LED indicator. This would not be too helpful on a bus that was idle most of the time.

That is exactly what I’d use (in fact I built it into a product). It depends what you mean by “idle most of the time”. The CAN System I have built send data once a second, and it is perfect for that.
It is useful because it will indicate if the transmitter is continuously retransmitting because it is not receiving acknowledge pulses.
It is also handy to have an LED directly controlled by RXD as it shows if the bus is jammed in the “dominant” state (although it might be misleading in a bus that was in almost constant use)

 

@Ian0
So, do you advise me to build this test probe in mentioned post? If you maked any changes in the schematic can you please share with us?

 

What do You Guys think about this idea ?
.
.
.

.

 

What do You Guys think about this idea ?
.
.
.
View attachment 290846
.

I’d use something like that. It would free up the ‘scope for other jobs.
By the way, I think the comparators in the lower half are the wrong way round.

 

Further to post #5, my RXD LED was gated with the output of the monostable, so that it indicated a fault if RXD was still dominant after the edge-triggered monostable had timed out.

 

I
This is a real CAN waveform, twisted pair cable about 2 feet long, terminated both ends, from a Microchip MCP2551 transceiver.
Anyone hoping for 0.5V to 4.5V levels is going to be disappointed.
(By the way, you don't need to remind me how hopeless my scope's real-time clock is - it gained over a year whilst the company was shut for Covid lockdown)

 

in fact I built it into a product

Can you share with us the schematic.

 

What do You Guys think about this idea ?
.
.
.
View attachment 290846
.

I like your idea, but isn’t a 100 Meg resistor way too high?
Use a 1 Meg and scale up the cap to achieve the same time constant.

 

I originally had in mind small Battery Power,
but then later, decided on a Cigarette-Lighter-Plug for Power.
.
.
.

 

I originally had in mind small Battery Power,
but then later, decided on a Cigarette-Lighter-Plug for Power.
.
.
.

do tyo have any simulator program to try the schematic?

 

The Circuit I provided is nothing more than a stack of "Window-Comparitors".
The only unique things about it are the Voltage-Divider-Stack, ( Diodes replacing Resistors ),
and a simple Pulse-Extending R-C Filter for each LED-Output,
which is supposed to make the super-short-pulses easier to see.

Any "simulation" would require using it on several different actual Cars,
( or other CAN-Buss applications ),
and under varying conditions,
to see if any small adjustments/improvements would improve i's usefulness.

It will NOT tell You anything about the Data being transferred,
only Signal-Strength and Balance,
and it will NOT indicate any problems related to the SWR ( Standing-Wave-Ratio ), of the Signal.

I's a simple "Go/No-Go" indicator of Signal-Strength,
that simply shows that the system "should-be", or definitely is not, working.
.
.
.

 

I already know it's not telling me what data is going in to the CAN-Buss. Bat, it will tell me if the can is working, correct?
When you will be reasonable sure, I can build the probe. I have many kind of car where I can test It. Even on bmw car with DCAN.

 

It is only an extremely fast Volt-Meter.
I don't know the Voltage-Specifications of "D-CAN".
.
.
.

 

It's very difficult to tell whether it is working correctly unless you receive and decode the messages.
The usual fault is a damaged transceiver at one node, and that tends to jam the bus in one state. Very easy to spot with a scope.

 

I already know it's not telling me what data is going in to the CAN-Buss. Bat, it will tell me if the can is working, correct?
When you will be reasonable sure, I can build the probe. I have many kind of car where I can test It. Even on bmw car with DCAN.

No this is not necessarily the case. Consider the case of a network with one lonely node. It sets up a frame for transmission, it does not receive a dominant bit in the ACK slot and the lonely node will retry the frame forever without any actual work going on.

Then consider the case where one node tries to transmit at the wrong bitrate. Every other node will throw error frames until the faulty node goes bus-off. The network may not recover if the busoff node is the one managing the traffic and responsible for most of the produced messages.

Then consider the case where two producers try to use the same identifier.

 

No this is not necessarily the case. Consider the case of a network with one lonely node. It sets up a frame for transmission, it does not receive a dominant bit in the ACK slot and the lonely node will retry the frame forever without any actual work going on.

That is also the behaviour of two-node network where the MCU on the receiving node has crashed. (The CAN module in the processor generates the acknowledge pulse not the CAN transceiver.)