Regular reports of my grabber activity and that of others, plus information on QRSS software, hardware and technique that comes my way

Monday, April 2, 2018

Keying a Tranceiver for QRSS Work

A conventional transceiver can be keyed for QRSS work using ON7YD's QRS software.  I often do this using my TS-480 to run 5 Watts on the 80m and 160m.

The software is versatile, easy to use and provides a keying output on both serial and parallel ports.  Here is the circuit diagram between the port and the transceiver keying jack:

Note that it requires no source of power.  I use an old serial port cable with a small Manhatten style pcb  at the transmitter end for the components with the output leads clipped across my hand key.

The  help file included with the software explains everything and ZL2IK has more info at his blog

ON7YD developed his program back in the dark ages of QRSS when it was virtually impossible to find a keyer that would send at our low speeds.  It was actually the keyer used when I built my first QRSS rig 10 years ago.  I've used it off and on for homebrew rigs as well as recently to key my TS-440 and TS-480.  It's definitely a handy accessory to have around the QRSS shack.

Saturday, August 22, 2015

Precision Markers at Any Frequency Using an OCXO with Spectrum Lab

I recently purchased an Oven Controlled Crystal Oscillator (OCXO) on eBay to use as a "house frequency standard."  It features an SC cut crystal with a double oven and a sine wave output at 10 MHz.  The question is, how to use it on all frequencies covered by my TS-440?

I calibrated the OCXO by comparison to WWV to an accuracy of just better than 1 Hz and verified by repeated observations that it is virtually drift-free, at least for QRSS work.  I'll describe how to do this in my next post.

In the old days of tube receivers a standard method for finding the band edge was to use a 100 kHz crystal oscillator with a harmonic generator to provide markers every 100 kHz.  This posts describes a similar approach to allow the 10 MHz oscillator to provide markers every 2.44 kHz with an accuracy of 1 Hz up through the Ten Meter Band.  It couples the OCXO with a binary divider to divide down to 2.44 kHz, or 2.4414060 to be exact, then produces harmonics which occur at this interval up through 10m.

Several years ago I purchased a frequency calibrator kit from W8DIZ which used this scheme with a TCXO and a 74HC4040 12 bit Binary Counter which can be configured to divide by up to 4096.  The DIZ kit used only the divide-by 2, 4 and 8 to produce strong markers at 10, 5 and 2.5 MHz but I reconfigured it for the 4096 maximum and was pleasantly surprised to see a plethora of harmonics throughout the HF spectrum.
Figure 1.  W8DIZ Frequency Standard
The next step was to see if the sine wave output of the OCXO would do the same since Binary Counters are designed to work with square waves....and it does.  I suspect the strong output of the OCXO overdrives the 4040 counter and acts like a square wave due to clipping.  The output of the OCXO was injected directly into the DIZ circuit at the base of Q2.   To select the 4096 divide-by I scratched through the trace from pin 7 of the divider and jumpered over from pin 1.  As a sidenote, this method surpressed the output of the TCXO but by adding a gimmick capacitor between the OCXO and Q2 to reduce it's amplitude I can also see harmonics from both sources.

The output from J2 was injected into the receiver's input through a BNC "T" adapter with a gimmick capacitor to adjust the amplitude.

The difficulty of having 2.44 kHz harmonics is that they are not likely to be close enough to the frequency span of a waterfall grabber to be seen.  Consider a typical grabber screen on 30m which extends from 10130.9 to 10140.1 kHz.  The nearest marker from the OCXO is at 10139.159 kHz or about 740 Hz below the grabber window.  What to do?

Spectrum Lab is a bottomless pit of useful features along with a tiny programming language to make them work.  One of these features is an internal audio oscillator by which the frequency can be set either manually or under computer control.  The programming command to set the frequency is,

      generator[0].freq = "desired frequency",

[0] refers to the first of three oscillators and note that "desired frequency" can be an algebraic expression.

There is also a special command to measure the peak frequency of a signal in a specified interval,


Putting it all together,

      generator[0].freq = 879 + peak_f(450,470).

I use the "Conditional Actions" section to execute the command every 1000 milliseconds.  Use "always" as the "if" statement and the generator command as the "then" statement.

The OCXO harmonic appears at an audio frequency of about 461 Hz and the second part of the above equation measures it's exact value, after which 878 is added to move the audio oscillator output frequency to a nominal value of  1340 Hz which is well within the grabber window.  I used 879 just to illustrate how to move the OCXO signal but other values could be used to move it, for example, to be close to a signal being studied.

