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 userfriendly 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.



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.

[Netzpfuscher]

I've tried to interpret your scope shot.



It looks like there is a overcurrent event and the driver goes to the freewheeling mode. But I don't know if it should do phaseshift during the ringdown. I haven't tested the QCW mode very much because I have a big low impedance coil. The big mess is under ~90A primary current, what CT ratio did you use?

The input comparator stage has a threshold which is defined in ZCDtoPWM.c:

   //set reference voltage for zero current detector comparators
   ZCDref_Data = 25;

If I find a little bit time, I can do measurements at my coil to see if there are problems with the logic.

[Hydron]

Yeah I was thinking about overcurrent, but didn't expect it to do phase shift during ringdown. The threshold is also set to 225A, rather than <150A where it seemed to trip earlier. Later on in the burst it does trip at the correct point, as seen below (QCW modulation finished by this point):


And another with odder behaviour (overall view, part of interest at division labelled 16.05ms):


Zoomed in:


I am still suspicious that there is some element of interference from the hard switching spikes happening here - behaviour seemed better when I'd reduced them by modifying the bridge. Unfortunately I don't think I'm going to have a chance to work on the coil again to test anything until about this time next month, however I will have a go with using the UD3 (and also taking some arc current measurements) on a larger DRSSTC if time permits.

[Steve Ward]

Phase shifting will remain in effect during current limiting, which does tend to make for unusual-looking waveforms as the phase shifted gate signals are still applied alternately between the 2 outputs.  It does appear that there's some phase error in your switching, still, which is a typical side effect of the the current limit function combined with the phase-shift control. The phase-shift bridge switching scheme gives a rise in operating frequency because the driving voltage pulses are leading by a significant phase compared to the primary current.  When it switches to freewheeling/current limit mode, the applied voltage is basically zero, so the phase lead of the driving voltage no longer comes into play, and so the frequency of oscillation will drop.  Toggling quickly between these modes is tricky for the phase predictor thingy and so it misses ZCS by a decent amount under some conditions.  Ideally, your QCW coil is designed so that it does NOT current limit while phase shift modulation is applied.  A few hard switchings should not be a significant problem for a properly designed bridge.

All that being said, did you follow the same schematic as the UD3 for the CT input?  Those filter caps are pretty essential i think... routing long wires to the dev board might be iffy around tesla coils .

I used 15 ohm turn on gate resistance with the FGH60N60 IGBTs and i use 2:1 GDT ratio to step the 24V drive to 12V as we are not abusing the peak current rating of the IGBTs in QCW coils.  Be sure you have sufficient dead time in your gate drive to avoid hard commutation of the output voltage.  What i mean is, the IGBT should always switch off early enough so that the primary current causes voltage commutation at the half-bridge output and the IGBT turn on is at zero voltage (ZVS).  If there is not enough deadtime, you will switch the IGBT on before the voltage at the output has changed, and this rapid charging of the other IGBTs junction capacitance can ring at very high frequencies with the stray inductance of your bridge.  Also, if the IGBTs are switching late, and the IGBT turning on must force the opposite diode to recover, this will lead to large spikes as the diode recovery is a high di/dt across the stray inductance.  I observe very nice switching waveforms on the 60n60s even when hard switching in phase shift mode.  Perhaps 50V maximum overshoot with 400V bus and 60A peak current per device.  Going easy on the turn-on seems like a good, simple choice to combat all the downsides of insufficient deadtime or too-hard-reverse-recovery of the co pack diodes giving big voltage spikes.

[Netzpfuscher]

I've made big progress on the UD3 software. The command line now supports more datatypes:

-uint8 / uint16 / uint32
-int8 / int16 / int32
-float
-char
-string

The EEPROM-Dataset is revision save. With the new function it is possible to change the parameterlist and still read the EEPROM to the new parameterlist. The EEPROM function gives a warning if it can't find values in the EEPROM for a new parameter and it warns if there is a value in the EEPROM but not in the firmware.

The next thing I'm working on is a terminal for the UD3. It's based on Chrome App (Javascript) and should run fine on Windows/Linux/Mac. It includes a simple MIDI player which sends the MIDI messages over UART to the UD3 so you don't need a special Interface, a normal USB-UART is fine.

[profdc9]

Do you have an example of the interface circuit between the microcontroller UART connection and the MIDI interface? 

Also, I was wondering if it would be possible to connect one of the ESP8266 wireless modules to it and use that for a serial port.  There's a serial to wifi interface here

https://github.com/jeelabs/esp-link

so it would be possible to use Wifi to talk to the terminal rather than USB.  The serial port is totally transparent and as long as there is TTL serial on the microcontroller side you don't need to do anything.  You just have to flash the ESP8266 with this firmware and it becomes a serial to wifi interface with a serial port.  You can get a ESP8266 module on ebay for like $2, and a CH340 to ESP8266 interface for about $1.50.

Thanks,

Dan

[Hydron]

I look forward to playing with the new code! I have been busy/away so haven't had much time to play with the existing stuff other than some more bench tests with my CY8CKIT-059 based QCW prototype (focusing on the power side of stuff rather than software).

profdc9:
As for serial, the command-line interface also comes up on the TTL TX/RX port in exactly the same way as the USB-UART interface, so it would be easy to talk to the ESP8266. The only thing you might need to check is what the UART speed is set to in the cypress design files. I have used this feature to connect via a fibre-optic serial link (see orange wire in post here: https://highvoltageforum.net/index.php?topic=188.msg1778#msg1778 )

[Netzpfuscher]

It should be no problem if you use a transparent WIFI-Bridge. You can send terminal commands and MIDI commands to the TTL-UART on the UD3. The UD3 separates these and route the messages to the MIDI-Interrupter task or to the command line task.

With the new terminal there can be a second option. It is possible to implement a TCP or UDP connection to the ESP8266 over socket. This eliminates the need of a virtual com port driver on the computer side. But the WIFI-Link adds a few ms jitter to the data (MIDI), if the WIFI-Link is weak or there is a lot traffic it sounds a little bit wrong.

[Netzpfuscher]

The first test of teslaterm was a success  There is still a lot of work to do and improvements to make, but it's running.

UD3-Firmware with teslaterm support:
https://github.com/Netzpfuscher/UD3_PSOC/tree/new_CLI

Teslaterm:
https://github.com/Netzpfuscher/Teslaterm

For running Teslaterm (drop the folder on the nw.js executable or make a link like this: "C:\nwjs-sdk\nw.exe c:\git\teslaterm"):
https://nwjs.io/


And the demo:

[Hydron]

Ooh, looks very interesting - thanks for the update. I'll let you know when I've had a chance to test it myself.

[Mads Barnkob]

That is a super cool interface and the trend feature is something that can make me order a devkit at once to try this out myself

I do however not feel like I have a complete overview of what parts and bits are needed as you all seem to run this on different hardware

[Hydron]

I'm not so up to speed on the code for the "interface" PCB (seen in first post with LCD), but the UD3 code will run on either of two boards:

1) the UD3 design based on Steve Ward's work and updated by Netzpfuscher (not sure if he's released the files for this publicly). This board comes with primary and secondary CT inputs, USB, UART header, relay/fan control, bus voltage/current monitoring, and GDT driver. No changes necessary to compile/run

