Digital Operations
Basics
I’ll be the very first to admit that I don’t know very much about digital RF communications. I did not do a bunch of homework in order to understand very much of it, let alone all of the ins/outs of operating digital modes in Amateur Radio. I learned what I needed to get started, how to hook things up and a basic idea of how the software works. I am expanding on that every time I fire up my rig.
Many thanks goes out to Clint White, AE8CW, for getting me up and running. His instruction and assistance in getting my first couple of contacts in the logbook were essential to getting an understanding of what’s going on in digital modes.
Now, I did not see, in my casual reading, a couple of key aspects to operating digital in any of the documents I browsed. Here’s a couple of key elements I learned within the first hour of getting my gear together, configured and the software up and running.
- First, after you’ve followed some basic guidance and gotten your equipment functional, you should understand how digital comms work in the amateur radio world. The very basic operating methodology revolves around a send and a receive cycle. Both the send and the receive portions constitutes in my mind, a complete cycle of operation. Once your rig is working and listening, you can view everything being sent and received by two or more different stations. I have concentrated thus far on FT8 mode, using WSJT-X software (totally free). This software has a waterfall display (you don’t need to use it). Center your rig on the desired frequency for the band (Look at the bottom/left of the software for a band/freq list). Tune your rig to that freq, set it on USB (not mentioned in any of the casual reading I’ve done) data. Say we want to be on 40m, the current freq primarily used by FT8 is 7.076. Tune your rig to that freq, usb-data. The software will begin listening. You can’t have any filters turned on, on the rig. What you’re about to see, coupled with this brief explanation will open your eyes up to what’s going on. If you’ve followed this guide: https://www.youtube.com/watch?v=LlIA_utAJfs – you have WSJT-X setup so that there will be dividers between the send and receive portions of the cycles. It will show something like ——40m—– between the send and receive portions. What you’re seeing is the exchange of data, which may be something like: K8KDC WV0CQ EM98 – which means, WV0CQ is calling K8KDC from Grid Square EM98 (You set this up in the software as your first step in the above mentioned Youtube video. This becomes the first step in answer someone’s CQ. Someone will first call CQ and it will be highlighted in green in the left window. You answer by double-clicking their CQ. And that about sums up how to make a contact. There’s other things involved of course, but that gives you a general idea.
- I learned early on, listen first, then try to reply. I will listen for a couple of cycles, paying attention to which part of the cycle has the most people calling CQ. I will pick out, depending on the db level, the strongest signals and try to get back to them first. And then, move down the list. (I like to take notes).
- The band/frequency portion of the WSJT-X software is primarily for when you hit the “Log” button. You log your finalized contacts into WSJT-X which produces two useable files, one a “.log” file, that you can open and read, and the other, a “.adi” file, which you would use to upload (import) into QRZ. From QRZ, if you have it setup properly, you can then upload to LoTW.
- Tuning. You can tune your rig by hitting the “Tune” button. I have an auto-tuner, so I place my auto-tuner into Tune mode, then I hit that button and tune the tuner.
- It takes 4-5 “back and forth” transmissions from each station to complete an entire QSO. The current etiquette involves the following (which takes approximately one minute):
- Calling CQ (CQ WV0CQ EM98) WV0CQ is calling CQ, giving grid square.
- Answering a CQ (WV0CQ W8KD HI28) W8KD is answering the CQ with his grid square.
- Sending power levels received (W8KD WV0CQ +9) WV0CQ hears W8KD at +9db
- Sending power levels back (WV0CQ W8KD +8) W8KD hears WV0CQ at +8db
- Sending a “Roger” to acknowledge the receipt (W8KD WV0CQ RRR) WV0CQ rogers W8KD’s transmissions
- Sending a “Roger” + Signing off (WV0CQ W8KD R-73) W8KD Rogers and sends 73, effectively terminating the exchange.
Now, this isn’t as efficient as it could be. The mix of etiquette into the equation, human conditioning, calls for more traffic on the radio than is absolutely necessary, which in turn slows down the process. People are not robots and they waste time. A more streamlined approach to this exchange would be:
- Calling CQ (CQ WV0CQ EM98) WV0CQ is calling CQ
- Answering a CQ (WV0CQ W8KD HI28 +8) W8KD is answering the CQ with grid and giving a power level
- Sending power levels received (K8KDC WV0CQ RR +9 73) WV0CQ hears W8KD, gets the power level sent by W8KD (RR), gives the power level at +9db and signs off (73)
Each part of the exchange takes about 15 seconds. By doing the bare minimum, you’re talking about 45 seconds between exchanges. By doing the normal approach, which is what we’re seeing at this time, we’re looking at 1.5 minutes per exchange.
During Phone comms, if you’re working a pile-up, you can work 2 contacts per minute if you’re a great operator (about 120 per hour). If you’re average, you should be doing at least 50 per hour. By cutting down the ancillary chit-chat, even on digital, you can get 1.25 per minute, which isn’t blistering fast, but it’s 2x as fast as the current normal exchange.
I feel that in the near future, especially on Field Day, we’re going to see short-cuts being taken in the exchange.
The shorter version of the above: When both sides exchange “R’s”, the conversation is effectively over, anything in addition to that would be considered pleasantries.
Monitoring Only
You can setup WSJT-X to report what it hears to the PSK Reporter website (instructions for doing so are located on that page). You will need to leave your computer and rig on and functioning together in order to do this. There’s several interesting facets about doing such: There’s propagation studies that can be performed, because you’re seeing traffic from all over the world. It’s very easy to setup, just takes a couple of minutes to do. Once you’ve done this, you can let it run, listening, and then take a look at their site to see how well your station hears other stations over a period of time.
Within the first 8-10 hours of reporting what my station hears, I reported 1800+ reports from every where between the Philippines, Australia, Europe, Asia, South America, Africa and of course, the USA/Canada. It’s amazing at the number of stations operating digital.
With FT8, the capability of your computer reading digital signals as low as -24db exists, which is below the sound floor on any of the bands, meaning, your ear cannot pick out the signals, but the computer can. This means, FT8 (and I believe PSK31) mode is capable of being heard when CW isn’t! How exciting is that?
All of these years, we’ve heard “CW works when nothing else will!” Well, that’s no longer the case, if of course, you have access to a rig setup with a computer capable of doing digital modes!
Advanced
If you’re forgetful like myself, you may miss either logging a contact or whether or not you’ve logged a particular station in the last little bit. I do both occasionally. The first part, hitting the log button, I can’t really help you with at this time, as logging isn’t automatic and there’s no way of doing it (yet) in WSJT-X). I was incorrect about the aforementioned “not possible to automatically log”, kinda-sorta. You can enable a “Prompt” to log. Go into the settings, go under the “Reporting” tab and click “Prompt me to log QSO”. I guess I missed this at some point, but found it and thought I would make the correction. The second part (and it still helps you keep track of what you’ve logged), I can help out a little bit with this.
If you use a version of *nix, such as Linux, as your operating system, it’s very easy to keep an eye on a logfile by using the command line tool “tail”. Tail works like this:
From the (tail) manpage:
With –follow (-f), tail defaults to following the file descriptor,
which means that even if a tail’ed file is renamed, tail will continue
to track its end. This default behavior is not desirable when you
really want to track the actual name of the file, not the file descrip-
tor (e.g., log rotation). Use –follow=name in that case. That causes
tail to track the named file in a way that accommodates renaming,
removal and creation.
Therefore, the tail -f command line, used against the wsjt.log file would look like:
# tail -f wsjt.log
2018-02-04,11:35:15,2018-02-04,11:36:17,WD7KR,DC42,7.077200,FT8,-10,-10,100,,
The above just shows the last line in the wsjt.log file, but in the reality, it will show the last 10 entries.
There’s a port for the tail command available at http://tailforwin32.sourceforge.net/ This program will open a window where you can select a file (wsjt.log), and run tail -f against this file in windows. It will monitor the file for changes. So when you hit the “Log” button in WSJT-X, and submit a log entry, it will show the new entry to the .log file. This is a handy way of looking at the last X number of contacts, to make sure you’re not duplicating a contact.
Busted Operations:
Here, I’ll give some examples of busted operations. This first example, I am calling CQ. F5QN responds with his Grid. As you can see, his signal is weak, -22, so the next go-around, I may or may not be able to hear him.
If you’re notice, at no time did I send a “RRR” or “R-22”. I only sent “-22”. Yet, he responds with a “73”. Wrong. So very, very wrong.
The left side indicates the timeline. Starting at 16:50:30 with my CQ, then his response on the next cycle, it takes him another 8 cycles to respond, which he responds on the 9th cycle. Really? Seriously?
F5QN is probably running in manual mode. He never received a confirmation from me that I received a signal report from him, yet, he’s signing off with a “73”. This is a busted contact and I did not log the contact. I will of course, deny any type of confirmation he sends to me.
I decided to go ahead and do some research on F5QN to find out if he is new to FT8. I found very little information on this callsign, including that it isn’t registered in QRZ.com. Further info shows very little other info gleaned, little to no information for the owner of the callsign and a brief look into FT8 reports shows that he did not transmit before one hour previous to the writing of this example. He may or may not be “new” to FT8 mode. However, do not let this type of busted contact happen to you. Give the Grid, give and receive signal reports, acknowledge, move on. (73 is optional!).
Time Calibration/Sync
I am going to strike out everything I wrote below and replace it with just a two simple words: Use Meinberg. I learned a valuable lesson. Yes, I can accurately sync my clock on my Windows PC and it will work, for awhile. I can tune into WWV, monitor another network appliance with NTP enabled and verify everything is right. Even tho I can, even tho I am a highly trained calibration technician, doesn’t mean I should need to worry about it. And folks, worry you should. Windows implementation of an NTP client is horrible. So horrible in fact, my clock was “sync’d” (I hate using the term, because it’s not what happened) 1.5 seconds off of WWV through using the Microsoft server and ALL THREE NIST servers listed in the Internet Time sync tool in Windows. 1.5 seconds is A LOT for FT8. Don’t be fooled. Don’t use Windows Time Sync. Go get Meinberg and “be done with it” as Jerry, aka kb0xy said to me. While the problem between his and my QSO wasn’t specifically time related, he led me into Meinberg, which I finally implemented late yesterday evening. It works, it’s keeping perfect time and all is right in the world. Do not beat your head into the wall. Just do it.
The time on your computer MUST BE SYNCED. By default, on MS Windows computers, this sync is done to Microsoft servers. These are not the best servers. They may in fact be in perfect sync, but you have access to better servers to do the job. The best servers in the entire world to sync your time to are the NIST servers. Now, before I link to these servers, please note, there’s a couple of ways you can go about syncing. You can use the tool that’s built into your clock on your Windows PC (or Linux if that’s the case) and change the servers. Or you can simply tune to one of the frequencies listed here on your radio and pay attention to what the pre-recorded voice says. Near the top of the minute, the voice will say “At the tone, the time is BLAH Universal Coordinated Time” or something to that effect. Then, a couple of seconds later the tone will sound. It’s at this point that you should manually have your computer’s clock adjusted for whatever time the voice says, then click “OK” on your Clock Settings Window. This will set your clock to the appropriate time. Be as precise with this as you can be. You want to click the button as close to the exact split second the tone sounds. There is a human factor built into the tone sounding, so don’t worry, you will be close enough. They base the sounding of the tone and factor in the average reaction time by humans. You’ll be close enough.
Another method, is to do a semi-manual sync using the tools provided in your operating system. I am not in front of my Linux desktop right now (I’ll append a how-to for my flavor of Linux at a later date), so I’ll explain how to sync in Windows 7. Go to your clock. Click it, when the Window comes up, go to Change Time and Date Settings, then select the Internet Time tab at the top. Click Change Settings, then change the server to one of the NIST servers. Then click Update Now. This will sync your clock to the NIST servers (or Microsoft server if you didn’t change it). Now, go to WSJT-X or any other time sensitive digital mode software and watch the sequences. If the tx from the station begins before the time it’s suppose to start (in JT8 Mode, it’s after the 15 second timer reaches 15), then your clock is off. If you don’t hear stations right at the 15 second mark (or perhaps just a tenth of a second beyond that), your clock is still off. The sequences will always begin just a split second after the WSJT-X software reaches 15 seconds.
I ran into a problem recently where no matter which server I set my Windows PC to sync to, it would sync 2 seconds slow. I noticed this problem because the sequencing of the FT8 I was listening to was 2 seconds fast (per my clock on my PC). I knew something was wrong.
The absolute best way to sync your clock is to use the aforementioned NIST servers via radio and the tone. I learned about these when I went through Electronic Test Equipment Calibration School while in the Navy.
Something I realized this evening when I was helping KD8VYO get up and running on digital mode (and his clock was out of sync), well, actually two things. First, it’s a pain in the ass to set the second in Windows 10. It doesn’t let you, that I could find, set the clock seconds down to zero. I didn’t find it, but what I did was, is watch the clock and match the sequence in WSJT-X and hit “ok” until I got it set. The time doesn’t have to be perfect with the Atomic Clock (NIST), but the sequence needs to be perfect. One would hope they’re one in the same, but that may not always be the case. If by chance you had several that were operating with similar problems like I’ve experienced with the Windows time sync, you could see two or three people that are delayed a couple of seconds. As long as you’re in sequence with the majority of people transmitting, you’ll probably be fine and the correct time doesn’t matter, in as much as the sequence start times matter. Minutes can be off, the seconds should not be. Therefore, it’s not such a big deal in finding the Atomic clock signal or using an app to sync the time as it is to make sure the seconds are in sync.
Interesting Notes:
- If we have a QSO and the signal reports are exchanged, along with an R- or RRR from both parties, that constitutes a full QSO. If you hit RRR seventeen times in the row wanting a “73”, or you hit “73” thirteen times in a row, but hear nothing from me, there’s a really good chance that I’ve moved on. Exchange the signal reports, acknowledge receipt of the signal reports and then be prepared to move on. While etiquette may require cordial “73”s to be passed between one another at the end, chasing DX takes precedence. If I see a cool shiny thing, aka a rare (to me) DX entity and the previous QSO that I had passed along signal reports and acknowledgements, I will leave you. Buh-bye. And I will log the QSO as confirmed. You will receive a LoTW and QRZ confirmation request. If you base your confirmations upon receipt of a “73”, well, that may not happen, you may be disappointed and perhaps, you won’t log the QSO. That’s YOUR LOSS, not mine. The QSO occurred, whether or not you admit it, that’s your choice. I won’t beg for your confirmation, because, I know it happened. Someone being bull-headed about a tradition in amateur radio to do things “thus and so” make absolutely no difference to me what-so-ever.