Digital modes & the importance of synchronization

WSJT-X waterfall showing good synchronization

When using the newest digital modes (such as JT65, FT8, FT4, etc…) to decode signals well into the noise floor, it is imperative to have accurate time. More accurately, it is important to have good synchronization. Many modern protocols used today rely on consistent start/stop times to establish decoding windows. Being ±1s becomes important!

I am no horologist, nor do I claim to have any depth of knowledge on the topic of time and time keeping, however, it is an interest of mine and so I will discuss some concepts in a very basic form. For the sake of brevity, I will omit concepts as : oscillator aging, derating, Allan variance, etc.

WSJT-X time offset of +1s
WSJT-X transmission showing leading time offset of +1s

Sometimes, you will see “DT” values >1s when operators have not been careful to ensure system clock synchronization.

Interestingly, all that truly matters is the synchronization of the beginning of the minutes; your clock could be off by 1, 2, 40 minutes and so long as the change-over time between minutes is synchronized with other operators, decoding should work fine. Taken a bit further, if the protocol uses 15 second “frames” such as FT8, it is the beginning of the “frame” that needs to be synchronized.

FOCS 1, a continuous cold caesium fountain atomic clock in Switzerland, started operating in 2004 at an uncertainty of one second in 30 million years.
By METAS –, doi:10.1007/s00340-006-2398-4, Public Domain

Luckily, there is a well-established protocol that allows a network of computers to establish and maintain consistent time across machines. Most modern computers rely on NTP servers to establish and maintain their local time. A good choice would be:

More on that in a moment.

NTP allows for mass-synchronization which for our purposes is more important than time accuracy.

If you’ve been in the computer game long enough, you may recall the days of on-board batteries failing and having to reset CMOS settings as well as time and date. Motherboards of most modern devices tend to have built-in real-time clocks (RTC) with battery back-up which “keep the beat” and maintain system time, albeit with some degree of local “drift”. This drift comes from inherent instabilities of the real-time clocks which may exhibit frequency accuracy of 10-20ppm which corresponds to an approximate drift of between 1 and 2 seconds per day.

 1s / day  = 1s / 86400 s/day *
          = 1.15 x 10e-5 / day
          = 11.5 x 10e-6 / day  [ 10e-6 = PPM ]
          ≈ 11.5 PPM to lose 1 second per day

1s / year = 1s / 3.153 x 10e7 s/year
          = 3.168 x 10e-8 / year
          = 31.7 x 10e-9 / year [ 10e-9 = PPB ]
          ≈ 31.7 PPB to lose 1 second per year

* TAI (International atomic time) seconds are shorter than UT1 (Astronomical) seconds by 0.03 PPM which led to the creation of “leap seconds” (37 have already occurred) in the UTC system, the next of which is predicted to occur June 30 2020.

seconds per day  = 60 s/min * 60 min/h * 24 h/day
                 = 86400

seconds per year = 60s/min * 60min/h * 24h/day * 365.25day/year
                 ≈ 3.154 x 10e7
Chip scale atomic clock (CSAC) by Microsemi
Chip scale atomic clock (CSAC) by Microsemi

Clock systems such as the GPS constellation have an accuracy of between 10-8 and 10-11 PPM which means that a clock with the equivalent attributes would lose 1 second every 3 to 3000 years.

If you have some $$ to spend ($2175 for 1 unit; at the time of writing), you could have <±5 x 10-11 accuracy with a chip scale atomic clock (CSAC) which would give a (simplified) drift of ~1s in ≈633 years, not properly accounting for aging.

1 PPM = 10e-6 ; 1 PPB = 10e-9 ; 1 PPT = 10e-12
5 PPM = 5 x 10e-6 .. etc

