Radio W4KAZ

Thanks for stopping by the virtual KazShack. Feel free to comment - I often approve them.

CFL’s Suck – Roll Out The LED’s

I’ve been running a bit of an informal experiment in house lighting for the past seven or eight years.  Been using CFL’s since they first appeared in the local retail outlets.  Hate to think about how expensive they were before they became Politically Correctified.

Some of the fixtures in the hacienda have sockets for two bulbs. I’ve gradually been removing the old bulbs and replacing them(simultaneously) with a mixed pair – a regular incandescent paired with a “name brand” compact fluorescent. Just wondering if the CFL longevity claims have any merit.

The sample size is pretty small, but the CFL performance has been a lot less than the hype. I had high hopes for one of the outdoor fixtures, but the outdoors CFL crapped out before the incandescent. The CFL crapped out first in one of the indoor fixtures too.

CFL Bad: The bad points

  • Long life claims not meeting expectations
  • Seem to be “bug magnets” when used alone, much more so than incandescents.  The insects must love the color of the light, because the bulbs run a lot cooler than incandescents.  This is a big problem outdoors.  This is not as noticeable a problem when combined with an incandescent.
  • Light color distasteful to certain humans.  (can also a good point-very subjective)

CFL Good:

  • The CFL bulbs use less energy.  In hindsight, I’d like to test this claim too.
  • Price per bulb dropped to more reasonable levels, but the shorter than hyped useful bulb-life offsets this benefit.
  • Light color is improved by pairing with an incandescent of similar luminescence.  Combined, this makes for improved work area lighting.

I also had high hopes for the longevity claims – hopes were shattered by the reality.  Don’t see any improvements in either longevity or the light color with newer bulbs.  Wondering what the cause for the “early” failures might be. Is it:

  • situational, something about the location?
  • indoor vs outdoor(slightly better life indoors)?
  • voltage spikes?
  • current spikes?

Whatever the reason, the CFL’s are moving rapidly to the top of the “get rid of this crap” list.  Several reasons, besides the shorter than advertised bulb life.  Don’t much care for the light color when they are the only source.

The color can also be a  positive side to the CFL’s – if you like it.  It seems worthwhile  to combine a CFL and an incandescent for workshop lighting, the two together are good.

Conclusion: In general, for my purposes, CFL’s suck. The CFL’s absolutely suck for outdoor usages.  CFL’s really suck most in the winter outdoors.  They seem to be good for about half there rated output once temps drop into the 50’s.

Time for the LED’s from Lighting Science Group.  Getting close to pulling the trigger.

Notes On SSB RFI In Homebrew SO2R Box

Chasing down the RFI caused by inserting all of the home-brewed SO2R components into the station set up was a useful hands-on experiment. Annoying, but certainly educational.  I verged on ordering the ARRL RFI tome, but now the thing is fixed, owning the reference seems less urgent.  Might be worth reading though…..probably quicker than re-inventing each technique personally.

To start, the shack layout resulted in a few less than ideal situations. Both radios are side-by-side, separated by about 300mm. The computer that logs and controls both radios is on a rolling cart normally kept close to the station desk. The computer was also being introduced into the audio chain as the DVK, and I was also working towards routing the mic audio through the sound card full time. The cramped space on the desk is further reduced by the antenna switching controls and an antenna tuner. One set of bandpass filters is built into a relatively large computer case, and that occupies much of the top shelf.

No RF problems were noticed on CW, but on SSB the audio was terrible, and I got many reports to that effect. Apologies to those who were exposed to it.

The unshielded plastic enclosures used may have contributed to the problem, but so far most of the trouble has been corrected by applying the normal RFI kludge, clamp on ferrites.  Shielded enclosures probably can’t make the problem any WORSE though.

The audio stream for the Yaesu FT-920 was relatively easy to clear up. Three or four turns of cable through one or two ferrites seemed to do the trick. The K2 was more difficult to tame, but it was also the furthest from the computer. I expect that the longer audio cables needed to reach the K2 made better antennas for picking up the stray RF. The cables used are a mix of CAT-5 and shielded RCA audio cables. The CAT-5 cables carried the mic audio, PTT and CW from the So2R box to either radio.

