I had an idea to try and make a more fancy version of those 'kill-a-watt' watt meter things - one that would interface to a PC, so you could get real-time stats. How difficult would it be? Well, you'd need some kind of voltage and current sensors and a ADC. Always someone to keep costs down, I realized that a perfectly respectable ADC can be found in the sound card (line-input) and voltage and current sensors can be constructed out of some now unnecessary pregnant plugs that have been taking up space in the kitchen drawers. Not really knowing if this would work, I set up a feasibility rig to measure voltage and knocked up some software to capture the voltage signal and perform some signal analysis. This is where the problem started, the voltage waveform captured is badly distorted. It's not clipping, and while mains voltage distortions do genuinely exist, my measurements are about 150% of the legal limit (and about 300% of a 'typical' mains supply). I think it's probably my choice of voltage transformer - as the distortion rises drastically as line voltage increases. Typical voltage here is about 240V during the day, but it'll reach up to about 250V overnight, and at that high voltage my analysis reveals distortion of about 7%. So, does anyone have any idea where the distortion is coming from (it seems to be related to line voltage - Pearson's R = 0.96)? Does this mean my crappy transformer is running into saturation? This would explain why it runs so damn hot. If so, how can I compensate for this distortion? Would a better transformer (e.g. a toroid help?) or would putting a resistor in series with the transformer be good enough (or would this add an unacceptable phase shift - remember I will in the future want to measure current as well?) i intend to achieve current sensing by connecting the secondary a mains transformer (e.g. a 240V -> 6V) in series with the load, and then measure the voltage across a 100 ohm load across the primary. A fairly bog-standard current transformer arrangement. However, there's no point in rigging this up, with the extensive safety precautions required, unless I can be sure it's going to have some hope of working. Anyway, just to whet your appetites, here's a picture:
For the high voltage, have you maybe tripped up over Vrms and Vpp? 240v RMS (mains) gives 340v peak to peak, if youre using a peak holding circuit this might mess things up. To remove the distortion I would try a low pass filter, its cheating I know, and it dosnt really remove the distortion but it will give a clean output to the soundcard. Can you post a schematic of the circuit as you have it? The picture looks good, confusing though because I cant see anything wrong with it. I hope you perservere with this, it would be very useful. Moriquendi
There isn't much of a schematic. Essentially it's just a standard 230:9 V transformer. In fact, it's just a main adaptor from a now defunct modem, that just happens to output AC, so skips the rectifier and capacitors, that you normally see. Output of the transformer then feeds a 10k:400 ohm potential divider, which is connected to line-in. That's it. No cleverness. This is the actual waveform that I'm recording: . X: 5ms/div; Y: 50V / div. Looking at some of the data I've recorded over the last couple of days, it looks as though some of the distortion is genuine (especially the 5th harmonic distortion), as at about 09:00 the amount of 5th harmonic surges to about double the overnight level, and then backs off later in the day. So it's obviously something switching on, but I haven't the faintest idea what it could be. I still think the transformer is responsible for a lot of the problems - not least because the line voltage here is 245 V or so, whereas the transformer is rated for 230 V. It's obviously struggling as it's really scorching for an otherwise unloaded transformer. In the mean time I've added a data export function: This is an example graph. The top traces are voltage. The traces represent max/mean/min voltage over a 5 second recording period. Notice the dips when I turn my Air con on, and degauss my monitor. The lower trace is line frequency.
I have to say that your plot dosn't look too bad to me, the grid does fluctuate quite a lot and the change at 9:00 might not have anything to do with you, chances are that somewhere has all their computers set to turn on at 9 or something like that so suddenly theres a much higher demand and all the transformers along the chain back to the powerstation will respond plus there will be some regulating transformers changing windings and things. With no current coming out of the secondary the transformer will not give you 9v anyway, probably more like 15v or 18v and that might also have something to do with it running at such a high temperature, if you have a suitable power resistor you could try putting it across the secondary and see if that improves things. What language are you using to write the program and access the waveform data? I would like to play around with things like this but windows seems to be very insulated from the hardware ports that access the real world. Moriquendi
Morquendi, it seems to me that Mark R is using vb.net or a .net language. In the latest framework you can access the hardware ports more easily. The graphs seem to be drawn using the System.Drawing.Graphics classes
Well, I changed the transformer and the performance is drastically improved. The waveform now looks 'nice', and the distortion figures have gone down from over 5% to below 2%. The distortion figures still perfectly mirror voltage fluctuations, at least in the short term, so I'm sure that the transformer is still contributing to them - but the numbers are drastically lower. E.g. mains voltage fluctuating from 240-245 V would take distortion from 5 to over 6% with the old transformer. With the new one it's from about 1.9 - 2.0% Unfortunately, it was a bit of a pain - at least the first transformer was ready packaged into an adaptor. The second required hacksawing an adaptor in 2, removing the rectifiers and capacitors and then gluing the thing back together. The software is written in C# (using C# express 2005). The data acquisition is with Managed DirectX v1.0 (specifically DirectSound). The various graphs are user controls I knocked up a while ago - you give them an array of data, and they'll plot it, scrolling and autoscaling as necessary - or triggering on rising/falling/zero-crossing in the case of the oscilloscope control. No directX here though - it's all system.drawing. As an aside, managed directX works quite nicely. You get reasonable access to Direct3D 9 - I've managed to build a very fast voxel rendering engine in C#. The problem is that MS are now abandoning Managed DirectX - there was a MDX v2.0 beta launched with .NET 2.0 - but the beta has now been discontinued and programs written using the beta libraries will no longer run (the entire framework has timed out). This has been superseded by XNA, which has the advantage of being a unified system for PC and XBOX - however, it's extremely high level, and some functions, notably audio capture are completely missing.
Just an update. I'm still tinkering with getting voltage monitoring up and running before I add current. I should be getting a new potential transformer, which should give much better performance than the rather naff plug-top one. (A very high specification 250 VA toroidal transformer - worth £30 from RS, but I got it for £2 off ebay). However, I've found another problem, which is that I get occasional corruption of the audio capture. I'm really not sure why this is happening, and it happens with all of my sound cards and on-board sound. I think it might be because I've implemented the capture as MS have in their sample code - the problem is that MS have later admitted that the interface they describe in the samples (buffer position notification) is hopelessly broken, and that I should instead be polling the DirectSound for the recording cursor position before deciding to analyse the data. I'll have a go at changing this in due course and see what happens. Really, I want to get this sorted before spending much more time and money on this project. If this is a show stopper and Windows Vista simply can't record audio, well it kind of scuppers the project. I haven't really worked out how I'm going to sort out current - I'll probably use a cheap current transformer from RS or somewhere, and buffer it with appropriate ballast resistors and an op-amp. Still, at £2 each I got a spare transformer, so I might try connecting one up in current configuration (but that's not really a particularly good idea - I'd imagine the neo-secondary current winding could produce some spectacular voltages if left unballasted)
Thanks all. Just thought I'd update. It looks like I've solved the glitching issue. I changed the software to bypass DirectX and access the Audio hardware directly via WASAPI 'exclusive mode' access. I also changed the priority of the data capture thread to 'pro audio' priority, instead of normal priority. Captures now seem to work fine on the on-board sound. The X-fi still glitches hopelessly. I've just been tweaking the software to get a bit more info out of the voltage signal, and cleaned up a few problems in the code, and am gradually preparing it for measuring current as well. I'll probably get one of the cheap £1 current transformers from RS e.g. 537-4485. Anyway, I may as well show some pics of the new software: 1. Voltage trace. Min/Max/Avg voltage over a few seconds. Also notice a close up of a glitch automatically detected and recorded. In this case it's me turning my monitor on. Notice the discontinuity and ringing as the switch closes, then how the peak of the waveform gets flattened under the load of the capacitors charging. 2. Frequency trace, and a dynamic oscilloscope trace. Nothing too exciting here. 3. Harmonic analysis. Evaluates both amplitude and phase angle of harmonic voltages. THD, 3rd and 5th harmonics are recorded in the trace. Notice drastic improvement in numbers from previous screenshots (the benefits of a transformer that doesn't saturate on every half cycle). 4. Flicker analysis. Uses an industry standard technique for measuring the visibility of lamp flickering due to fluctuating voltage. Both short term (pink) and long term (cream) values are shown. Even though ST and LT values require 10 mins and 2 hours measurement respectively, the trace is updated at 1 minute intervals by interleaving analyses, giving nice smooth traces. The red line marks an 'irritability' score of 1, which is the legal limit (the value should be below this 95% of the time). Nevertheless, when the pink curve peaks, the lights do flicker very noticably (I'm guessing this is the nearby Corus and Forgemasters factories running their steel-making electric arc furnaces). Pressing things to do: Remove some of the hard coded sample rates in the code, and allow the use of a single constant Find a faster Fourier transform routine. The current one is a fairly basic one written in C# which struggles a bit with the 2M point complex transforms.
After about 4 years, I've resurrected the project and finished it off. It now measures current, voltage, power, harmonics, waveforms, power factor, flicker, phase angle, and probably a lot more stuff that I can't remember off hand. Oh, and it exports subtitle files, so I can overlay the display on videos. Quick demo: HID lamp warming up Plasma telly Demo of the waveform functions, and rather boring discussion about phase angles and power factor Hoover motor and air con inrush current demos Crappy video showing how it's put together
