DRSSTC Driver Logic

[Laci]

I start this topic to understand the logic part of the universal DRSSTC drivers.The idea is to build the well known UD1.3 then upgrade it with digital phase lead control and freeweeling current limiter.In addition I'd like to make a bluetooth or ethernet interrupter.

The core of my design is a CY8CKIT-059 prototyping kit.

So far my driver looks similar to the UD1.3,expect one little bug:overcurrent has on direct effect on the output.Basically whatever I do at the CLR pin(13)it doesn't change the output.Only interrupter input at CLK pin(11) changes it,while I thought a logic high at CLR(overcurrent)should immediately turn off the drive at least for the set time constant(100us in my case and in case of the UD2.7).Is my theory right and my schematic wrong?
I think my code has no problems as it's really simple,just starting the DACs,comparators and the interrupt for the time constant.

My driver:



The internal of FliPC,which I made as a 74HC74 equivalent:



...and the UD1.3:

[sjsimmo]

Hi Laci, 

Not sure if this is what's causing your problem, but your FliPC looks like it would update its output whenever the CLK pin is high. Whereas the 74HC74 is edge triggered, meaning that it will only update as the CLK pin changes from a low signal to a high signal. As for CLR signals, a logical LOW on the CLR' pin should cause the flip-flop to output 0 instantaneously (since the PRE/CLR inputs are inverted for both your schematic and the 74HC74).

Generally the OCD should actually disable the driver output on the next ZCS point (the same effect as the interrupter turning off), otherwise the IGBT would have to switch with the full peak current. I think that's what your circuit would do too, if the flip-flops were edge triggered.

Hope this helps, 
-sjsimmo

[Mads Barnkob]

Is there a reason why you did not use a standard D Flip Flop w/ Enable like this? https://www.cypress.com/documentation/component-datasheets/d-flip-flop-wenable

Keep in mind that some Set-Reset function blocks have different priorities, most has Reset prioritized higher than Set.

While looking for this flip-flip, I came across this problem with edge triggered signals that might be a help to you: https://community.cypress.com/message/2120#2120

[Netzpfuscher]

What's the reason not to use the UD3? The logic is tested and I had no IGBT failures since I use the UD3. With a simple modification to the logic you can add a simple external interrupter, if you want this.

[Teravolt]

The only purpace of the flip flop is to interupt your on time from the fiber reciever. It will stop the primary current from going higher than your mosfets can handle. the OC LED should show this on the board

[Laci]

Hi Laci, 

Not sure if this is what's causing your problem, but your FliPC looks like it would update its output whenever the CLK pin is high. Whereas the 74HC74 is edge triggered, meaning that it will only update as the CLK pin changes from a low signal to a high signal. As for CLR signals, a logical LOW on the CLR' pin should cause the flip-flop to output 0 instantaneously (since the PRE/CLR inputs are inverted for both your schematic and the 74HC74).

Generally the OCD should actually disable the driver output on the next ZCS point (the same effect as the interrupter turning off), otherwise the IGBT would have to switch with the full peak current. I think that's what your circuit would do too, if the flip-flops were edge triggered.

Hope this helps, 
-sjsimmo

Thanks,sjsimmo!I'll read a few more times your suggestions and hopefully realise what's wrong with my logic when I'll have some time.

Is there a reason why you did not use a standard D Flip Flop w/ Enable like this? https://www.cypress.com/documentation/component-datasheets/d-flip-flop-wenable

Keep in mind that some Set-Reset function blocks have different priorities, most has Reset prioritized higher than Set.

While looking for this flip-flip, I came across this problem with edge triggered signals that might be a help to you: https://community.cypress.com/message/2120#2120

Thanks,Mads.I saw that D flip flop with enable but I only had a day to work with my design,not much time to understand every component's logic.Also that one has 3 inputs,while a 74HC74 has 4.Do you know about some additional logic to make it the same?

What's the reason not to use the UD3? The logic is tested and I had no IGBT failures since I use the UD3. With a simple modification to the logic you can add a simple external interrupter, if you want this.

