Next Gen DRSSTC

[Hydron]

Didn't see this until today, but am happy I wasn't imagining things about the lead-time being broken when I tried it (about 18 months ago I think?)

Will report back results when I get a chance to try the latest version. Thanks for the efforts keeping this updated.

[TMaxElectronics]

After continuously having issues with my own controller design for a while I decided to join the family and implemented the design into my controller:


It is 100% compatible with the existing version, but has the power supplies (24V,+-12V and 5V), fiber TX&RX and the LEDs on board, and because of this I gave it the c suffix (for compact). (even if it is 10cm larger in width and height )
The PCB ist sized to slide into a cheap extruded aluminium box like this one (the 110mm version):
https://de.aliexpress.com/item/32802719197.html

I also moved the GDT driver to a daughter board, so it can be replaced with a digital isolator board for use with gate driver ICs.
Because of this the FAN power is now only 12V though, to keep the 24V (and when using gate drive ICs also mains) completely isolated from the control logic.

The design files (for altium) are here: https://github.com/TMaxElectronics/UD3c (un-tested at the moment)
If you have the time I'd appreciate any suggestions for improvements. The repo also has a PDF version of the schematic

EDIT: i never ended up using this version, as I got a fully assembled UD3, incase anybody was wondering

[Netzpfuscher]

I added a few new software features and TMaxElectronics is working on a new fiber Ethernet interface:




Arbitrary QCW ramps:








Configurable telemetry during runtime:

[TMaxElectronics]

