• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 41 subscribers
  • Views 294 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

TIDA-010035: HVD1786

TIDA-010035: disturbed signals A and B on sn65hvd1786

Peter Herijgers
Prodigy 10 points
Part Number: TIDA-010035
Other Parts Discussed in Thread: SN65HVD1786, THVD8000

Hi All,

I have created a project based on this:

The device on the left in the transmitter, the right one is the receiver.
On the left device: DE and REZ are connected to +5V and R is left open, on the right device DE and REZ are connected to ground and D is left open.
Supplied power to the left coil is 12V. The rest of the schematic is the same.
When nothing is connected at the right coil, the signals on A and B are:

Red is signal A, signal B is green. The right device gets power from a separate power supply.

First question: is it possible to reduce the spikes in both signals?

But when at the right coil a LM7805 is connected which will supply power to the right device, the signals become:


The blue signal is the data received and is correct, but signals A and B are very disturbed.
Is it possible to maintain a steady signal on A and B?
The cable length is 1 meter.

I hope someone can help me.
Thanks is advance.

  • 0
    TI__Prodigy 600 points

    Hello, we are looking into your questions above.  It appears that B2 is not connected and there is a wire connected to B_bus that is connected elsewhere and just cut off in the screenshot or its just a floating wire.  Is this a TINA simulation?  If so, could you send over the TINA file?

  • 0
    Prodigy 10 points

    Hi, you are right. The schematic was copied from one of your documents: tiduei9.pdf (TIDA-010035) page 12, but in my project line B2 is connected to the device.
    Should B2 be left open? This is not a TINA simulation but a real one.

  • 0 in reply to Peter Herijgers
    Prodigy 10 points

    I have included my schematic,

    0V and +5V0 on the left are not connected to the 0V and +5V0 on the right.
    0V on the left sn65hvd1786 is not connected to the 0V coil.
    I hope someone can help me.

  • 0 in reply to Peter Herijgers
    TI__Mastermind 46427 points

    Hi Peter,

    I am an RS-485 applications engineer here at TI and I am here to help look into this problem a bit deeper for you. 

    First I will say that those spikes are most likely from the LC coupling/decoupling network and in general they do look like its common to both bus signals. Since this device is only looking at the differential signal these spikes should be, and it looks like they are, filtered out at the transceiver output. Also one thing to note is that the reference design doesn't use common mode chokes for the inductive coupling - they use differential mode inductors so that could also be negatively impacting your signals - because the reference design doesn't use chokes. 

    However I understand why you still may want to reduce these - essentially I see 4 possible modifications that can be done to this system that may help reduce those spikes. 

    1. A common mode choke can be applied to help cut down on common mode noise on the line. 

    2. Split terminations - instead of the 120 ohm terminations - convert those into split terminations:

    Please note this does say "CAN" but the split termination is the same in this case. Usually we see Csplit around ~470pF for many applications. 

    3. While I personally don't love to use them because they can create non-ideal loadings for the driver - since this is a relatively short bus you can place 50pF to 100pF capacitors to ground on the A/B lines in-between the series 47uF capacitors and the IC that can help reduce common mode signals on the bus. 

    4. Adding a capacitor in parallel with the termination may help clean up the signal a bit - but it can also reduce the data signal. 

    You wouldn't need to implement all four most likely - and 1 and 2 are definitely preferred  as they have the least negative impact on the desired goal. 

    With all that being said however - we generally don't promote this device/reference for power line communication anymore - I'd like to introduce the THVD8000 - it combines an RS-485 transceiver with an OOK modulator/demodulator to work in power line communication and you can use much smaller Inductors and capacitors (which also may help with how large the signals are).  

    So in conclusion:

    1. The design should be using differential inductance  - not a common mode choke for the inductive coupling. You could be seeing strange results due to that.

    2. You can apply the techniques that I introduced to help cut down on higher frequency signals (including those spikes)

    3. You can look at the THVD8000 - as you may be able to get a smaller/easier PLC design - the 8000  is our best RS-485 PLC type part. 

    Please let me know if you have any other questions and I will see what I can do!

    Best,

    Parker Dodson

  • 0
    Prodigy 10 points

    Thank our very much, Parker.
    Your advice was really helpful.

    I replaced the common mode chokes with other inductors and used the split termination method. The signals are quite steady now.
    An extra note to mention: I used two power diodes between the power supply and the inductors which supply power to lines A and B.
    Not doing so will somewhat disform the signals.
    I read the documentation of the THVD8000 and the application notes. Based on that I did some tests with both 56uH and 120uH inductors,
    but cannot see the difference.
    Maybe we will use the THVD8000 at a later stage, because for now we are stuck to a soic-8 footprint.
    Another thing I noticed is that some devices get really hot, like 70 degrees Celsius (158 Fahrenheit). Is that normal? Any idea?

  • 0 in reply to Peter Herijgers
    Prodigy 10 points

    Red signal is A, Blue signal is B. Yellow is output from device.

  • +1 in reply to Peter Herijgers
    TI__Mastermind 46427 points

    Hi Peter,

    I am glad that you have seen some improvement in the system - and I totally understand being stuck to a standard 8-Pin SOIC for package. 

    As for the high temperature rise - this device does have a pretty high thermal impedance - for every 1W we measure a 138C rise in die temperature compared to ambient and 61 C rise per Watt for case temp. 

    This can be plugged in for junction temperature measurements:

    Tj = TA + R_theta_JA * Power --> R_theta_JA = 138C/W for this device in SOIC package

    Tj = TC + R_theta_JC(top) * Power --> R_theta_JC(top) = 61C/W for this device in SOIC package

    Setting those equal to each other and solving for TC (case temperature - which most temperature measurements end up being case measurements -but please let me know if you are doing something different) 

    TC  = TA + (R_theta_JA - R_theta_JC(top)) * Power --> TC = TA + 77C/W * Power for this device in SOIC package

    so from case temperature to ambient is given by TC = TA  + 77C/W * Power (77C/W is 138 - 61 - these are based on the thermal parameters in the datasheet)- obviously in various applications this can change because thermal parameters are pretty strongly linked to system parameters as well as IC parameters - but it is our reference point.

    Based on the voltage signals showing I'd approximate you are using about 1/2W across the RS-485 device which would line up with with pretty large temperature increase. Considering that you are most likely working from ~25C is that would be a 45C degrees and based on the quick approximation for this part TC = TA + 77 * 1/2 --> TC = 25 + 38.5  --> TC = 63.5C - and this is a very rough estimate of the power consumption based on the waveforms shown. Our device will typically, in a standard RS-485 loaded system is spec'd at around 400mW - the coupling network may increase that even more because our power measurements for this device didn't include this type of network - so that's where I am getting about 1/2W as a quick estimate. 

    Ultimately my point is  that based on what I have seen from your application the temperature rise as measured doesn't seem too outlandish of what we we would expect - to get a closer approximation measuring the current directly out of the "A" pin would be the best way if possible because that will get you an accurate measurement of  power (most of the power is from the transmitter sending signals on the RS-485 bus) . If this is a concern adding a heat sink on the IC can help reduce the heat stress on the device.

    Please let me know if you have any other questions!

    Best,

    Parker Dodson

  • 0 in reply to Parker Dodson
    Prodigy 10 points

    Thank you for your reply.
    For now the power supply for the transmitter indicates 58.3 mA and the power supply for injecting the power on the A and B lines: 107 mA. But I will measure the current at the 'A' pin. BTW, the device getting hot is the receiver.

  • 0 in reply to Peter Herijgers
    TI__Mastermind 46427 points

    Hi Peter,

    Thanks for the update - if the receiver end is getting really hot I would check to see if there are current spikes being injected into the device receiver because it should be pretty high input impedance and that is a lot of heat for the receiver to generate as that usually isn't the device mode that gets as hot because the power should be relatively low  - unless other components are getting hot around it contributing to the heat rise.  

    Best,

    Parker Dodson

  • 0 in reply to Parker Dodson
    Prodigy 10 points

    Hi Parker,

    I will check, thank you for all your help.

    Best,
    Peter

  • 0 in reply to Peter Herijgers
    TI__Mastermind 46427 points

    Hi Peter,

    Alright sounds good - if you have any other questions please don't hesitate to reach back out. If for whatever reason this  thread is locked if you have additional questions about this device - you can post in our Interface forum with part # it will come directly back to us - either myself or my other colleague who also covers RS-485 applications. 

    Best,

    Parker Dodson