Netzpfuscher,I really like the multifunctionality of your driver,but I didn't find the settings and it seemed far too complex to modify it so I gave up and started building a simpler,while also learning in PSoC Creator.I tried to follow the instructions on Steve's spec sheet,however I couldn't find the variables.
If I'm wrong please correct me or tell the settings file location.

The only purpace of the flip flop is to interupt your on time from the fiber reciever. It will stop the primary current from going higher than your mosfets can handle. the OC LED should show this on the board

Teravolt,I can hardly understand what you mean.The OCD comparator is connected to the CLR input of the flip flop,so it should have some effect on it.I mean the OC LED does light up when an overcurrent occours so the Q output in case of an overcurrent is always low,right?!

[sjsimmo]

You could also use the standard D Flip Flop without enable (instead of the D flip flop w/ enable): https://www.cypress.com/documentation/component-datasheets/d-flip-flop
It can be configured to have both PRE and reset (CLR) inputs (see datasheet linked).

Just note that you'll have to add inverters to the PRE and CLR inputs, to make it logically identical to the 74hc74 (which has the PRE and CLR inputs inverted).

[Netzpfuscher]

I think I must write a getting started in the next days^^
The software side of the UD3 is a nearly complete rewrite, the spec sheet from steve is obsolete.

1. Compile
2. Flash
3. Connect micro USB
4. Open putty with the new USB COM-port
5. type help for a list of commands or get for list of parameters
6. set the start freq with "set start_freq 65.6" (in kHz)
7. Configure the CT (windings, OCD, Shunt resistor)
8. save everything with "eeprom save"
9. connect a midi player to the USB Midi port
10. play a midi and type in the pulsewidth "pw 50" (µs)

[Laci]

I think I must write a getting started in the next days^^
The software side of the UD3 is a nearly complete rewrite, the spec sheet from steve is obsolete.

1. Compile
2. Flash
3. Connect micro USB
4. Open putty with the new USB COM-port
5. type help for a list of commands or get for list of parameters
6. set the start freq with "set start_freq 65.6" (in kHz)
7. Configure the CT (windings, OCD, Shunt resistor)
8. save everything with "eeprom save"
9. connect a midi player to the USB Midi port
10. play a midi and type in the pulsewidth "pw 50" (µs)

Could you tell me the settings in putty?I get infinite cycle putting out random characters on serial.

[Netzpfuscher]

The settings are not relevant. You can use any baudrate, it is ignored and the communication is at max USB speed.
Make sure you are not connected to the KitProg COM-Port of the Debugger. It only works over the Micro USB at the right side.

Have you checked out the latest version in the git (Mar 11, 2019)?

If you are connected and type "cls" then you should see:


If you type "get" you should see:


https://github.com/Netzpfuscher/UD3/wiki/Commands

[Laci]

Thank you,it works!I tried previously to connect it via micro usb,but didn't see the COM changing. 
I'm going to test the driver in a few days and try to include the bluetooth module in your design,so probably some questions incoming.

[Netzpfuscher]

If it is a Bluetooth to Serial module (Warning the psoc puts out 5V at the UART not 3,3V) you can connect it without modifications.

TX from Bluetooth to Pin 3.4 of the Psoc
RX from Bluetooth to Pin 3.0 of the Psoc

In the configuration set min_enable to 0.

If the Bluetooth Module not supports 2Mbit on Serial, you must change the baudrate in psoc creator.

Change the clock to internal


Set the Baudrate


Delete the clock connection


The schematic for the external circuit. The minimum you need is the CT circuit and the two gatedrives. The Pinout in the Schematic is for the TQFP Version it is not compatible with the dev Kit. Use the pinout from psoc creator!
Schematic.pdf

[Laci]

Thanks to your detailed instructions I managed to make your UD3 bluetooth controlled via a bluetooth - serial android app.The next thing I'd like to do is to make it interrupted from the same bluetooth module.Is this possible?I plan to make an app which can change the settings and work as an interrupter.So far I couldn't connect to my fake HM-10 BLE4.0 module from any simple app I made...

[Netzpfuscher]

You can use the internal interrupter of the UD3.

"tr start" or "tr stop" start the classic interrupter
"pw xxx" or "pwd xxx" for the on and offtime
"bon xxx" or "boff xxx" for the burst mode