After a week of intensive development I finally got the fiber ethernet (FiberNet ) addon working through teslaterm.
All it does for now is forward MIN frames between UD3 and the PC over UDP, but since it has an SD card slot there is the potential for more (like loading UD3 parameters from the card for example). That is still a work in progress though. It also supports DHCP and automatic network discovery (though the last one isn't in TT yet).
I've tested the adapter under the big SKM600 coil Netzpfuscher posted here a while back, and communications seem even a little more reliable than the serial over fiber connection that that coil uses, though further testing is required to see if it can actually perform that well in use.

Interestingly enough the finished module has a comparable component cost to ONE HFBR optical transmitter, so I would consider this to be a viable replacement for those (fibernet is ~20€ + 5€ for the SFP modules and 30€ for the media converter = 55€ as opposed to 4x17€ for the HFBR series). The module also fits onto the UD3 nicely:



I'm also currently working on a new coil using SKM400 bricks from Netzpfuscher, and since we all live close enough together there is a good chance that Netzpfuschers new coil, mine and the big one I mentioned earlier will be run next to each other if we can find the space at the HV lab Here's how my new bridge looks at the moment. Can't wait to try it out

[Intra]

I fixed some small bugs, and a big bug (lead time has no effect, I don't know since when, but the bug is very old):
https://github.com/Netzpfuscher/UD3

There are also new binarys:
https://github.com/Netzpfuscher/UD3/tree/master/common/binary/UD3


And I added a little bit of documentation in the Readme.
https://github.com/Netzpfuscher/UD3/blob/master/README.md

And a small getting started:
https://github.com/Netzpfuscher/UD3/wiki

Looks like lead time still have no effect. I flashed a TTerm branch from last of Nov 4, 2020 commit of UD3 rep. Teslaterm is from malte0811's Oct 25, 2020 last commit of electron-ts branch.

[Netzpfuscher]

Oh, you discovered the TTerm branch ^^ You need to be warned it is under very heavy development. I'm implementing the terminal from Tmax fibernet project. The complete user interface needs to be ported. I think you discovered several bugs like the tr stop... ^^

 Can you give me little more information of your setup? Which UD3 devkit or real?
Have you tuned the start oscillator?  It looks like your coil switches way to early.

As a hint a lead_time of 1000ns was sufficient for my SKM600 @ 53kHz.
Slow IGBTs can be in the order of 2000ns

[Intra]

It's a little test-QCW. Driver is QFN-version. Transient mode I use to just try to set leadtime as usual. Sure, about 150nS maybe enough for TO-247 but with good softswitch switching losses significantly decrease.

Fsec is about 310kHz, Fpri is 250kHz but freq of starting oscillator set on 310kHz and I gave it 20 cycles.

My idea is to drive coil at upper pole while primary will be at lower pole so when energy transfers and Fsec drops coil can be more in resonance and can easier transfer more energy.

With tune prim command I got 33kHz Fres and that looks like another bug in circumstance of 250-311kHz distance because I put final geometry in JavaTC to check up before power on.

Primary CT is 1:22:22, Bridge on FGH60N60SMD, K15U 6.8nF 10kv MMC, almost half-donut primary, k=0.45, PEH200 6mF 450V bus cap.

A couple of photos attached.

[Netzpfuscher]

For the autotune: You need to set up the autotune range for your coil tune_start 190 tune_end 350. Please post the plot of Teslaterm here.

You need to set the resonance frequency very close in the start_freq. 310kHz vs. 250kHz is far away. Perhaps your secondary is not at 310kHz so it doesn't suck energy out of the primary. I have no deep knowledge in QCW and I have no small coil to test the QCW stuff.

A good start is a static load test with scrap metal in the primary. Set it all up and check if everything is working.


Perhaps tomorrow I can make measurements if everything is correct. But I haven't touched the essential code for this after I find the lead_time bug.

[Intra]

I think I figured it out.

The problem was in bad solder connection between GDT and emitter of one of IGBT.

Found this solder problem only when check GDT outs separately and without connecting negative probe connector. One IGBT opens not at full voltage and become opens at full voltage only when I grab IGBT emitter's wire by negative probe connector instead of grabbing emitter-side TVS leg.

Never seen that problem on scope before, especially with that kind of driver. The ugly shots of collector-emitters attached. 

[Intra]

The driver itself works a bit different than UD2.7 which I used before so rest half of evening I spent on mess with feedback.

In UD2.7, when you compensate the phases, your signals start slide to right or left and you see how it is going and where is the end of tuning.

In UD3 I not found that behavior and found that even you set a Fres right but lead time was not set right, your feedback will be dance and glitch and energy won't be well transfered in secondary. Or I am wrong and misunderstood what I saw. Anyway.

After setting lead time, which was 310nS, my scope helped me see that feedback determine my Fpri as 235kHz (not tune prim, it's still 33.6kHz and plot is just all empty), Fsec is 309kHz, and with Fres=235kHz transient mode started brilliantly even with 309kHz secondary. Tank current starts grow as usual and with 400uS on 27vdc on bus the terminal starts crackled a little. As my k~=0.45, I afraid to see what streamer I could got with 1.5:1 secondary even on 310vdc and besides, when Fres=Fpri with that far Fsec, so I moved to testing a phase-shift.

[Intra]

Phase-shift works equally with 235kHz, 309kHz, 320kHz and 350kHz of Fres. I left 320. If lead time not set correctly, phase-shift mode do a bad result of feedback too and when this result bad, current did not accumulated in RLC and did not grows.

0, 1, 2, 4, 8 and 20 start cycles do not make sifnificant changes between themselves.

Looks like it's time to move on 310vdc or give a try to figure out why Teslaterm not shows data from my Hall sensor. I so hope my plastic primary isolation and supports will not melted in first minute of full power.

[Intra]

I have a question about hall sensor wiring.

I saw that you are using the sensor LEM LF 306-S if I identified it correctly on photo. I bought one LF 306-S to check DC current sensing and power showing features but I found that someting wrong because Teslaterm always shows 0 amps.

From https://github.com/Netzpfuscher/UD3_PCB schematics R30 seems to be the sensor's measuring resistor, which marked in schematic as 470 ohm but in LF 306-S datasheet I found that with +\-12V sensor supply for measure range of +\-300A measuring resistor should be 37 ohm.

Will it help to change 470 ohm resistor to 37 ohm if I use LF 306-S with +\-12V supply? How much ohm for R30 do you use with yours LF 306-S?

Besides, I found ratio 1:2000 in LF 306-S datasheet but schematic's note says ratio should be 1:1000. If I change ct2_ratio to 2000 will it helps? Your Teslaterm's ct2_ratio is 2000 with your LF 306-S?

Thanks

[TMaxElectronics]

The current shunt on the input current monitor is R48, not R30. R30 is part of the low pass filter for signal conditioning.

R48 has a suggested value of 49.9ohms, but can be adjusted to match what is required by the sensor.
Having a wrong value here would only result in a wrong reading though, and not in the UD3 always showing zero current.

Have you measured the output current from it with a multimeter without connecting it to the driver to make sure it actually works?

[Netzpfuscher]

The UD3 does the math for you. You simply give the ct2_ratio and ct2_burden. But you need to make sure that the voltage at the shunt is not higher than 5V 

50 Ohm shunt is good. And your LEM has 1:2000. But your coil is not a multi kW coil ^^ You simply make more turns through the CT to reduce the ratio But you need to set the ratio that the current spikes are in the measurement range so that the RMS calculation works. With a 50 Ohm and 1:1000 you can measure 100A.

If you see always zero, it can be possible that the voltage of the CT goes negative because the current flows in the wrong direction.

You can test the CT if you wind like 10 times through the core and give it 1A, then you should see 10A in Teslaterm.

[Intra]

Thanks! The problem was in wrong wiring direction. Now current and power is ok.

Next problem I found is in EMI I suppose.

As driver communicates with PC via UART on top of USB and while bad input signal can't directly open IGBT for a long time with way that was in UD2.7, I decided to check up is any needs to do specially an opto communication instead of just USB cable and a couple of ferrite EMI chokes. And, driver seems to be get the EMI because Teslaterm shows lost connection message any time I trying to start qcw or transient mode.

I saw your commit about external interrupter. The record said is in WIP status. I did the test-circuit to check up can it works and maybe it still WIP or I just did something wrong but it isn't worked for me. I tried a part of Steve's External trig circuit from his origin schematic of UD3, and plug it in port which was marked as for external interrupter in PSoC Creator's UD3 project, and also I tries to set 1 or 2 in ext interrupter row in Teslaterm's settings, but pushing the button nothing done. Is ext.trig is still WIP?

[TMaxElectronics]

I'm not sure I understand the way you connected the UD3 to the pc. Did you use UART over fiber, or the USB connector on the UD3 itself?

The ext. interrupter input was a quick addition so I can test the MidiSticks on my new coil, but neither Netzpfuscher nor me had time to test it so far, thats why its still WIP at the moment

[Intra]

Oh, it seems I understood this feature in wrong way. I took ext.interrupter input for trigger input. The driver have a trigger input like this? Something for qcw-gunning by button finger push.

[Intra]

The driver is connected to PC this way. It good when about 30V on bus and EMI is not so big but with 310V it crashing connection with Teslaterm even when watchdog is off and when connection is crashed then signal is stopped generating a ramp.

[Netzpfuscher]

No, the trigger input is gone and you cannot copy it from the old UD3 schematic. The complete QCW timing part is rewritten. But it's not a big deal to re implement it.

You need a isolation for the PC, it is essential. The USB on the UD3 was only intended for "offline" configuration.

[Intra]

After opto isolation was done I found that a programmer which I left plugged in inside a driver box was a reason to chip fells from EMI.

I got a two problems next.

First is a strikes in primary from toroid's edge what I suppose I can handle with some plexiglass isolation

Second is start cycles seems to be not enough to stable driving. 16 start cycles looks better than 8 and 8 better than 4. May I ask to increase max start cycles from 20 to 999999? I want to try drive a coil from start generator entirely.

Short video of 1mS test. primary strike is on 0:51