This weekend I continued the
Power Play which started back in 2014, so as to extend recent interest in
RF probing and voltage detection.
Readers of long-standing may recall how I described a variation on a theme first expounded by Eamon "Ed" Skelton, ei9gq, in
RadCom, concerning a little compensated peak RF voltage detector. Unlike Ed's, my version was hooked up to the ubiquitous
open-source electronics platform, to offer advantages in user interface and calculation of derived units - not unlike the approach recently described by Tex, g1tex, in
Practical Wireless, for his RF Power Meter (or, indeed, g4fon's original digital power meter).
I hinted back in the original article in 2014 that my unit had some additional features - now it is time to get them proven and documented.
Most important among those features is an enhanced power-handling range, which allows the unit to accept RF signals of up to 50V pk-pk (which corresponds to 25W into 50 Ohms). This is managed by simple external circuitry, with no 'switching' (of the sort which Tex uses). Of course, I don't care about running up to 25W (of which, more below) but the power handling is important to qualify the unit as a complete 'QRP' power meter, where the term 'QRP' might imply up to 10W and some kind of headroom is required.
Here's the prototype, set up on the bench for testing...
Input RF (
here shown at QRP levels) enters the system stage left, to meet a couple of 100R resistors, playing the role of a
dummy load.
The compensated detector is pretty much as described back in August 2014 (
which itself is pretty much as described by Ed) but, grafted into this is both i) means to protect the analog channels of the Arduino against over-voltage and ii) a second, "high power" channel, which comes into play when the input signal climbs to vulgar, QRO power levels.
I say '
comes into play' - that's not strictly true; it is in play at all times. The Arduino decides whether to believe the low-power channel or the high power channel result, depending on the data they are providing. In that way, no switching of the external circuitry is required, simplifying both the circuit and the code which accompanies it.
Of course, your humble servant doesn't really have much in the way of vulgar sources of RF at QRO power (as sign of his humility HI HI). Again - that's not strictly true - because there's the old FT-101ZD sitting here next to me as I type - but let's turn a blind eye to that.
Fortunately, it is a useful property of the type of peak detector used in this circuit that it may be 'calibrated' by a d.c. voltage - so that is what I did in this case.
For the third time in this post, that's not strictly true either, as the d.c. currents in the detector diode and the 'reference' diode will not be in the same ratio during so-called calibration from a d.c. voltage as the ratio of currents in application - so this is only an
approximate calibration. But is is way better than nothing and certainly good enough for the rough-and-ready style in which I approach my games in radio-frequency-land.
I looked for a nice source of controllable, high d.c. voltages and - guess where I found it?
Yes - the nice old
HT power supply I found at the Red Rose Rally a fortnight ago. Ironic that a power supply purchased for tube projects should come in handy for dainty micro-controller applications!
So - here's the system, working with a wide range of inputs...
The top two were generated by real RF, flowing into a real 50 Ohm load.
The bottom one was d.c. - with no 50 Ohms resistor connected (
to save on my electricity bill). But the same 'measurement' system was used, with no change to the hard- or soft-ware configuration. This is yielding a wider useful display dynamic range than (e.g.) the excellent
Sandford Wattmeter - but it does have the rather significant disadvantage of needing a power supply (such as a battery)!
More details of "how it is done" to be revealed at a certain
gig in May, after which there will more publication - somewhere.
The remainder of 'playtime' this weekend has been spent
downloading IDE version 1.6.7 for the 'open-source electronics platform' and confronting some of the less-than-attractive consequences. I now have to spend a lot of time making what was once entirely worthy and acceptable into an offering which is fit to be submitted to the new compiler without it spitting back a series of warnings.
They tell me this is progress. I am not convinced.
...-.- de m0xpd