Antenna Experiments

Let me state from the outset that my knowledge of RF and antenna design is very rudimentary. I basically consider it to be black magic.

With that out of the way, I read something a while back that made me wonder if it was possible to measure antenna resonance with a track-generator equipped spectrum analyser.  In particular, with two identical antennae - one connected to the track-generator output and one connected to the spectrum analyser input - would there be an obvious peak in response at the antenna's resonant frequency.  That is an experiment worth trying.  

Here is the initial setup:-

 It is sweeping from 0 - 1.5GHz and there is already a very obvious peak.  Looking closer:-

The antennae are intended for use with DFRobot APC220 radios which have a frequency-range of 418-455MHz.  So in the ballpark, even if the measured peak is kind of low.  There is a significant difference between performance at the two ends of that frequency range, though. Reducing the frequency span on the spectrum analyser from to 418-455MHz:-

There is nearly 15dB difference between 418MHz and 455MHz.  Still...I can't say for sure what the resonant frequency of the antenna is actually supposed to be: perhaps it is 407.5MHz and the result is completely valid.

For the second test, I replaced the both antennae with a simple monopole consisting of a piece of coax with 16.5cm of the shielding stripped back.  This should resonate at a wavelength of 4 × 16.5cm = 66cm.  Assuming the speed of light is  3 × 10⁸m/s, that should be equivalent to 454.5MHz.  Let's see:-

Far from conclusive. The peak is at 152.5MHz, way over on the left.  There is a second peak at about 415MHz.  Zooming in to the 418-455MHz range:-

There is no sign of a peak of any kind near the resonant frequency.  

My "assumption" above about the speed of light wasn't entirely tongue-in-cheek.  The headline figure of 3 × 10⁸m/s is the speed of light in a vacuum. Signals travel through coax cable significantly slower than this.  According to a datasheet for RG179 coax that I checked (I think that the kind of coax I have), the velocity factor is 0.7.  That would put the speed of the signal propagating through that coax at closer to 2.1 × 10⁸m/s and - if the wavelength-to-frequency computation should take this into account - would put the resonant frequency at 318MHz.  I have no idea if the velocity factor should be applied here or not: if you know, please leave a comment.  There is certainly no bump in the output of the spectrum analyser at or near 318MHz that would give a clue either way.

Finally, I replaced the two coax monopoles with two lengths of wire, balanced precariously in the SMA connectors:-

The pieces of wire are identical and are both 10.5cm long. Looking at them as 1/4 wavelength monopoles and applying the equation, their resonant frequency should be 714MHz.  It doesn't appear to be:

There is indeed a strong peak, but it is nowhere near where it is supposed to be.  Interestingly, if I apply the velocity factor of 0.7, things look a lot better: that would imply a resonant frequency of 500MHz.  But I have no reason to believe that the velocity factor of a scrap of wire is 0.7, even if I knew that it was supposed to be included in the calculation.  I'm just fudging numbers here.

I got a similar result with 16.7cm of the same wire:

A good strong peak at 345MHz where is nowhere near the predicted 449MHz, but in the right ballpark if I apply the magic velocity factor of 0.7.

If you read down this far hoping for a satisfying conclusion and some enlightenment then I can only apologise for the disappointment you must be feeling.  I promise you, I feel your pain.

Nothing in any of this has done anything to shake my conviction that RF and antenna design is a black art.

Rotary Encoders

These are wonderful little things.

I got to thinking a bit about exactly how they worked, so I hooked one up to a power-supply and an oscilloscope.  There is 3V being delivered to the centre pin and one oscilloscope channel connected to each of the the two outer pins.  At rest, the centre pin isn't connected to either of the outer pins.  Turning the encoder clockwise...

...you can see that the blue trace goes to 3V a little before the yellow trace (the blue channel is the left-hand "A" pin on the encoder). 

Turning the encoder counter-clockwise and the opposite happens:-

