When I was compiling a new version of the ntpsec package that I use for my Stratum-2 NTP server, I noticed an interesting warning that is well known but I had never paid attention to:
WARNING: This system has a 32-bit time_t.
WARNING: Your ntpd will fail on 2038-01-19T03:14:07Z.
This is fairly easy to explain and has to do with how time is calculated. First we need to discuss integers. An integer in a programming sense is a whole number which can be either positive or negative. For example: 12345 is an integer as is -54321. Integer variables can be assigned a size which best suits the intended variable value(s) to optimize computing resources. An integer variable that is used to store both positive and negative values is known as a signed integer. Variables which will only store positive values are unsigned integers and as you will soon see, have double the maximum value of signed integers.
In the simplest sense, a 32-bit processor has a maximum size integer of 32 binary bits, minus one. Thus, (232 – 1) = 4294967295 which is the value upper limit for an unsigned 32-bit integer. If instead, you use a signed integer (i.e. one that can have both positive and negative values) your maximum value is cut in half since one of the bits becomes the sign bit. (231 – 1) = 2147483647.
Next we need to know about the Unix epoch. It was decided that modern computer time would begin at precisely 1970-01-01T00:00:00UTC. All time after this point is counted as the number of seconds past epoch. Yes, seconds!
Ok, so knowing the maximum number a 32-bit signed integer can store, we can determine the precise upper limit of time which just so happens to be … 2038-01-19T03:14:07UTC
This is not really cause for concern (for the most part) since you can cheat systems to “think” that the time is different from current. This kludge will help support systems which may not be patched (i.e. very old hardware used for nostalgia purposes). Just be aware that left un-patched, file-systems which employ 32-bit time may not function post 32-bit time.
Taken from Wikipedia:
At 03:33:20 UTC on Wednesday, 18 May 2033, the Unix time value will equal 2000000000 seconds.
At 03:14:08 UTC on Tuesday, 19 January 2038, 32-bit versions of the Unix time stamp will cease to work
At 15:30:08 UTC on Sunday, 4 December 292277026596 (LOL) 64-bit versions of the Unix time stamp cease to work
In order to remotely power my SG-230 Smartuner which will (temporarily) live in my attic to “tune” a large vertical loop antenna, I opted to use a bias-T to inject DC power onto the coax. Bias tees are passive components (subject to losses) which allow coupling and de-coupling of DC on an RF transmission line. When used properly (in the correct orientation), the device (theoretically) never sees DC on the TX/RX port but there exists a DC “offset” or bias to the RF signal.
In lieu of sourcing the components myself, I opted to purchase 1 x MFJ-4117 (on/off switch) and 1x MFJ-4116. These bias tees are relatively simple devices (see schematic) that can be invaluable in powering remote equipment without the need to run additional antennas (I mean wires). The bias tees are specified to handle 1 amp DC at up to 50 volts and are said to handle up to 1500 W CW (I have my doubts).
The question is: what are the trade-offs?
With the addition of anything in the signal path, one should expect some bi-directional loss. I wanted to know how much loss the two bias tees would add to my particular setup, so it was time to fire up my trusty Rigol DS815-TG.
I started by connecting two N-to-PL235 cables with a SO-237 coupler in order to “zero” the tracking generator output with the spectrum analyzer. This is done to account for any cable losses, impedance discontinuities and to give the spectrum analyzer a reference point for what its tracking generator is outputting along the frequency sweep. This normalization process is done each time the setup changes. I even repeat normalization if I vary the frequency range or receive bandwidth (RBW). The result after normalization was a 0.03dB loss (to be subtracted from the test results later). I could have accounted for this system loss automatically but I prefer to see all the variables and work with them as I go.
The next step was to replace the SO-237 coupler with the MFJ-4117 in its place. As I primarily operate on 20M (14MHz) I wanted to know the insertion loss at that frequency in particular.
With the spectrum analyzer set for a frequency range of 0-60 MHz with RBW of 1 kHz, I measured a mere 0.06dB of loss at 14 MHz (accounting for systematic 0.03dB loss).
Interestingly, it was noted that 3.63dB loss was found to be at 37.5 MHz which is not an issue for amateur radio use, but interesting none the less. It may be possible to make some assumptions as to the component values and/or circuit design knowing this frequency dependent loss figure.
Sweeping from 1 MHz to 30 MHz with an RBW of 1 kHz, the frequency response curve shows a little more detail as to what the loss / frequency relationship will be for each bias tee in the system.
The loss only becomes 0.3dB once you reach approximately 24 MHz (12M WARC @ 24.890–24.990 MHz and 10M @ 28-29.7 MHz in Canada affected).
The bias tees that I will be using are only specified to work from 1-60 MHz but I thought it would be an interesting exercise to test the devices outside that range. I swept 0-1 MHz and not surprisingly, there is a dip in the frequency response graph. There is 18.2dB of loss at 206 kHz. There is only 0.3dB (or so) loss starting at 300 kHz, improving until the roll-off as previously seen.
All said and done, I am very happy with the minimal loss that I expect to experience. Testing shows that I am looking at 0.12dB total loss for the addition of the bias tees. This does not however account for the connector and cable losses required by the addition of these units. Perhaps I should re-test with the actual jumper cables being used.
Since roughly 2010, I have been using (formerly) CadSoft’s EagleCAD electronic design automation software quite happily. It took a lot of getting used to (it had a very steep learning curve) but I became quite good at using Eagle. I came to really enjoy the EDA software and would use it to design all kinds of things. I was able to secure a student license thanks to a generous licensing program which allows College and University students full-featured license for free. The free version of EagleCAD allows only 2 layer designs and board sizes of up to 80 cm². A student license allows 16 layers and 4 m² of board area.
As my abilities and interests matured, I began to grow unhappy with with the pre-made libraries. I wanted to create something with integration with my chosen supplier, so I started to make my own library, hand-drawing every single component that I used in my designs. Using datasheets and mechanical drawings, I drew a large list of components that I had manufacturer and distributor part numbers, hyper-links to datasheets, descriptions, latest pricing, you name it! I am quite proud of my private library.
During the initial stages of my library build-out, I briefly tried a new open-source EDA known as KiCad. As I had already committed to the learning curve of EagleCAD, I did not give KiCad a whole lot of effort because I found KiCad to be very clunky and amateur. Having tried a few previous versions, I gave 4.0.5 a little more of an effort knowing my prejudice. I was still not impressed.
Saturday morning, I decided to fire up Eagle to start working on a new project: a GPS disciplined crystal oscillator. Happily working away, adding in new custom components, I developed the schematic until the point that I was ready to start the layout process. Luckily, I begin rough PCB layouts early on in my design so that I can discover errors, optimizations, and to quite frankly, just get started.
Estimating a board size, I tried to start the layout process only to find out that my version of (now) Autodesk’s Eagle (9.5) had reverted to the free version. No problem I thought, if the software hasn’t “called home” recently, it defaults back to the free version until it can validate your license. In the past, I’ve had to validate my license so I logged back in to the Autodesk site and to my horror, I discovered that my license was revoked.
It is totally fair that my license is no longer valid; I am no longer a student (I have not been for some time now) and so I can not fault Autodesk for this. What I do take issue with is their business model.
For me to continue enjoying the use of the EagleCAD software as I have been, I only have one option: subscription based licensing. I despise this trend in software. I do not mind purchasing software that I use; I am happy to pay a one-time fee to have a stable version of a platform. A one-time purchase for access is not an option. For the current version that I was using (9.5) I would have been willing to pay a one-time fee of $1000. I see the value in that. My only option now however is to pay $645 per year ($80/month) or $1740 for 3 years. I simply do not see the value in their “super bundle” that they offer.
More importantly, I am NOT willing to perpetually license access to a program in which I have spent hundreds of hours working, only to effectively lose access to my intellectual property. I see this as little more than extortion. There are alternatives out there, even paid ones which do not emply predatory business models. If you do not support subscription based models, I would urge you to do as I have done and abandon companies which chose this path. Consumers have far more power than they are aware of; it is time to leverage this power!
I promptly downloaded KiCadversion 5.1.5_3 with little hope to be impressed. I knew that this time I would have to commit to actually learning the software, to take the time necessary to watch and/or read tutorials on its use. During the lengthy download process (1.1GB @ 5Mbps DSL plus another 486MB for FreeCAD), I took the time to read a few tutorials on using KiCad, most importantly a “quick start guide” because the workflow differences between EagleCAD and KiCad are quite significant. I decided that it was finally time to master this free, open source software that so many people seem to love.
I should point out that KiCad has long been available on various Linux platforms (such as Ubuntu) as well as MacOS. Aside from Microsoft Word, abandoning EagleCAD is the second last step towards no longer having a need to run Windows as an OS. I am one step further to committing 100% to Linux.
The short version: I am glad I gave KiCad another try! It is fantastic.
I have been using KiCad for a few days now and have gotten used to (most of) the differences between KiCad and EagleCAD. As I am more accustomed to EagleCAD, I still find myself missing certain features, functions, etc. but I am resolved to master KiCad.
I am so impressed with KiCad that I have to fight the urge to write up my own quick-start guide. My love to teach / impart knowledge can sometime be a curse; I find myself spending too much time documenting my projects and not enough time actually working on them. I have to remind myself that the project is not yet done, so my time is best served completing my own work first. Besides, there are a ton of resources already available.
What I will say is that I never appreciated the power of 3D rendering a design while working on it. This amazing tool has forever changed my layout methodology and will very likely save me a lot of time. It is so cool to be able to see a rendered version of the project as you work on it. This allows me to spot problems sooner; modify over-all layout, so many things!
I’ve got to say, the more I use KiCad, the more I fall in love with it.
I have even found the library process to be better than the Eagle one; there are features I miss about Eagle but I am sure that I can find creative ways to fill those gaps.
I suppose the whole point of this post is to emplore you to try KiCad if you haven’t already adopted it. Yes, I get it .. there is value in sticking with what you know. If you have a system that works for you then great. If however, you find yourself faced with paying what amounts to recurring access fees, perhaps it is time to take a (second?) look at KiCad. I am certainly glad that I have!
So your digital mode software is configured to control your transceiver via CAT control (excellent!). The software indicates that you are currently on the 20m band in FT8 mode, so your radio has been tuned to 14.074MHz USB (or digital mode, which is in-turn configured for upper-sideband). Good! Everything is coming together.
You have good time synchronization and so you start to decode some signals, all separated by some value of frequency. Excellent! You are on track to make contacts. In fact, this is good enough for most people – you are “on the air” and can make your exchanges and all is well. That is, until you wonder to yourself: “how accurately am I reporting the frequency of these exchanges?” or “can I improve my accuracy of frequency reporting?” or even “what is the frequency precision between our stations?”
Welcome to the inner struggles of VE3BUX
If you are not concerned with chasing accuracy and precision, then you are probably a well adjusted individual who enjoys more actual operating time, and have no need to read on. If you are however curious about adopting new and frankly unhelpful compulsions, read on.
Synthesized transceivers tend to display a frequency dependent offset which closely approximates a linear dependence involving factors such as oscillator age, stability, temperature and operating conditions. Can we both measure and account for such an offset (or error)? Yes we can!
Follow me for a thought experiment for a moment. Imagine you know of a transmitter that has extremely high accuracy and stability. Imagine this transmitter is transmitting a 1 kHz tone at exactly 14.1 Mhz on USB (single peak at 14.101’000 MHz on a spec-an). You would expect that if you tune your radio to 14.100’000 Mhz that you should receive a pure tone at 1 kHz audio frequency (as measured by an oscilloscope or spectrum analyzer). Instead, you measure an audio tone at 1037 Hz, or done differently, you tune your radio until you receive a tone of 1 kHz (or no beat frequency) and note the dial frequency reads 14.100’037 MHz. You have just measured a frequency difference of a mere 37 Hz. What does that mean though? It means that between your radio and the distant station, you have a frequency difference of +37 Hz over what you agree are the same frequency. What is this in oscillator terms? It is simply (ΔfHz / fMHz) = (37 / 14) = 2.6 PPM difference. This 2.6 PPM would be considered as “not bad” for a standard oscillator. Consider how this may compare with a TCXO such as (TXCO-9 for the FT-857D which boasts 0.5 PPM) or something like a GPSDO with 10 MHz output at 0.001 PPM.
The authors of the truly amazing WSJT-X software have coded in the ability to automatically tune to various frequency (and time) standards, allowing the measurement of frequency differential between the highly stable time/frequency standards and the receiving station (you). With enough samples, a “best fit” correction factor for your particular station set up can be computed. This allows for compensation to be done in software, tuning the radio a little high or low to account for the measured offset. This gets you in to the single-digit Hz accuracy realm! We are talking sub-PPM range! (e.g. 9 Hz / 14.074 MHz = 0.63 PPM)
To start the calibration process, I found it useful to copy my current configuration file into a new version, specifically made for the purpose of tuning to the various time/frequency standards in my area. You will then edit the new configuration file to remove the FreqCal mode frequencies which would not apply due to your location and/or propagation.
First, start by cloning your current (usually default) configuration.
This is done by clicking on “Configurations” at the top of the main WSJT-X window, selecting your current configuration (indicated by the black circle on the left), and clicking on “Clone”.
If you have multiple configurations, it is best to clone one which has been proven to work with your current setup. The WSJT-X software needs to be able to reliably control the transceiver via CAT controls in order to tune through the frequency standard list. You need at least two frequency measurements to calculate the slope and X-intercept of a dial-error vs frequency function.
Give your new configuration profile a useful name, something to indicate its purpose. I use the name “FreqCal”. Change the name by once again clicking on “Configurations”, selecting “Default – Copy” and then “Rename”.
Next, you will need to “load” your new FreqCal configuration. This is done by clicking on “Configurations”, and selecting “FreqCal” and then “Switch To”. The WSJT-X window will disappear and re-appear with the FreqCal configuration file loaded.
Once you have loaded your new configuration file, try changing radio frequencies by clicking on the “operating band” to the left of the frequency display in the WSJT-X software. You should see the radio’s displayed frequency change as you “tune around the bands” in the software.
Next, we will pare down the list of frequencies that the FreqCal mode uses to measure its reference carriers.
I like to reduce my FreqCal setting to include only FreqCal mode frequencies. This is accomplished by clicking on “File”, then selecting “Settings” and once the window appears, select the “Frequencies” tab at the top.
You can sort the list of frequencies by clicking on “Mode” (as indicated in the red box). I select all frequencies which are not associated to the FreqCal mode and then delete them by right-clicking and select “Delete”. I saved my list of FreqCal only frequencies and exported them for future use / reference. The list is available for download and subsequent loading into future configuration files. You can replace the current list of frequencies of your configuration by right clicking in the “Working Frequencies” list and selecting “Load …” and opening the FreqCal.qrg file I’ve made public.
With your frequency list configured, it is time to run the frequency calibration routine. This is done by clicking on “Tools” and then selecting “Execute frequency calibration cycle”.
Enabling the frequency calibration cycle simply means that the WSJT-X software will automatically cycle through the FreqCal frequencies which you have selected in your configuration file. Once you confirm that the automatic band switching is working and that you can see a carrier “tone” on the waterfall (or corresponding data in the “decode window”), you are set to start actually measuring the frequency differences. The next step is to click on “Measure” and wait.
As the frequency calibration measurement cycle progresses, you will see operating frequency, expected audio frequency, measured audio frequency, computed frequency difference, signal level and “S/N” ratio information populate the data window. I like to set the T/R time to 30s and run the measurement routine so that at least two cycles of the entire frequency list have been completed.
Next, you stop the measurement cycle by clicking on “Measure” and then click on “Tools” and then “Solve for calibration parameters”.
If you have enough good data, the software will calculate the slope and intercept values of the linear-dependence function that you have measured. It is important to note that any significant changes in station conditions (such as large temperature changes) should prompt a new calibration routine.
With a good calibration solutine available, you can “Apply” the values to the current configuration file (which is your FreqCal configuration).
On the next pop-up window, you will be asked if the fmt.all file should be renamed as fmt.bak. Select “No” this time, we want to “import” that same data into your other configuration(s) without having to manually enter the calibration data each time.
It would be a good idea to write the calibration data somewhere as a good start-point in case the data is lost in the software.
When prompted to rename the fmt.all file, you should select “No” for each configuration file that you plan to update / use unless you only have one main configuration file.
In most cases, you are fine to simply load your “Default” configuration (Configuration -> Default -> Switch to) and then click on Tools -> Solve for calibration parameters, select “Apply” and then “Yes” to delete calibration measurements.
You can now verify that the slope and intercept data have been applied to your configuration file by clicking on “File”, then selecting “Settings” and once the window appears, select the “Frequencies” tab at the top.
That’s it! You now have sub-PPM frequency resolution (with respect to the time/frequency standards used). If all operators would perform this calibration routine, you would be better able to trust the frequency data being reported. This is particularly useful / true of pskreporter.info data.
For the benefit of pskreporter.info users, It might be worth adding a line in the “antenna description” line of the “station information” section found under File -> Settings -> Frequencies to report something to the effect of:
“xyz antenna type; freq cal sub PPM via FreqCal”
This data is displayed in pskreporter.info as the antenna description when someone hovers on your station to see when and at what frequency you last heard a particular callsign.
One method is to right-click in the white space, select “Insert”. You then select the band of interest and write / paste in your narrative. This is an adequate method if you only use one or two bands.
A quicker method of adding more than just a couple of bands involves clicking in the “Working Frequencies” window, pressing Ctl-A to “select all” and drag the list into the “Station Information” window.
Once fully populated with bands, delete any unused bands and copy/paste your narrative into the antenna section by double-clicking on the “Antenna Description” line beside any remaining bands.
At this point, you have both measured and corrected any frequency offset which your station suffered from. You should now enjoy a much higher level of accuracy and precision while on the bands. You may even notice that more signals seem to be sent & received on even number frequencies (often in 50Hz increments). Enjoy!