In addition to the ferrites, I also routed the audio from the computer through an isolation transformer. That step alone almost completely solved issues with the FT-920.  Using a separate power supply for the SO2R box resulted in acceptable audio –  better, but not BEST.

Two of the issues were a big surprise – and I only discovered them as RFI ingress points because I reached the point where I was determined to cover every base.  The separate power supply was an issue that was unexpected, but should not have been.  NT4D has made that point to me several times over the years.  Unfortunately good advice often falls on deaf ears.  I have heard the gospel now….

The one that I really dd not expect was that the PTT line might be an RFI source.  It became obvious this was a source when I methodically disconnected various cables on the K2 end of the chain.  Low and behold, once the PTT line was disconnected from the SO2R box – no more RFI.

I may now re-visit the entire chain, substituting a better quality cable to see if there is any difference or if fewer ferrites might be required.  It took three ferrites with about five turns on each to subdue the RFI ingress from the PTT line.

Here’s a summary of the mitigation steps taken to end the RFI issues.

Problem #1:
Power supply – One source of RFI problems was sharing the radio power supply with the SO2R box. Putting the SO2R box on a separate wall wart helped a lot.

Problem #2:
SO2R box cabling. Because of the shack layout, the SO2R cables are all pretty long. Putting ferrites on all cables more or less solved the problem with the FT-920. Still had RFI on the K2.

Problem #3:
Added .01 bypass caps across all of the relay coils and DC connections in all switch boxes.

Problem #4:
Didn’t really have ferrites on ALL of the cables. I really didn’t expect the PTT line to be an RFI issue, but solving the RFI problem on the K2 required ferrites on both ends of the PTT line(at the radio mike jack, and at the relay output in the SO2R box), as well as on the foot switch itself(at the SO2R box). While I was at it I added ferrites to the DC power cords too. It took three ferrites right at the mike jack on the radio end, so that may have been the real source of ingress.

Problem #5: Add isolation transformer in line with audio from the computer before going into the SO2R box.  Putting the transformer at the input to the SO2R box was an arbitrary choice – I don’t know if its location in the audio stream is of great consequence in mitigating the RFI.  Its placement there ensured only one transformer was required, since all audio is routed through that location, not being split until later in the SO2R box.  The location was convenient – perhaps not ideal.

Caveat: It is possible I also did something else inadvertently which helped solve the problem, but after a couple of weeks of head scratching and trial and error, I can say that UNdoing any one of #1 thru #5 will re-introduce some amount of RFI.

The problem with the PTT line really has me perplexed, but I guess it is in close proximity to the audio cable at the radio mike jack, so any RF on the PTT line is probably getting into the audio there.

After all of the trial and error, my impulse in the future will be to add ferrites on all control cables on both ends, and immediately after they enter/exit each device.

Windows 7 GodMode

Leave it to the RedmondGeeks to create a useful tool but leave it undocumented rather than make it easily available.  And a big thanks to NumberOneSon for showing me the trick.

There’s a feature for Windows 7 users called GodMode, which is simply a tool/folder that has a lot of the more useful system administration tasks grouped together in one place.  [As opposed to navigating five screens to get to them.]

All that is required to use the feature is to create a folder then re-name it.  See the link for the details or just goog up the word “godmode” for yourself.  No use re-inventing the wheel here.

[hey!  I didn’t name it…]

Installing Writelog Under Windows 7 UAC

OBSOLETE:  Versions after version 11 are much better.  Disregard if using a version of Writelog after 2011. [w4kaz, 20150101]

ENVIRONMENT: The following applies to an install of Writelog on a Windows 7 64 bit platform with User Account Control enabled.  Probably works for any Windows 7 version.  It may also apply to Vista, but that version of Windows has not found its way into my hands, so experiment at your own speed.  All installs were done under the administrators account, and testing of the application done in a limited user account.  No special permissions were granted to the limited user, nor to any of the directories.

