Does anybody have experience with this kind of capacitors?Are they any good for a MMC?

Another thing: in series connection the overall pulse resistance(dVdT) of the MMC gets multiplied by the amount of series capacitors? In this case the voltage gets shared by the series capacitors and they see a smaller voltage rise across them,so 1.8kV/us capacitors would already be good with 4 in series at 6kV across the MMC?I just saw Futurist's DRSSTC1 and he used C4BS capacitors,which have around 1kV/us rating if I remember right and they worked fine for him...

I doubt old PIO capacitors will last long in a DRSSTC, unless it is some special Russian secret cold war indestructible super caps As mentioned, their losses at high frequency is most likely very bad, but check their datasheet if you can find one.

I think you are mistaken about the AC voltage rating needed for a resonant capacitor vs. dV/dt, dV/dt is simply a value derived from capacitance and the peak current it is rated to pass through it, and the pulse capacitors we use are almost always high peak current specced or low capacitance, so there is rarely a case of dV/dt being broken.

I did some more calculations and choose the KEMET R76TR31004030J. 4 in series, 8 in parallel gives 0.2uF at 6400V,so around 850A peak. They are cheap and common so I can update the MMC in the future if needed.Their RMS current rating is just under 10A around 100kHz.This gives around IRMS=80A for 8 in parallel.

I calculated a maximum of 100 bps at 800us for the 80A IRMS. What do you think about this choice?

After waiting a week for the components and another few days of work, I could finally make some better tests.It looks like with longer pulses at lower peak currents I get good results,just like with short pulses at higher currents.I tested midi notes up to 300A peak and transient up to 500 and the midi notes can already destroy 4A fuses.I'm a bit worried about huge sparks,because I blew up my SSTC2 bridge yesterday. I was running it from mains ground and cranked up the power to maximum.A secondary - primary flashover killed it...Stupid!...RIP 2pcs HGTG30N60A4D...

The MMC is the same that I planned, 0.2uF 6400V KEMET R76 series, around 80A IRMS. They are working,but didn't make any measurements yet.I painted the metal enclosure blue,just like the MMC and added plenty of screw terminals.

For higher power running I want to make sure that it won't kill the bridge. I don't have strike rail and bus negative to earth capacitor.Adding these should hopefully save the bridge from flashovers. Another thing that might result in a fail is the IGBT losses.I have to calculate this...

The sparks already scary to me, I have to get used to them. One bigger spark from the video, spark length is as much as secondary + topload length:

I posted here quite a while ago. Not because I didn't want, but I made small changes and I needed time. Some of the changes I made:-cut the primary at 5.75 turns and added a strike rail-added a 0.22uF 1000V MKT capacitor from the heatsink to the bus negative-paralleled two 50A 1000V full bridge rectifiers after the single one blew up-added a 10A circuit breaker and a 7.5kW contactor-finished the UD3 by using the bus voltage sensing circuit and installing the LEDs on the metal enclosure

The parts used up all of the space under the coil, so wires are everywhere.I wanted to upgrade the 30A current sensor to a 50A, but either it was factory defective or I overheated it while soldering and it doesn't work.

The cheapest communication was bluetooth for me, the android app can already control the UD3 without being able to play MIDI files. For that I got myself a USB-BLE dongle and tried to use it as a master device to connect to the slave HM-10 module on the UD3's side. Sadly the dongle doesn't want to automatically connect to the HM-10 after trying many settings...

I made a test a few minutes ago. Plenty of things confirmed to work, like temperature sensing, fan control and internal fuse.After around 10 minutes of not continous run I smelled something melting or burning and turned the coil off, but I couldn't see any problems so that might be just coming from the neighbourhood.

The goal was to achieve sparks that can hit the floor. The breakout point is 110cm over it and at 800A, 800us I was hoping this to be possible. For some reason no overcurrent occours over 600A which should be displayed by the LED. Can something prevent the primary current from ringing up, or the UD3 goes too early in freewheeling/limits ths current? Maybe because my primary frequency is tuned too low(Fpri=120kHz Fsec=135kHz)?

