Next Gen DRSSTC

[Netzpfuscher]

I'm working on this coil for a while now. Now I reached a point where it's almost finished.
I used Steves UD3 driver with small modifications and made a huge code rewrite. The CPU of this driver is a Psoc5LP Cortex-M3 micro, which has a on board FPGA.
The software consists of a FreeRTOS operating system and a bunch of tasks which handles all the control functions. The interrupter is a piece of software inside the driver. I worked a lot to get the software as user friendly as possible. The PC-Interface connects via USB to the PC and enumerates as USB-Midi and USB-Serial Port. You can connect to the serial port with a vt100 terminal and the driver offers you a CLI with autocomplete, history and help functions.

github repo and Wiki: https://github.com/Netzpfuscher/UD3/wiki



The driver can sweep through a given frequency range and plot the response of the primary and secondary for easy tuning.

Primary:

Secondary:


Interface:


The driver samples the maximum primary current an displays it in the status window (Youtube Video). It measures the Voltage on the bus and the current to the bus to calculate the rms current and the power.


The driver board:


The complete coil:


The inverter box:



To handle the peak powers I build a buck converter to reduce the 3 phase mains voltage (565V in Germany) to 400V which is the maximum voltage of the capacitors at the moment. The buck is calculated for 10kW continuous power and waits for a enclosure 



At the moment I'm working on a new PCB which includes the secondary current circuit and a small fix at the USB-Port.


I would put the complete code and the PCB-Design files on GitHub if I get the permission from Steve (90% of the PCB, the Logic in the FPGA and a little bit of software which I haven't rewritten is his work)

[futurist]

Big thanks for sharing your results!

I've been playing with lower-tech UD+ for some time now and I use it on my DRSSTC. It's a really nice upgrade from UD2.7C I've been previously using, and Hydron did some tweaks to the VHDL code to make SIG and OCD LEDs more visible. So far there isn't a single writeup of someone using the driver and/or potential problems they encountered, which I hope will change in the future.

Until now I didn't see any details about UD3, except spec sheet written by Steve. I'd like to see it gets public like UD2 and UD+ and I'm looking forward to building one. Do you know what does Steve think about releasing UD3 to the public?

[Hydron]

Looks great now that it's nearly finished!

I assume you're using 1200V silicon, and that the 400V limit is because you're trying to maximise the energy storage of the electrolytics by running 3 in parallel rather than 2 in series? Or can the IGBTs not handle the 565V either?

I am very interested in using and adding to your work if it can be released. I am currently building a phase-shift modulation QCW coil, and while the hardware design is well advanced, I am inexperienced in coding and VHDL, so that is going very slow (I currently just have a simple driver running on a FPGA dev board, and have not added a MCU yet). Anything with the sort of functionality that you've managed to implement would be a huge help (especially if the RTOS makes it easy to add tasks, e.g. for controlling a PFC boost stage), though I'd be doing my own PCB design.

[Mads Barnkob]

Welcome to HVF Netzpfuscher

I really like the idea of a terminal/cli controlled coil, OS independent.

Built in tuning functions, surveillance sensors and MIDI, what is not to like. I was wondering if your interface/driver can be networked/cascaded for multiply coils running on each their midi channel?

Great work so far and I hope you find a solution with Steve, he has a good record for publishing his stuff and only stopped because he spend too much time supporting others building from his plans.

[Netzpfuscher]

@Hydron
Yes I'm using SKM200GB124D IGBTs. The inverter was intended for developing the firmware, not for maximum streamer length. Therefore for the ease of building the bridge I only used one cap. I ordered a box of 40µF 1100V DC-Bus film capacitors with a rms current rating of 21A each. If I have time I build a MMC for the DC-Bus with around 500µF.
With RTOS it is very easy to add other functions, there are a lot of CPU cycles free.

@Mads Barnkob
The cascading feature is on the way ^^ the hardware is there. I used little daughter boards for the fiber conversion. On the connector are two UARTs so it is only a software thing to add this feature. Then the master coil filters on the MIDI-Channel and relays the messages to the other coils.
The CLI is a little bit trickier. I think I use a command for switching between the coils like "switch coil2".



The other way is to use WIFI daughter boards. I have a working prototype with a ESP8266 which acts as a MIDI-RTP (Apple MIDI) and Telnet Server. But the timing over WIFI is not very accurate.

[Steve Ward]

Just wanted to say how great it is to see Jens expand upon the UD3!  I'm at a point where im sure im not gonna pursue any for-profit business with my work with Tesla coils, so I'm totally fine with releasing design/code, so long as my name gets in there still :-).  The main reason UD3 isn't out there, easy to find and download files, is that it's quite an undertaking to build one and make it work and supporting others in that effort is quite time consuming, so i've been limiting its release to a few people that have contacted me.  Jens seems to be quite at home with embedded programming, so I hardly had to do more than send some files over and he took it from there.  I've had quite a time supporting other guys who were totally new to coding, but eventually everything worked out.

