RF Noise Bridge for antenna tuning?

An early electronics project for me was to construct an RF noise bridge. This remarkably simple device, combined with a receiver, let me measure resistive and reactive impedance by adjusting for a null in the noise on the receiver.

I'm putting together a compact station for portable operation and it occurred to me that a noise bridge might be a good way to adjust an antenna tuner used to match an end fed wire in a tree. Sometimes it's hard to find the resonant point.

I tried this with a random wire, a Z match and a QMX transceiver (with the recent SSB software). It was not a good way to tune up, partly because of the QMX's excellent AGC.

To see what's going on I hooked up an SDR as the receiver, so I can see the noise over a broad bandwidth:

The antenna is an off centre fed dipole and the tuner is a simple L match. The dip can be seen above up the top end of 40m after tuning. A traditional antenna analyser confirms the tuning:

So it does work but is difficult compared to other options such as minimising an LED on the Z-match or using a NanoVNA. 

I wonder if I'm not doing this correctly. I'm not seeing what I would characterise as a "deep null".

The Palomar bridge is a nice bit of gear and I rather like the warning on the back of the manual:

They have an article about using the noise bridge for antenna tuning. Oh, and this story is another example of Betteridge's law of headlines.

Rotary encoder in MicroPython

Sample code for rotary encoder handling that I've found seems to double step with my encoder. I guess there's other that have half steps or something. Anyhow, here's how I've been doing it and it's working just fine.

CLKPin.irq(trigger=Pin.IRQ_FALLING, handler=rotary_callback)

def rotary_callback(pin):

"""Interrupt handler for rotary encoder falling edge"""

global frequency

if DTPin.value() == 1:

frequency += int(math.pow(10, step_power))

else:

frequency -= int(math.pow(10, step_power))

setFrequency(frequency)

So, the interrupt triggers just on the falling edge of the clock pin and then looks to see if the data pin is high (for clockwise) or low (counter-clockwise).

A full project is stored here.

Thonny alternative for MicroPython - MicroPico

Recently, I've been enjoying developing embedded projects on an RP2040 zero board using MicroPython. The RP2040s are fast and cheap and the zero board is much more compact than the Pi Pico but has more than enough I/O for my needs. (Actually, all the I/O is there if you need it).

MicroPython is a wonderful language and I like the fact that the source code is on the device so I can always find it again.

The normal way to develop MicroPython is Thonny. It's fine but the editor is rudimentary compared the modern code editors with completion and AI suggestions.

Recently I've discovered the MicroPico extension for VSCode and it is working pretty well.

The environment does all the things I need including showing the files on the board, letting me run the current file, stop it, and use the REPL console.

Most impressive is the AI code completion which often stuns me with its guesses about what I was about to type. (The suggestion is the italic stuff after time. below).

MicroPico doesn't do the firmware install but that's quite easy on the RP2040 (hold the boot button and plug in). 

The files stored on the device are shown in the "Mpy Remote Workspace" area on the left and a project folder is above. You can drag files up or down between areas but it moves the file. To copy a file on macOS you option-drag as is the normal convention here.

I wish single step debugging was available for MicroPython but if I'm debugging pure python algorithmic code it can be debugged locally if needed.

There are other MicroPython extensions for VSCode but this one seems to work quite well for me.

Low cost display and rotary encoder board for VFO building

As part of my objective to take the SolderSmoke DC receiver forward to be a double sideband transceiver I've been messing about with an Si5351 based VFO. The CPU is an RP2040 Zero board which I program in Micropython. I've just bought a couple of these handy boards that include a 1.3 inch OLED display, a rotary encoder and two extra push buttons.

No documentation comes with it but the edge pins are nicely labeled on the back.

When I hooked it up and tried my existing code, written for an SSD1306 OLED, the display showed mostly noise. It turns out the boards with a larger, 1.3 inch, display require the SH1106 driver which I found here. Both drivers subclass the Micropython Framebuffer class which is a very interesting thing in its own right.

The display / encoder board has nice big mounting holes on the corners as you can see.

I paid AU$6.79 each for the larger display version on AliExpress. For you in America I guess they'll be about $100. ;-) The board seems to be widely available and is called "0.96/1.3-inch OLED Display Module With Button EC11 Rotary Encoder IIC Interface LCD Screen"

MicroPython OSError error numbers on RP-2040

I've seen an OSError stack trace when trying to talk to an I2C device on the wrong address and wondered what EIO means. It would be nice to have a list of all the error codes and what they mean.

From what I've read, error numbers are different for each hardware port of MicroPython. I'm using a Raspberry PI PICO and can get a list like this:

MicroPython v1.24.1 on 2024-11-29; Raspberry Pi Pico with RP2040

Type "help()" for more information.

>>> import errno

>>> print(errno.errorcode)

{1: 'EPERM', 2: 'ENOENT', 5: 'EIO', 9: 'EBADF', 11: 'EAGAIN', 12: 'ENOMEM', 13: 'EACCES', 17: 'EEXIST', 19: 'ENODEV', 21: 'EISDIR', 22: 'EINVAL', 95: 'EOPNOTSUPP', 98: 'EADDRINUSE', 103: 'ECONNABORTED', 104: 'ECONNRESET', 105: 'ENOBUFS', 107: 'ENOTCONN', 110: 'ETIMEDOUT', 111: 'ECONNREFUSED', 113: 'EHOSTUNREACH', 114: 'EALREADY', 115: 'EINPROGRESS’}

But it doesn’t really tell much. They all start with ‘E' and so 'EIO' just means IO error, which makes sense.

In face they're all more readable if you know to drop the E.

{1: 'PERM', 

2: 'NOENT', 

5: 'IO', 

9: 'BADF', 

11: 'AGAIN', 

12: 'NOMEM', 

13: 'ACCES', 

17: 'EXIST', 

19: 'NODEV', 

21: 'ISDIR', 

22: 'INVAL', 

95: 'OPNOTSUPP', 

98: 'ADDRINUSE', 

103: 'CONNABORTED', 

104: 'CONNRESET', 

105: 'NOBUFS', 

107: 'NOTCONN', 

110: 'TIMEDOUT', 

111: 'CONNREFUSED', 

113: 'HOSTUNREACH', 

114: 'ALREADY', 

115: 'INPROGRESS’}

Technology talk on ABC Radio

Cyber criminals were able to breach a number of super funds, stealing hundreds of thousands of dollars from members.

The breach was unsophisticated, and likely came about because some super funds had not implemented basic security protocols on members' accounts

Peter Marks, a software developer and technology commentator from Access Informatics, joined Philip Clark on Nightlife to discuss the latest news in technology. https://www.abc.net.au/listen/programs/nightlife/nightlife-tech-talk-with-peter-marks/105152996

How DRM is shaping the future of digital radio

An interesting discussion of Digital Radio Mondiale. Some comments about how the west has retreated from Shortwave broadcasting are particularly pertinent at the moment.

The good news, to me, is that there are modules coming that will make it easy to make consumer receivers with DRM reception.

Thanks to the good folks at World Radio TV Handbook.