THVD8000: High voltage DC design/G.hn compatibility

Hi Alexander,

1. So 48V is generally crossed into "high-voltage" (relative to the THVD8000 - as 48V isn't usually considered high voltage in many other applications) and in general I'd direct you to our using the THVD8000 to communicate over an AC outlet - the title a bit of a misnomer as it really is just high voltage - we tested on HV DC and AC systems with the same design and it worked. I have attached that application note below;

THVD80X0_ACHighVoltage_OR_LowZ.pdf 

With that being said though - this implementation may be overkill. Essentially as long as the series capacitors + shunting diodes can keep the A and B pins between -7V and 12V and any injected current will be shunted mainly through the diode (surge or TVS or whatever device you may end up choosing) and using the same architecture as in the base design should be okay if you can guarantee that the A and B pins will never see beyond the -7V to 12V (for rec. operating conditions - in reality the pins will not take damage between +/- 18V but functionality isn't necessarily guaranteed at that point.  So the general approach may be fine - as our typical max is 36V but that has very little to do with the THVD8000 and I think more just where the part was being aimed at creation.

2.So this is a unique use case that I haven't seen before. However I'd imagine that the bandpass filter inside of the THVD8000 is also reading the OFM signal on top of the OOK signal because while there is a bandpass filter internal to the THVD8000 that sets it passband through FSET resistor - the filter has a pretty low quality factor (i.e. the passband is rather large and not super selective)  - this is through design, as it allows for larger modulation frequency tolerance and supports the additional bandwidth for the spread spectrum clocking, but  not through characterization so we don't have a full set of data on when this point is - but from the simulations we have ran - there is a possibility that energy at around 2MHz to a bit higher are probably also being read by the THVD8000 causing the issues that you are seeing from the THVD8000 side also considering the very low threshold needed to trigger a change of state small amounts of leakage can affect the data - I am not sure why the other communication is stopping however as the frequency band should be different enough avoid issues - but this is just my first pass from what I am seeing is your problem. Also I am not sue if the bus itself is affecting the other signal due to passives - while I am not sure I just haven't seen OFM being used for multiple data signals with this device. 

Can you describe the failures in communication seen - what pins stop communicating or is the data stream just meaningless? Anything like that could possibly point to solutions - but I do think it may be hard to get multiple data streams onto the THVD8000 bus with the current setup due to the internals of the bandpass filter on the THVD8000. Using two AC/Data signals on the same bus with the THVD8000 is possible (the app note above uses a 60Hz power signal with 125KHz data modulation on the same bus) but the big thing is that they have to be separated enough in frequency to where the THVD8000 isn't picking up the non-OOK signal - based on the simulations I have seen I'd suggest a minimum of +/- 1 decade from 500K (so 50K to 5M) to hopefully avoid most of the problem - the +/-1 decade is a bit conservative  but the filter shouldn't really be able to read to much of the OFM signal if its out of the range - this may not be something that can be changed in your system but that is probably the best bet when it comes using frequency multiplexing with this device. 

Please let me know!

Best,

Parker Dodson

Hi Parker,

thanks a lot for answering so fast.

Just to be sure that I got you right I will double check some things said.

1.) I already had a look into the ACHIghVoltage paper you mentioned and I totally agree with you that it is "a little bit over the top" for us.

And besides, we did a lot of experiments with 2 EVMs (modified; 47uF/25V cap removed) running on a line with 54V DC and we did not see no drawbacks or problems so far.

So, as a conclusin, the following setup should work for us (it is basically the standard approach and, if I got you right, what you suggested).

The THVD8000 side

with the outputs UART3_RS485_A/UART3_RS485_B  connected to READER_2CON+ and READER_2CON- (OOK filter is L19 and L20; the others are G.hn and HD-PLC filters) to

2.) Here I'm absolutely unsure how to deal with.

What I can say is, that we could lift the used communication band of the G.hn or HD-PLC a little (maybe up to 5MHz) and see what happens. For sure this will reduce the communication bandwidth a little, but we can probably live with that.

More interesting is, why the OOK disturby the G.hn/HD-PLC communication as it's "carrier" frequency is far away from the used band of G.hn/HD-PLC and band filters of the both are very selective (basically implemented in SW). Besides manufacturer of the chips used for G.hn and HD-PLC see no general problem.

So, maybe it's amore fundamental problem? Actually I'm a little lost, to be honest....

Another information: G.hn or HD-PLC signals are coupled to the line using a transformer between the DC-decoupling capacitors and the line driver/receiver.

Any idea? Need more information?

Thanks for a feedback in advance.

Cheers Alex

Hi Alex,

Thanks for the additional information - if you can test with the higher carrier for the OFM signal and share the results that would be very helpful as I do think that is at least part of the issue that you are seeing. The EVM modifications you have made look fine the big thing is that the capacitors are roughly rated for double the voltage (unless you take into account derating) - but they are 100V caps so it should be fine. Also depending on data-rate needed from the THVD8000 a lower modulation frequency may also help. With that being said - what is the data rate you are looking for? 