After doing many measurements, the only thing I can think of that limits the spark length is inadequate tuning. The secondary Fres is 136kHz with the "bottom FG, scope antenna" measurement. The primary is a bit more complicated. Right now the driving frequency is 120kHz which is the lower pole. I suppose this is a bit too much undertuned and some heavy spark loading would be required to lower the secondary's frequency to this level. The upper pole is already over the secondary's frequency, so basically the secondary is between the primary poles.Steve Ward mentioned in his DRSSTC log book:

Quote

I found something interesting with the tuning of this coil now. Originally the primary was tuned somewhere in the middle of the 2 modes. This worked well with very high coupling as normal, but I did see some limit to my spark length (about 24" max). I really liked the idea of tuning to the lower pole, because when the coil starts making streamers nearly 3X its length, its going to detune considerably! So I started tuning the primary lower. Instantly I noticed the primary current had a much nicer linear ring up, instead of the choppy looking current ring up when tuned in the middle. I had to reduce my coupling to about .15-.2 because arcs began racing up the side of the secondary, and jumping to the primary nearby. When tuned lower, it took more input voltage to get it to produce real streamers, but once streamers start forming, the result is like an explosion of streamers! Looking at the primary current, its forming a notch at the end of the burst (current rises and then returns back to 0). If I turned thepower even higher, a second "burst" began to form after the notch. The notch occurs at about 18 cycles or so... and I'm not sure what causes it, but I think its a sign that the coils need to be tuned better. So I slapped on a turn of 12 awg at the base of my primary to get more tuning room. Now it takes even higher input voltage (about 60-70% input) but the resulting sparks are even longer! Interestingly, primary current increases with voltage input, until long streamers are formed, then the primary current doesn't increase any more at all! Right now I'm running about 420A. But even still, as I'm getting about 30" sparks, the notch is occurring again at the end of the burst... need more primary L! Its easy to see the improvement that adding more primary inductance has. I'm tuned at least 1.5 turns lower than before (the coil only had 5 turns to start with!),obviously these streamers really do detune things a lot.

One other benefit I see to running at the lower pole is that you are reducing switching losses. You now have fewer RF cycles per burst length, and also, any delays in the gate driver become less significant as each half-cycle is now longer. I think my primary circuit is running at about 170khz, the secondary Fr is something like 220khz. Hey, but it works great so far!

It looks like the UD3 locks to the pole where the current is the highest. As I decrease the primary turns, so the frequency goes up, the upper pole starts to overtake which is already higher than the secondary's frequency.

The problem is that I see no overcurrent over 400A, which I think is caused by the weak energy transfer caused by too much undertuning. What am I doing wrong here?

Have you set a new start_freq? The autotune writes nothing to the configuration.By the way I see a high current in the tune graph. During the tune the IGBTs are switching hard. You should consider this. Do not run this with high bus voltage. I think I add a interlock in a future revision.

The start_freq is 136kHz and 3 cycles. I measured between the 3rd and 4th cycles, but the following cycles seems to be at the same frequency. Shouldn't primary feedback take over and switch at the tune_p result?

After 3 months, I'm back here again. The goal is to rebuild many things to improve on the previous results. A few of these things:-each brick on a different heatsink with 2 fans-increase bus capacitance to 2*4600uF-PC interface with TOSLINK

This isn't the lowest inductance way to design a bridge, but with 1200V bricks running at <385V bus (assumption based on the caps I can see) you have a lot of headroom for any spikes etc caused by stray inductance.

As for TOSLINK, be aware that the receivers may be AC coupled, i.e. a standard interrupter signal will likely not work with them. This is unfortunate given the price and availability vs expensive industrial fibre optics, but could potentially be worked around with a fancier driver and controller if required.

I started putting everything together. One thing that every day comes into my mind is the inverter to primary connector. Until now I used 3 5x20mm fuse socket pieces. I wonder what else can be used for better connection?

As for TOSLINK, be aware that the receivers may be AC coupled, i.e. a standard interrupter signal will likely not work with them. This is unfortunate given the price and availability vs expensive industrial fibre optics, but could potentially be worked around with a fancier driver and controller if required.

I want to use TOSLINK as serial communication with the UD3 at high speed. I built a small box to convert USB to serial with a FT232 module, then to TOSLINK. On the UD3 side I added a small board with the TOSLINK transmitter and receiver.

Previously I rarely got a few incorrect characters using an arduino for testing instead of the UD3. Now with the UD3, the serial is pretty bad. Only at 1Mbps are some good characters. Does anybody have an idea how could I improve on this?

@NetzpfuscherCan the min protocol fix this? Also when I run the UD3-node windows executable the command line briefly shows up and says "mDNS discovery is not available". Am I missing something?

1Mbps:

500Kbps:

EDIT:While testing with an arduino again, I found out that the serial signal pulses often go into a high frequency noise on the receiver side. What is causing this?

As Hydron says the Toslink receivers are AC coupled. Some may be more sensitive than others, my Sharp receivers do a great job also at very low baudrates.

I think the MIN protocol should solve the problem. If a connection over MIN is established there is a constant stream of data from the UD3 to the PC and back. That should be lot better for the AC coupling in the receiver. If some packages are corrupted they get simply re transmitted by the protocol. You can observe the link quality with the "minstat" command.

The mDNS warning is "normal" there is a problem in the MIDI RTP lib. But this only affects the auto discovery feature. MIDI RTP works fine if you specify the IP and port manually on the PC side.

If you run the UD3-Node correct it shouldn't exit automatically. Have you run it over the command line? It throws a warning whats missing.

Thanks. I tried to run it from cmd, but without the -c argument. Now it seems to work.

This is what I receive from the minstat command at 1Mbps. While typing in the commands many characters are still incorrect. But using the sliders the values changes nicely if I see it right. Playing midi should be this good, right.Also, should I enable watchdog and min at the same time?

EDIT:After reconnecting a few times the measurements appeared on the monitor, but the dropped frames increased. I bet they are too much now...

The dropped frames are not a problem of the noise. Some dropped Frames are "normal"

For explanation:-Dropped frames-This are frames which can't added to the transmit queue. If the PC disconnects without to inform the UD3 the UD3 try to transmit telemetry frames but the PC did not ACK these, so the queue runs full. If the connection is more than 1s idle the UD3 closes the connection.-Resets received-If the other side is not responding, a reset is send to clear all queues and reset the sequence number.-Spurious acks-If the other side ACKs a frame which is not in the right order or is not in the transmit window-Sequence mismatch drop-The UD3 receives a frame which is not expected. Let's say the UD3 expected a frame with the sequence numer 150 and gets a frame with 152 the UD3 knows that two frames are missing-Max frames in buffer-The high watermark of the transmit queue-CRC errors-This are the frames which are corrupted during transmission <-- This is the counter which gives you a hint of the link quality

Yes you can activate the watchdog. UD3-node sends a watchdog reset every 100ms. But I have seen that you using a old version on the UD3, I think for this version 100ms is to slow. You can update if you want.

Have you tried lower baudrates? I use 500kBaud.

Can you check for the high frequency noise? If it is still there you can try to low pass filter the 5V to the receiver with a RC or LC filter. If this all doesn't help, I can send you a pair of my Toslink receivers. I bought a 50 pcs bag (0,15€ a piece)

I tried 500Kbps too with the same results. Right now the the problem is the following: correct data is sent over TOSLINK from the UD3 to the receiver, the bits are all OK, but about 20us after the stop bit the receiver goes low for some reason with a small noise burst. In theory when the transmitter's signal is high, there is light and the receiver's output should be low. Shouldn't the AC coupling prevent this?

I wonder what the shipping costs to Romania from you. I would definitely like to buy plenty of those, maybe for future coils too.

EDIT:By connecting the UD3's TX pin to the FT232's RX pin with a wire and leaving the other connection over TOSLINK, I get perfect (I would say) communication. Probably the TOSLINK receiver is bad on the FT232 side.

Another option to avoid the expensive DC coupled fibre transcievers and the hard-to-use AC coupled TOSLINK would be to grab an ESP32 module and use the WiFi mode than is built into the UD3 firmware. I managed to get it working on my board, though it did take a bit of fiddling and work to get the environment running, code building etc (and also note that the ESP32 is _not_ 5V tolerant).

If you can find some, there's a part called IF-D92. It's just a phototransistor in a housing for 1mm plastic fiber. That's what my DRSSTC uses. I've also used TOSLINK couplers with one end partially drilled out and a 3mm photodiode glued in the hole.