This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

  • Resolved

ISO1050: iso1050 dub not working

Part Number: ISO1050

I created a design using the iso1050 dub can transciever.  I designed exactly as shown in the datasheet.  I can't get any meaningful signal out of it.  Occasionally I'll get a few square waves but most of the signal is noise.  It's not a board design problem because I (through great effort) replaced the iso1050 with an SN65HV transciever and everything worked fine.  Any help would be appreciated.

  • In reply to Dan Kisling:

    Hello Dan,

    Thanks for taking the time to help me figure this out.

    Okay, I've taken some scope shots with a 10kHz 50% duty cycle signal applied to TX.  I only have a 2 channel scope at the moment but can obtain a 4 channel if necessary.

    This is a shot of the PWM signal applied to TX.

    Here is TX and CANH

    And here is TX and CANL

  • In reply to TODD COLLINS:

    Hi Todd,
    These scope shots look good. From these shots of TX and CANH and CANL it looks like there isn't an issue with the hardware. Could it possibly be an issue with the software? I know that this works with a non-isolated transceiver - which points to this being an issue with the hardware, but I think there's a chance the small differences between the non-isolated CAN transceiver and the ISO1050 may require slight changes in the software - such as sampling points.
    Best regards,
    Dan
  • In reply to Dan Kisling:

    Hi Dan,

    I've tried a number of different sampling points, but to no avail.  Wouldn't sampling points cause issues with receiving messages exclusively?  All I'm trying to do is send data on the CAN bus.

  • In reply to TODD COLLINS:

    Hi Todd,

    Yes, sampling points should really only affect how the micro controller receives the messages from the transceiver. That is, unless you're CAN analyzer tool is expecting a certain response.

    To recap we've verified:

    • Decoupling capacitors are sufficient 
    • Device is connected correctly
    • Vcc1 / Vcc2 is within recommended operating conditions (reported 4.9V at pin)
    • TX to CANH / CANL looks healthy with 50% duty cycle clock signal

    The only thing I can think of to still check on the ISO1050 is to verify that RX is healthy. Could you capture scope shots similar to the experiment you did to verify TX to CANH / CANL is healthy for RX? You could do either CANH / CANL and RX or TX and RX (I know you only have two scope probes available with this particular scope). 

    If this attempt does not work perhaps we could set up a quick call to discuss this issue. I've sent you an E2E friend request so we can exchange contact information in private messages (rather than posting them on the public forum). 

    Best regards, 

    Dan

  • In reply to Dan Kisling:

    Hi Todd,
    I haven't heard from you in a few days. Would you like to set up a call to debug this issue? Or have you been able to solve the issue?
    Best regards,
    Dan
  • In reply to Dan Kisling:

    Hi Todd, 

    I'm going to close this thread for now. Please feel free to open a new thread if this issue is still not resolved. 

    Best regards, 

    Dan

  • In reply to Dan Kisling:

    Setting up a call would be a good idea.  I've been able to obtain a four channel scope.  I took some screen shots this morning.

    ISO1050 @ 100kpbs (don't know why image is inverted).

    SN65HVD251 @ 100kbps

    Sorry about the inverted images.  They imported that way.  I even inverted my source and it still imported upside down here.

    After looking at all four channels and comparing a good signal to bad, it looks to me like my TX and RX signals are being distorted by the ISO1050.  What do you think?

  • In reply to TODD COLLINS:

    This debug effort is now being handled over email / phone.
    Best regards,
    Dan
  • In reply to Dan Kisling:

    Follow up:
    Todd and I debugged the issue over email / phone calls. The issue was due to RX being set as an output instead of an input on the MCU. Once this was fixed the ISO1050 performed fine in this application.
    Best regards,
    Dan

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.