QRP Labs QRSS/WSPR Kit (Part 5 – mitigation)

Continued from Part 4

I looked at the design of the transmitter again, thinking about where all the VHF energy could be coming from. The transmit signal is generated by the Si5351A synthesizer module, and then goes directly to the FET Power Amplifier (PA). Low pass filters for each band are then switched into the output to remove harmonics.

The synthesizer generates a square wave, which by its nature contains all the odd-integer harmonics of the fundamental frequency. This is the source of the VHF.

Continue reading

Posted in Uncategorized | Leave a comment

QRP Labs QRSS/WSPR Kit (Part 4 – chasing the problem)

Continued from Part 3

I replaced the 25mm standoffs between the main and filter boards with aluminum ones, and retested.

Things got better . . . and worse.

It was now passing on half the bands but still failing on 10m due to VHF emissions, and on 40 and 80m due to second harmonic emissions. The 10m VHF emissions were worse than with the nylon spacers!

Continue reading

Posted in Uncategorized | Leave a comment

QRP Labs QRSS/WSPR Kit (Part 3 – Testing)

Continued from Part Two.

When I put the kit on the test bench, I found that it didn’t meet FCC Part 97 requirements on any of the six bands: 10, 15, 20, 30, 40, or 80 meters.

Part 97.307 requires that “. . . the mean power of any spurious emission from a station transmitter or external RF power amplifier transmitting on a frequency below 30 MHz must be at least 43 dB below the mean power of the fundamental emission.”

Continue reading

Posted in Uncategorized | Leave a comment

QRP Labs QRSS/WSPR Kit (Part 2 – the User Interface)

Continued from Part 1

The user interface for the unit is a two-line LCD display, and two pushbuttons. The LCD is a good looking White on Blue backlit display. There are construction options to set autodimming of the backlight, and I may go back and set that up. As I built it, the display never dims.

Continue reading

Posted in Uncategorized | Leave a comment

QRP Labs QRSS/WSPR Kit (Part 1 – the Build)

I recently built and tested the QRP Labs “Ultimate3S” kit, and I wanted to share the experience, including an issue I had.

At $USD 135 the Deluxe 6-band U3S set looked like a fun if slightly challenging kit to build, and I’ve been wanting to get a WSPR transmitter on the air, because it’s a kick to see what sort of propagation you can get with very low power (less than a watt). The price includes the case, parts for 6 HF bands, and a GPS receiver, so it’s a lot for the buck.

Continue reading

Posted in Uncategorized | Leave a comment

Ubuntu File System Benchmarking

UPDATE: The URLs below are dead. I no longer work at Canonical, and don’t know if file system benchmarking is still part of their kernel testing process.



I’ve been working to implement file system benchmarking as part of the test process that the kernel team applies to every kernel update. These are intended to help us spot performance issues. The following announcement I just sent to the Ubuntu kernel mailing list covers the specifics:

[EDIT] Fixed tags to enable the copied email text to flow.


The Ubuntu kernel team has implemented the first of what we hope will be
a growing set of benchmarks which are run against Ubuntu kernel
releases. The first two benchmarks to be included are iozone file system
tests, with and without fsync enabled. These are being run as part of
the testing applied to all kernel releases.

== Disclaimers ==


1. These benchmarks are not intended to indicate any performance metrics
in any real world or end user situations. They are intended to expose
possible performance differences between releases, and not to reflect
any particular use case.

2. Fixes for file system bugs reduce performance in some cases.
Performance decreases between releases may be a side effect of fixing
bugs, and not a bug in themselves.

3. While assessments of performance are valuable, they are not the only
criteria that should be used to select a file system. In addition to
benchmarks, file systems must be tested for a variety of use cases and
verified for correctness under a variety of conditions.

== General Information ==

1. The top level benchmarking results page is located here:
This page is linked from the top level index at kernel.ubuntu.com

2. The tests are run on the same bare-metal hardware for each release,
on spinning magnetic media.

3. Test partitions are sized at twice system memory size to prevent the
entire test data set from being cached.

4. File systems tested are ext2, ext3, ext4, xfs, and btrfs

5. For each release, each test is run on each file system five times,
and then the results are averaged.

== Types of results ==

There are three types of results. To find performance regressions, we
(the Ubuntu kernel team) are primarily interested in the second and
third types.

1. The Iozone test generates charts of the data for each individual file
system type. To navigate to these, select the links under the “Ran” or
“Passed” columns in the list of results for each benchmark, then select
the test name (“iozone”, for example) from that page. The graphs for
each run for each file system type will be available from that page in
the “Graphs” column.