BACKGROUND: The new BlogBox is not used down in the KazShack dungeon, but  is the day-to-day computer.  After a contest, I move the log file up to the main computer and use an install of WriteLog on that box to spew out the Cabrillo, and ADIF backup, and the reports.  For my own nefarious reasons, I chose to set the new BlogBox up with an administrative user, and do all of the day-to-day activities within a limited user account.

WriteLog is still backwards compatible with older versions of windows, and runs well even on systems with limited resources.  That is something that is a useful feature, as it allows a wide  choice of hardware platforms to be pressed into service.  Plus, I just damn well like WriteLog better than anything else.

But since Writelog was designed before the day of user accounts there are some adjustments that need to be made to get it working in Windows 7.

THE INSTALL: One approach used by many is to disable User Account Control[UAC] and run the system as the administrator.  That’s a judgment call.  Diametrically opposed to the goal here…but used with success by many.

Another approach that seemed to work is to install it under an account with  administrator privileges.  But that also falls short of the goal, which is to get it going under a limited user account.  When installed as the administrator, the user accounts were able to run the program, but not able to save the configuration settings.

The approach that seemed to work is to install WriteLog into its own directory[I named it c:\writelog_install_home].

The install went without a hitch.  The real trick is simply to find where everything is right after the install.  The important part is locating the “writelog.ini” configuration file.  For whatever reason the RedmondGeeks in Windows 7 [and maybe Vista] have an environment variable [“appdata”] that is used for hiding certain bits of data under UAC.  The term “hiding” is used deliberately since the directory referenced by the environment variable is indeed hidden.

Finding STUFF:

  • start a command prompt window, and type “set” with no other parameters.  that will display all of the environment variables. The pertinent one is “appdata”
  • In the file explorer, under “organize” –> “Folder and search options” –> “View” -> “Hidden files and folder”  check “Show files, folders and drives”
  • In Windows 7 user info/program data is generally is stored in “C:\users\xxxxxx”, where xxxxxx is whatever your user name might be.
  • Writelog creates a directory in the “c:\users\xxxxxx\documents” directory[i.e., “My Documents” under the logged on user account] for its data files, wav files, contest “ini” files, etc.

The basic install is all pretty easy once you locate the files.  The critical file is the configuration file, “writelog.ini”. In this sort of install there are actually two copies of writelog.ini.  One copy is in C:\windows.  That copy is an abbreviated version, which has what I expect are the bare minimum bits of info required by WriteLog to run.  [NOTE:After installing the program several times it is possible this copy in C:\windows could just be cruft left in place from a previous install.] It seems likely that “writelog.ini” is used to initialize the program.  Probably best to ignore that copy of Writelog.ini, and leave it undisturbed.  You will need to have admin privileges to edit it.

The second copy is stored under the c:\users\xxxxxx\appdata directory in the sub directory \VirtualStore\Windows.  The full path in my install was “c:\users\w4kaz\appdata\VirtualStore\Windows\writelog.ini”.  THIS is the file used to store config settings for the logged on user, and it is here that customizations should be added.

The user copy is created for each user individually and uniquely. That copy is the version that can be customized as required for the particular situation.  A lot of WriteLog users have custom versions of their config file for different situations.  Rather than maintain numerous copies of the file, it might also be appropriate to define a separate user for each situation.  Then all of the copying/management of config files could be avoided by simply logging on to the appropriate user.

That’s enough to get the program functional as far as opening logs, exporting reports and files.  Testing connectivity is to peripherals is more difficult, since the shack is not in the same location and there are no USB dongles yet in use in the KazShack.

The defaulted directories were as follows, after the user had opened the program, and done a “save config”:

Directory=C:\Program Files (x86)\WriteLog\



Wave files and data files are defaulted to the user’s documents folder.  Customize those as needed.

The only real curiosity is that the user writelog.ini install directory was not updated in the final install to reflect the actual install directory.  Its probably best to update that entry to reflect the actual installation directory.