Wanted to mention that UD3, with its extra HVDC sensing inputs, DC current sensor input and the few unassigned digital outputs, is capable of controlling a PFC or buck stage in addition to its usual TC duties (and it can also do phase-shift bridge control).  I have code for both of these instances (the buck driver code is really hacky... but it works) so if someone is really wanting to take this on, i can send code.  Of course, it's not at all compatible with what Jens has done here!

The tuning plots are really slick... did you add an extra CT input to get the secondary response?  Im sorta confused about what the difference is between those 2 plots you show... since the Fres dropped and another peak showed up, my guess was that the first plot was primary only (secondary physically removed) and then second plot had the secondary in place, but it says 0.3A which to me means you have a CT on the secondary ground lead.

[Hydron]

Steve - thanks for releasing this out there (and for all the previous UD drivers - most of us got our coils going with one of them!). If I can help with documenting how to use the UD3 without hand-holding I will (though it'll be a while before I understand most of the code myself - hardware is more my thing!).

As for the response plots - there is indeed an extra CT input, using the same circuit as the CTout net but with a 5R burden resistor. Once I get something up and running myself I'll be comparing the plots to what I get out of a FRA instrument (which also gives the primary, secondary and split-poles).

I'm personally also interested in the PFC possibilities/code, though I have a lot of work to do on my coil before I get to that part (and would also need to understand FreeRTOS more before I start adding tasks/code to Netzpfuscher's work). Will PM with my email address.

[Netzpfuscher]

Yes I added a extra CT.

Steve you are right, the first plot is without secondary and the second plot is with the secondary in place. The primary capacitor needs to be bridged while plotting the secondary.
I think we should add a autotune lockout if the bus voltage is higher than xx Volts. The peak detection is done in analog hardware, so the ADC has plenty of time to digitize the peak current. The peak detector consists of a sample and hold and a comperator. If the interrupter signal gets high the sample and hold is enabled and tracks the maximum peak. If the interrupter gets low the ADC kicks in and digitizes the voltage from the sample and hold. If the ADC conversion complete signal goes high the sample and hold gets zeroed. I think I post a picture later.
I think we can use this circuit to tune the "max_current" parameter, we can add a factor which is controlled by the peak detector. If you dial in 400A max_current trip point and during run the current goes higher, the factor is set to for example 0,8. Then at the next cycle the overcurrent trips at 320A.

The analog processing in my code is done asynchronous. The ADC fills a buffer and at a certain level the analog task gets a semaphore. The complete buffer gets processed and the task goes back to sleep. This is a problem to implement a buck or a pfc. There is work to be done. I removed nearly all of the float calculations and the square root, because this is very expensive on a cortex-m3. The calculations are done with integer arithmetic and the sqrt is a approximation.

[Netzpfuscher]

The git is online. For now only the firmware. The PCB files follow.

https://github.com/Netzpfuscher/UD3_PSOC

This is the last working version. I'm working to update to FreeRTOS 10 which isn't running yet, I get a out of heap error . If it is running I will add a development branch.

[malte0811]