You can familiarize yourself with the Spectrum Lab commands by clicking on the help screen and scrolling down to  Interpreter : -commands, -functions, -expressions.

Make sure your receiver's bandpass is wide enough to allow the marker frequency as well as the grabber window.

Here's an example:

This is a high resolution study of WA5DJJ's GPS stabilized fsk QRSS signal.  The individual dots and dashes are not evident because the scan speed is very slow.  Note that the frequency range is only 20 Hz.  The slow drift of the OCXO is due to temperature changes in the receiver and can be used to correct the frequency of the signal being measured by subtraction, ie, the OCXO is the baseline.

Near the right side you can see a gap in the OCXO signal.  This was caused by QRM down at the frequency of the OCXO marker, probably from JT65.

Though this post describes precision frequency measurement for QRSS work it can be used for other applications by choosing the appropriate Spectrum Lab parameters.

Sunday, June 7, 2015

Time-sharing a Grabber for Multiband Coverage

The most popular band for QRSS work is by far 30m.  Although at least one grabber op, G0XXX, has several receivers to allow other bands to be covered most of us cover other bands by moving on special occasions, such as a "weekend on 40m" or such.  Here I describe a technique I am now using which allows me to grab on several bands by time-sharing, i.e.,  moving the grabber periodically in ten minute frames.

The best and easiest way to control a receiver's frequency is via commands sent from the computer's serial port. Unfortunately the RS232 function in my TS440 no longer works so I've devised a technique which utilizes the UP/DOWN pins on the mic jack.  On the 440, shorting pin 3 will cause the frequency or memory to increment up while shorting pin 4 moves it down.  Computer commands can be obtained from the RS234 port by sending a binary number to the COM1 address from a simple program, which in my case is FreeBasic.  Here's an example of the FreeBasic code to make that happen:

     open "COM1:9600,N,8,1,CS,DS,RS" FOR Binary AS #1
     Out &h3fc,01      Rem set DTR low
     Sleep 250,0         Rem delay 250 ms
     Out &h3fc,00      Rem Set DTR hi

&h3fc is the address of the serial port,  01 causes the DTR pin to go from -10 to +10 vdc and 00 moves it back to -10v.  The  200ms delay gives enough time for the hardware to respond but not so much that memory moves more than one channel.  02 sets the RTS hi (mic/dwn)

The RS232 voltages need to be converted to an open/short condition with a level converter.  This is the circuit I use (two needed) :

Circuit from QRS by ON7YD

At present I use just three bands, 40m, 30m and 20m, with 40m being replaced by 10m or 15m during the daylight hours.  Here is the program written in the QuickBasic dialect of FreeBasic:

#Lang "qb"

Dim m As Integer
OPEN  "COM1:9600,N,8,1,CS,DS,RS" FOR Binary AS #1
Out &h3fc,00

Print "start"
zero: Rem inc To Next frequency when m changes (10 minutes)

If m=Val(Mid$(Time$,4,1)) Then GoTo zero
GoSub inc

Rem Print "at one"
one:  Rem inc To Next frequency when m changes (10 minutes)

If m=Val(Mid$(Time$,4,1)) Then GoTo one
GoSub inc

Rem Print "at two"
two:  Rem dec back To first frequency

If m=Val(Mid$(Time$,4,1)) Then GoTo two
GoSub dec

Print "inc"
Out &h3fc,01 Rem set DTR low
Sleep 200,0  Rem delay 250 ms
Out &h3fc,00 Rem Set DTR hi
m=Val(Mid$(Time$,4,1)) Rem set New m
Rem Print "leaving inc"


Print "dec"
Out &h3fc,02 rem dec twice To Return To start frequency
Sleep 200,0
Out &h3fc,00
Sleep 1
Out &h3fc,02
Sleep 200,0
Out &h3fc,00
rem Print "leaving dec"

GoTo zero

The program starts on the first frequency and checks the tens digit of minutes until it changes and increments to the second frequency. Repeats this a second time to reach the third frequency and finally decrements twice to return to the first frequency.  The "print" commands are for debugging.

In order to make the Spectrum Lab frequency scale show the correct values it's necessary to use the "Conditional Actions" feature to load in the "frequency offset" based on each ten minute period.  Here's what that looks like:

Be sure that the "sync" box is checked to activate "conditional actions"..

The start times of the first frequency are xx00 and xx30. The program can be started anytime during these time intervals in order to be synchronized.