Installed in this manner I have not yet run into anything that required administrator privileges, or that Writelog be “run as administrator”.  But admittedly, I have not yet tested  keying CW, .wav file audio, or rig control.  The BlogBox is not the computer used for contest logging, nor do I use any USB dongles at this point.  In the end, admin privileges may indeed be required for full featured usage that bangs away on the com ports, but in a limited use it is not required.  Best guess is that LPT keying probably is more complicated, if possible at all, and that a Winkeyer would probably work easily via USB.

CAVEAT: After I was satisfied the main program was functional, I went through the Writelog directory and executed each of the utility programs.  The  “tuning indicator and audio snapshot” program received an error window trying to edit the system registry.  That program is for use with RTTY, a mode I am not using, so it is not clear to me that the program has actually failed.  After acknowledging the error, the program appears to load and be ready for action.

UPGRADES: For these tests, Writelog v10.70c was used for the full install.  Upgrades 10.71 through 10.75 were then applied via the administrator, with no problems encountered.  The program ran for both the administrator and the limited user accounts.

And dats da fax, jack…..

W7IUV PreAmp in RX System

After building the 80m/160m splitter, it seemed like the signal levels from the K9AY were down a bit, probably from losses in the filters.  So after looking around at pre-amps, and procrastinating on buying the Ar2 preamp, I again landed on the W7IUV site.

W7IUV has updated his preamp schematic, and it looked easy enough.  Building the project was simple after gathering some suitable parts.

Trying the pre-amp out seemed to show that it was more or less filling the desired role quite well. With the preamp engaged, levels from the K9AY were now on par with signal levels from the transmit antennas on both 160m and 80m.  The preamp is installed in the shack just ahead of the band splitter.   Noise levels on the RX system were down about two to three S units from the TX antenna in these moderate noise conditions.

During the 160m contest this weekend, the RX system got its chance to proove itself.  Noise levels here were moderate – not as quiet as good winter conditions, but not S9+ summertime noise either.  The RX antenna with the preamp turned on was always the best choice on weak signals in these conditions.  It also necessary to switch the K9AY around a lot – signals were not always best in the expected direction because of higher noise to the north.   The southeast direction was dead quiet, but from here in central NC there isn’t much to listen to on 160m to the SSE. The actual compass direction on the SE leg is about 10 degrees south of southeast.

So the short version is that the preamp is an improvement when splitting the RX antenna for two radios.  

Future projects/curiosities:

  • Try moving the preamp out to the base of the K9AY, probably in a new K9AY switch box
  • Test the RX with the splitter removed, preamp on/off.


Recycled Radials

Finally figured out what to do with burnt out strands of Christmas lights. Scavenged about 100 ft of wire in 20-25 foot long hunks and used it to augment the radial system on the K9AY.

The K9AY RX antenna itself is in need of replacement. It is constructed of 18ga wire, and has had several breaks in the past couple of years. Right now it has five or six splices where repairs were made. Probably time to replace it with 14ga THHN, now that copper prices are down again. A 500ft spool of 14ga stranded THHN housing wire was $35.00USD yesterday at the local BigBox retailer.

Time to stockpile before hyperinflation kicks in?

Public Statement re the “Fi-Ni Report”

At this time I would like to make a public statement acknowledging the fact that I am in no way connected to the publication of the Lost Island DX Society, the “Fi-Ni Report”, nor any of its paraphernalia dispensing outlets. I reap no monetary benefits from the sale, promotion, nor dispensing of any of the materials related to either the Lost Island DX Society, nor from Dr. DX’s product sales.

I just don’t know how that unfortunate rumor could have been instigated.

I do admit to being acquainted with both Dr. DX and Macho Cueso, and more closely with Leche Dinero, but these casual acquaintances are the limit of my contact with the formal publications of the LIDS group.