Thanks for uploading it! I had a look at some of the files, the copyright header doesn't look like this is supposed to be on GitHub/public ("CONFIDENTIAL AND PROPRIETARY INFORMATION", and it looks like you forgot to fill in the owner's name)? Is that intended or did you forget to change it?

[Netzpfuscher]

I forget to change it. This is the standard header from Psoc-Creator. I think I clean it up with the next commit.

[Hydron]

I've managed to get the UD3 code up and running on a CY8CKIT-059 PSoC dev board (see http://www.cypress.com/documentation/development-kitsboards/cy8ckit-059-psoc-5lp-prototyping-kit-onboard-programmer-and), and it's happily running my hacked-up QCW coil using both the serial/USB CLI interface and USB midi input.

See the attached pic of the rats nest of cables I was using to run it - breadboard with PSoC PCB is above the mousepad (bench PSU power has now been replaced by a variac+isolation transformer and things have been tidied a little!). I also took a quick video of it running at 130V on the bus (obviously more space will be needed to put real power through the coil!):

/>


I have run it up to ~170V on the bus, though I am running into issues much above 130-150V with interference occasionally causing the controller to lose ZCS sync - probably not a surprise given how messy it is. The spikes on the hard switched transitions (in QCW phase shift modulation mode) are also quite large and a little worrying - I will need to look carefully at the PCB layout of the bridge and the gate drive resistors etc to see if I can tidy it up a bit.

To get it running on the dev board + breadboard setup I had to do a bit of work changing it to compile on the (slightly) different PSoC part, and have a few goes with pin selection to get the analogue routing to complete. I haven't had time to look at much of the code other than this stuff, though I do intend to get in and add/change things, and to have a go at getting an interface other than a serial console working.

Thanks to Netzpfusher and Steve for their work - has been fun getting it making sparks, and has helped hugely with testing things before I do any more PCB/software design for my coil.

[profdc9]

It would be nice to have a version of UD 3 that uses the CYC8KIT-059 PSoC dev board for the PSoc 5 chip.  I have a couple of these dev boards, and they are very cheap, around $10, and very easy to use.  Perhaps a UD board could be made that is simple to assemble without exotic soldering techniques, and then has a pin header over which the  CYC8KIT-059 is plugged in to.  Is there a schematic for the UD3 showing how the chip is used, because as long as none of the committed pins for the dev board are used in the UD3 design, I think this should be possible.

[Hydron]

