Sunday 9 November 2014

Thales e-Security - Programmers are strange..

This one can probably be filed under 'do they ever give up?' or 'Can I ever win?'

In my day-job I am working with this Thales cryptographic security module - the nCipher netHSM.

The application normally runs as a daemon on Linux so I didn't notice this message until I started it under the debugger.

Basically it constantly issues this message

2014-11-09 22:59:06 [16458] t00c71fc6ff7f0000: pkcs11-sam: 000008d2 Warning: key is considered weak; set CKNFAST_OVERRIDE_SECURITY_ASSURANCES=weak_des to allow

Now I completely agree with this warning in the sense that I wouldn't use DES for anything security critical either. The thing is we are just using the HSM as a fast asymmetric (RSA) key generator and the quickest way to get the private key off the device (and avoid the key policing woe) is to encrypt it and then decrypt it again. For whatever reason the guy who wrote this chose DES as the algorithm so I get this message.

So I set the environment variable and ran it again. It still keeps spitting out a message but this time it says:

t00c71fc6ff7f0000: pkcs11-sam: 000008d1 Warning: key considered adequate because CKNFAST_OVERRIDE_SECURITY_ASSURANCES=weak_des set

Is there any way to make it actually STFU?


Monday 3 November 2014

Constant Current Dummy Load

What is it?


The internet (and places like the EEVBlog forum) are full of implementations of some variant of this basic MOSFET based constant current dummy load.

It's pretty simple - The positive input terminal of the op amp is connected to a voltage reference and the negative input is connected to a sense resistor. The opamp turns on the MOSFET until enough current flows in the resistor so the voltage matches the reference voltage.

In the example above I am putting a 1kHz, 200mV square wave as the reference which should generate 200mA current at peak.

The current should be constant regardless of the load voltage. MOSFETs can handle large amounts of power and have a very low resistance when saturated (less than an ohm). The circuit looks pretty simple over all. What could go wrong? We'll see below!

Why Do it?

People use these types of dummy load circuit to test the performance of power supplies. For example the 1kHz signal could be used to check how long a power supply takes to recover when the load is varied sharply.

I wonder about the value of this since this is essentially a closed-loop control circuit trying to keep the current constant while connected to another closed-loop control circuit trying to keep the voltage constant. Will you get any meaningful results from this or just some weird interactions between to control loops? I don't know and I'm not sure I would risk it. Certainly it would be a handy way of checking the voltage doesn't drift under load or to check the thermal design etc.

I do want to build a linear bench power supply at some point though and I thought this was an interesting stepping stone towards that goal. Not so much as a test tool but because ultimately regulating the output of the supply is going to be done with a closed look control circuit something like this.

Real vs Simulated

I think the first one of these I saw was put together by Dave Jones on EEVBlog here. Lots of people tried to replicate his design (which is identical to the circuit above) and found it didn't work. The circuit would oscillate at even relatively low current loads.

When I simulated the circuit above, the output was exactly what I expected which is that the voltage on the resistor would switch from zero to 200mV and back to zero.


So then I went ahead and built this up on a breadboard and connected in a 1kHz 200mV signal to the inverting input and guess what? It oscillates! A lot!

So why is it so different to what I simulated? One explanation is that the leads between the power supply and the circuit have some inductance. Lets try adding 1.5uH of inductance and say 0.1 ohms of resistance and see what happens to the simulation. Here is the circuit:

And here is the waveform at R1. The signal on the scope is a tiny bit worse (the oscillations have a slightly higher magnitude) but it is close.


Modeling the Problem

To make this work better we first have to understand what is going on. The problem is the control loop is causing the output to oscillate so we have to fix the control loop. But how do we model the control loop?

One way of figuring out how to stabilise the control loop is to model the open-loop gain of the circuit and then ensure it has at least a significant amount of phase margin. See here. What this means is that where the gain crosses 0dB (which corresponds to a gain of 1) you don't want the phase to be negative. If it is then this means the output is going to be the opposite phase to the input which causes the circuit to oscillate.

The tricky part is the open loop gain needs to be modeled which means you have to break the control loop and model the transfer function. The problem with this is that when you break the control loop you break the DC conditions also and then the results aren't valid.

The way you do this in LTspice is you:

  1. Zero out the inputs - we don't want the inputs to perturb our result.
  2. Cut the control loop somewhere and place a voltage source in the loop. Set the voltage source to have an AC value of 1.
  3. Label the nodes either side of the AC source as 'fb' and 'input'
  4. Run an AC analysis and plot the value of v(fb)/v(input).
In my case I changed the voltage source going to the positive terminal to be a fixed 100mV and added the AC source to the loop. if I change the 100mV it effectively will show me the stability at different output loads.


Here is the AC analysis of v(fb)/v(input). As you can see the phase margin is -15 degrees so it makes sense that the circuit oscillates.


Fixing it

So we can see the weirdness at around 1MHz - 10MHz caused by the MOSFET capacitance and the inductance on the output. If we roll off the gain a bit faster maybe the 0dB point will occur while we still have some positive phase margin. So I add a 10n capacitor between the output terminal of the op amp and the negative input and now it looks like this.


That certainly brought the gain down but we still only have 5 degrees of phase margin. If I switch back to my transient response model the output when a 1kHz square wave is applied looks like this

Some pretty serious overshoot but otherwise it looks a lot better. If I make the same change to the real circuit it looks like this:

Still a fare bit of ringing but it looks better.

Now because the MOSFET is effectively a capacitive load for the opamp, I tried adding a resistors between the opamp output and the MOSFET gate. I fiddled with different values but no matter what I couldn't increase the phase margin. Then I tried also adding a feedback resistor between the negative terminal and the 1ohm sense resistor and this cleaned it up a lot. The final circuit looks like this:


The AC analysis looks like this - much better!
And finally it looks like this on the scope when I breadboarded it
Ok so the corners are not as square as my simulation but that doesn't look bad!

Sunday 2 November 2014

Adding components not Supported by LTspice IV

I've been messing around with LTspice IV which is a free circuit simulator from Linear Technology. It is essentially the SPICE circuit simulator (which has been around forever) with a basic GUI including a graph display tool and a means of drawing circuits.

It comes with a broad selection of Linear Technology components as well as a selection of other common components.

Annoyingly it doesn't include some common op amps from other manufacturers (such as a 741 or a LM324 etc). If you want to use cheap components like these it makes simulating harder.

I figured out you can do it however.

I downloaded a SPICE simulation of the LM324 from the Texas Instruments web site. The process for adding a component is


  1. Copy the component into the same directory as your circuit files (in my case this was a file called LM32.lib)
  2. Hit the .op button to add a spice directive and say
    .include LM324.lib
  3. Choose a generic component from the library - in my case this was opamp2 
  4. Right click the component, modify the 'value' parameter to have the same name as the name of the model in the file you included. In my case this was LM324. Make sure the prefix is X (not sure why this matters).
Now when you simulate your circuit it will use the model you included.

There is another way to do this where you can add your component to the library but I found that then you have to draw your own circuit symbol. It seems easier to me if you just use a generic component and specify the model.