Also, the actual geographic location of Lost Island and Jumbawunba Land are confidential and closely guarded by the LID Society. Due to the nature of my confidentiality agreement I am not at liberty to disclose any information regarding any information regarding LIDS that is not previously published by their official outlet, the Fi Ni Report.

Society membership is strictly controlled personally by Big Gun DXer. Please take up all such inquiries with him. I’m sure his QRZ info is kept current.


W4KAZ SO2R Collection – Engineer The Possible -SO2R part 2

At the bottom of this page is an accumulation of some of the SO2R resource materials I used in developing my own custom SO2R solution. My first SO2R post hashes out the thought process involved in choosing the homebrew methodology for hacking together a workable SO2R set up via home brew components.

The big issues for customizing an SO2R capability appear to me to be philosophical. It is possible to wear two sets of headphones and manually switch everything, praying you don’t transmit from radio A into radio B. That is a bit TOO minimal, even for me. A minimum SO2R set up for my purpose came down to an audio switch box, a switch for the CW, microphone, and PTT, as well as band pass filters and filter switching(manual and/or automatic).  And something like the Array Solutions SixPak to “keep ’em separated”[cue “The Offspring”].

It turns out none of those components are out of reach for home-brewing – if you are willing to compromise. The audio and radio input functions can coexist, but they could also easily be separated into two discrete units. One unit to handle headphone audio and the second for CW/MIC/PTT switching and route band data(if used). Likewise, the filters, switching, and band decoder for automatic antenna/filter switching can all be discrete units.

The crucial decision is whether to use USB(New Hotness) versus serial/parallel(old-n-Busted) interfacing. It didn’t take very long to determine that Old-N-Busted was going to be much easier to twist up in the KazShack. YMMV, and it is a VERY subjective decision. For my own uses it is just simpler to use the parallel interface, even if it requires milking the life from a few old computers running un-supported OS’s. But I suffer no illusions that “simpler” equates to “better”. That’s a subjective call, and will depend upon the circumstances and resources available.

Building a custom SO2R set-up grew out of my interest in a project by Jim, K4QPL, as well as my interest in filters, both band pass filters and coaxial stub notch filters. Being able to scout a second band will be fun, and it isn’t a great leap from a bit of extra S&P to full two radio operation. I don’t expect to be very proficient at it, but running at low power into mediocre antennas is not terribly productive either. So a full integration of the second radio into the station set-up might be fun.

All of those considerations lead to researching the topic. Others have done a good job of documenting certain things via the internet, so I’m just aggregating a few of the links I found useful. Some are ideas I have incorporated, like the band pass filters. The filters merit their own separate treatment. Some of the other SO2R links discuss ideas that seem to have merit, but did not apply to my situation. Some are just good reading.

The first set of links are station specific information, posted by folks describing their own SO2R set-ups. My own customized designs will be referenced first, simply because I can. But just so it is clear, my own design is an amalgamation of the work of others, including K4QPL, KK1L, and others.

Many thanks to K4QPL. Jim sparked my initial interest in this project via a club program about his own SO2R project, and answered several philosophical questions that led me to my own research and experiments.

The next set of links point to reference materials or other sites aggregating similar links, or some of the commercial sources. Note: There is a lot of duplication and cross linking. K8ND’s site has a good round up of the commercial sources from here in North America.

Hardcopy Reference:

2004 ARRL Handbook, Chapter 22.47, “A Computer Controlled Radio Switch Box”

Last Amended 9/20/2009, w4kaz

BPFF – The Guess-timated Scale and actual Guess-timates – Part 6

Part 6 of the W4KAZ filter project series discusses the actual measured S-meter calibration, and the filter attenuation estimated based on S-meter measurements.

As I meandered through Part 5 of this group of posts, I needed to find a way to calibrate the S-meter scale on the FT-920 to a 6DB reference. Lacking any real test equipment, this will allow me to do relative tests on the band pass filters to measure the filter attenuation on the harmonics and sub harmonic. So I used the attenuator pad(6,12, and 18db) to measure the delta between each S-unit from S-0 to S-9, “10 over S-9” and “20 over S-9”.