This is exactly what I discussed with Mads on IRC - it's definitely possible to lay out a board using a PSoC dev board + headers as a "through hole" part, and the dev board is _cheaper_ than the chip by itself. I'm probably not going to do such a layout myself (gonna stick to SMD), but am happy to help someone who is. BTW I disagree that soldering a QFP counts as "exotic", but the cheaper argument remains, and the dev board also comes with a USB connector inbuilt and even a whole extra PSoC chip (the programmer chip could be re-used as another mini dev board if you don't need many pins!)

The only reason I haven't posted more detail is because my setup is such a hack, and while all pins are routed on the PSoC, many are un-used. I just have the gate drive pins (going to another PCB with the actual drive circuitry on it - the green board in the top of the attached pic), UVLO shorted to +5V, CT current-sense and ZCS pins used. I've attached a close-up of the breadboard setup (note that while there is a crystal on there I couldn't find the right load capacitors in my parts box so I'm using the internal oscillator, which is really good enough anyway).

The biggest thing to watch for is to make sure that all pins can be internally routed to the required places on the PSoC chip - there are some restrictions as to what pins can go where on the chip, and limited routing resources (especially for analogue), so I had to shuffle some pins around the chip until the PSoC creator software could find a way to route everything. The other thing that should be done (but doesn't have to) is to adjust the speed that the PLL is running at - the PSoC dev board has a faster version of the chip than the UD3 design, and can run up to 80MHz rather than 67MHz (actually set to 64).

[Netzpfuscher]

TQFP is easy to solder with a normal soldering iron.

/>
The price is definitively lower with the dev-board. But there are some points to save money on the board, I used gatedrivers from Micrel which are a lot cheaper than TI. For the GDT-output stage there are cheaper mosfets from Diodes (DMC3021LK4-13). The DCDC Converter is a 7805 compatible device, which can be sourced from china. Perhaps we can change the board and add the DCDC from the UD+.

You must be careful if you run the chip at 80Mhz. Some of the logic uses the 64Mhz PLL as Clock, I'm not sure if all of the timing calculations works correctly. Thats a thing to check before cranking up the speed.

[Hydron]

Yes, that's why I haven't changed the clock speed yet - I saw some stuff in the code that would need to be changed before the PLL frequency can be set to 80MHz.

[Mads Barnkob]

Great progress Hydron, the complexity of your rats nest has also grown over time, it used to be two probes and a single board

Could some of your switching spikes be due to low voltage DC bus and the output capacitance is playing you a trick? About the interference, I would get things boxed up and shielded before looking more into that.

I would still prefer a through hole driver board with a pin header for the dev. board, the only downside to this would be when the dev. board is discontinued from the manufacturer and suddenly it would be a bigger job making that yourself than soldering in the actually chip on a UD.

[Netzpfuscher]

To the interface. I think we should go with a industrial standard protocol for the standalone interface. Something like Modbus RTU, DMX or CAN. The Hardware has enough resources left for a second UART transceiver. The protocols can be implemented in tasks, it should be no problem to implement more than one protocol and execute the task according the config in eeprom. Yesterday I got FreeRTOS 10 up and running. I haven't tested everything, but I think in the next days it all works fine. The main feature why I upgraded the RTOS is the new streambuffer in FreeRTOS 10 this should improve the performance of the UART.

It is also possible to add WiFi or Ethernet to the UD3 with a ESP32 or ESP8266, I have a proof of concept on my hard drive.

[Hydron]

Anything that works over a <5MBps fibre link should be fine. Not sure how you'd do CAN, but the RS485/RS232 based protocols will work fine with fibre as the physical layer rather than differential twised pair copper, as they're basically asynchronous serial at heart.
Absent something more standardised I had actually thought of re-purposing a RS485 protocol we use for CCTV control at work (mainly because there's well-debugged code that I could re-use, though not release), but using something standard and open-source would be best.

I'm just putting together a Mouser order for UD3 parts, and the 80MHz speed grade part (CY8C5888AXI-LP096) is barely more than the 67MHz part, so I'll build a board up with one of those and have a go at increasing the clock frequency (work on the clock speed will likely be delayed by a long vacation though).

Lastly, I'll probably have a go at running my coil outside at full mains voltage in the next few days - will try and get video of the success/destruction.

[Hydron]

So I got the coil running outdoors, unfortunately with wind and in the middle of the day so no worthwhile video, but I have attached a pic of the setup taken from the "control room" (upstairs window where the variac, scope and PC were):


Control was via serial over the orange fibre optic lead, and I was able to look at bridge output current/voltage using a pearson CT and a couple of differential probes. The heater that can be seen is acting as ballast for my poor 2A Variac so it won't blow it's brushes to bits trying to charge the caps after each burst

The test was a success in that nothing went pop at 360VDC on the bus (variac cranked up to 11 on 240VAC supply), but the coil didn't behave that well otherwise. The spikes seen when hard switching were rather extreme, at up to ~750V (that may be a little high - I know that the probes used will ring themselves due to parasitics of the leads they use, but having checked with other standard 100x probes, I know the spikes are still there and large). This seems to cause the controller to lose ZCS synch, and causes waveforms like the following throughout most of the burst:


I'll be looking at the code to see if it can be made more resilient to noise, but to really fix things I think I'll need to get a revised version of the coil running with better layout etc (and higher current capability with 4x the number of IGBTS - was hitting my 225A limit a lot!). It has been really useful building up part of the bridge as a small scale prototype though - I've learnt a lot about what I should do for the final coil and will probably re-use some of the spare parts to make a smaller coil in the future.