Unfortunately, I didn’t get to participate in the BCRA June fox hunt because it conflicted with the ARRL June VHF contest. As a result, I was rather excited to participate. Just like last time, Holly joined me.
Our goals were:
We were going to keep the last goal to ourselves, but during the fox hunt check-in at 9:45am, Mindy threw some shade in our direction…so, I guess that’s the kind of game we’re playing. ;) (For the record, Marc and Mindy were accompanied by Jeremy. So, they had three hams on their team.)
This time, the two foxes were within a 5-mile radius of Church St in Swansea. I like this. A 5-mile radius is still a lot of ground to cover but avoids having to drive for a long time.
For the most part, this hunt was like the last one. I used the same Alinco handheld with the same home-built yagi. I jotted down the measured vectors on a map on my iPad. The major change since last time is the addition of a second radio—a GT-5R Baofeng handheld with a small loop antenna I threw together a few nights ago. I’m not sure how much it helped, since the Baofeng is both poorly shielded (and therefore picks up strong signals) and kind of deaf (and therefore doesn’t pick up weaker signals).
Inspecting the map while enjoying breakfast in a Dunks parking lot a couple of miles north of Fall River, we concluded that we should start the hunt near I-195 in Fall River. That way, we could quickly get to the other side of the river if it turned out that both foxes were on the other side.
(The higher resolution map resulted in my annotations being kind of small when zoomed all the way out. The ~2MB full-sized image shows them better.)
The first vectors were rather disappointing. The first fox (which we dubbed the red fox), seemed not too far away but not very close. The second fox (blue), was very weak and apparently on the other side of the river. Well, that’s what we got from the Alinco+yagi. The Baofeng+loop got nothing.
Driving to stop number two, Holly picked up a little bit of the red fox’s second transmission. This was encouraging—the loop wasn’t completely useless and hopefully we were getting closer to the fox. Unfortunately, the first and second red fox vectors disagreed a little too much. So, we drove a bit further to see which direction it would confirm.
At stop number three, we concluded that either the red fox was down near the water or somewhere on the other side of the river (but not too far past it). Recalling the back-and-forth driving we did during last year’s hunt, we decided that our next stop would be near the bridge, which should tell us which bank the fox is on.
The signal got a whole lot stronger at the fourth stop. So much so that we thought that the fox must be in or near the nearby cemetery or park. This is why you can see stops 5–8 so close together on the map. After getting a very strong signal (even with 16dB of attenuation) at stop number 8 (and not having too many convenient places to pull over) I started to circle the various blocks looking for parking lots where someone could park for the 4+ hours of the hunt to act as a fox. While I was circling, Holly was trying to use the loop antenna and looking at the map.
Soon enough, we happened onto a parking lot for a strip mall. We drove around the lot, not seeing the Jeep we were expecting. So, I pulled into a spot to regroup and get another yagi vector when I noticed that a car on the other side of parking lot had two antennas on the roof. Sure enough, it was Skip’s Jeep.
We were the third ones to find it. (I didn’t actually note down the time, but it was something like 11:15-11:25, so somewhere between an hour and hour and a half since the start.)
You can see that I stopped jotting down blue fox’s vectors after the 4th stop. That is because we concluded that it was on the other side of the river and because it was weak, it was probably far enough that we’d just continue getting essentially parallel vectors.
Next stop (#10) was Home Depot. Well, their parking lot. It is large and it is easy to get out of the car and swing the yagi around. The signal was stronger, but that’s all the new information we got. So, looking at the map, we picked a spot about halfway between the Home Depot and the edge of the 5-mile circle.
There was not a whole lot in the vicinity of stop #11, so we just pulled over on a side street. Unfortunately, due to a timing error on our behalf, we missed one transmission. So we had to wait for the next one delaying us 5 minutes. The vector we got was confusing. It pointed north, but was weaker than the Home Depot one. On a gut feeling, we chose to ignore it and continue west. Just as we were going to get into our car, we were approached by a woman who lived in the house near which we stopped. After I explained that we were doing a ham radio fox hunt, she wished us luck and headed back inside the house.
Our penultimate stop was the parking lot of a middle school in Warren. There, we got confused because we heard the blue fox transmit 2.5 minutes early, and then right on time. After briefly considering that someone was transmitting a fake fox signal, we decided to trust the vector and follow the RI-136 north, hoping to stop around the middle for another vector.
While driving up RI-136, I started looking for a good place to stop…when suddenly I noticed a blue pickup with a “BCRA” sign in the window. A quick turn into the adjacent parking lot and a little bit of parking lot hopping later, we pulled up to Kevin’s truck at 12:01. We found out that we were the second ones to find his fox, and that earlier, due to a technical issue, he transmitted off-cycle.
After chatting for a few minutes, we headed home, walked downtown, and got tasty burgers and beer.
So, to recap: we found both foxes, we found them in 2 hours and 1 minute, got to enjoy the Arlington Town Day, and last (but definitely not least) I think we wiped the floor with the KM1NDY team. ;)
Edit: Mindy wrote her own blog post about the fox hunt.
Directly after our last lighttpd announcement where we wrote about the (in our view) deprecated option server.set-v6only we have been contacted by a lighttpd developer who corrected us. To cite him:
server.set-v6only still exists as an option, though I have removed some
of the documentation. server.v4mapped should be used, instead.
Our perl versions were outdated for quite some time. Finally the old versions have been replaced with 5.34 and 5.36.
OmniOS r151042q, r151040aq and r151038bq are now available.
compress/xz updated to version 5.2.6, fixing CVE-2022-1271.
library/libxml2 updated to version 2.10.0, fixing CVE-2022-2309.
library/zlib updated to fix CVE-2022-37434.
Fix for a boundary condition in the 9p library used by bhyve.
runtime/java/runtime64package, which is just a rename to
runtime/java, to aid developers working on illumos-gate.
For further details, please see https://omnios.org/releasenotes
Any problems or questions, please get in touch.
A while ago, I wrote about deploying Tribblix on Digital Ocean.
The good news is that the same process works flawlessly with the recently released m28 Tribblix release.
If you recall from the original article, adding an additional storage volume didn't work. But, we now have a vioscsi driver, so has the situation improved?
All I did was select an additional volume when creating the droplet. Then if I run format, I see:
AVAILABLE DISK SELECTIONS:
0. c3t0d1 <DO-Volume-2.5+ cyl 13052 alt 2 hd 255 sec 63>
1. c4t0d0 <Virtio-Block Device-0000-25.00GB>
That 25GB Virtio-Block device is the root device used for rpool; the other one is the 100GB additional volume. It's also visible in diskinfo:
TYPE DISK VID PID SIZE RMV SSD
SCSI c3t0d1 DO Volume 100.00 GiB no no
- c4t0d0 Virtio Block Device 25.00 GiB no no
- c5t0d0 Virtio Block Device 0.00 GiB no no
(That empty c5t0d0 is the metadata service, by the way.)
Let's create a pool:
zpool create store c3t0d1
It just works. And performance isn't too shabby - I can read and write at 300MB/s.
There you go. More options for running illumos.
I am a happy user of 1/4 wave verticals and hamsticks, but I’ve been thinking that I should look into another antenna type to add to my bag of tricks when I go out to do a POTA/WWFF activation. The hamsticks are easy to set up and completely avoid dealing with people tripping over wires, but they aren’t as good as full-sized antennas. On the other end of the spectrum, 1/4 wave verticals work really well, but the radial field needs quite a bit of space and curious passers-by have a tendency to walk right through it.
For a long while, I was contemplating building a end-fed half-wave antenna. The draw with this type of antenna is that it has a minimal ground footprint, but it is still a full-sized antenna, so it should perform well.
Before I go any further, I should say that there is a difference between end-fed half-wave and random-wire antennas. End-fed half-waves, as the name suggests, are exactly half a wavelength long. In theory, the feed point has an infinite impedance, but in practice it is between 3 and 4kΩ. As a result, they are often fed with a 49:1 or 64:1 unun which transforms the 50Ω coax feedline impedance to about 2.5–3.2kΩ. Because the impedance is so close, it is possible to use these antennas without a tuner. Random wire antennas are also end-fed, but their length is specifically chosen to be not resonant. They are often fed with a 9:1 unun and require a tuner.
Before I ordered the parts to build my antenna (or to be more accurate, the 49:1 unun), I looked for information about this type of antenna.
I found K1RF’s slides from 2018 titled The End-Fed Half-Wave Antenna. They seem to cover pretty much everything I wanted to know about the design—namely the ferrite toroid sizing, capacitor specs, and so on.
As far as what to expect from the mechanical build, I drew inspiration from KM1NDY’s DIY 49:1 Unun Impedance Transformer For End-Fed Half Wave (EFWH) Antenna (Step-by-Step Instructions) blog post.
I ordered the items I was missing from Mouser. I could have probably saved a few dollars by hunting around on eBay, but I like the idea of receiving what I wanted instead of mis-advertised garbage…and I was going to place an order with them anyway for one of my other hobbies.
Using K1RF’s summary table (see slide 25), I targeted something between “QRP” and “QRP Plus” to make it somewhat portable. I tend to run 50-66W SSB and 15-25W digital, which is certainly on the upper end of the approximate power rating from that slide.
Namely, I went with two T140-43 toroids, 21:3 turns of #20 magnet wire, and 100pF 3kV capacitor. I used #20 magnet wire simply because I already had a spool.
Here’s the list of items for my build including prices (some of which I estimated):
|Capacitor 100pF 3kV||$0.22||1x||$0.22|
|Magnet wire #20||~9’||~$1|
|Assorted screws, nuts, and washers||~$2|
I used my favorite source for project boxes—a nearby restaurant. Many restaurants use various plastic boxes for take out orders. I love using these for various projects. Since they don’t cost me anything, I don’t care if I break it during construction or scrape it up during subsequent use.
(And yes, I’m aware, type-N connectors aren’t necessary for HF. I standardized on them to allow me to use the same coaxes for whatever band I wish without having to worry about adapters or losses.)
After the build was done, I soldered a 2.2kΩ and a 1kΩ resistor in series to use as a 1/4W dummy load for the NanoVNA. I didn’t bother doing anything fancy with the “dummy load”. I simply let it rest between the antenna terminal and the ground on the connector:
Anyway, here’s the VNA sweep from 1 MHz to 30 MHz:
Here is the complex impedance in rectangular coordinates:
Finally, the SWR is at its lowest (1.085:1) at 7.55 MHz. (Note the different x-axis range.)
Not perfect, but certainly quite usable. And for those that prefer, here’s a table with various amateur radio HF bands:
|Band||Freq (MHz)||SWR||Z (Ω)||Usable?|
Of course, this is with the 3.2kΩ dummy load. The impedances may be completely different with an actual antenna connected.
I mentioned that I went with smaller toroids to make it more portable. The whole unun weighs 161 g (that’s 5.7 funny units, or 0.36 bigger funny units).
Not super light, but it would have been much worse with 2.4" T240-43 toroids which weigh more than three times as much (106g vs. 33g per toroid).
No matter how nice the results of a bench test are, they are irrelevant. What actually matters is on-air performance. So, I packed up my FT-991A, the new unun, and the 40m 1/4 wave antenna’s radiating element (1/4 wave for 40m is the same as 1/2 for 20m) and headed to a nearby park.
I did this two days in a row.
On Saturday (August 13th), I went exclusively with FT4 running 20W. I spent about 1 hour and 12 minutes on-air and got 50 contacts all over Europe, some in North America, and a handful in South America and Africa. A very good activation! (Average: 0.7 contacts/minute)
On Sunday (August 14th), I started with SSB at 66W and later moved to FT4 at 20W. After about an hour and a half and 96 contacts, the SSB pileup kind of dried up, so I switched to FT4 for another hour and a half and another 44 contacts. On SSB, I got only US stations. On FT4, I had a mix of North America and Europe. (Average: 1.04 contacts/minute SSB, 0.5 contacts/min FT4)
Both days, I had the antenna set up as a sloper with the feedpoint (and therefore the unun) about 2 m above ground fed through 100’ of off-brand LMR-240-UF. I know that the repurposed radiating element is too long, but I’ve been too lazy to try to trim it better since the FT-991A’s tuner handles it just fine. The 100’ of coax is completely silly and 20’ would do, but I didn’t have a shorter one handy. The datasheet says that there is 1.60dB loss per 100’ at 30MHz.
With that said, here’s what the NanoVNA showed for the 20m band:
The bottom of the band has SWR of 1.34:1 and the top of the band 1.50:1. The minimum of 1.03:1 is at 13.470 MHz.
For completeness, here’s the 1–30 MHz sweep:
Even though I’ve only used the unun for little over 4 hours, I already started collecting todo items for what to check or build next. For example:
For about $17, I’m very happy with it so far.
OmniOS r151042o, r151040ao and r151038bo are now available.
Fix for Post-barrier Return Stack Buffer Predictions CVE-2022-26373
Fix for a rare kernel panic due to a race condition in poll()
AMD CPU microcode updated to latest versions as of 20220408
OpenJDK packages updated to versions 1.8.345-01, 11.0.16+8 and 17.0.4+8
OpenSSL updated to version 1.1.1q and 3.0.5
Updates to ZFS to gracefully handle unknown/invalid vdev device IDs
For further details, please see https://omnios.org/releasenotes
Any problems or questions, please get in touch.