2) A PSoC5 dev board, connected to (at a minimum) a CT and external GDT driver. This needs the pinout and device selection of the PSoC project to be changed before compilation, and some support circuitry either on a breadboard (as I did, see pics) or on a support PCB like what profdc9 designed. Ironically the dev board is cheaper than a single PSoC part despite having TWO devices on it (one for the programmer/debugger, which you'll need anyway for bringing up a UD3 PCB).

Both of these boards let you connect via USB (it enumerates as a virtual serial port + USB MIDI controller) or a straight TTL UART connection to the appropriate pins. I believe it falls back to UART if USB is not present, but not 100% sure.
When I used it the PC got very unhappy with EMI when using the chipset-native USB2 controller, but was happy with the motherboard's non-native USB3 controller (operating in USB2 mode). Dunno why one was OK and not the other, but I do know that USB is pretty garbage from an EMC immunity point of view, so you'll probably want to hook up to the serial port via a fibre link for proper full-power testing.
The primary interface via serial port is a command-line (as seen in the video and screenshots); I have not investigated properly what other methods can be used for control as the CLI has worked so far for what I have been testing.

[profdc9]

I built up my PsoC 3 board.  The only things missing are the precision resistors for the voltage bus sensing, and the bus Hall-effect current sensor.  I have tested the microcontroller and verified that it can drive the gates however.   I haven't put it in a coil yet though.  The board for this is in the DRSSTC PCB pack.  The one in there is slightly modified because I moved a few components around to make the USB connector easier to access.



I modified the project for the new pin assignments.  You can get the file in 7zip format below.  It doesn't have any of Netzpfuscher's Tesla term modifications yet though.  I also modified the serial port speed to be 38400 baud rather than 2 Mbaud, because I will probably be using this with either a ESP8266 (which I have used successfully) or with an optical transmitter and receiver.

https://drive.google.com/open?id=19qv76rRRxeaazcwBBeACj1WtnnMVr_3k

One note:  when putting the PSoc5 into the pin socket, you might need to bend the pin sockets in slightly because if they are bowing out, they will tend to push the PSoC5 out of the sockets causing loose connections.  I think this is because it is difficult to get the pin header socket to stand up perfectly straight when soldering it in so you have to tweak it.

I probably won't have time to try this, but I would like to, but I am having too much fun with the UD2.9 skip pulse to take the coil apart, but I will probably try this driver eventually.

Dan

[Hydron]

Hah, I was wondering why you were complaining about not having room to fit everything on the PCB, now I understand! (Has been a while since I've done anything with much through-hole stuff on it other than TO-247 half-bridges)

It will run just fine without the sensing stuff (see my minimal breadboard on the first page), just doesn't report anything.

[profdc9]

Yup the PCB is packed.  There's stuff underneath the PSoc5 chip too (low profile resistors and diodes).  Almost every square millimeter is used!

Dan

[Netzpfuscher]

The PCB files are on Github:
https://github.com/Netzpfuscher/UD3_PCB

This design is untested due to a lack of time ^^
I would be very happy if someone helps with the UD3, we need documentation (Git Wiki). A SMD version with Kicad would be a big thing, Altium is to expensive. If we go with the same processor like on the dev-kit (QFN), we only need to maintain one software. I haven't found a good solution in PSOC-Creator to handle more than one processor.

@profdc9
The esp supports way more than 38400 baud. Perhaps the serial bridge software can be modified? If you want to use teslaterm the datarate can be a little bit slow. It works but the terminal can be little bit slow. While a chart/gauge frame is transferred the output of the CLI is blocked, so there can be a delay up to 145ms (70 bytes).  I have a missing option in teslaterm, there is no baud-rate selector

[Mads Barnkob]

I would be very happy if someone helps with the UD3, we need documentation (Git Wiki).

I would like to help, but consider me as a completely blank and new guy on that job, I would need a fairly detailed work list

[Netzpfuscher]

I added a little bit of documentation to the wiki. 

https://github.com/Netzpfuscher/UD3_PSOC/wiki

[profdc9]

If it would help you get started with Kicad, I put together a quick SMT board.  However, I used the target board rather than the bare IC because it is difficult to lay out because the target board effectively adds another layer, so I can get away with a two layer board.



Certainly some optimizations could be made.  Most of the footprints are 0805, and there are a handful of components on the back.  The project is attached. There are some things from your design that aren't in mine that could be added (mostly the second current transformer).

Dan

[Hydron]

I am looking at whether PSoC creator supports building for more than one target configuration. It does not look like it's something built in, so may be a case of copying source files between two separate projects (annoying, but doable).

I can also have a look at updating Netzpfuscher's (untested) PCB to use the same pinout, device etc as the dev board, but it may not be that simple on a 2-layer board with a QFN (also requires hot air to solder the chip, vs a QFP which is do-able with a reasonable iron).

[profdc9]

Would it be possible to just change the same pins so that different parts would be used but the pins would be essentially the same?  There would be some flexibility to changing the pins of the devkit model but of course many pins are committed to things like capacitors, switches, and the two-wire port.

Dan

[Hydron]

It may be possible to do this, yes. I believe that the TQFP parts (in Netzpfuscher's PCB) are basically a superset of the QFNs on the dev board, so that any pin selection that works for the dev board can also work for a TQFP based PCB.

Unfortunately the PCBs out in the wild (those from when Steve Ward built his, Netzpfuscher's and one that I have) are designed around a pinout that can't be replicated with a dev board, so there'll always be a need for a couple of different configs. None of this is particularly hard, it's just annoying as someone has to muck about changing stuff for every code release.

[Netzpfuscher]

I reorganized the code and found a relatively good solution for the different boards. I split the code in a common code base and the board specific files. The common code is linked in the board specific folders. The _QFN projects are for the dev board and the _TQFP for the classic boards.

If someone gives me the pinout of the dev board version I merge it to the git. I only need the ".cydwr" file. Or clone the new repository and make a pull request.

https://github.com/Netzpfuscher/UD3

common:
binary Binary files like the precompiled bootloader
ntshell Shell code
rtos FreeRTOS code
uart_ldr UART-Bootloader code
ud3core UD3 code

[profdc9]

Here is what I have for the cydwr attached.  I also changed the clocks around as well.

Thanks,

Dan

[Netzpfuscher]

There are a bunch of new features incoming. https://github.com/Netzpfuscher/UD3/tree/burst_mode

• Ethernet support with a Wiznet W5500
• Teslaterm with IP-Support
• Teslaterm now has a MIDI-In. With a virtual MIDI-Port it is possible to send MIDI from every App you like
• Teslaterm with support for a Korg nanoKONTROL2 controller
• The UART is equipped with a protocol and transport layer for error detection and retransmission (https://github.com/min-protocol/min)
• Burst mode interrupter

The Ethernet connects to the 8pin header on the UD3. I think Ethernet is a good choice. It is isolated, cheap and you don't need special Hardware. If you want to run a multi coil system, you can throw a switch between the coils and connect a fiber Ethernet to the computer. If I have the Firmware in a good state, I upload a release in binary form. I think it is much easier to flash a binary for someone who is no programmer ^^

We hit the 2m ^^

[Netzpfuscher]

I've made several bugfixes. Ethernet is working, Teslaterm is more stable.

Actually I'm working on the duty cycle limiter for the MIDI mode. My first proof of concept works relatively good. There are no more big current spikes if a very high MIDI-Note is playing.

[Netzpfuscher]

I've added a new synthesizer in the UD3. The new synthesizer "emulates" the famous SID chip. The UD3 interprets the music on a register level. The noise synthesis of the SID makes a very nice drum effects.

[Uspring]

Very neat 
There was a short discussion on 4hv a few years ago on tricks to enhance TC sounds.
http://4hv.org/e107_plugins/forum/forum_viewtopic.php?157570.0#post_157851

[Hydron]

Cool, new stuff to play with
Unfortunately I haven't had time to do much work on coiling recently, but I will be giving your new code a go when I get a chance. I'll also be in NZ again at the end of the year, so will have my large coil to play with too (I have a 75% finished UD3 board to install into it). On that note, Uspring - I'll be having another go at the toroid current measurements I promised and failed to do in April, this time I will have a lot more time to spare and hopefully won't injure my back trying to lift the coil down out of storage like I did in April!

[Mads Barnkob]

Great progress on the UD3 Netzpfuscher!

I will set it up as a goal for this winter to get a working UD3 with your software

[Netzpfuscher]

One warning. The newest GIT-Version of the Dev-Board UD3 software has a messy pinout. I need to correct this before I merge it in the master branch. I use the dev-board for ethernet debugging so it is a little bit hackish. In general there is heavy work in progress ^^

I also work on a new PCB revision in Kicad with integrated Ethernet. Ethernet works so great and doesn't need special Hardware. I think it is better to go away from the expensive Altium ^^


Thanks to malte0811 the Teslaterm is growing. He added a scripting feature to automate the coil for show use.
In general the UD3 ist still fully functional with a normal VT100 Terminal.

[Netzpfuscher]

I've made Teslaterm and the UD3 more user friendly with a settings form. I found some small bugs in Teslaterm and the UD3 and fixed these. The newest files are in the master branches:

https://github.com/Netzpfuscher/UD3
https://github.com/Netzpfuscher/Teslaterm

[Hydron]

Thanks! I'm about to order some boards to upgrade my big coil (in NZ) to a UD3 to use when I'm there over Xmas. Will take some pics/video and also some topload current waveforms to share.

[plasmatree]

Hello everybody and thanks already for this amazing work!
It has been >10y that I messed with tesla stuff, but somehow it's in my head again. 
Looking at the different UD iterations using FPGAs seems obvious to me. Combined with the simplicity of this dev board... great!

I'm preparing to order the pcbs and was wondering if the plans for the Psoc5-Power found in the pcb pack are still the most recent/recommended versions for this driver?
Should I consider to add or change something?

Greetings from Cologne,
Flo

[profdc9]

Apparently there have been updates to the pinout that I have not incorporated into Psoc5-power yet, so you might want to hold off.  You don't need the board if you want to breadboard it.

I could update it if I get an updated pin list.  I haven't looked at the latest PsoC creator project lately to see what the new assignments are.  I think there is support for Ethernet now.

Dan

[Netzpfuscher]

It should be possible to go back to the old pinout. I primarily changed it to make a simple connector cable to the W5500 board on my desk ^^
Perhaps I add a non development version with the dev kit to the UD3 project.

[Netzpfuscher]

I've added a new experimental feature. A fuse emulation.

You set the maximum continuous current and the 10s limit from the breaker curve. The UD3 tries to limit the duty cycle to keep the fuse under 60% of the trip point. The gauge on the lowest right is the fuse (100% fuse tripped). The gauge in top of the "fuse" is the duty cycle limiter (higher is more limited).

If the controller can not keep the current low enough and the fuse reaches the 100% the UD3 shuts the coil down.

I think there is a lot to improve, but you can see what I'm trying to do.

[Mads Barnkob]

Very nice feature, I can really see that come in handy for shows where it would be good not to have a trip or any kind. Did you try it out with sparks and most interesting heavy ground strikes?

[Netzpfuscher]

No, this is the next step. The test in the video is only a static load test with a bunch of scrap metal in the primary.

[Netzpfuscher]

We have made some full power runs. Input power is around 10-18kW from 3 phase mains 580V on the bus.

We had some problems with the ESP32 interface, but I'm working on a new one. Based on node.js and can be run on every computer/raspberry/orange pi/ etc...

[Hydron]

Just watched the videos - nice work!

Unfortunately haven't had time to do much work on my coil(s) recently, but when I do I'll have a play with all the new features you've added.

[Mads Barnkob]

Is it just the recording or is there some stuttering in the music playback?

Do you have more recordings from a little further away, the video does not fully represent how large the coil and sparks really are at those power levels!

[Netzpfuscher]

No I have no other videos, the cage is too small for my cellphone. For a bigger image I need a wide angle lens.

Yes you are right, there is stuttering. I investigate this, there are two options. The javascript midiplayer cause this, or there is crap on the serial line in the coil. I added a counter for broken packets in the software. The protocol works like this:

-packet with a sequence number is send to coil
-coil sends a ACK with the sequence number
-the next packet is send
-packet gets corrupted
-no ACK is send
-after 50ms the packet is retransmitted

But 50ms is way to slow for MIDI, you can hear this. I need to play with the parametes perhaps I reduce the retransmit time and introduce a NACK which causes the transmitter to resend the last packet instantaneous.

You don't hear this in the first video. This uses the SID-Synth which has a buffer with around 500ms in the driver.

And we need to change the serial line in the coil. There is a 1m shielded cable from the driver at the bottom to the front panel with the fiber transceiver. In the past we have seen much crap on this line. With the protocol this crap is not visible in the data but it adds jitter.

[Hydron]

Just a quick question for Netzpfuscher - is the behaviour of the lead_time value changed at all between versions of the UD3 code? I've had a go with a newer version and it doesn't seem to have any effect on the timing of the IGBT switching, whereas previously (at least a year ago!) it seemed to work as intended. I'll have a dig through the code to properly understand how it works, but I thought I'd just quickly ask incase there is an easy answer.

On another note, I have gotten my CY8CKIT-059 dev board up and running (other than the bootloader mode) with an ESP32 for wireless control - seems to work nicely! For those looking to do the same, note that I did need to change things a bit to run the PSoC UART TX on a SIO pin so that I could lower the high output level (the ESP32 isn't 5V tolerant). I used a different board to the Olimex ESP32 as I only wanted Wifi mode and it was cheap on ebay - I will integrate a ESP32-WROOM module directly into my final design whenever I get to that point!

[Netzpfuscher]

No, I think I haven't touched it. But I cannot guarantee that there is no bug on other changes which can cause this. At the first sight everything looks ok. I haven't measured the leadtime for a while now, all of our coils have the same SKM400 bricks.

I have used a voltage divider on the TX pin for the ESP32.

Actually there is a new feature incoming, a alarm and event system. Which helps a lot to debug a coil.



At the end of the month there is a big event here in Germany "Extraschicht" where we have a high voltage show at a old power station. Besides a 4m SGTC we have the big UD3 DRSSTC. I hope everything works 

[Hydron]

Thanks for the answer, I'll have more of a dig myself in the code. I look forward to the new features, and any footage from the show!

[Mads Barnkob]

Good job on the continued development of the software, looks real good with a debugging system and as Hydron says, we look forward to video from the show, hopefully you can get on a distance this time to capture how big it really is

[Netzpfuscher]

I finished the alarm & event system. I added a value field that you can see at which temperate or voltage something happens. The sysfault is much finer, now you can clearly see which signal is bad and stops the coil.

alarms get  --> shows the last 50 events
alarms reset --> clears the event list
signals --> shows the signal states
kill reset --> clears the sysfault registers which are not self clearing

I merged everything in the master branch https://github.com/Netzpfuscher/UD3

@Hydron I cleaned the timing calculations but I can't see any fault. If you find something, feel free to make a pull request. By the way the lead_time resolution is in 15ns.

[Netzpfuscher]

I have a couple of videos from our high voltage show at the Extraschicht. Everything was working fine  The man in suit is my friend Florian.

The big SRSGTC

DRSSTC with Popcorn

DRSSTC with Pirates

[Netzpfuscher]

There are some new features:

• Envelope generators for MIDI and SID (ADSR)
• Signal monitor with auto refresh (q for quit)
• Synthesizer monitor with auto refresh
• Rolling mode for alarm monitor (alarms roll)

The envelopes for SID are automatically configured over the SID-register stream. The envelopes for MIDI can be configured over the command line (mch, attack, decay, release) or over MIDI-Control Change messages (CC 73 --> attack CC 75 --> decay CC 72 --> release). You can set different envelopes for each MIDI channel. The envelope modulates the max-current the pulsewidth is constant.

The UD3-node (node.js interface) now supports the network SID-device protocol, you simply can stream SID music over the ACID64 player.

SID Demo:

[Mads Barnkob]

That video is awesome and it got so intense at 0:45!

It seems like I am running out of excuses to get a UD3 up and running, didn't someone promise me to write up a guide on which hardware to use etc? Was it Hydron? Futurist? Profdc9? I forgot and unfortunately I do not have the time or mental surplus to take in more new things from scratch right now

[Hydron]

Profdc9 made a through-hole UD3 PCB to mount the CY8CKIT-059 dev board (which is cheaper than a single chip, and includes a programmer) - given your aversion to SMD this is probably the way to go. Getting the board up and going isn't that hard once you have the bits, though none of us have written a guide yet as far as I know.

I'll likely be having another go with mine in the next week or so (in NZ right now), so will report back on how it runs.

[profdc9]

The through-hole PCB is at

https://github.com/profdc9/DRSSTC-PCB-Pack/tree/master/Psoc5-power

You just need to zip the gerber files and send it to a PCB house like JLCPCB or Seeedstudio and they will send you a board.

Dan

That video is awesome and it got so intense at 0:45!

It seems like I am running out of excuses to get a UD3 up and running, didn't someone promise me to write up a guide on which hardware to use etc? Was it Hydron? Futurist? Profdc9? I forgot and unfortunately I do not have the time or mental surplus to take in more new things from scratch right now

[Netzpfuscher]

I think I can release a binary package in the next days for the UD3 and the interface. Then there is no need for compiling something. At cypress there is a standalone psoc programmer app and after the initial programming you can simply drag and drop a firmware file in Teslaterm for updates.
For a simple "Hello UD3" you only need a Dev-Kit and a micro USB cable. For a teslacoil safe connection you only need a USB to TTL board, a pair of fiber transceiver and the interface software.

On the PC side it is as simple as writing the COM-Port to a config.ini, start the .exe and point your browser to "127.0.0.1:2525"

@profdc9
I need to check the pinout against your PCBs. It's possible that I changed some pins over the time. But it can easily corrected in software.

@Hydron
Whats the status with the lead time? Is there an bug?



Edit: 16.07.19 20:15

I added binarys for the UD3 and Teslaterm:

https://github.com/Netzpfuscher/UD3/releases
https://github.com/Netzpfuscher/UD3-node/releases

Flash the hex file with psoc programmer: https://www.cypress.com/products/psoc-programming-solutions
Configure the config.ini according to you com port and start the interface with: UD3-node-win.exe -c config.ini

UD3-node is only working over the UD3 UART, not over the dev-kit micro usb. You need a USB TTL UART.

[Netzpfuscher]

I'm working on a new Coil ^^ It's nearly identical to the big DRSSTC from the videos.

Resonator:
-1m secondary winding
-~56kHz fres
-500nF 15kV Atesys primary capacitor

Inverter:
-UD3
-2x Electronicon 1800µF 600V DC-Link capacitor
-SKM400 full bridge
-3 phase rectifier -->400V 3ph AC --> 565V DC






 

[Coyote]

Hi guys,

I find this very interesting. I took a look into a schematics which is available on the web, both versions Netzpfuscher and through hole variant of Profdc9, they seem almost identical to me.

But there is something that caught my eye that I can't understand, it's about Vbus and Vin monitor.  Netzpfuscher  has a note that on each input a 500k resistor has to be connected externally. All clear, it is a differential HV probe with 100:1 attenuation. But the opamp TL082 is supplied with +/-12V, I guess the output range is almost the same, wouldn't this harm the Psoc5 input?

[Mads Barnkob]

Netzpfuscher, seems like I completely missed your update on the inverter Some days the amount of new threads and posts are running wild, but that is nice

Nice and solid design, where did you get the DC link capacitors? The blue current transformer is for 50 Hz input current measurement? I can barely read it, is it HIMA timers? Got them cheap somewhere or just at hand, only found only price and that was not low! How about the current rating of the soft-start contactors?

[Netzpfuscher]

@Coyote
The opamp design is from Steve. You are right, the output can go around +-11V the series resistors should high enough that the output only goes to 5V. But the Psoc pin is protected by a 1k resistor. Perhaps it is good idea to clamp the signal in the next revision.


@mads
I've bought the DC link on eBay. 5 for 100€. The DC links makes the bridge design much more easy ^^
The blue transformer is a hall effect current transformer for the DC behind the rectifier. On the picture I had forgotten to put the wire through. Yes the relays are from HIMA, just simple SIL3 relays I had them at hand. I don't know exactly right now I think the contractors are 40A.

I was a bit lazy the last weeks, we have a turnaround at work... The next thing is to build a enclosure for the inverter. But I have run a static load test:

[acobaugh]

Hey folks! In planning out my next DRSSTC (12" diameter, CM600 full bridge), I finally got a chance to sit down and parse everything discussed in this thread and others relating to the UD3.

What's the current status of this project? I poked through a couple of github repos, and I think I understand what firmware exists, though I haven't tried to build any of it (I don't think PSoC designer/creator run on Linux).

Specifically, I'm looking for the most up to date PCB designs. Kicad or the final gerber files would be nice. I'm a bit partial to SMT, and I'm not afraid of hand soldering a TQFP. So, either an SMT board with headers for a cypress dev kit, or an SMT board for the TQFP (preferred). I found profdc9's SMT Kicad project, but there was a note that it was unfinished and untested.

I'm also willing to help with github wiki pages and docs if/when I get up to speed on this stuff and gain some operational experience with it.

[Hydron]

Netzpfuscher has a github repo with a PCB design (done in Altium) to take the TQFP, this is then wired up to power, GDT(s), a CT, serial comms (either fibre, or a wifi/ethernet module) etc to build a full controller. Also in other repos is a PC GUI for coil control and ESP32 code.

You may need to have a trawl through the thread and the ud3 github wiki to find the right links but it's all there, at most needing some pin configuration or baud rate tweaking (maybe just because my setup differed slightly).

If you have any issues with the PCB file format (i.e. don't have altium) and there aren't suitable pre-built gerbers the please let me know and I can try and see what formats I can export into.

[acobaugh]

I've been looking through Netzpfuscher's gh repos. I don't have Altium. I was going to try and run the kicad converter tool for altium projects, but if you could export to gerber, I can just take those straight to PCB.

I'm also curious about the secondary CT - I thought I read that had to be added on after the fact - has that not  been added to the PCB?

It's kind of hard to follow along without the ability to open and view the various project files. Maybe someone could export them to png or pdf maybe?

[Netzpfuscher]

The secondary CT input is on the revision 2 of the PCB. That's the one on github. But it's not realy used in the firmware, only for the autotune. But I haven't used it for a long time. I even was thinking if I can toss it from the firmware.

I can export all PCB files. I need to make gerbers for myself to order some PCBs. But I'm very busy in the moment.

I started with a Kicad design, but it's not finished: https://github.com/Netzpfuscher/UD3_Kicad
I tried to do some reduction of special components and go for a 4 layer PCB. I'm happy if someone helps me with the whole UD3 thing ^^

This is my actual kicad progress:

[fnordest]

Big respect! Really great work  . I just got myself a dev board and as soon as i have everything up and running i will try and see if i can contribute. Right now i am trying to connect over serial but without success. USB works fine. 

Cheers

Got it! I had to deactivate min protocol.

[Netzpfuscher]

I improved some things in the software.
-The drums in SID are better now
-Autotune has a warning due to hardswitching
-Sanity checks for current transformer measuring range (burden/current/turns)

We upgraded Florians coil to SKM600 bricks and reached the 3m.

And I worked a little bit on my inverter. Now also with SKM600. ^^





And I bought a car full of new DC link caps 350uF 1500V partly for our next coil with FZ1200 bricks. An because they were cheap ^^

[futurist]

Wow
How much current are you pushing trough SKM600?

Why did you go for 4-layer pcb, were there any layout issues with 2-layer one? They are at least 3 times more expensive to manufacture unfortunately (elecrow, jlcpcb)

[Netzpfuscher]

The OCD is set to 1200A and we getting a peak of 1500A. During the music the coil consumes from 10-20kW of power with 565V at the bus.

No there are no issues. I am working also on a new revision from the 2 layer version in Altium.
I started the Kicad 4 layer version with the intention to integrate Ethernet and with the added complexity I wanted a better power routing on the board, so I went to 4 layer. Yes you are right it is not cheap.

The latest pcb:

[Hydron]

And I bought a car full of new DC link caps 350uF 1500V partly for our next coil with FZ1200 bricks. An because they were cheap ^^

Nice work! I saw those cheap caps on eBay too, problem was the shipping outside Germany was 10x the cost of the caps themselves. Good to see someone is going to get some use out of them!

[acobaugh]

Is there any interest in also helping to maintain a 2 layer version in kicad? I'm with futurist on this one. 4-layer boards seem to be at least 2x as much as 2-layer boards.

I'm also beginning to get the sense that maybe a version of this driver based on an STM32 MCU might be better for more of us to work on? Just barely dipping my toes into the embedded systems waters, so I'm not sure what the real differences are between the cypress PSoCs are and a straight STM32, at least in terms of how the UD3 is using them. All I know is from vscode on linux and the PlatformIO extension I was able to easily hack on and compile firmware for something else.

[Netzpfuscher]

No, it's not possible to use a STM. The Psoc has a "FPGA" like part for Analog and Digital. The UD3 makes heavy use of this, the switching logic is independent from the CPU. If you want to migrate to another CPU I think you need a combination of CPLD and micro. But this will definitely more expensive.
The best candidate for a CPU upgrade is the Psoc 6 but it can be tricky because the hardware is different and it has less macro cells, but a dual core CPU (M0 and M4). It is definitely the better choice for number crunching due to the FPU.
I work on a revision of the two layer board in Altium. But I am a little bit busy at the moment. I can push it to GitHub it would be nice if you can migrate to Kicad.

[Netzpfuscher]

Big news!!!

I got my new PCBs and made a small batch (5) for me and some friends  When I tested everything, I put the gerbers online.

But there a some new cool features in the software too.

-There is a option for line coding. This activates Manchester encoding and decoding. It encodes the UART on a 8 times faster carrier. It is DC free!! so it can transmitted over a transformer or optics from fiber ethernet. I think it also works over SFP modules  . Be careful with the baudrate 500 kbaud results in a 4 MHz carrier. The bootloader supports this too.

-WS2812 it's highly in development but it works with a 8x8 matrix. There is some visualization of the synthesizer or the bus status.

-Voltage measurement of the driver voltage. Not very accurate but better than nothing.


https://github.com/Netzpfuscher/UD3

[oneKone]

oh wow, it looks brilliant! tbh even though your project is beyond me, it's still awesome to see the development you're putting into it.

also,
where did you get the boards made, the soldering looks damn decent!

[fnordest]

These are good news indeed  i can't wait to check out the new features and run my system with two of those!

Do you have any plans about selling populated boards?

[Netzpfuscher]

@onekone
The boards are from jlcpcb, I ordered a stencil too. We pick and placed by hand and soldered with a cheap Chinese reflow oven.

@fnordest
It took around one hour for one board. I don't know if I make another run. The parts alone are around 70€ for a single board. The costs for the parts go down quickly if the quantity is higher. For 50 it's around 40€/board.

[Hydron]

Thanks for the new features - will have to have a play with them. I've just packed my UD3 to come with me on a hastily re-arranged trip to NZ (where my larger coil is), so I might be able have another go at using it on that. Gotta use those 2 weeks in isolation somehow!

For those that may not realise, manchester encoding would also likely allow for the use of cheap TOSLINK cables and recievers/transmitters. It would however need to be translated back to a normal UART encoding on the PC control end.

[malte0811]

TOSLINK works quite well already (without Manchester encoding), but some receivers work better than others. I use 2 cheap receivers I got from Netzpfuscher. They work reliably at 500k baud, but when I tested them at ~115k, the signal at the receiver went high too soon when transmitting a character with a long chain of 0 bits. I assume that with less suitable modules this happens quicker, so it's a problem even at 500k baud.
Manchester encoding could fix this, and since the modules (at least the ones I have) seem to be fine with a constant "high" signal it would be possible to use a standard UART module at the PC and do the Manchester encoding in software (effectively using 4 bits per byte).

For the "real" Manchester encoding Netzpfuscher implemented I believe the plan is to use another PSoC at the PC end.

[Netzpfuscher]

I designed a SFP to 5v TTL circuit. It uses only standard components and works from around 50kHz to 16MHz. The lower bandwidth depends of the used SFP module. A 2 layer Kicad board is in progress.

[Netzpfuscher]

Cool new things in the dev branch. It's possible to define a Master-Coil and multiple Slave-Coils. For this it was needed to expand the SID-frames with a timecode which is written by the master and transmitted to all slaves. The UD3s are playing the frames by the timecode. To get it over multiple control computers working the master sends his time to all slaves every 500ms. The slaves are calculating a offset (which get smoothed to get rid of latency jitter) to their time and are sending the corrected time to their UD3 which is syncing to this time (the master time). I need to measure the timing differences but it sounds good.

In every UD3 it's now possible to define a filter string in a simple format:
f<100 = only frequencys over 100Hz are played
f>500 = only frequencys under 500Hz are played
c0 = only midi/sid-channel 0
c1 = only midi/sid-channel 1
c3 = only midi-channel 3

so a string can look like: "c0c3f<100f>500"

With this filter it is possible to split the music over many coils, I think the only limit is the bandwidth of the ethernet  If the lockdown is over I need to test it on the real coil.

[fnordest]

It is really awesome to see this project develop - keep it coming  . I am close to the point where i can put my UD3 in a real coil. Everything works just beautifully. The only thing which gives me a little trouble is the connection to the SID server. I have tried jsid2play but it disconnects NETSID with error because the filter function is not found. I tried different settings for the MOS6581 but no luck so far.

What SID player and editor do you use?

Maybe i could look into a implementation of OSC for the UD3. I think that would make a smooth integration in a professional stage setup. Unfortunately i don't know how to java so it may take a while.

Right now i am messing with java and node trying to build Teslaterm from source.  When i connect to teslaterms web-server i get a nested UI in the lower part of the main UI where the terminal should be. I am trying to fix this and get more familiar with java in the process.

[Netzpfuscher]

Yes yesterday I found it too. Actually the only working SID-Player is ACID64, this was the player which I used for testing and I only implemented the parts of the protocol which this player uses. I need to work a little bit to get full compatibility.

There is a OSC module in node.js, I can take a look on this. My work on all of this is for professional use, sadly due to corona our big event is canceled.

The nested UI thing is only present in Firefox, I need to fix it. You can use Chrome. I merged the dev branch to the master, now everything is up to date. But at the moment I can not upload a new prebuild release. There is a problem while packaging the node modules. But everything should work if you install node.js. But I compiled new UD3 firmware binarys the "cyacd" files are in the git.

At the first time you need "npm install" after that you can run it with "node index.js -c config.ini".

The SID function of the new UD3 firmware is incompatible with my version of Teslaterm (Malte is working on a newer, which is not yet ready) and it is incompatible with older versions of UD3-node!!!!!!!!

[fnordest]

Thanks, i still have the firmware from last year running  . Connection to SID server and replay works fine with acid64. Teslaterm-master runs aswell. 

[Netzpfuscher]

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

[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

[Netzpfuscher]

I won't change the max start cycles. There must be something wrong with your coil. You know that your coil is hard switching during startup? 

But you can do it yourself, don't set values over 254, it is only a 8 bit counter:

https://github.com/Netzpfuscher/UD3/blob/8485ae9c3ac583cc6fc78cb531a84307acef4161/common/ud3core/cli_common.c#L216

[TMaxElectronics]

I finally finished my new coil, can't wait to test it at the lab with more space (and maybe Netzpfuschers coil too)

Setting it up was so much easier than with more basic drivers too.
Just hook up the primary and run the autotune to see if it is tuned right, and that's it
No messing around with an oscilloscope, the feedback polarity, or tweaking potis to get the lead time correct. Just type in the numbers and the coil works, pretty awesome to be honest.

[Intra]

I won't change the max start cycles. There must be something wrong with your coil. You know that your coil is hard switching during startup? 

But you can do it yourself, don't set values over 254, it is only a 8 bit counter:

https://github.com/Netzpfuscher/UD3/blob/8485ae9c3ac583cc6fc78cb531a84307acef4161/common/ud3core/cli_common.c#L216

Thanks! Yes, you were right. Something was wrong with a coil. After deep analysis I found that my flashovers from previous test some way burnt sensor's comparator or +\-12v supply driver chain. After I cut out all peripheral driver part the signal became looking good.

Anyway, I choosed secondary and primary inductors for mmc I have and looks like the impedances is not matched good. Result of 20mS under 60A current limit is about 10-15cm spark.

Nevertheless I want to try to oscilate whole coil on start freq because I see the coil grab a feedback and sometimes jump between poles and I do not see another way besides to force a coil to sometimes hardswitch through the whole freq sweeping down under spark loading so please if you can change the start cycles counter to 16 or 32 bit I will be very appreciated.

[Hydron]

Netzpfuscher pointed at the place where the range can be changed - treat it as an opportunity to learn how to modify and compile the code (PSoC creator is freely available from Cypress semi).

[Intra]

Netzpfuscher pointed at the place where the range can be changed - treat it as an opportunity to learn how to modify and compile the code (PSoC creator is freely available from Cypress semi).

My apologies.

[Intra]

QCW MIDI is awesome :3

[pc50kd]

A while ago I build a coil using the UD3 driver. Back then I used the pre-compiled firmware posted by Netzpfuscher.
The coil worked great except for the lead time compensation.

Recently I saw that the bug concerning the lead time compensation was fixed. So I updated my UD3 to the latest firmware.

After doing this the UD3 only communicates over the onboard USB connection. On the RX and TX pins for the UART connections I get no data at all.
I tried enabling and disabling the min protocol and various other settings but this made no difference. The board only communicates on 480600 baud with plain UART over the onboard USB connection.

Am I missing a new setting in the firmware or is there something else I might be doing wrong?

If someone could point me in the right direction it would be greatly appreciated.

[TMaxElectronics]

I remember the UART pins accidentally being swapped in a previous firmware revision. Did you try reversing RX and TX?

[acobaugh]

Looking to build one of these boards to swap in my big 8" coil to replace the existing UD2.7C. Does anyone have a kicad version of this board? I've been looking at https://github.com/Netzpfuscher/UD3_Kicad, but it looks like that project differs from the original Altium version, and without access to altium, I'm having a hard time figuring out what those differences are, and why. Any help is greatly appreciated!

[Netzpfuscher]

I never finished the Kicad version. Only the Altium Version is up to date. I initially worked on the Kicad to make the board 4 layer and integrated ethernet. But now with the Fibernet everything is obsolete.

There is at least a board importer in Kicad which on the first look works great.

[acobaugh]

I tried the kicad importer a couple different ways. At least with the version I tried on Linux, it never quite got the board layout right. In the end I ended up grabbing a free trial version of altium designer, and figured it out just enough to generate PDFs and gerbers. Just to make sure before I place my order, https://github.com/Netzpfuscher/UD3_PCB is the right repo for the latest board?

What capacitors are we using for C1, C2, C36, C43, C46? The BOM just says "electrolytic capacitor."

What SFP modules are we using with the fibernet board? It looks like the lan9250 supports 100base-fx. Is it sensitive to vendors at all, or will just about any 100base-fx sfp module work? What are folks doing on the other end to hook up to a PC, just a media converter? Ethernet switch? Is the wire protocol used with the fibernet documented anywhere? Just curious.

[TMaxElectronics]

The fibernet can work with any 100Base-Fx module. I have been using some used ones from ebay with no problem.
The others side just goes into a 100Base-Fx media converter, the fibernet supports DHCP and will get itself a unique Mac address from the ID bytes in the UD3.

The protocol used is MIN, but with some slight modifications. It transmits individual packets, which are converted into UDP. All data coming in on port 1337 is forwarded to the UD3 and all data it sends back gets sent to the last client that sent data to 1337.
There isn't really much more documentation about the thing at the moment...

The PCBs should be the most recent revision, I've ordered some of them from JLC and they came out fine, except for the little TC pcb art on the left having some weird rings over it. Shouldn't affect functionality though.

I can check those caps later.

[VEKTOR]

Hello there

The PCBs should be the most recent revision, I've ordered some of them from JLC and they came out fine, except for the little TC pcb art on the left having some weird rings over it. Shouldn't affect functionality though.

I did the same as acobaugh, installed altium viewer, generated gerber files and quoted them at JLCPCB.
At least the online PCB viewer knows how to handle this files, so they shot be correct enough, i guess 
BUT now comes the trap for young players (or maybe not), this files contain two different designs! The main driver board an the 4 gate PCBs.
So, when I understood this page correctly
https://jlcpcb.com//quote/pcbOrderFaq/Different%20Design%20in%20Panel?_ga=2.186550766.618861736.1612917287-1327371747.1609403369
they'll charge you extra for this, to be precise the price jumps from 2$ to 12.10$...
I would pay that but it's contra intuitive, to squeeze everything into 10x10cm and then have to pay much more compered to quoting two different PCBs, that would cost only 4$.

I guess you just made a quote for a single design (2$) and hoped that it slips through?

[Hydron]

I think the $2 thing might just be for the first board design in an order, then it rises to 5 or something? Could be wrong about that, has been a while since I've ordered from them. Regardless, very cheap even when not at the $2 promo price.

I personally wouldn't complain too much about the JLC policy - they do actually tell you how to be a cheapskate at the bottom of the page!

[acobaugh]

I actually managed to slog my way through altium long enough to modify the PCB to take out the gate drive boards, since I have my own design for CM300 half bridge modules. I can share the gerber files for that if you're interested.

JLC usually has some sort of deal for new users or new designs. I've been happy with them. And consider not too long ago we were still having to pay a premium for PCBs or etch them ourselves.

[TMaxElectronics]

Though it might be a little sketchy, you can just say "the slots near the top are for HV isolation". They didn't require the multiple different designs charge when I did that.

I can share the gerber files for that if you're interested.

Sure contributions are always welcome
I think it would work best if you created a fork of the repo and added your files to a new branch, then people can just download that if they need it. (or you could just send them to me and I'll add then if you want )

[AeraCura_]

I can share the gerber files for that if you're interested.

Wherever you decide to put the files let me know.

[acobaugh]

As of this afternoon, I now have a fully assembled and flashed UD3. Booted it up and played around with the CLI a bit. This is going to be fun!

As far as gerber files - I can issue a PR if that would be helpful. That being said, I found about a dozen or so pads that weren't labeled in the silkscreen layer, so I had to go back and forth with Altium with a Viewer license to locate the right parts. If I had caught this sooner, I would have fixed it before my trial license expired. Sigh.

What I would like to do long term is put together a place with links to the different projects, guides, assembly/testing instructions, errata, etc. Preferably something collaborative. I'm tempted to just throw a page up on my personal site, which is done in markdown (using Hugo) and versioned on github. I'd happily accept PRs. Maybe I'll just do this on my own and see how far I get with creating actual content.

[acobaugh]

I'm having problems using the serial line on my UD3. It started when I went to test the Fibernet board I received. The board was never initializing the ethernet port, so it seemed like it was never receiving the UD3 ID. Since then I've tried using just a simple usb to uart converter. Here's what I've observed:

* baudrate = 460800 for all tests
* ivo_uart doesn't seem to make any difference (that I could see)
* physically swapping RX/TX definitely has an effect. One way (RX->TX, TX->RX) causes the COMM light to blink when I type, the other way nothing happens
* min_enable = 1 causes garbage characters to be printed to the terminal every 1s, along with "min reset" alarms logged every 1s
* when typing in the terminal, I can see the COMM light blink.
* I get garbage characters at startup, and sometimes if I type fast enough I can get garbage characters back
* Teslaterm is unable to connect no matter what I try - plain serial or min serial
* USB CLI works just fine

All of these tests were done with both GNU screen, minicom, and the latest teslaterm with identical results.

This is with 54449c1728419ab4e3e3023d3c90874c25ec97e1 from master.

What I observed with the fibernet is this:

* with the firmware located here (https://github.com/Netzpfuscher/UD3/blob/master/common/binary/UARTldr/CY8C5868AXI-LP032.hex), the UD3 would boot, fibernet LED would be red. Right after boot, fibernet LED would go solid green
* after updating to (54449c1728419ab4e3e3023d3c90874c25ec97e1), fibernet LED would stay solid red

So, I'm at a loss. I don't do embedded systems, so I don't have much troubleshooting experience beyond the basics. Oh, and I killed my programmer over the weekend, so I need to wait for another devkit to show up

[Netzpfuscher]

- Baudrate 460800 is correct for Fibernet.
- ivo_uart needs to be set to 0
- RX-TX is swapped in the revision you tested (I forget to change this back, the first fibernet revision had false pinout) I fixed it: 5e215fe77a72e46d5eb83f55406cefff23c0661f
- min_enable needs to be set at 1... Then saved with eeprom save... then restart with reset... The "garbage" are binary min frames. The 1s min reset is correct until a client is connected
- blink of the com light is good
- with min_enable = 1 the "garbage" is a "hello computer I'm a starting UD3" frame
- Teslaterm with a serial cable should connect with "min" and baudrate 460800 and the correct COM port
- USB-CLI is exactly for that reason, if the serial parameters are fucked up to configure the UD3

* with the firmware located here (https://github.com/Netzpfuscher/UD3/blob/master/common/binary/UARTldr/CY8C5868AXI-LP032.hex), the UD3 would boot, fibernet LED would be red. Right after boot, fibernet LED would go solid green

This is only a bootloader. I think I can compile you a actual complete binary and put it on the git release page today.

Oh, and I killed my programmer over the weekend, so I need to wait for another devkit to show up

If the bootloader is still on the board it can be recovered. I take a look if the bootloader pinout is correct. The binary is 13 months old, perhaps it is also from the pre fibernet time. But for updating the bootloader you need a programmer.

If you still have problems, I'm shure we can solve that over Zoom or Teams



Edit (new binarys):
https://github.com/Netzpfuscher/UD3/releases/tag/2.1.0

[acobaugh]

Still no luck. New programmer works. Built a binary from the latest master, and no matter what I try, both the fibernet and a plain usb-uart converter fail to talk to the serial output. I can see bits being passed with the convert, but it's unintelligible.

[Netzpfuscher]

With min enabled you cannot use a normal Terminal, you need Teslaterm. It's a binary protocol. If you want to use a normal Terminal you need to switch off min save and restart. Then you should get a CLI with a usb serial cable.

With fibernet... You have a DHCP running? We have a fallback to a static IP but it can take some time.

[TMaxElectronics]

The fibernet will not initialize networking until it got its setup data from the UD3, so if there is no serial comms for whatever reason it will not even try to get an IP. Does the fibernet LED still remain solid red?
If the red LED goes out it means it got its setup data, once the blue LED is on it got an IP from the DHCP server. whenever there's comms with the UD3 it will flash the green LED and network stuff should flash the blue one if I remember correctly.

It also has the segger find protocol implemented so you can get its IP without needing to do a scan. The client is on this website (teslaterm has one built in too if you go to the IP box of the connect dialog, delete everything and press arrow down on your keyboard) https://www.segger.com/products/connectivity/emnet/technology/find-protocol/

Did you check the alarms on the UD3 with the cli on the USB port? The fibernet pushes some initialisation messages there

[acobaugh]

Figured it out. I have the wrong XTAL. The BOM was generated from the Altium project, which calls out a 16MHz crystal (ABM8G-16.000MHZ-18-D2Y-T3). The project was configured to use a 24MHz XTAL. Changed that to 16MHz, and I'm off to the races. How critical is the XTAL frequency to the timing of other functions?

I guess that explains all the unusual behavior I've been seeing!

Next issue: my local dhcp server made a DHCPOFFER of 192.168.0.199, but the fibernet configured itself with 192.168.0.100. There was no DHCPACK. I can use .100 to talk to it just fine, so I can carry on with my testing. Maybe there's something it doesn't like about the response from dnsmaq?

[Netzpfuscher]

The 16Mhz shouldn't be an issue, the PLL locks to 64Mhz if you set the XTAL to 16Mhz in Psoc Creator. But then you need to make it every time I change something on this file in the GIT. A much better solution is to just remove the XTAL from the board. The firmware starts on the internal oscillator and try to start the XTAL, which fails and stays on the internal oscillator. The accuracy from the crystal isn't needed. The clock to the PC is synced with a PLL and can compensate for that. With the dev board version of the UD3 there is also no crystal.

The IP problem...
You can logon to the fibernet through the UD3. Just type "debug fn", then you get the CLI in the fibernet. To exit just press CTRL+C, to exit top or iotop in the fibernet just press "q".
"ifconfig" gives you some ip infos or let you set a ip (You loose connection with setting the IP over a IP connection ) If you connect over USB to the UD3 you can see the DHCP messages from the fibernet without the problem of loosing the connection.

The ifconfig settings are not saved yet. I think we can make a config file on the SD card later.

[Kevindk9]

I built profdc9's SMD version for the dev kit, as you can see there were a few mistakes with the PCB I didn't notice until I received the board.. KiCad got the pinout wrong for the gate drive mosfets so I had to airwire them


Anyway very long story short I got the driver working! I am unsure if i am using it right though, there is not much documentation for the interface.

There was also a lot of timing warnings when i built and programmed the board. Do i need an external crystal for this board? I also moved the gate drive pins around to fit the dev board layout. And is the correct order to build the "UARTldr_QFN", then program the board, then build the "UD3_QFN" and program the board?



As you can see in the photo im using a USB to TTL converter to connect to my laptop. I see the default baud rate set to 460800 but it looks like my computers USB can output a max of 128000. Do I change it in the PSoC creator to match my USB port?

I connect to Teslaterm in serial(simple) with 460800 baud, then change it to serial(MIN). I connect my coil with a low voltage on the bus and type in "Tune Prim" to run the tuning and get the suggested resonant frequency. I then change the start frequency to that frequency with 3 start cycles.  I turn "TR mode on" and adjust the on time and frequency which works fine. But when I try to play MIDI files it sounds bad and a lot of files that work on other members coils don't sound right. 

As im typing this i realize that it might be the UVLO triggering, im powering it at 17v because the on board regulators get way too hot at 24v im afraid they will die.  Could this be the problem, or is it a serial issue, or a problem with the midi files?  But i see in PSoC creator the UVLO doesn't have anything there so maybe thats not it.


Also what's the difference between UD3 node and Teslaterm? What is UD3 node for? only if you want to connect over ethernet? Do i need it to play SID music files? When i try running UD3-node.exe from https://github.com/malte0811/Teslaterm/releases/tag/v0.0.2  i get this error message.

 I also see this version of UD3 node from https://github.com/Netzpfuscher/UD3-node but i don't know what to do with those files, so i will stick with using Teslaterm on malte0811's github.

Sorry for all the questions and for rambling on, I want to get everything working and make sure im doing it right so i can write step by step instructions instructions for the wiki how to get it to work.

[Intra]

There was also a lot of timing warnings when i built and programmed the board.

Not sure you can ignore this exactly warnings but I got a bunch warning with my setup and seems to it's okay. Try to skip it.

Do i need an external crystal for this board?

No.

Is the correct order to build the "UARTldr_QFN", then program the board, then build the "UD3_QFN" and program the board?

Yes. I built all then from PSoC Programmer upload "UARTldr_QFN" then upload "UD3_QFN".

As you can see in the photo im using a USB to TTL converter to connect to my laptop. I see the default baud rate set to 460800 but it looks like my computers USB can output a max of 128000. Do I change it in the PSoC creator to match my USB port?

Not sure I'm right person to answer on that, but I bet for no. What laptop model do you use?

im powering it at 17v because the on board regulators get way too hot at 24v im afraid they will die.  Could this be the problem

Yes. You should use 24v and some way cold down your board regulators or use another way to deliver regulated power to board. SMD regulators on high load without decent cooling system is in risk of overheating and damaging. For SMD there is a special boards classified as "one-sided aluminum PCB", which capable to be screwed up to heatsink it's aluminium side and pass heat to heatsink through the board's holes under component if maked, but this profdc9's SMD version did not made for that boards. So regulators and if will be high load on gate transistor then the gate transistors too should not be in SMD and should be in TO-220 or something and should be screwed up on decent size heatsinks through aluminium nitride ceramic substrate with Arctic MX-5 or another.

Do i need it to play SID music files?

I used Teslaterm to play SID files. If I remember right then you need drag and drop the SID file to Teslaterm to play it in SID mode and enable SID mode in Teslaterm

When i try running UD3-node.exe from https://github.com/malte0811/Teslaterm/releases/tag/v0.0.2  i get this error message.
I also see this version of UD3 node from https://github.com/Netzpfuscher/UD3-node but i don't know what to do with those files, so i will stick with using Teslaterm on malte0811's github.

Try this build https://drive.google.com/file/d/1pMMMhAq4u94cykIYivyjZuGO93iYG1C2/view

[Netzpfuscher]

Anyway very long story short I got the driver working! I am unsure if i am using it right though, there is not much documentation for the interface.

Cool 

There was also a lot of timing warnings when i built and programmed the board. Do i need an external crystal for this board? I also moved the gate drive pins around to fit the dev board layout. And is the correct order to build the "UARTldr_QFN", then program the board, then build the "UD3_QFN" and program the board?

Yes, all correct. You don't need a crystal.

As you can see in the photo im using a USB to TTL converter to connect to my laptop. I see the default baud rate set to 460800 but it looks like my computers USB can output a max of 128000. Do I change it in the PSoC creator to match my USB port?

You can change the baudrate with Teslaterm in settings. But 460800 is standard for all UD3 also for the Fibernet, its fast enough. You get no benefit of turning it up.

I connect to Teslaterm in serial(simple) with 460800 baud, then change it to serial(MIN). I connect my coil with a low voltage on the bus and type in "Tune Prim" to run the tuning and get the suggested resonant frequency. I then change the start frequency to that frequency with 3 start cycles.  I turn "TR mode on" and adjust the on time and frequency which works fine. But when I try to play MIDI files it sounds bad and a lot of files that work on other members coils don't sound right. 

Have you tested with a coil or a speaker on TP6? A speaker will not sound right on current modulation for debugging with a speaker it needs to be set to ontime modulation ("vol_mod"). For the coil, there is another parameter (you also can use ontime modulation on a coil) Whats the maximum current of your coil? There is a min current parameter, it's used for volume modulation "min_tr_current" maybe set it to a lower value. "set min_tr_current 50" It means that a playing note with low volume still produces a output of 50A (for linearization).

As im typing this i realize that it might be the UVLO triggering, im powering it at 17v because the on board regulators get way too hot at 24v im afraid they will die.  Could this be the problem, or is it a serial issue, or a problem with the midi files?  But i see in PSoC creator the UVLO doesn't have anything there so maybe thats not it.

You cannot set the UVLO in software it is simply a digital pin, you need to modify the external voltage divider. You can check if it was UVLO, with "alarms get" if there is a UVLO event in the alarm monitor or display the signal state with "signals". I bet it is the problem. No one has a problem with MIDI.

Also what's the difference between UD3 node and Teslaterm? What is UD3 node for? only if you want to connect over ethernet? Do i need it to play SID music files? When i try running UD3-node.exe from https://github.com/malte0811/Teslaterm/releases/tag/v0.0.2  i get this error message.

 I also see this version of UD3 node from https://github.com/Netzpfuscher/UD3-node but i don't know what to do with those files, so i will stick with using Teslaterm on malte0811's github.

If you use a new version of Teslaterm and Node... There is no difference in function. The node version is simply for a headless device like a Raspberry in the coil. The UI can then accessed with Chrome from another computer.

Please use only this: https://github.com/Netzpfuscher/Teslaterm/tree/new_versions
Binarys: https://github.com/Netzpfuscher/Teslaterm/actions/runs/1221655930

Other versions are not really supported anymore.

Sorry for all the questions and for rambling on, I want to get everything working and make sure im doing it right so i can write step by step instructions instructions for the wiki how to get it to work.

That would be great

Oh and please give me your complete changed pinout, then I put it into github. That makes updates easier. Now I put together the VMS branch, it is a super big improvement over the old MIDI synthesizer. But the master branch is also working. But it doesn't support drums and other instruments in MIDI mode.

If you want to try (I added the pinout of the screenshot):
https://github.com/Netzpfuscher/UD3/tree/vms_dev

The instrument file (you need actual Teslaterm: https://github.com/Netzpfuscher/Teslaterm/actions/runs/1221655930) just pull the file into the scope on teslaterm to flash it into the UD3:
https://github.com/TMaxElectronics/MidiStick_Firmware/releases/download/V2.0/VMS.example.mcf

If you update the UD3 over psoc creator the instruments are deleted you need to reflash the mcf file. If you update over bootloader it is preserved.

[Kevindk9]

Hey Netzpfuscher and Intra thanks for all the help, I think I've got everything working pretty good!

Camels_Run.sid - https://i.imgur.com/tz1zx1n.mp4

Here im trying the QCW function with a 15ms burst - https://i.imgur.com/LzcDnUn.mp4

This is the coil accidently going CW when I issued  "set synth 3" - https://i.imgur.com/v4iRskI.mp4

The pinout for the VMS-DEV branch is now correct for the dev board, so you don't need to change anything.  And here is a link to the fixed board at EasyEDA with an up to date BOM. https://easyeda.com/editor#id=0fd4d406188442ae8a9967b1bb865cb6|bf5b447561684507937553f8265b6cd4

I have a few small things im still working on, I want to include an ESP8266 or 32 on the board, i bought some modules but cant figure out how to interface with them.  I should choose MIN over UDP, correct? And i shouldn't need to modify any code?

I cant get the pulse width longer than 400us in TR mode. I've tried editing the range in psoc creator, and some of the GUI files for TeslaTerm, nothing seems to work and i don't know where to look.  Another suggestion i have is a "one shot" button for TR and QCW mode.

And finally, for tuning, I run "tune_Prim" and i get a graph. Say my secondary resonance is 55khz, I should try to get my primary resonance in the graph at ~50khz? Then have the auto tune start at 56khz?

Thanks again!

[Netzpfuscher]

Camels_Run.sid - https://i.imgur.com/tz1zx1n.mp4

Here im trying the QCW function with a 15ms burst - https://i.imgur.com/LzcDnUn.mp4

Cool, good progress

This is the coil accidently going CW when I issued  "set synth 3" - https://i.imgur.com/v4iRskI.mp4

Oh, yes there was something. Check the newest commit (I also switched VMS_Dev to master) I disabled QCW synth for now. With the VMS it was intended to make the QCW MIDI synth also block based configurable but I had not time to do it yet. So I disabled the QCW synth for safety reasons now.

I have a few small things im still working on, I want to include an ESP8266 or 32 on the board, i bought some modules but cant figure out how to interface with them.  I should choose MIN over UDP, correct? And i shouldn't need to modify any code?

Not right... The ESP32 project is obsolete and not working anymore. https://github.com/TMaxElectronics/UD3-Fibernet-Firmware <--Essentially we need to port this or port it in parts. MIN UDP is very simple, you get a UDP packet from teslaterm and you can put it 1:1 to the UART on the ESP. For receiving you need to implement parts of the MIN UART receive function to detect frame start and end (you can take a look at the fibernet code) und put a MIN frame 1:1 in a UDP packet and send it to Teslaterm.

I cant get the pulse width longer than 400us in TR mode. I've tried editing the range in psoc creator, and some of the GUI files for TeslaTerm, nothing seems to work and i don't know where to look.  Another suggestion i have is a "one shot" button for TR and QCW mode.

The 400us is only a limit in Teslaterm. The UD3 allows 10000us have you set "max_tr_pw" also to a higher value? For the Teslaterm slider I need to take a look in the code. As workaround you can set a higher pw directly in the console with "set pw 1000" or so

And finally, for tuning, I run "tune_Prim" and i get a graph. Say my secondary resonance is 55khz, I should try to get my primary resonance in the graph at ~50khz? Then have the auto tune start at 56khz?

If you run tune prim you get the primary resonance frequency. For best results you should remove the secondary and make a run at low voltage (like 60V or so) to change the frequency you only can change the tap on the primary. There is no way to change the frequency in software.

[dbach]

Hello,

The UD3s are playing the frames by the timecode. To get it over multiple control computers working the master sends his time to all slaves every 500ms. The slaves are calculating a offset (which get smoothed to get rid of latency jitter) to their time and are sending the corrected time to their UD3 which is syncing to this time (the master time). I need to measure the timing differences but it sounds good.

I had some confusion over this, is there one master computer using the others as slaves, and then each slave is paired with a ud3? Or is one computer with a master ud3 using the others as salves (with the other computers being used as aux USB ports?)

Thanks so much! The ud3 looks amazing

[Intra]

With the VMS it was intended to make the QCW MIDI synth also block based configurable but I had not time to do it yet. So I disabled the QCW synth for safety reasons now.

Which commit is last safe for using QCW synth? This one? https://github.com/Netzpfuscher/UD3/commit/cd4d18a4d5818ee01e0f0742d89642772fda708a

[Netzpfuscher]

Hello,

The UD3s are playing the frames by the timecode. To get it over multiple control computers working the master sends his time to all slaves every 500ms. The slaves are calculating a offset (which get smoothed to get rid of latency jitter) to their time and are sending the corrected time to their UD3 which is syncing to this time (the master time). I need to measure the timing differences but it sounds good.

I had some confusion over this, is there one master computer using the others as slaves, and then each slave is paired with a ud3? Or is one computer with a master ud3 using the others as salves (with the other computers being used as aux USB ports?)

Thanks so much! The ud3 looks amazing

Problem is, that I hadn't time to implement it in the new Teslaterm version.

-One UD3 is connected to one instance of Teslaterm it syncs its time with a PLL to the computer time
-One Master Teslaterm syncs the time to all slave Teslaterms
-The Master Teslaterm plays the SID and taggs the frames with time and transmit it to slaves.

Which commit is last safe for using QCW synth? This one? https://github.com/Netzpfuscher/UD3/commit/cd4d18a4d5818ee01e0f0742d89642772fda708a

Seems so. All before VMS I think.

[Intra]

Which commit is last safe for using QCW synth? This one? https://github.com/Netzpfuscher/UD3/commit/cd4d18a4d5818ee01e0f0742d89642772fda708a

Seems so. All before VMS I think.

Wouldn't it be inconvenient if I bother you to help with build errors for a QFN project from a commit https://github.com/Netzpfuscher/UD3/commit/cd4d18a4d5818ee01e0f0742d89642772fda708a ?

[Netzpfuscher]

Here you go:

https://github.com/Netzpfuscher/UD3/commits/intra

[Intra]

Here you go:

https://github.com/Netzpfuscher/UD3/commits/intra

*0*
Thank you!

[Kevindk9]

I've been using and learning about the UD3 for awhile now, and I just finished a smaller QCW coil and it works great.  I would like to play music on them both at the same time, but im having a hard time figuring out how to do that. 

Im controlling the UD3 with a HC-06 bluetooth module which acts like a serial com port. I would like to keep the whole thing wireless if its possible.

Also, I have a few suggestions for features that could be added to the Teslaterm app. It would be nice to have the lead time as an adjustable slider to make tuning faster. Im getting a random bug where changing the lead time will stop transient mode from working when you try starting it again. "reset" fixes the problem but it seems to be a 1 in 5 chance it happens when I change the lead time.

It would also be nice to have a "one shot" button, a tr/qcw mode switch, and a start/stop button instead of a dropdown menu.

Is there a way to change the scale of the telemetry readout? I have my maximum current set to 300a, but the graph seems to default to 327a/division.

I've tried to make some changes to the teslaterm source code but I'm not quite sure how to compile it.

[zix]

Im getting a random bug where changing the lead time will stop transient mode from working when you try starting it again. "reset" fixes the problem but it seems to be a 1 in 5 chance it happens when I change the lead time.

I've seen the same thing.  I think it is because there is a resource leak in initialize_interrupter() which gets called when lead_time is changed.  After about 5 times the system runs out of dma descriptors and some of the dma channels become disabled which stops the interrupter.  I fixed it in my own copy and it is working for me.  If Netzpfuscher agrees I will make a pull request for my changes.

[Netzpfuscher]

  I would like to play music on them both at the same time, but im having a hard time figuring out how to do that.

Teslaterm makes a MIDI RTP server. Here is a Windows client: https://www.tobias-erichsen.de/software/rtpmidi.html
You need to start multiple instances of Teslaterm (I remember you need to copy Teslaterm to a second folder or use a second computer) Then put them all into one MIDI RTP session. With the filter string in the UD3 you can set the channels and frequency you want to play on that coil.

I've tried to make some changes to the teslaterm source code but I'm not quite sure how to compile it.

You can execute it directly with electron no need to compile. Sadly our build system in github is broken because of some packages missing.
To start if you have npm:
npm run-script install-electron
npm run-script start-electron

For the headless version (with webserver):
npm run-script install-node
npm run-script start-node

Is there a way to change the scale of the telemetry readout? I have my maximum current set to 300a, but the graph seems to default to 327a/division.

It's calculated with max measurable current... The values are not in Teslaterm, the UD3 say Teslaterm how to configure every chart and gauge. So needs changes in the UD3... Please show what you mean, I'm not 100% sure.

[zix]

The PSoC chip used in the UD3 is just about impossible to find due to the chip shortage.  One solution is to desolder the cy8c5868axi-lp032 chip from a SparkFun FreeSoC dev board using a hot air rework station.  You can currently buy these dev boards on eBay for about $25.  That is the same price as the chip itself (if you can find one for sale).  Here is the link to the ebay board I used in case it helps anyone: https://www.ebay.com/itm/134041232376?ViewItem=&item=134041232376

[Hydron]

Got a UD3 all boxed up ready to go in my suitcase, will be re-united with my big coil in NZ next week




Will report back on how it goes - last time I used it with this coil was 2019 and it was a bit of a rush and without any case etc, plus lead-time was broken at that point (I still can't quite figure out how that part works other than the initial value offsetting the expected first period loaded into the PWM generator).

Am having to use serial-over-fibre control at this point as I don't have a fibrenet board built into this - it does actually have an ESP32 module inside (and an RF window on the end-plate for it) but apparently this is currently not working? I'll have a look at the ESP32 code but SW is not my strong suit sadly. The ESP32 is certainly the cheapest way to get galvanically isolated comms!

[zix]

That is a very nice looking enclosure!

BTW, we updated the documentation on the UD3 Wiki.  See https://github.com/Netzpfuscher/UD3/wiki

[Netzpfuscher]

Looks cool 

The ESP32 project is not working anymore. Since then we changed so many things, we needed to include a timecode in the frames and changed the packet sequence number from 8 to 32 bit. But with the Fibernet we simplified the network code. It's as simple a encapsulating the protocol frames into a UDP packet. I think I can port it to the ESP32 in short time, but need to find a bit of time to do it.

[Hydron]

Found the updates to the wiki earlier today - thanks! Would have been most handy about 3 weeks ago when I was bringing it up, but I managed with the basic info that was there at the time.

Looking through the info, I have a couple of questions about the Vsense/Isense connections:
- when using the "battery voltage" connection to look at mains voltage, other than a bridge rectifier does this need a capacitor to smooth out the resulting 100/120Hz signal, or is this filtered out in SW?
- where should the DC current sensor be placed? between the mains rectifier and the big bus capacitors, or between these capacitors and the rest of the bridge?

[Netzpfuscher]

I thought I had put a RMS filter in the voltage too, but it isn't. So actually you need a capacitor. Only the current signal has a RMS filter. I think I will add RMS to the voltage too.

The DC current sensor needs to be between rectifier and bus capacitor.


Edit:
Added RMS for the voltage. So theoretically no capacitor necessary.

https://github.com/Netzpfuscher/UD3/commit/a4ba5f52c30d6a502a41842188e9969980612b06

[TMaxElectronics]

Netzpfuscher and me finally got some high power run time on our UD3s, playing some SIDs at our show at the Extraschicht:

We had some issues with the synth filter though, so both small coils play the same tunes, we initially planned to split the notes between the three coils we had, with the other problem being a slight... lets just say "issue" with the third, 3.5m coil

[futurist]

Magic smoke caught in IGBT goop

[Mads Barnkob]

Very nice how and the SIDs are just extremely lovely, wonderful chip sound

The IGBT explosion, might deserve its own thread about the coil in question? Certainly must be a driver issue or pounding it too hard? Water cooling and everything and you still manage to blow of EVERY single die, that is impressive in itself!

[TMaxElectronics]

Magic smoke caught in IGBT goop

Hmm maybe we could pump it back in

The IGBT explosion, might deserve its own thread about the coil in question?

The big coil is from the guy that works at the HV Lab we test our coils at, not mine so idk if I'm qualified to make a post about it. I only helped installing and setting up the UD3

I suspect the problem that killed the IGBTs was just poor HF earth routing. We tested it inside for a long time and had no problems, but we had a very good earth there. When we went to the museum we only earthed the coil with quite a long cable, which caused the UD3 to crash and reset everytime we had a groundstrike and ultimately die (we had to replace the psoc for it on site ). After that the resonant circuit struggled to even reach 1000A in 400us (whereas it easily went to 2000A in half that time before), so something was likely already damaged by that point. Interestingly enough we didn't see excessive heat dissipation in the bridge, which makes me suspect an issue with switch timing but thats just a gut feeling. We didn't have the equipment there to verify everything and just risked a full power run... which didn't go well I wasn't at the controls at the time but I feel like the bang happened almost immediately after we started a song too, when the IGBTs were still cold.

The current limit was set at 1500A with the current peaking at a little under 2000A which is actually within the datasheet ratings of the IGBTs
We used two of those: https://www.infineon.com/dgdl/Infineon-FS450R17OE4-DS-v03_00-EN.pdf?fileId=db3a304336797ff90136c09b45906f3b
all three half bridges in each module were paralleled so I wouldn't be too sure about current balancing and thus the actual maximum current rating in that configuration, but I'm almost certain that the current we drove wasn't pushing the IGBTs.

[pache11]

Anyone have any CY8CKIT-059?  Looks to be about as rare as hen's teeth now.

[Mike]

Anyone have any CY8CKIT-059?  Looks to be about as rare as hen's teeth now.

You can get them from AliExpress, but the price is eye-watering. There's also the "legitimacy" question. I'd expect at least the PSOC itself is probably genuine, even if it's recycled and soldered on a new board.

So far as the more traditional distributors, it's not looking good for the next 12 months at least.

[Mads Barnkob]

Anyone have any CY8CKIT-059?  Looks to be about as rare as hen's teeth now.

You can get them from AliExpress, but the price is eye-watering. There's also the "legitimacy" question. I'd expect at least the PSOC itself is probably genuine, even if it's recycled and soldered on a new board.

So far as the more traditional distributors, it's not looking good for the next 12 months at least.

Is there a thing as virtual ICs? Like there is Virtual machines for computers. As times are right now, very few designs can be replicated by others or even by yourself a couple of years later

[dbach]

I have quite a few Psoc 5 dev boards that im not using (3 or 4 of them)

happy to sell them to someone here.

[pache11]

Are the boards CY8CKIT-059?  Look specifically for a build.   Quote me a price.  Thanks for a quick response!