The second and third result sets are generated by the
iozone-results-comparator tool, located here:


2. Charts comparing performance among all tested file systems for each
individual release. To navigate to these, select the links under the
“Ran” or “Passed” columns in the list of results, then select the
“charts” link at the top of that page.

3. Charts comparing different releases to each other. These comparisons
are generated for each file system type, and are linked at the bottom of
the index page for each benchmark. These comparisons include:

3A. Comparison between the latest kernel for each Ubuntu series (i.e.
raring, saucy, etc).

3B. Comparison between the latest kernel for each LTS release.

3C. comparison of successive versions within each series.

Posted in Open Source, Ubuntu | Tagged , , , , | 5 Comments

Baofeng Packet Radio Adventures

Recently, I decided to set up packet radio capability for my station. This is primarily in order to be able to reach the local Winlink Radio Message Server (RMS) gateway and have email access when power and/or internet are down, as has happened in the past after massive tornado damage in the area. I learned some interesting things while doing this, so I thought I’d share. I’ll include links and explanations of some of the radio-related terms, so I hope this is accessible to everyone.

I have a good station with excellent backup power sources, and I serve as an Official Emergency Station for Amateur Radio Emergency Services, (ARES). Adding Winlink email capability seemed like a good thing to do.

The RMS gateway station is in a facility a few miles from me, with redundant power and internet backup, and operates on the amateur radio two meter band.

Since the gateway is close to me and shouldn’t take much transmit power to access , I decided to try to put together a small package combining a handheld transceiver and interface which could serve me at my home location, or be portable if needed. For the interface, I chose a TinyTrak4 (TT4). While this device is commonly used as an APRS position reporter, it also functions as a Terminal Node Controller (TNC) which has a KISS Mode interface that can be used by the Winlink software.


TinyTrak4 (with my input level adjust modification)

I decided to try using one of the incredibly inexpensive Chinese handheld radios as the transceiver, and bought a Baofeng UV-3R for $30 on Amazon. It’s not hard to connect this to the TT4 – the radio has a four-wire plug and jack that connects the audio output, Mic input, and Push to Talk (PTT) signals.

The Baofeng puts out about 2 Watts of RF transmit power, which should be enough given that I’m close to the gateway and can transmit through a 3-element yagi antenna mounted on my roof, about 30 feet high.

Hooking all this up, I found I could not get a good connection to the gateway. My first thought was that it was low transmit power, but I decided to troubleshoot the entire functionality in a sensible order, and switched to monitoring APRS packet transmissions on 144.39 MHz. Received packet decode was terrible. I was successfully decoding less than 10% of what I could hear.

I know from prior experience that some packet decoders are very sensitive to input level, and I spent a lot of time fiddling with this. There’s a good procedure in the TT4 documentation, and I followed this.

Carrier Detect (CD) is a signal that’s present when another station is transmitting, and is used by the TT4 to determine when it’s OK to transmit, and also (presumably) when to try to decode received packets. The TT4 has three selectable options for determining that Carrier Detect (CD) has been asserted. The first is with an external wired connection. This option is not available for most radios, including the Baofeng, so I was limited to the second and third choices. The second is “Level” detection, which detects when the audio level exceeds a certain threshold. The reason that this works is that most radio transceivers are set to Squelch the audio output, or turn it off, unless there’s a signal present. The third method used by the TT4 is to detect the presence of the tones used to transmit the packet data.

I noticed that with the squelch turned on, and CD mode set to “Level”, I was unable to successfully decode a single packet. I figured that this was because the radio was slow to break squelch, and the beginning of the actual data was getting chopped off. With the squelch turned off on the radio, I was able to get a few packet decodes.

The next thing I did was to hook the TT4 up to another radio, an Icom 2200H. I immediately got decode of most packets I could hear, and when I adjusted the audio level, it went to near 100%. I tried this with the squelch both on and off on the Icom, and had good results both ways. There’s a software adjustment for “Audio Gain” as a configuration option in the TT4, and after playing with that in combination with actual input voltage level, it seems that any audio level between about 200 mV and 1.5V P-P will work well with the TT4.

A digression about what I can infer about the way the TT4 works:

The input circuit on the TT4 is worth understanding. The schematic diagram is in the kit manual, which is available here as a PDF document.