Do you have any scope shots across the inductors (L19/L20) and the input filter/transformer for the other signal. At first glance I don't think the setup should be too problematic for the THVD8000 - as there seems to be an excess of inductance (which is fine - you just don't want to violate minimum) but I'd be curious to see if there is any higher frequency noise that may be presenting from the OOK signal - there is up to 25% deviation in the center frequency for the modulation frequency so at 500KHz that could be up to 625KHz + 30KHz spread spectrum clock - a lower level harmonic may possibility still show up in the frequency band of interest  + potential EMI due to impedance mismatch in the system- so I am very interetested to see if the adjustments in bandwidth are switching.

Also have you confirm communication works when no HD-PLC signal is applied and the issue only appears with both or the HD-PLC signal?  Also are the inductors other than L19/L20 part of the transformer or just afterwards as additional filtering (I ask because sometimes I have seen coupled inductors are transformers as just close inductors)  - and if the transformer isn't show can you show the connection and possibly provide the part number. Also is it possible to get the values of the inductors - I am having a bit of trouble reading the values. 

Please let me know if you can provide the scope shots and answer the few additional questions above - as I am not too sure what the root cause of the issue but I suspect it may have to do with the coupling  for the G.hn  signal in conjunction with the THVD8000 coupling + the relative closeness of the lower level harmonics of the OOK signal compared to the spectrum of the G.hn signal - but I'd like to see potential signals as well as potentially try to simulate the the coupling to see if there is problems from the THVD8000 side.

Best,

Parker Dodson

Hi PArker,

sorry for answering so late. A lot of end year business these days....

Here are some details you asked for:

- Concerning the data rate, we can probably live with 38.4kBaud and thought a carrier frequency of 500kHz would be good for that refering to the data sheet. Besides, a lower carrier frequency, like suggested, would need higher values for the inductors. And since we also have high currents, it will raise the component costs too much.

- Every single communication is working fine as long as it is alone on bus. HD-PLC alone is working, G.hn alone is working and OOK alone is working as well.

- All inductors are NOT part of the coupling transformer, just DC blocker/filers. Coupling transformer of HD-PLC and G.hn is a separate part on another sheet. Coupling schematics are shown below, value of the cpacitors is 1nF, the transformer is of type #458PT-1566=P3 e.g.

- L19 and L20 (SRR1260-121K) have 120uH (OOK DC filter) and a maximum DC/saturation current of 1.65A. L23 and L24 have a value of 22uH (R321 and R322 are 1.5K) , L22 and L25 are 1uH. This is the filter combination is the G.hn filter/DC decoupling (2-200MHz). L21 and L26 have a value of 47uH and it is the filter/DC decoupling bank for HD-PLC (2-30MHz).

- Unfortunately I did not have the chance to do further test/experiments/evaluation because of suffering from lack of time ;)

Hope this helps a little.

Cheers Alex

Hi Alex,

No worries - 100% understand, end of year business can be a lot!

Understood on the inductors - that makes sense its not uncommon for cost being a driving factor behind higher modulation frequencies.

So if you can run some tests as I previously asked for that would be great - as seeing the signal shape will be beneficial to understand what is happening. I understand that this take some time - please know that if the thread gets locked (they auto-lock after I think 30 days) just open a new thread and you can link this one and I will be the one that answers it. 

A couple thoughts that I do have:

1. A bandpass filter before the receiver A/B inputs  but off of the shared bus. This is a technique we use on our higher voltage implementation - I don't see a particular reason why this would be super problematic if you are selecting for the OOK frequency. This filter can be tuned to a higher quality factor allowing for a more narrow pass band. The only real concern is that the detection thresholds are low so you may not see a ton of improvement - but it would help create a slightly more narrow window for OOK data - if possible lifting the G.hn band a bit higher to the 5MHz point would be helpful as well. This may have the added benefit of keeping the THVD8000 transceiver nodes looking "high impedance" to the G.hn source. 

2. I am not the most familiar with G.hn  - do you know if there is a minimum impedance w.r.t. ground or a max current limit of these devices? My concern is since G.hn is shutting down communication when OOK is operating I am wondering if the THVD8000 nodes going low impedance when they are actively driving is causing an issue for the G.hn source. As when in Receive mode the input impedance should be a minimum of 96K - but in driving mode its more like effectively 10 Ohms - and the system is more or less okay to assume its linear so by superposition the G.hn source is being loaded by a 10 Ohm node to ground when the THVD8000 is driving. I don't know if that's an issue for the driver. 

I think adding a filter that looks hi-Z between the series caps and the THVD8000 which is selecting for the OOK frequency may be an option here so that the nodes don't ever look low-Z - as that's what I am kind of leaning towards right now - since they each work independently (i.e. OOK works when the G.hn is not running and vice versa) and don't when they are both running I think the biggest issues are: THVD8000 internal filter isn't very selective and maybe the loading when the THVD8000 is driving is causing the issue for the G.hn source. Bumping up the G.hn source frequency and adding a bandpass filter that a) selects the OOK frequency and b) looks like a high-Z load to ground from the G.hn source could help to mitigate both issues.

Please let me know if you have any thoughts on these approaches and if they will fit into your overall design goals/plans!

Best,

Parker Dodson