To calculate seconds lost per year using PPM:
(# PPM) * (1e-6) * (3.154 x 10e7 sec/year)

or more simply:
# PPM * 31.54 sec/year

E.g. 5 PPM = (5) * (1 x 10e-6) * (3.154 x 10e7 sec/year)
= (5) x (31.54 sec/year)
≈ 158 sec/year

Excel sheet to do basic PPM / PPB calculations: PPM_calcs.xlsx

DS3231 RTC battery backed-up module for Raspberry Pi
DS3231 RTC battery backed-up module for Raspberry Pi

It should be noted that some devices such as the Raspberry Pi do not have a battery backed-up RTC on board and thus rely heavily on NTP to set and maintain accurate system time. If you need to use a Raspberry Pi without NTP access, it would be recommended (at a minimum) to add an RTC to your design.

The DS3231 is specified to have an accuracy of ±2ppm which means at the nominal operating frequency, it would lose (on average) 63 seconds per year.

Better yet, you can turn a Raspberry Pi into a highly effective GPS disciplined time server if you use a GPS receiver with a PPM output! This will be the subject of a future write-up as I have built my own GPS disciplined time standard which has some impressive accuracy (≈5 PPB, put another way, it would take approximately 6.3 years to lose a second).

For those using Windows as their OS of choice, you will need to make some modifications to your system to keep the most accurate time possible. This is because although Windows will use NTP to update the system clock, it is not done frequently enough! One option is to download and install software which forces the system time to update more frequently, the other option is to make some modifications to the registry file. Run the registry editor as follows:

 click on start button and simply type: regedit then press enter

You are looking to navigate through the branches to the following:

SpecialPollInterval editing in windows registry; HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\W32Time\TimeProviders\NtpClient

Double click on SpecialPollInterval and then select the decimal radio button. Enter an interval (in seconds) to have the system poll the NTP server of your choice. I use 900s (15 minutes) as I am polling my local stratum-1 time server. A value of something like 7200 is enough to keep good time and not spam the time servers with too many requests. If you do set up your own local NTP server, spam it to your heart’s content!

To make configuration quick and easy, I have created a regedit merge file with the aforementioned parameters which will configure Windows to use and to update every 2h (7200 seconds = 1c20 in hexidecimal). Simply download the merge file (right-click on link and “Save link as”) and then double-click it to merge the contents. For safety, it is best to right click and select “edit” to validate the file prior to double-clicking it.


Your system should now be configured to connect to the NTP server pool every 2 hours to update your system time. Good stuff! You should now see DT (difference of time; offset) values approaching 0 in your favourite weak-signal mode software (provided other people have good synchronization also).

Posted in General, Operating, Project | Tagged , , , , , , , , , , , , , | 2 Comments

SG-230 Smartuner (Antenna coupler) investigation

I am fortunate that I have in my possession an SG-230 Smartuner remote automatic antenna coupler. This unit is capable of “tuning” a wide variety of antenna configurations from 1.6 to 30 MHz at power levels between 3 to 200W (PEP) and 80W (Continuous). Contrary to my usual method of operating, I took a moment to read the entire manual cover-to-cover. A summary of some of the specifications can be found in a comparison brochure which SGC provides. By the way, SGC provides a great deal of useful information such as an HF guidebook – lots of great information to be found!

SG-230 mainboard showing top layer of board and bodge wire near CPU
SG-230 mainboard showing top layer of board and bodge wire near CPU

Although, this unit is a few years old, it should certainly meet my goals. My intermediate-term goal is to use this coupler to allow the use of random long-wire antenna systems while camping. My present goal is to press the unit into service as a long-wire loop antenna coupler for an attic installation. As the SG-230 comes to be as a status-unknown unit, I wanted to bench-test the antenna coupler prior to deploying it in a difficult to access location. I started by having a look under the clam-shell to perform a sniff-test and to look for any signs of abuse.

SG-230 CPU version 1.03 dated July 2006 and bodge wire visible
SG-230 CPU version 1.03 dated July 2006 and bodge wire visible

Lo-and-behold, a bodge wire jumps out at me right away. The wire runs between pin-9 of a 74F74 and pin-1 of a 74HC393D. Investigating a little further, it looks like a rather shoddily done bodge at that! I really hope this was not done by SGC themselves; the quality of work on this is pretty poor, and the work was not cleaned either.

I took pictures so that I could later refer to the images for settings such as jumpers, CPU version, etc. I am glad I took these photos to better document this investigation.

Now there are many reasons to run a bodge-wire, namely when a problem in a design is identified and it is not practical to spin-up a new board immediately. This would likely have been fixed in subsequent designs, were it an actual design issue. When a bodge wire is found in a relatively simple design, it may be beneficial to investigate a bit further. Was this a repair? or a design re-work?

74F74 Dual D-Type Positive Edge-Triggered Flip-Flop pinout
74F74 Dual D-Type Positive Edge-Triggered Flip-Flop pinout

Never the less, let’s dive into the details. What exactly are the devices and does it make sens to have run the bodge wire the way that they have? Referring to the datasheets for the 74F74, we discover that this IC is a dual d-type positive edge-triggered flip-flop. This is likely used to convert an analog waveform to a digital fast-edge binary waveform for frequency measurement. It is likely that the output of this flip-flop goes to a counter or a buffer. The 74HC393D turns out to be a high speed CMOS 4-bit binary counter.

74HC393D high speed CMOS 4-bit binary counter pinout
74HC393D high speed CMOS 4-bit binary counter pin-out

Looking at the pin-out of each IC, it is apparent that the CK1 pin and Q2 pins are tied together and this makes sense for converting an analog waveform and then counting the resulting signal. It may be worth probing the traces between the two IC pads to see what the issue is/was. It may be that there is no electrical connection between the pins on the board (layout issues, forgotten pads, etc) or it may be that there is a compromise of some kind which negatively impacts the operation of this (supposed) frequency counter circuit. To really dig into this, I would need to remove both ICs to probe the pads properly. I would also be interested to know if as part of the bodge, they “lifted” either of the pins to isolate them from the PCB. So many questions!

Detailed view of bodge wire between 74F74 (Dual D-Type Positive Edge-Triggered Flip-Flop) and 74HC393D (high speed CMOS 4-bit binary counter)
Detailed view of bodge wire between 74F74 (Dual D-Type Positive Edge-Triggered Flip-Flop) and 74HC393D (high speed CMOS 4-bit binary counter)

Also note that there appears to be a (deliberate) solder bridge on pin 14 (Vcc) of the 74HC393D to a near-by SMD resistor. Using pin-14 of the 74F74, I was able to ascertain that the solder bridge to pin-14 of the 74HC393D makes sense to provide a Vcc source to the IC through the common PCB trace wire running vertically along side the two ICs.

My question here is: was this an intentional solder-bridge or an accident? My guess is that someone goofed on this portion of the circuit design, requiring two bodges in this PCB version. If anyone out there has an SG-230, I would be VERY curious to know if you have a similar bodge as I found. Please let me know if you can!

Being fairly confident that the bodges found would not negatively impact the operation of the antenna coupler, and with no other evidence found in a quick sniff and poke of the board, I powered the unit (observing the correct polarity, which apparently has been an issue for some users). Brief testing yielded no magic smoke being let-out and what appeared to be good function of the unit. Time to install it in my attic! If ever you run into issues with one of these units, SGC put out a troubleshooting guide to refer to; I can really get behind a company that demonstrates the right-to-repair.

One last note, with HF radios which “fold-back” power during SWR mis-match, sometimes an antenna tuner or (in this case) coupler is not able to find a match due to the low input power. It may be necessary to increase the power output during high SWR events. Here is a description of how to accomplish this task on a Yaesu FT817.

Posted in General, Operating | Tagged , , , | 10 Comments

Electronics as a hobby ..

For many years now, I have enjoyed electronics as a hobby; something to keep my grey matter engaged and a creative outlet to solve real-world challenges. I view every “problem” which I encounter to be an opportunity to devise an overly: designed, engineered, built, complicated … (pick one) solution.

Were I a real bona fide engineer, I would be designing and building my solutions down to the bare minimum required to resolve the challenge. Engineers spend untold hours optimizing and redesigning, looking to eek out every last bit of design genius or efficiency. Not me! There is no thrill like overkill. Besides, just because you can do more with less, it doesn’t mean that: you have to, it is a good idea, or even necessary.

On to a (relatively) recent example of a problem in search of a James solution.

Picture of the backyard showing fruit tree orchard, raised planers / herb garden, apiary, quail hutch and garden.
Locations (aside from lawn) where irrigation / water are required

When we bought our property, Julie and I decided that we would convert a brick structure in the back into a raised garden for herbs and strawberries. We also wanted to make a garden, so we did. Backing onto a creek, I decided that I would draw surface water for our gardening needs. Naturally, I wanted to know if a permit was required and the answer was: maybe. In our case, for personal use, less than 50’000L a day, a permit was not required.

View of backyard showing creek and pump location
Backyard showing location of water.

Hoping to also one day install an irrigation system for the lawn (or at least portions thereof), I set to looking for an appropriate irrigation zone controller which is both user programmable and “weather smart”. My initial searching revealed commercial offerings starting at $300+ for what I wanted. Being cheap and knowing full well that I could make precisely what I wanted (for around the same price), I set out to making my own.

Requirements: The custom irrigation controller must be capable of at least 8 zones and have WiFi connectivity so that programming changes could be made via web interface. The user would have the option of making it available over the public internet, but in my case, I know better and would make my own IoT device live behind a firewall in its own VLAN allocation. Having the basic requirements down, I decided to make an interface between a Raspberry Pi and the logic and control of a 24VAC irrigation system.

Photo by Gareth Halfacree from Bradford, UK – Raspberry Pi 3 B+, CC BY-SA 2.0

The Raspberry Pi 3B+ was released April 2017 and boasted new features, of which included built-in WiFi and Bluetooth connectivity. Bonus! As it turns out however, due to distance, a USB WiFi adapter with an external antenna connector is a better choice. I was still able to use the Pi’s WiFi but it required installing a yagi antenna on one of my access points and pointing it at the controller.

Eagle cad photo from website

I fired up an old, free version of Eagle CAD and started working away. Being that I started with Eagle CAD many years ago, and having made many rookie mistakes with using provided parts libraries, I set out to create my own entirely hand-made library from data-sheets of components that I planned to use. I started by looking at the mechanical drawings of the Raspberry Pi 3 (chosen for its newly added on-board WiFi). With a part footprint and schematic drawn up for the Pi, I was able to start making the interface.

Raspberry Pi 3 GPIO header and mounting holes PCB footprint.

I started with the footprint of the Raspberry Pi so that I knew roughly what the layout requirements would be in terms of interfacing with the GPIO and power pins. In this design, I opted to use the I2C interface to avoid using 14 GPIO pins for mundane on/off switching. To multiplex the I2C out, I used the venerable MCP23017 I/O expander. Down-stream from the MCP23017, I used a pair of ULN2003 Darlington arrays since the Raspberry Pi has an output voltage of 3v3 and a current limit of 16mA.

My plan was to drive relays (be they mechanical, or as I ended up choosing, solid state) since the Raspberry Pi could not handle the voltage or current requirements directly.

Board layout for Raspberry Pi power supply section

Relays would switch the standard 24VAC used in irrigation systems. Knowing that I would have to step-down 110VAC to 24VAC, I selected a step-down transformer ($17!!) with enough current handling to both drive the irrigation solenoids, as well as power the Raspberry Pi.

This gave me the opportunity to make my own power-supply, more or less from scratch. I was also able to design the whole thing to reside on a purpose built PCB as opposed to an assemblage of parts connected by flying wires (as was my previous iteration of this project, prior to PCB design).

Schematic of AC rectification and DC-DC switching and regulation.

With power to the irrigation solenoids and the Raspberry Pi’s AC-to-DC design block, it was time to work out how to actually rectify and condition the 24VAC input.

I ended up using an LM2596 DC-to-DC switching regulator due to its current handling of 3A (plenty for a Raspberry Pi 3B+). For transient protection (this is a field-mounted device, so lightning impulses may be a thing) I chose a 5A MOV and put it across the transformer’s secondary windings. As it turned out, speccing out my one-off power supply was quite a bit more expensive than purchasing a ready-made “power brick” such as the RAC20-05SK (which still comes in at $18 at the time of writing).

In this specific case, I wanted access to the 24VAC required to drive irrigation solenoids, something which my design afforded. Keep in mind that the transformer which I selected cost me $17 alone.

(Solid state) relay driver schematics

Moving along, it was a simple matter of connecting the Pi’s SDA and SCL lines (header pins 3&5 respectively) to pins 13 and 12 on the MCP2307 I/O expander. From the MCP2307, all 14 possible control lines were brought out to control devices.

Of the 14 control lines, 12 were selected to drive TLP222AF photo relays that are capable of handling up to 500mA of AC (or DC) current at up to 60V!

The remaining two control lines were used to drive mechanical relays which would have current ratings high enough to switch on or off a 110/220v irrigation pump. This would allow full control of the system to prevent wasting water in the event of a distribution line rupture (i.e. the pump is only enabled when the system calls for an irrigation zone to be enabled).

Top layer board layout

Ultimately, the project was really straight forward but it allowed me to roll my first custom power supply, as well as learn a few things the hard way in terms of PCB design. This was not my first project where I would have a design sent out to a PCB fab house; I’ve been in the game for quite a few years now as a hobbyist. I have to say, things have changed! The quality, price and turn-around time are phenomenal from off-shore sources! I find it difficult to understand how these fab houses make any money.

PCB (top side) back from fab house

My latest version of the design came back and is what I’ve been using for a couple of years now with absolutely no regrets. The design meets all of my needs; I am the weak link in the system. My programming skills have gotten VERY lax and so the potential of my irrigation controller is not even close to being met. My future hope is to leverage the OpenWeatherMap API for evapo-transpiration / irrigation calculations and smart watering based on good data. Right now I have a way over-designed on-off timer. Lol.

Raspberry Pi 3 and irrigation control board housed in an 8x8x4″ plastic junction box for weather protection

The controller has been serving me well for a couple of years now, and offers a remote temperature sensing station in the back yard. I have a few other plans for the Raspberry Pi’s processing power which more or less sits idle.

Perhaps this Raspberry Pi will see an interface to a WSPR station or another radio related use. We shall see.

Posted in General | Tagged , , , , , , | Leave a comment

2 Year update


Perhaps it is time to pull the plug on this blog? I haven’t updated in two years mostly because (unfortunately) this place has taken a back-seat to the daily grind. With two young children, there is not much time to spare (at the moment) so I find it difficult to put time into some of the activities I once enjoyed.

I am happy to report that I finally did set up my permanent office / lab in the basement. The make-over of a rather large basement bedroom included running 7 CAT6 ethernet drops, a dedicated UPS backed up circuit, and of course, a coax run to the attic. Of most interest to this blog would be the use of the remaining Heliax that I purchased some time ago. This new run is longer than the original (and still in-place) run that I detailed back in 2015. The new run terminates nicely to an N-type 90° elbow into a decora-style face plate. I have to say, it is a nice install. Perhaps I will make some time to write up a post about it in the near future (though, given my  recent activity, I wouldn’t hold my breath – lol).

Anyways, cheers for now!


Posted in General | Tagged , , | 1 Comment