if you want MIDI just send the MIDI notes over the same serial connection.

Or you can use TeslaTerm. It is still in heavy development, but it works.
https://github.com/Netzpfuscher/Teslaterm

to start it install nw.js (https://nwjs.io/) and make a shortcut like this: "C:\nwjs\nw.exe c:\git\teslaterm"

[Laci]

So I made a basic UD3 controller application which sends commands over bluetooth low energy to a target UD3 device.While testing I connected the BLE module to an arduino nano and used the serial monitor of arduino IDE and everything worked.After connecting the module to the PSoC dev.kit the received data isn't what I wanted.When the app sends a command ex. get offtime the received data isn't something like offtime=2.Instead,I receive the same commands that were sent four times,then it glitches and receives the same command until the dev.kit gets restarted.Is this how it's supposed to work and the settings can only be modified over PC connection and only the interrupter works this way?

[Netzpfuscher]

I don't really understand the problem.
Have you terminated the command with a CR LF?
The UD3 has a Terminal like SSH. It echoes every char back, autocompletion with tab,...
You can take a look in the UD3 Terminal "Teslaterm" how everything works. There is also a binary mode for the settings and the telemetry.

https://github.com/Netzpfuscher/Teslaterm

The offtime parameter is not the normal offtime. It is the minimal offtime between two midi note pulses. Polyphonic notes are not simply mixed with a or.

You can change every parameter or configuration over the terminal. It doesn't matter over which connection.

[Laci]

My problem is this:when I press a configuration button from the list in the app,it sends its name to the UD3 in form of a command(ex.when I press the offtime button it sends the get offtime command).After pressing the button the app waits for a serial response from the UD3.The received data should be the value of the required configuration and it gets monitored in a text box(2nd picture,to the left of the SET button).However this data isn't what it's supposed to be,on the 2nd picture you can see that it's "get offtime" not the value of the offtime.It should be something like "offtime=2".

What is CR LF?Not terminating the command like you said might explain why the commands aren't getting registered and I get incorrect response.

Another question:can I test the UD3 with a function generator?If yes the only thing I should do is connect the FG(how?),start the interrupter with tr start,set pw and pwd and scope the GD outputs?

[Netzpfuscher]

CR LF is what you get, if you press enter. Without enter the command is not processed. That you get the same back what you send is because of the echo, without that the user will not see what he is typing.
If you send a string like "get offtime\r" you should get a response. But this response should be like "get offtime\r\nofftime=2" because auf the echo. (\r is carriage return and \n is line feed)
I haven't yet connected a function generator directly to the dev board, the signal is differential. I must take a look at the schematic to give you a proper answer.

Edit:
With the command "config_get" you can dump the complete configuration to the terminal. I've documented the protocol here: https://github.com/Netzpfuscher/UD3/wiki/Telemetry-protocol
After you send "config_get" you get a bunch of telegrams:

1 byte start: 0xFF
1 byte length
1 byte type: TT_CONFIG_GET
x bytes help text
1 byte: ';'
x bytes values (all values as string): [param name];[value];[type];[size];[min];[max]

and after the last config telegram you get:
1 byte start: 0xFF
1 byte length
1 byte type: TT_CONFIG_GET
x bytes: "NULL;NULL"

[Laci]

I completed my UD3 BLE(Bluetooth Low Energy)Controller Application.The only reason to use a low energy module was that I had one available.
The application can modify the configuration and parameters of the UD3 and work as an interrupter via serial commands.It is good to make small modifications in the settings,but does not contain all of the UD3 features!
The app is not tested with a working Tesla coil yet.See attachments for screenshots about the app.
If anyone is more interested in the app,feel free to send me a message or reply in this topic.

Thanks Netzpfuscher for all the help and the UD3!

The used Bluetooth 4.0 BLE Module:

[Laci]

While building the hardware I found some new questions:
-Feedback and OC comes from the same CT?
-Can I swap around the pins in PSoC without ruining other stuff,like swap GD1A and GD2A with Relay1 and Relay2 to have all of the GD outputs next to eachother?

About extending the app:is the transpose command used to send a midi notes or something else?If yes,what do the values exactly mean?