Big shock(NOT!): The S-meter on the FT-920 is definitely not linear.

Actual Big shock: The S-meter actually IS linear over part of its scale. I was a bit surprised by that.

The S-meter on the FT-920 was “measured” by using the attenuator pad, inserting attenuation and noting the S-meter drop. It came out to something like this:

  • S0-S4 – 6db
  • S4-S5 -6db
  • S5-S6 – 6db
  • S6-S7 – 6db
  • S7-S8 – 6db
  • S8-S9 – ~9db
  • S9-10 over 9 – ~12db
  • 10 over to 20 over – **Not measured**.

It was hard to decide if the drop from 20 over 9 to 10 over 9 was 12db or more, so I didn’t do any testing with any signals that strong. For the sake of an example, when the original signal was reading S4, adding 6db attenuation dropped the reading to S0.

It seems noteworthy that the spread from S0 to S4 is only 6db. I can often work stations that are down around S0, and almost always work anything higher in decent conditions. I guess to me it emphasized how important just a few db difference might be to making a contact. Maybe a 1db loss throught the filters is more siginficant than it appears. To paraphrase the OM’s, “every db counts…”.

Armed with that calibration scale, there now is a way to make an educated guess at the amount of attenuation a filter is providing on its harmonics and sub harmonics. By injecting a signal on the harmonic band, comparing the S-meter readings with and without the filter gives an easy way to approximate the filter’s attenuation on that band. It won’t be surprising to find that the accuracy of the measurements will be poor when compared to lab measurements, but it gives a rule of thumb guideline. Better than nothing.

Amendment, 2009.06.21– Somewhere along the way I misplaced my notes with the measurements made during mid-May. It looks like I won’t have time to re-test the filters for a couple of months, so here are a few notes from an e-mail to N4YDU. The executive summary….

K4VX filters – worst case is about 30 to 35 db of attenuation, through the 20m filter. The best cases are probably 35 to 40 db attenuation on the second harmonics.

NVARC Ugly filters – Woooweee! These puppies may have a bit of loss, but they sure do a great job on the harmonics. All bands showed 6 to 12 db better attenuation on the second harmonics than their K4VX counterparts. An S9 signal is dropped to S0, still readable. An S7 signal becomes barely audible at the noise floor of the F-920. The guestimate here is better than 40db attenuation on the second harmonics. Higher order harmonics were disappeared, so no ideas on the attenuation there, except that is “Enough!”.

Previous in series: Part 5 Guess-timating the filter efficacy

Start from the beginning at the W4KAZ Band Pass Filter series.

Field Day and The K3NG HomeBrew Rain Fly

With Field Day right around the corner the K3NG Home Brew Field Day Tarp Canopy seemed timely. I don’t have(i.e. “will not have”) a google account, so I couldn’t post comments to K3NG’s post. But it’s cool enough to bookmark permanently. Literally. Putting shade on the tent keeps the operating position much cooler.

My initial reaction was that K3NG’s cover would be subject to water pooling. As I kept reading, I saw that he noticed that too. Back in the swamps as a WB5, we used a similar strategery for shade and rain. Rather than risk poking holes in the tarps with center supports, our solution was to make the front posts about 18 inches longer than the rear posts. The slope was sufficient even in a heavy rain.

Our own posts were cut from pine saplings liberated from one of the club member’s farm.

With the front facing north, that also helps throw the shade a bit lower on the tents below the cover. It works pretty well at shedding rain too. Lots of chances for rain on Field Day when you are only 20 miles off the Gulf of Mexico. Ick.

O’course, it rained about three inches here at the NC KazShack Tuesday morning. My front yard becomes a small stream in these conditions, with water flowing over the driveway, down across the yard and over my neighbor’s driveway too. So much for the landscaping. Landscape timbers, mulch, even the grass – whoosh.

I sure hope the wx dries out before FD. Ugh.

Anyway, I like the rain fly solution. Kinda’ labor intensive, but worth the effort if there are enough warm bodies on hand to help throw it up.