This page is intended to document only how I put my system together and a few other miscellaneous items. It should go without saying that there are probably better ways to do these things, that your mileage may vary, blah blah blah...
Back in 2003 I bought a used HP Z3801A GPS receiver (often called a "Z-Box") with the intent of using it as a time/frequency reference. As with most projects, this one was ongoing, with incremental progress dependent on available time and current whim. Nevertheless, it didn't take too long to get it up and running, following the "make it work, then make it look good..." mantra.
Use as a frequency reference:
Why would one need a frequency reference?A known-good frequency reference is handy for making sure that everything else is on frequency. At this location (Utah) reception of WWV on 10 MHz (the most convenient frequency for calibrating against) is very sporadic and it is often difficult to get a good zero beat owing to the constantly changing path and the usual presence of WWVH.
On the status screen of both the HP SatStat program as well as GPSCon (see below) a signal strength indication is given. All the Z3801 manual really says is that this value should be above 20-25 for reliable tracking, and it should be higher than this for best accuracy.
In digging around the Motorola Oncore GPS documentation (the receiver used in the Z3801) I determined that this is an indication of "Signal to Noise Density ratio" (S/No) and is shown in db.
What does this mean, then? This explanation requires a bit of communications theory - so I'll keep the explanation as simple as practical:
Take a relatively weak CW carrier as an example. If your receiver has a bandpass filter 1 kHz wide, let's say that the strength of the that CW signal is the same as total energy in the noise everywhere else in that 1 kHz bandpass. In this case, one has a 0 db Signal to Noise ratio, for the noise and signal are of the same total strength.
It would make sense, then, if you were to cut your bandpass filter down to 100 Hz bandwidth, you'd still be intercepting all of your original CW signal, but you'd be intercepting only 1/10th as much noise. In this case, the CW signal is now 10 db stronger than the noise.
If you take it the other way, let's say that you widen the bandwidth to 10000 Hz (10 kHz) - the signal/noise ratio is now -10 db.
The GPS signal consists of several different signals, all modulated atop the same carrier. If all you want to do is recover the GPS receiver's carrier (but no information) you could (theoretically) use an extremely narrow bandwidth to detect the carrier. For receiving the data, you need wider bandwidth - a bandwidth proportional to the data rate.
So, to keep lock on the GPS signal, a C/No ratio of 20-25 db is the minimum required. This represents a pretty "ratty" signal, however, and the amount of noise present makes it difficult to recover the data stream and timing with great accuracy. As you might expect, increasing the the C/No will reduce the amount of noise - and improve the accuracy of the recovered timing.
How much signal is "enough?" As it turns out, by the time one gets up to a C/No of 45-50 db, enough of the uncertainty (noise) is gone and relatively little improvement may be had (comparatively speaking) by a further increase - at least for the "typical" L1-only (non-differential) GPS receiver.
As it turns out, most receivers don't go through a lot of pains to obtain really good C/No values, so it is more reasonable to take a "sliding average" to get a picture of how well a particular satellite is being received.
(I'm a bit skeptical about the receiver's reporting, though: I have difficulty believing that this parameter is, in fact, accurate when it reports a C/No of >200 db...)
An interesting article that appeared in GPSWorld that describes C/No as well as effects of interference on GPS systems may be found here
The Z3801 receiver:
The receiver itself needs several things to operate:
The "PBJ" (Peanut Butter Jar) antenna:
Generally, an amplified (powered) antenna is employed with a GPS receiver such as this with the receiver (usually) located at some convenient distance - say, in the ham shack. Owing to the very high frequency of the L1 GPS frequency (centered on 1575.42 MHz) typical coaxial cabling has high losses. Because these losses directly contribute to receiver noise figure (and thus, overall sensitivity) it doesn't take very much coax loss before the GPS signal from an unamplified antenna disappears into the thermal noise. Having an antenna with a built-in preamplifier allows the receive system to tolerate significant cable losses without degradation of the actual signal - a factor that also translates to being able to use inexpensive, smaller-diameter coaxial cable such as type RG-6 which is often used for TV and satellite reception.
While a wide variety of amplified antennas are commercially
available, I decided to "roll my own" GPS antenna starting from
the article "An Inexpensive External GPS Antenna" by Mark Kesauer,
October 2002, Pp. 36-39) - ARRL Members only link.
I constructed the turnstile antenna more-or-less described in the article, departing from the article on several points:
Figure 2 shows how the two turnstile conductors (comprising 4 elements, actually...) are mounted atop the short length of UT-141 coax. While not obvious from Figure 2, the bottom end of the UT-141 coax goes through the circuit-board disk with its shield soldered on both sides of the board.
On the bottom side of the board is a simple preamplifier (see Figure 3) constructed using the inexpensive Mini-Circuits MAR-6 MMIC (see the schematic, Figure 5, below.) This amplifier has a moderate noise figure (3-4 db) and reasonable gain (13-15 db or so) at this frequency - enough to overcome reasonable coax losses. This amplifier is powered from the 5 volts superimposed on the coaxial cable: The DC is first decoupled with a coil with the RF being blocked by a chip capacitor, then the DC is bypassed with an electrolytic capacitor. Finally, DC is re-injected into the circuit via another choke. Note that there is no blocking capacitor in the input of the MMIC, so a small amount of DC (about 1.5 volts) is actually present on the antenna - but this isn't any sort of problem.
The output of the amplifier is fed to another length of UT-141
coax which is soldered directly to an "N" connector (refer again
to Figure 2.) This piece of coax is used to support
the antenna and its circuit board, and the entire assembly is
"captured" by the glass jar. If preferred, one could use a
BNC or even an "F" type connector (if one used RG-6 coax, for
example) but in any case, one must assure that the connector is
adequately waterproofed upon installation.
Figure 4 shows the PBJ antenna installed on the roof. In this installation, the coax (about 60' - or approximately 20 meters of RG-11) is fed up through the center of the pipe to which another antenna is mounted. The antenna is secured partly by the weight of the coax pulling down, and partly by the black nylon wire ties which tie to a mast clamp below the GPS antenna. It is worth mentioning that while the antenna mast to the right of the PBJ antenna (due south) somewhat blocks the view to the south, it doesn't appear to have any significant effect on the received signals.
Some eyebrows may be raised concerning the use of the MAR-6 as
the amplifier. True, there are more modern, lower-noise
MMICs around - and if you have one, by all means, use it!
The MAR-6 (also known as the MSA-0685) is relatively noisy at this
frequency - a noise figure of 3-4 db or so - but because the
current generation of GPS satellites have such strong signals, a
full-sized antenna that is in the clear gets plenty of
margin. Also, owing partly to aperture, a full-sized
turnstile antenna such as this is likely to intercept a little
more signal than a dielectrically-loaded (i.e. smaller) patch
antenna - something that can help make up a bit of lost signal.
In looking at the track map and statistics, the tracking ability
of the receiver/antenna system appears to be limited only by
horizon visibility. To the southeast and west/northwest,
visibility is somewhat limited by some tall trees - but in other
directions (due south, due east, southwest) only mountains
(elevations of <3 degrees, typically) limit the view.
During initial testing I'd seen the GPS receiver track satellites
as low as 4 degrees - but this was rare because there are usually
enough satellites at higher elevations and the receiver rarely has
to try to track those...
Comparison of the homebrew antenna with a commercially-made antenna:
For several weeks (ending 3/10/04) I used a commercially-made GPS antenna instead of the homebrew. The antenna used was a Magellan OEM-type of antenna (the round, white one.) The results were observed to be as follows:
How well has this antenna held up? As noted below, I had repeated problems with one solder-tack joint breaking loose (until I encapsulated it in clear epoxy) but it has been on the roof since at least 2003 and shows no obvious signs of degradation.
Putting this antenna on the roof:
The best location for any GPS antenna is one with a clear view of the eastern, western and southern horizons (or northern horizon, if you are down 'unda, or both if you are nearing the equator.) In North America and Europe, for example, the inclination of the GPS constellation causes the minimum elevation to be fairly high. In most cases, therefore, the preferred location for mounting the antenna is on the roof.
What are the mounting options? A few come to mind:
Unfortunately, none of these are viable options on my roof::
You could also make your own mount from a metal plate sized to accommodate two side-by-side cement blocks. Using angle brackets and a piece of pipe, one can make a suitable mount for small antennas. One would also use one or two pieces of metal as a "strut" not only to stabilize the pipe but to make the pipe sit vertical to accommodate the pitch of your roof. Under this plate, one would put the protective mat, and atop the plate, the two cement blocks: Two are recommended as they form a "square" footprint, aiding in mechanical stability.
A few comments:
Needless to say, these are suggestions: It is up to you to do the appropriate research and take appropriate safety measures!
The power supply:
After originally using a voltage-doubled 24 volt AC "wall wart" I replaced it with a a cast-off "48 volt" 2 amp switching-type supply from a telephone switch. A simple modification was made to raise its voltage from 50 to 56 volts (the addition of a parallel resistor which was done to keep the Z3801 happy.) The supply was mounted in a metal box and "brute-force" L/C EMI/RFI filtering (their circuits similar to that depicted in Figure 7) was added on both the input and output to keep its switching supply noises out of my amateur receivers. In the years since it was put into service, I have had no troubles with it at all - but that should be expected from a high-reliability device intended for telephone use.
There is one "gotcha" about using switching supplies with the Z3801A: The Z3801A itself has a switching-type supply - and like typical switching supplies, it has its own start-up issues:
The solution to this problem? Actually, the fix is a very old one: Delayed start. If you power up the supply - then connect it to the GPS receiver - it may do just fine. This "delay" may be done with an old-fashioned relay and delay circuit, or one could take a solid-state approach and use a transistor (bipolar or MOSFET) switch.
Power supply RFI:
As mentioned before, the Z3801 uses a switching supply to generate its internal voltages. Actually, it uses several...
One of my "sub-hobbies" is LF/VLF listening. Several years ago, with winter arriving and the summer static subsiding, I decided to test my LF receive setup once again and was greeted with a noise floor about 30 db higher than I was expecting. Presuming that the antenna itself was having some problems, I checked further and no, there wasn't a problem with the antenna at all - but that it was an external noise source. It was now time to start shutting things down and/or disconnecting things.
The "Ah Ha!" moment came when I disconnected the antenna from the GPS receiver and the noise dropped 15-20 db. Shutting the receiver off (something that I hate to do...) returned the LF receive antenna system to its expected performance levels...
At this point, I knew what I had to do: Add a power supply filter in the Z3801. Note that this racket was not coming from the outboard AC supply mentioned above which I'd already filtered, but from the Z3801 itself, via its DC power connector/cable.
Removing the top cover, the obvious place to mount a filter was
in a clear spot against the back panel - next to the power
connector, so I carefully cut a piece of circuit board
material to the maximum size that would fit in the space and
mounted it with two screws.
Then, the power connector was removed from the chassis and disconnected from the input on the power supply board. I then carefully "un-crimped" the "board-end" of the internal power cable and soldered longer wires to it - although I could have simply cut and spliced. Doing this gave me a long enough run of wire to go from the power supply input to the (to be added) filter.
Effective filtering at VLF/LF/MF frequencies isn't as
straightforward as it might seem - especially when higher currents
are involved. Too often, I have seen hams simply slap
ferrite beads on QRM sources - only to be disappointed when doing
so wasn't particularly effective. Furthermore, simple
ferrite beads and snap-on chokes only have effects above several
MHz anyway and will do absolutely nothing at VLF/LF and MF
frequencies and are only mildly effective at HF in most cases.
Referring to the schematic in Figure 7, L1 was salvaged
from a computer power supply. Typically, these chokes come
in three flavors: A bifilar-wound toroidal choke, a toroidal
choke that has a winding on each half of the core, or one that
looks like a small, square power transformer with two distinctly
separate windings side-by-side. In either case, both
windings are tightly coupled together and any common-mode energy
passing through them is suppressed significantly. If you
have a means to do so, make certain that this choke has
quite high inductance: The choke that I used measured about
1.5 mH (that's Millihenries) per winding and thus has
enough inductance to offer significant reactance at LF frequencies
(nearly 100 ohms at 10 kHz.) If you don't care about
frequencies that low, then a choke with lower inductance may be
used. Remember: We are trying to keep LF
energy from the switching supply inside the GPS receiver
from being conducted onto the power cable!
L2 can be either a choke similar to that of L1, or it may be two smaller inductors. Their primary purpose is to keep HF out of the receiver and thus, the inductance of each winding (or inductor) may be in the 10-100 uH range (or higher, if you wish.) Finally, C8 is used to make any energy entering (or exiting, for that matter) the GPS receiver's power supply common-mode. Resist the temptation to connect a capacitor to ground at this point because any RF energy entering on the power supply lead will find it as a low-impedance path to the chassis: Let L2 do its job and choke it out, first!
Finally, make certain that all capacitors that you use are rated for the voltage: Ratings of at least 100 VDC are recommended on all capacitors. If you don't see a voltage rating plainly printed on the component, don't use it!
The results of adding the filter were good: No detectable
noise on LF, MF, or HF emanates from the GPS receiver anymore!
Other modifications - Improved heat-sinking of the power converter modules:
While I had the GPS receiver apart I decided to make another
modification: The addition of more heat-sinking to the
DC-to-DC converters inside the GPS receiver.
These are flat, square-ish modules with obvious printing on them
indicating their input and output voltage ratings. During
testing, I couldn't help but notice that they were "hotter than
hell" - too warm to touch comfortably. Knowing that the
reliability of any electronic device is inversely proportional to
its operating temperature I decided to do something about it.
Rummaging around the junkbox I found a few small CPU-type heat
sinks. Noting that the DC-DC converter modules already had
tapped holes in them for mounting, I found some mating machine
screws in my hardware collection and, along with white heat-sink
grease, I attached heat sinks to these supplies.
The result was that the temperature of these modules went from
"too hot to touch" to just "very warm" - a definite improvement!
Knowing that doing so would make the receiver potentially
more-sensitive to variations of ambient (room) temperature, I
resisted the temptation to put a small DC-powered fan inside the
The RS-422 interface:
One popular scheme is to utilize the Z3801's built-in RS-232 circuitry. Although installed, it is not connected by default - a process that takes some minor surgery to complete. Because this procedure may be found on the K8CU page (see below) it is not detailed here.
Several years ago, I was hiking with a group of hams, and we happened to be using a simplex frequency of 146.52 MHz. I also happened to have my GPS receiver with me (back then, a Magellan GPS-4000 - non-XL version) turned on. I couldn't help but notice that it didn't seem to be working very well at all: It was constantly losing lock on all satellites.
When we stopped for a break, I happened to let my HT (a Yeasu FT-530) do it's timed auto power-off: Since our group was all together in one place, there was no need to leave the radio on. I then noticed that my GPS receiver was working normally.
Putting two-and-two together, I surmised (and later verified) that the '530 was, in fact, jamming the GPS receiver. Here's how:
At 146.52, the FT-530 uses low-side injection for its local oscillator. With an IF of 15.25 MHz, this places the LO at 131.27 MHz - the 12th harmonic of which is 1575.24 MHz - almost exactly on the L1 GPS frequency of 1575.42 MHz. Apparently, when the GPS receiver and the HT are within a few feet of each other, there's enough LO energy present to "jam" the GPS receiver!
The cure for this problem? We now use a 147 MHz simplex frequency - which isn't as busy, anyway...
A question that may come to mind is, "Why use RS-422 in the first place?" The question is one of robustness. RS-422 is a differential signaling scheme - that is, each signal is transmitted on a twisted pair - with the two conductors carrying equal and opposite signals. This has the advantage of being able to handle "common mode" interference without corrupting data. What is common mode interference? Simply put, a common mode signal is one that travels down the pair of wires in unison - that is, not differentially. The common mode signal, affecting both wires equally (in ideal cases) is ignored by the receiver - which is looking only at the difference between the two wires.
Because of the differential nature of this scheme, it is possible to run RS-422 signals for miles - the distance being limited mostly by the high frequency response of the wire pair limiting the data rate. A note here: Even though RS-422 doesn't use the "ground" wire for signaling, per se, one is strongly recommended to limit the swing of the common mode signals on the wire pair to a level that the receivers can handle.Another important reason for using RS-422 over RS-232 is that '232 has in inherently slow slew rate - that is, it can't swing very fast. While RS-422 is capable of carrying signaling rates of several megabaud (for short distances) this simply isn't the case with RS-232. What this also means is that if you want to use the GPS receiver for absolute timing accuracy with the 1PPS output, you don't want to use the RS-232 output unless you take into account the "slowness" of the RS-232 hardware - and the likelihood that this reference is likely to drift around a bit as thresholds in the RS-232 hardware change with time and temperature. This isn't likely to be too much of a problem for the vast majority of users, as the difference is only likely to be a fraction of a microsecond, anyway...
All of that being said, I've been too lazy to build an
RS-422<>RS-232 and have stayed with the "kludge" from the
beginning. The only "problem" that I had was when I recently
interfaced the receiver with a computer that had no built-in
RS-232 port and I had to use a USB<>RS-232 adapter.
When doing this I noticed that the more-expensive Belkin adapter
didn't work at all, but the cheap, no-name adapter that used the
"Prolific" chipset has worked perfectly and with no errors at all.
Use as a time reference:
It would be nice to be able to, say, drive a clock and supply GPS information to a host computer. Being that there is only one serial port on the Z3801, one would have to multiplex both systems in a manner that the Z3801 can support. I'm currently working on a PIC-based controller that will do the following:
Status of the GPS receiver at KA7OEI:
- April 2015: No changes - everything is still working!
- March 2013: Making the GPSCon
SNTP server work under Windows 7
No problems for a while other than the fact that
my web page provider stopped supporting FTP - the only
protocol that GPSCon "knows" about. The
work-around was to write a script for the "WinSCP"
program that would use SCP (Secure CoPy) to relocate
the file from the directly defined in GPSCon to the
appropriate place on the web server. Every hour,
a scheduled task (under Windows XP) fires off a batch
file that causes the files on the web server to be
I also help a friend get GPSCon working properly
on his Windows 7 machine and this was a multi-step
process to permit it to function as an SNTP server and
allow GPSCon to set the system time. If you
don't do this properly, you can get this cryptic error
in GPSCon that says something like "Cannot set time
from F2" (or something close to that...)
1. GPSCon must be set to "Run as Administrator" if it is to have permission to twiddle the system time and/or be an SNTP service. This can be done manually (e.g. right-click and select "Run as Administrator") or, better yet, after right-clicking, go to Properties and set this program to always be run as an administrator. If you want the program to start when you boot the computer, you can set this as a scheduled task - but make sure that you set administrator privileges there as well!
2. You must STOP the Windows Time
service. To do this, under the "Start" button
enter "services.msc" on the line where you enter the
name of a program. Once the program comes up,
look for "Windows Time" and then right-click on it,
select Properties and then press the button that says
STOP. You must then go up to the line that says
"Startup Type" and select "Manual" so that it doesn't
start again when you boot up. REMEMBER:
Once you stop this service, your computer cannot
every synchronize itself to internet time again
until/unless you re-enable this service (e.g. start it
and set it to "Automatic.) If the GPSCon program
is always started on bootup and synchronizes
itself to your receiver, your system time will always
be properly set, but if you don't do this, it
will drift off!
3. In GPSCon, you should verify that you
are getting good time response from the GPS receiver
and that you have actually enabled SNTP. One
thing for which you should check on GPSCon is that
your main status screen says on it, just below the
time and date, "1PPS CLK Synchronized to UTC".
If it says that it is synchronized to GPS it will be
16 seconds off (as of March 2013) and one must issue
the command " :diag:GPs:utc 1 " (Include the colons,
but not the quotes) and then reboot the GPS receiver
for it to take effect. Remember that in
resetting the receiver, it will take a day or three to
fully re-synchronize and settle in again!
4. If you want to use the computer on
which GPSCon is running as a local time server, it must
have a static IP address, and it would be this address
that you set in other computers (including Windows
boxes) as the source for the internet time.
Windows XP and 7 are both perfectly happy with getting
their time from an SNTP source such as the GPSCon
5. REMEMBER: As noted above, you
should set your UART FIFO to zero bytes or, better
yet, un-check the "Use FIFO Buffers" box un the
"Advanced" properties under the serial port in "Device
Manager". Failure to do this will induce random
delays/offsets in the computer's synchronizing to the
GPS receiver since the FIFO will take some finite (and
essentially random) period to time out.
6. In the configuration screen in GPSCon
there's a setting for the delay between the "real"
time and what GPSCon is able to discern from the
receiver. Because it does not look at the 1PPS
pulse from the receiver, GPSCon has to quickly query
the receiver to determine when the second changes, and
this has a bit of a delay which may be compensated by
this value. I've found that the default value is
"pretty close" and is likely good enough for most
applications. One should also be aware that most
programs that display the system time (such as the
Windows' built in clock) doesn't necessarily update
the clock exactly on the second, so if you were to
listen to WWV and watch the clock, it may be slightly
off. There are other programs that can more
quickly query the clock and updated it, one of which
is the WSPR program, which seems to do a decent job of
minimizing the delay between the display and the
system time. If you feel adventurous, you can
tweak the delay value in GPSCon to dial this in as
good as it will get, but don't expect it to
consistently be better than a few 10's of
milliseconds! (Re-check your FIFO settings
if you find the time wandering about by more than,
say, 100 milliseconds!)
I've been using GPSCon to synchronize some of
the computers at home (e.g. the ones that stay there)
for several years now. One advantage of having
your own time server is that is you use an amateur
radio mode like WSPR that requires good time
synchronization to work properly, you can query your
local time server many times per day: Many
public time servers will not allow you to
query them more than once or twice per day!
- March 2011: Two problems:
1. It looks as though the "PBJ" antenna
has gone intermittent again. So far, it only
seems to do it for a short time, when it is
cold. As noted before, this could have been
prevented at the beginning by better-connecting the
MMIC's input lead to the UT-141 coax center
connector. When the weather is nice - and I have
more time - I'll pull it off the roof to see if it's
that same problem, or maybe a problem elsewhere.
After a few weeks, it stopped dropping out, so it
may have been snow-related. If it happens
again in the summer I'll pull it down and take a
2. I (think that I) finally solved a
problem that showed up with the new computer - and had
showed up on the old one, too. Since computers
no longer routinely come with RS-232 serial ports, I
had to use some USB<>Serial adapters. I'd
tried this on the old 366 MHz laptop with its single
built-in serial port, but when I tried to use a USB
adapter, it would crash after a while. I just
chalked that up to problems with the old computer and
When I switched to the "newer" computer (1.7
GHz) which had no RS-232 ports at all, I had
to use a serial port for the WX Satellite receive and
another for the GPS receiver. As noted above,
the Belkin didn't talk to the "Pseudo RS-232" level
from the RS-422 port on the GPS receiver - but the
no-name "Prolific" chipset-based adapter did!
All was well for a while - and then I started to
get more and more "BSOD" crashes with a cryptic
"USB_BUGCODE_DRIVER" error. By the process of
elimination, I determined that it was the Belkin
USB<>Serial driver. Putting another
generic "Prolific" chipset driver on there solved the
problem - and it was likely the same problem on the
It seems as though, if you were to put the same,
identical USB device on the same physical USB port
(this may not apply to an outboard USB hub, though)
then it will uniquely identify it for that USB
port. In other words, if you put a particular
USB<>Serial port on, say, the 1st USB port and
assign it COM1, it will ALWAYS be COM1. If you
move it to the 2nd USB port and assign it to COM2, it
will always be COM2 when plugged in that USB
port. (Note: To pick your COM port you
must force it to the desired COM port in the
hardware configuration screen or else it may just
pick the next-available COM port - usually a high
number like "COM5" or above. Note that the
"Com port already in use" warning you may get can
refer to a USB<>Serial port that had been
previously installed - but not necessarily one that
is plugged in at that moment! In other words,
if you EVER had a COM1 in the past, it will mark
that is "in use".)
The advantage of having two different-brand
USB<>Serial adapters is that they will never
be confused with each other as the computer cannot
mistake them for each other. In this case,
however, since I ended up using two "Prolific"
USB<>Serial adapters, I just had to make sure
that I always knew that "COM1" was associated with one
USB port and that "COM2" was associated with the
other reports, I've had no problems with the
"Prolific" chipsets on XP... 'dunno...)
- January 2011: After being online
for about 8 years everything continues to work fine -
including the "PBJ" antenna, which has been in the
weather, on the roof for just as long! The
receiver is now being monitored full-time as I now
have a low-power computer dedicated to the task - one
which also provides a local SNTP server for digital
modes - see above.
I also noted the GPSCon wouldn't always start up
in the "running" mode when the computer came up after
a power bump: While I'd scheduled GPSCon to be
started just after auto-login, it just came up in
"idle" mode which meant that it wasn't pulling the GPS
receiver, providing SNTP service or collecting log
Looking at the GPSCon web page I noticed that
the very next version after mine
included a check-box to auto-start the program - but
I'm a bit reluctant to pay for yet another upgrade for
a program that hasn't been updated recently and
wouldn't offer any other feature that I don't
What seems to have worked as a "fix" is to go
into the registry and set a key. Using Regedit,
I went to:
HKEY_CURRENT_USER, Sofware, GPSCon, Initial,
and changed that value from 0 (zero) to 1 (one.)
- March 2008: Not much to report, really: The "PBJ" antenna and the Z3801 continue to work. Note that the computer connected to the Z3801 is not used very much, so the graphs on this web page are not updated vary often. I had one more instance of the solder tack joint breaking loose as described below, but I repaired it and then encapsulated the joint with clear epoxy.
- July 2004: I recently had some trouble
with the Oncore GPS module: After a power cycle,
it would never lock and making it load defaults
resulted in it believing that it was in an impossible
location (e.g. at "596 degrees west and east at an
altitude of 13k miles or so) and due to "bad geometry"
the survey would never complete. I remedied this
by building an interface to power the Oncore module
and connect it to the computer and, using the Motorola
"WinOncore" program was able to reset the
receiver and successfully test it. Upon
re-installation, it again exhibited some strange
behavior - but I was able to work around it. (It
may be heat-related: Further investigation is
I was able to find an 8-channel Oncore unit and
installed it - along with a "super-cap" to hold the
RAM during power failures - in the Z3801, solving the
receiver problems. I also noticed
previously-noted susceptibility to about any VHF or UHF
transmission from my shack causing the receiver to go
into holdover was now gone - probably related to the
fact that the new receiver had a bandpass filter and
the old one did not!
- March 2004: For several weeks (until 3/10/04) I was using an OEM Magellan GPS antenna to compare it with the homebrew unit. The results of this testing are in the text, above.
- September 2003: On about 9/27/03, I fixed the GPS antenna. For some weeks prior to this, I'd intermittently lose all GPS signals. The problem got worse - to the point of total loss, but I didn't have time to look at it until the 27th. The problem turned out to be a solder tack joint had failed where the UT-141 coax from the turnstile connected to the input of the MAR-6.
This change was done as part of the
"permanentizing" of the receiver installation.
Much work remains to be done...
- May 2003: Initial installation of
One problem that I need to address is receiver jamming. When I operate 2 meter SSB, for example, the receiver loses lock on all satellites. Why is this? There are several possible explanations:
As it turns out, I answered the question (at least partially) by substituting the homebrew antenna with a commercial one. Because the commercial antenna was unaffected by the presence of a 2 meter transmitter, the "theory" that weak harmonics are the culprit was discounted. It could still be that the amplifier and/or the receiver itself are being overloaded by the presence of the local 2 meter signal.
What if it is the second situation? A simple bandpass filter stuck inline (a relatively tightly-coupled 1/4 wave cavity filter) would take care of the problem. The "awkardness" here is that I'd have to feed the DC (for the amplifier) around the filter. (I'll probably just build a GaAsFET preamp and avoid the problem...)
What about the last one - weak harmonics of the 2 meter
signal? Because I don't think that this is likely to be too
serious a problem, I haven't given it much thought. In
reality, the occasional nature of the SSB operation - and the fact
that the receiver seems to recover nicely from "holdover"
(resulting from loss of GPS lock) may make it so that I'll just
live with the problem...
(Again, since I replaced the original GPS module in my Z3801
with one that used a bandpass filter, the loss-of-lock that
occurred when a local transmitter was used is now very rare.)
Now, I wonder how things will work when I fire up my 23cm transverter???
This page will be updated as time goes on - check back later...
For more info on the Z3801A, the GPSCon program and other GPS receivers used as time/frequency references, go to K8CU's page at:
Any comments or questions? Send an email!
This page and its content copyright 2004-2013 and maintained by Clint Turner, KA7OEI and yes, I know the background is for the MedFER beacon... Any trademarks are the property of their respective owners. This page last updated on 20130304