Here the yellow trace (the "B" pin) goes to 3V before the blue one.  The key thing is that as the encoder passes over every detent, there is a point at which both pins are connected to the centre pin, but the direction of rotation determines whether the "A" pin gets there first or the "B" pin.

What sent me down this particular rabbit-hole was a very interesting pair of YouTube videos about using using just digital logic (i.e. no microcontrollers), here and here.  I had never previously thought about using these without a microcontroller and thinking about them in this way does reveal some interesting insights.

 

Sweet Mystery

 This packet contains 12 sweets of 4 different colours (black, red, yellow and - my favourites - green). 

 

 

The number and order of the colours in each pack appears to be random (based on many, many samples ). If my calculations are correct and if they are really randomly distributed, one in every 4.2 million packets will contain 12 sweets of the same colour. Something I have often wondered about: how do the manufacturers avoid this? I can see a number of possibilities:  

 

• Don't worry about it - it happens infrequently enough not to care
• Optically scan each group of 12 sweets just before wrapping them and if they aren't sufficiently heterogeneous, don't wrap them - throw them back into the pot and try again. This only seems like it would be worth doing if they were optically scanning them anyway for other reasons (e.g. quality control)
• They don't really throw all of the colours into one big pot and select them at random: they keep the individual colours separate right up to the packing stage and just shuffle the order in which they pick them to create the appearance of randomness.

Does anyone have any theories or insights? I'd love to know. In the meantime I'll keep eating them - purely in the interests of science, of course

GIMP Start-up Hang

This was a pain-in-the-ass to troubleshoot, so I'm sharing the story here in the hope that it will help someone else.

I have GIMP installed on a Windows 10 machine. Out of the blue, it started hanging on start-up: the main window would appear, but then it would freeze for about 5 minutes. Uninstalling and reinstalling didn't help and no amount of Googling yielded any solution.

The first useful clue I got was after it did become responsive (finally, after the 5-minute delay) and I clicked on the "File" menu-item, causing it to hang again for another 5 minutes. That hinted that the problem was with the "Recently Used" file list.  So where does GIMP store the list of recently-used files? Nowhere obvious, it turns out: on Windows, GIMP stores its recently-used file list in C:\Users\%USERNAME%\appdata\Local\recently-used.xbel (which may be shared by other applications).  It is an XML-format file.  Sure enough, in there are a bunch of references to files on a network share that no longer exists:-

I could probably have just deleted the entire file, but it was sufficient to just delete the <bookmark>...</bookmark> sections that referenced the now-absent network share.

I have to give a hat-tip Bing for leading me to the solution.  None of my Google searches along the lines of "where does gimp store its recently used file list" yielded any useful hints about where to look.  I was just about to start reading through the GIMP source-code - a daunting prospect - when I decided to try the same search on Bing:-

Even though this result refers to GIMP running on Linux, it was enough: one quick search for a file called "recently-used.xbel" and I was away. And so the score stands at Bing 1, Google 0.

Window Repainting Delays in Windows 10

A weird Windows 10 problem this morning. When I booted up the PC, it appeared very "sluggish". There was no obvious reason for this: CPU and disk I/O were all very low. On closer examination, the problem was with window refreshes: things were working OK in the background, but the contents of windows weren't being repainted for several seconds after. Switching away from a window and switching straight back seemed to "trigger" an update that should have happened all by itself.  

Anyway, after a bit of Google searching, I happened upon a description of a similar problem and its solution that I don't think I would ever have come up with by myself.  Somehow, the screen refresh rate had been changed from 60Hz to 59Hz:-

 

 

Sure enough, changing this back to 60Hz resolved the problem immediately.

I hope this saves someone else some pain (or saves me reliving the pain if it happens again and I have forgotten what the fix was !)

40dB Stereo Pad + Balanced-to-Unbalanced

The 30/40dB pad from my previous post works fantastically well. I have been using it to bring the balanced line-level output from a mixing desk down to an acceptable level for the microphone input on my camera and the sound-quality is crystal-clear. 