The TT4 audio input has a DC blocking capacitor (.1 uF) and is biased by two 220K resistors in a ladder from the A/D Reference pin of the MEGA644P microcontroller to ground. The ATMEGA controller allows you to output a selectable reference voltage on this pin, and that’s what the designer is using to bias the input. The choices are 1.1V or 2.56V. The input to the A/D converter sits at about 1.2 Volts, from which I infer that he’s using 2.56V. This can be seen in the following oscilloscope captures. It’s impossible to tell what the software design actually does (TT4 is not open source software), but with a 2.56 reference voltage for the A/D converter, this makes 2.56V the highest voltage that can be read accurately.

So in theory, input signals up to 2.5V Peak-to-Peak are fine, depending on how they’re processed. This pretty much matches with what I observed while using the Icom.

This brings us to the first examination of the receive problem with the Baofeng UV-3R. At the lowest volume setting, the voltage into the TT4 is about 600mV P-P, biased at about 2V. This is the very lowest volume setting on the Baofeng, one click off of silence. This level should work with the TT4, based on what I was seeing with the Icom. But it’s more complicated than just having the right input level . . .

Here’s what the beginning of the radio breaking squelch looks like:

Baofeng Breaking Squelch

Baofeng Breaking Squelch

The bottom trace is the A/D input pin, and is about the same (600 mV P-P). Note that the scales for the traces are different.

Another thing to notice here is that there are some large DC transients as the radio breaks squelch, with the A/D input going negative half a volt! It takes almost 80 mS before the bias level settles out (bottom trace). This could account for why it never decodes successfully when I have squelch enabled, but it sometimes decodes with the squelch off. I think that it just takes too long to break squelch and settle, and loses the beginning of the packet.

Here’s what the end of a packet looks like on the Baofeng:

Baofeng end of reception

Baofeng end of reception

You can see the end of the packet data, then a very short period of low signal (at the center of the image), then noise after the transmitting carrier stops. 100 mS later, the radio drops back into squelch. There are also DC changes from the radio here, and it takes another 150 mS for the input bias to settle.

When the squelch is turned off on the Baofeng and audio is output all the time, there are no DC shifts, so it appeared to be only related to squelch operation (more on this later).

Now, on to The Icom. Here’s a trace at the beginning of a packet when it breaks squelch:

Icom breaking squelch

Icom Breaking Squelch

1. Much lower DC bias on the speaker line
2. Much less DC transient on breaking squelch
3. Much less time to settle – about 12 mS at the A/D input as opposed to 80 mS

Now, here’s the Icom end of reception:

Icom end of squelch

Icom End Of Reception

There’s a larger transient here, but it probably doesn’t matter because we’re done decoding, and again, the A/D input settles fast – under 40 mS as opposed to 150 mS for the Baofeng.

After all this, I decided to add a 10K ‘volume control’ to the TT4 input, so I could turn up the Baofeng audio output a bit and then set the TT4 input level to exactly match the Icom levels which were working well.

Having done that, and doing A/B testing while monitoring APRS 144.390, with similar settings for both (Squelch enabled/disabled/ same settings for carrier detect), I got almost 100% decode with the Icom with or without squelch, zero decode on the Baofeng with Squelch enabled, and perhaps 5-10% decode with squelch turned off.

Lacking test equipment to examine the signals in more depth, I did try viewing audio from the Icom and Baofeng simultaneously on the two scope channels during packet reception, and they were nothing alike. This may be because the Baofeng claims to use “DSP”. This could lead to a delay in the audio, which would prevent it from correlating with the Icom. Or perhaps Baofeng is doing some audio processing for voice clarity, which is interfering with packet decode.

At this point, I decided that I didn’t want to put any more engineering time into looking at a $30 radio, and decided to move on and use the Icom to communicate with the gateway. I’ve been told by other local hams that they have successfully used this very same Baofeng model for packet radio, so I’m not sure why it doesn’t work for me.

And then . . .

Yesterday, this blog post was made, in which the author describes adding a Carrier Detect output signal to a different model of Baofeng radio. He was able to do this because the software in the radio only turns on power to the audio amplifier when it wants to make a sound. By connecting to the amplifier power supply inside the radio, he was able to implement hardware Carrier Detect.


Turning on the audio amplifier when squelch breaks would explain the crazy DC transients that are seen as the the UV-3R comes out of squelch. It makes sense that Baofeng would do this on multiple models, as it saves battery power. I think the mystery of the slow squelch and DC transients has been solved, but I still don’t know why packet decode is so bad with the Baofeng.

Posted in ham | Tagged , , , , | 3 Comments