Here's the steps to starting the program to ensure synchronization:

1.   Load the frequencies into the receiver's memory bank in sequential order and set to the first frequency.         The frequencies are the same as those specified in WSPR.

2.   Set up the "conditional actions" per figure xx and check the box in the files menu.

3.   Start the program between the first ten minutes (xx00 to xx10z) or the fourth ten minutes (xx30 to xx40z)       ensure synchronization.

I have chosen to use just 3 frequencies to allow each to be covered twice in one hour because it's a good compromise between bands and time between grabs for each band. At present 40/30/20m are covered at night and 15/30/20 during the day.  Changing from 40 to 15m for the first slot only requires entering the new frequency into memory slot one for the receiver and changing the corresponding frequency in the "conditional actions" table.

After debugging the software the only problem I've had is getting the delay correct in the inc: and dec: subroutines.  Remember, if the mic up/dwn button is held down the memory will scan until released and we want just one jog so it needs to be short enough to prevent this.  At the same time, if it is too brief the hardware does not have enough time to react.  For your system you may have to play with the delay.


Thursday, July 3, 2014

Using Google Analytics to Track Usage of Your Grabber

I used to have one of those cute little Maps on my grabber page that shows who's using it.  These apps are provided free and I read that they are a means of collecting user data, including IP addresses.  The provider can then sell this data to advertising companies, etc.  When I learned this I immediately removed the apps from my web page at

I really wanted a way to see if my grabber was being utilized since I rarely get feedback indicating it is.  I ran across a reference to Google Analytics which allows a web site operator to collect the data without obtaining personal data and IP address.  I've found it to be a useful and safe tool to monitor site activity and the most detailed info I get is rough geographic location and how many times my web page is accessed.   Here is what the info looks like:

I chose to watch on a daily basis but you can also select hourly, weekly or monthly.  In the graph above I can see that the peaks occur on weekends and the minima at mid-week.  Country information is also available.  There is also an option to monitor in real time so I can see who is accessing the web page now.

To install the app just to to Google Analytics and set up an account then follow the instructions.  You can also get reports for other web sites you may operate.

de w4hbk

Friday, May 30, 2014

One Billion Miles per Watt on 20m

Back in 2011 Dave, WA5DJJ, and I became interested in just how low we could go in power and still be able to copy his call letters, which is our definition of QSL for QRSS work.  On 30m we were able to make it down to 8.51 uW using image stacking technique.

Since that time we have kicked around the possibility of going down to 1 uW and last November started a new campaign to do so.

By early May of 2014 we had reached 15 uW on 30m after months of trying but could go no lower.  We need long periods of time free from interference in order to obtain a sufficient number of 10 minute grabs to use image stacking to extract the signal from the noise. Activity has increased since 2011 both from QRSS and other digital modes.  The notorious OTHR from Akritori, Cyprus is a regular visitor also.     In addition, this was a most unusual Winter here in North Florida with frequent thunder storms related to the infamous Polar Vortex which plagued the East Coast this year.

At this point we decided to try 20m to escape the QRM and hopefully see less QRN.  The difference was amazing.  Not only did we have the spectrum all to ourselves but the QRN dropped almost to nothing.  We started at 100 uW and came down rapidly in 3 dB steps to 5.8 uW.  After that the difficulty with each 3 dB step increased exponentially with the final step from 2.5 uW to 1 uW requiring 12 days until all the variables lined up in our favor.  Here's a 3-day stitched image showing our approach to the 5.8 uW level:

Note that the WA5DJJ signal was still drifting a bit until Dave installed the MEPT in a thick-walled styrofoam box.

On the night of May 17 the 1 uW signal was visible in and out on the 8 hour grabber from 0430z to 1040z.  Thirty-eight 10 minute grabs over this time period were processed with the stacking software Rot'n'Stack to produce a barely discernible image in which I could read all the letters of Dave's call.  That's 1 uW over a distance of 1164 miles/1873 km.  If you do the math that's over one billion miles per Watt for a signal propagated via the ionosphere.

Here is the results of the image stacking:

Note the use of a second signal from WA5DJJ from an older MEPT feeding a vertical.  It was not stable in time thus preventing stacking.  We used this to give some idea of propagation.  KB5R also joined in for the same purpose.  The cw signal from IK6ZEW was strong but not stackable.  The 1 uW signal eminated from a QRP Labs U2 mept feeding a Cushcraft A3 triband Yagi.  The receiving antenna at W4HBK was a 30/40m inverted V with the apex at 18 meters.