But it is time for version 2.0.  The things I want to change:-

• Stereo. Up to now, the cable I have been using to connect the pad to the camera simply connects the camera's L and R inputs together. It works fine, but the camera records two audio channels and I want to use them. 
• The first version is nice and general-purpose: it provides balanced output, handy for feeding into a balanced microphone input, if I ever wanted to. But my camera doesn't have a balanced input, so a camera-specific version with unbalanced output to a more convenient connector (phono or 1/4" stereo) would make connecting up a little easier (although I do love how rock-solid XLR connectors are). I'm willing to sacrifice some generality for convenience here.
• I don't really need it to have a switchable attentuation level.  The mixer has an output level fader and the camera has variable sensitivity on its microphone input. I'm willing to sacrifice the flexibility of a switchable attenuation level to reduce the (slight) risk that the contacts in the switch will become oxidised and noisy at some point.

Here is the schematic for version 2.0

The pad part is mostly the same as the earlier version.  I included some extra resistors (R1, R3, R6 and R8) that I have bridged with little wire links to give myself some flexibility.  If I want to increase the attenuation, I can snip the wire links which will increase the attenuation to around 45dB.  I had the board space (and the resistors) so it seemed a shame not to use it.  At the output, I have given myself a choice of either 1/4" stereo jack output or 2 x phonos.

If I had thought of it, I might have included a way to bypass the pad completely so that I could use this to connect two dynamic microphones (with balanced XLR outputs) directly to the camera input without any attenuation, but I didn't think of it (until now).  That's what version 3.0 is for, I guess.

This is what it looks like:-

I haven't tried it in anger yet, but initial testing is positive.  I'll report back once it has had its first proper outing.

UPDATE January 2021: I have been using this gadget regularly since May and it works absolutely perfectly: I am very happy with the result.  The amount of attenuation is applies is just about perfect and I haven't felt the need to snip the wires bypassing R1, R3, R6 and R8.  I do have about 12dB of attenuation dialed in on the camera's microphone input, bringing total attenuation up to about 42dB, which sounds about right and - more importantly - lands the recorded audio levels just about where I want them.

30dB/40dB Switchable Balanced Pad

I had a requirement to connect the (line-level) output from a small mixing desk into the microphone input on my camera (mic-level, obviously). I was using a DI box with a 30dB pad in it, but that required a 9V battery which was sure to run out at the most inopportune moment.  Since the camera didn't take balanced input anyway, there was no real need for the DI (in fact, the cable from the DI into the camera was wired as a balanced-to-unbalanced cable).  A little bit of internet research led me to http://www.uneeda-audio.com/pads/ which has all of the relevant information (but does require careful study !).  Based on that, here's what I came up with:-

This gives me the option of either 30dB or 40dB of attenuation, depending on the position of the switch (I find that with the in-camera gain turned down as far as it will go, 30dB is enough, but the flexibility is nice to have).  The input impedance seen by the mixer is about 27K at 40dB and about 6.8K at 30dB.  The output impedance presented to the camera is 220Ω.  It works pretty well.  I built it into a small plastic project box lined with copper foil (originally bought with the intention of shielding a guitar cavity):-

The resistors are of the metal film type to minimise thermal noise.

This is the end-result:-

It is fairly compact and rugged, completely noiseless and doesn't require any power.  

The justification for the choice of resistor values is as follows.  The general equation for gain (which will be negative) of a resistor divider network is:-

...where R₂ is the lower resistor in the circuit diagram and R₁ is the sum of the resistors labelled R_1.n in the circuit diagram above.  So, for 30dB of attenuation, the switch is closed and the 10K resistors are bypassed and the equation becomes:-

With the switch open, the 10K resistors are included in series and the equation becomes:-

I could (possibly should?) have used a slightly lower resistor value than 10K to land a little closer to -40dB.  7.5K would have done it, but it had already been a long night.  a 30K resistor in parallel with each of the 10Ks would do the trick.