For comparison here is one of the better 10 minute grabs:

It's fun to compare our miles/Watt to that of the NASA's deep space probe Voyager 1 which at a distance of 11.8 billion miles from Earth running a 20 Watt transmitter which gives 590 million miles per Watt.  Of course they are sending HiDef images and telemetry compared to our 6 scratchy letters but on the other hand they are using a 70m dish at the receiving site.

Here is the story from Dave's point of view:

de w4hbk

Friday, April 18, 2014

Frequency Scale Calibration for QRSS Grabbers

Spectrum Lab provides two methods of frequency calibration which can be utilized to set the frequency scale accurately on all bands.  The first applies to calibration of the sound card by injecting a known audio frequency and comparing it to the frequency measured by SL.  Figure 1 shows the Audio I/O screen for entering these values in the "Correct Frequency" and "Displayed Frequency" boxes on the right.  After entering click on the "Calibrate Input SR" and the sound card's Sample Rate will be determined and entered in the "Sound Rate Calibration Table".  I generally use a nominal SR of 11025 Hz and in the actual value is 11099.8922552 Hz which is now applied to the SL measurement.  At this point Spectrum Lab is reading audio frequencies accurately.  I used the standard tones of 500 and 600 Hz provided on the WWV carrier when listening in AM mode.

Figure 1.  Spectrum Lab Audio I/O Screen

The second frequency adjustment is via the "Radio Frequency Offset" value found on the Spectrum(2) screen, Figure 2.  This is the frequency to which the radio is tuned and adjusts the scale to read in units of the actual frequency being received.  For example, on 30m, my rx dial is set to 10138.70 kHz to produce an audio tone of 1300 Hz for 10140 kHz.  If the master oscillator were perfect then the frequencies measured by SL would also be perfect.  However, even the best receivers are off by at least a few Hz (unless locked to GPS or an atomic standard) so a little extra correction is needed.  This can be applied by adding or subtracting the appropriate value to the rx display.  My rx on 30m reads low by 7 Hz and I add this to the offset value as 10138.707.

Figure 2.  Spectrum Lab Radio Frequency Offset 
The offset can be determined in general by measuring the error for several know frequencies and applying a linear regression.  This is possible because the frequency my TS-440 and as far as I know all modern transceivers is controlled by a single crystal.  I used the standard frequencies of 5, 10, 15 and 20 MHz from WWV in Colorado to generate the curve shown in Figure 3.  The linear regression for this data is:

            F(offset), Hz = -0.2 + 0.672*F(rx), MHz,

where F(offset) is the offset needed to correct the received frequency and F(rx) is the receiver frequency.  Ideally the intercept value should be zero but the value of -0.2 is easily attributable to measurement error.  The offset values for each band are also printed on Figure 3 for quick reference.

Figure 3.  Offset Graph and Table
Use of WWV for frequency calibration can be tricky due to Doppler effects caused by motion of the ionosphere.  I made my measurements on a day when ionospheric conditions were settled and at a time when the night-to-day movement should have been completed.  I confirmed this by monitoring the Doppler shift for several hours.

Thursday, November 7, 2013

Comparison of SID detectors

On 07NOV13 there was a Sudden Ionospheric Disturbance which was captured by three amateur receiving stations:

G4JVF VLF receiving NAA on 24 kHz
W4HBK grabber on 10m receiving G0PKT
W5COV receiving WWVB

This is a comparison of the exact timing of the onset of the SID as seen by the three observers.

G4JVF VLF RX Receiving NAA in Maine

W4HBK 10m Grabber Receiving G0PKT

W5COV VLF RX receiving WWVB in Colorado
I measured the times on the first two by measuring distances with a ruler and interpolating.  Marks estimating the onset were placed first and then the measurements taken.  On the last image since the SID wasn't clear to me I calculated the time estimate from the first two and placed that on the figure.  As I understand it's one of the small spikes.

For comparison here is the X-Ray flux measured by the GOES satellite:

GOES X-Ray Flux for 06NOV13 SID

All things considered the agreement is excellent.  At the time of occurrence the Sun was over the Atlantic which would strongly illuminate the skip points for the EU-US path.   The W5COV-WWVB path was almost in the dark and might be expected to be minimally effected by the SID.

Previously with SIDs I had gotten the impression that the QRSS method was more sensitive to the onset time than were other methods.  But now that I have seen them together and put some numbers with onset features  it looks like there is no significant difference.

de w4hbk