WSJT-X keeps its own log in ADIF and text format which is fine for uploading, although you'd need to ensure that you're only uploading or importing the contacts logged since the previous upload. Also it records minimal information so if you want to record the US state for instance it lacks that capability, so I've typically entered JT65 contacts by hand into my logging program (DXLab/DXKeeper in my case) and suffered the consequences of various typos.
I'd heard about a program called JT-Alert but never found the time to try it until Canada Day, when I was cleaning up the shack and doing some research. The program was written by VK3AMA and is a free download for various versions of Windows. The advantage of JT-Alert is that it works with various logging programs to determine whether the call signs picked up by WSJT-X have been worked before on the same band and mode (WSJT-X will only tell you if you've worked the station before on any band or JT mode) and whether it's a new zone, country, state or grid (selectable by band so I only have grids set up on VHF, for instance). It even has a voice alert that will announce things like "New Grid" in your choice of male or female British voices, assuming you have a separate sound card from the one you use to connect to your radio.
The program supports standard ADIF files, DXLAB DXKeeper, HRD V5 or V6, Log4OM and MixW (CSV File), meaning it will work for just about everyone. It will also work with JT65-HF, which is an alternative implementation of the JT65 protocol with slightly different features.
So now the suite of software I run for JT65 and JT9 are as follows:
- WSJT-X V1.5
- JTAlertX 2.6.3
- DXLab DXKeeper 13.0.6
- Meinberg NTP (Network time protocol which is essential to keep your system clock in synch)
- PSKreporter (although this is a service, not a program you download)
- TrustedQSL which DXKeeper uses to upload and synchronize logs with ARRL Logbook of the World (LoTW)
- JT-Alert (at least with the settings I have currently) will advise me of new continents, zones, countries, grids (on 6m, as I've set it that way) and states for any station I've not worked before on that band and mode -
whether they're calling CQ or not . In the 10 seconds available to decide what to to after seeing all the decodes come through, there's still some excitement in picking the best station to respond to that's actually calling CQ. The ideal way to do this is to look use the "decodes history" window but unfortunately you need to look at the right hand column to see whose calling CQ, then the left column to choose the best option to respond to, then find that station in the WSJT-X decode display, and then double click on it.
- The programs should be started in a particular order. Meinberg NTP starts automatically on system startup, which is good because it can take 20 minutes or so to synchronize the system clock with network time. Then DXKeeper should be started. This is most important because otherwise JT-Alert will start it in the background. It will successfully look up stations that are heard in the DXKeeper log, but fail to actually log completed contacts. You will not be able to bring up the DXKeeper user interface either, as it will tell you that it's already running. Then JT-Alert can be started and it will prompt you to start WSJT-X.
- There are several versions of JT-Alert that will be installed. You need to use the one that matches the JT65 program you are using. JT-Alert X is the one for WSJT-X.
- It would be nice if I could somehow tell whether a "new country" was (a) never worked on any band (b) never worked on the band that I'm currently on (c) never worked on the mode (JT9 vs. JT65) that I'm currently using, or (d) whether it's just the band/mode combination that is new. I would give higher priority to stations earlier on the list.
- In the end though, I will work anyone anywhere if I haven't worked them on that band/mode combination before. It's just that new countries, grids and states will be worked first.
- In a week I haven't worked a single new country, although I've heard a couple (India and Indonesia) and worked some new band/country combinations on 30m and 17m.
JT-Alert is a way better method than what I was doing before, which was scrambling to look up stations I'd seen on the WSJT Band Activity window to see if I'd worked them on that band. This way is much more relaxing, but still has an element of decision making. I imagine someone, somewhere, is working on an add-on to run a fully automated station. That would be an interesting challenge to correctly respond to some of the non-standard messages that you see in this mode, and also to limit QRM with other stations on the band. Such a program would also ideally manipulate the power level of the transmitter to match the station being called. If see a station below -15db, for instance, I'll usually up the power, and if they're showing -5db or more, I'll usually lower it. Then I'll further adjust power based on the signal report I receive, sometimes taking observations of fading into account. If I answer a station calling CQ who then calls CQ again, I'll also up the power. Sometimes they don't hear me because I'm not the only station calling, but other times it's because they don't hear me as well as I hear them.
I didn't know about JT_Alert. I will have to try that one out.
ReplyDeleteOn another note, I have been trying to compile from source WSJT-X on the RPi2. Very difficult endeavour unfortunately. The designer of WSJT-X also doesn't know enough about the implementation details at the compilation level to help. Apparently, because it is open source, there is a developer community (still need to reach out to them) that manitains and extends the code base.
The biggest obstacle to getting the "Latest - v1.5" WSJT-X compiled on the RPi2 is QT5. This took me almost 30 hours to download all the source, dependencies, and then compile and link. Wow !! And the RPi2 is no slouch.
The problem now is the actual compilation of the WSJT-X program. One of the C++ files fails on compilation. My C++ is very very rusty and and the error code is likely pointing to something wrong with the QT5 compilation and installation. Oh Joy !! Not looking forward to wasting too much time on QT5 anymore. I think I will find a cheap netbook and install Ubuntu and foresake WSJT-X on the RPi2. Perhaps the Raspbian and WSJT-X folks will update their application repos to have the most recent versions of QT and WSJT-X and I won't have to waste my precious time on figuring out a compilation error.
I love the RPi2 and what it can do; especially what can be done with HamRadio applications. It has been a lot of fun. But, head banging on compilation errors of other people's code is where it stops being fun.
I post this comment because WSJT-X can be fun. But choose the right platform to ensure it is fun.
Would be interested in your progress. I managed to get WSJT-X working in Ubuntu on the RPI 3
DeleteAfter spending more time with JT-Alert (especially after enabling the alert that sounds a tone when someone calls) allows me to use it more productively (log-wise) and multi-task better (like writing this blog while operating).
ReplyDeleteBuilding large software packages from source can be frustrating on any platform, especially when it doesn't come with appropriate makefiles. There is a developer mailing list for WSJT where you can ask questions. When WSJT-X V1.6 comes out I think there'll be interest in building an R-Pi version because of the support for WSPR. As WSPR stations often run 24 hours a day I doubt people will want to dedicate their computers drawing 100-200 watts to the task.
Right now I'm looking at two applications for my R-Pi collection. I'm already using one as a phone switch, mail server and general purpose server for network support like DHCP, NTP, DNS and so forth, but also want to rebuild our repeater system's Echolink/IRLP gateway to run with minimum power, and also as a programming environment for Atmel processors including the ability to program the chip directly through the GPIO pins.
Thanks for stopping by Brian!
Chris
Nice write-up Chris. I sure wish I could use JT-Alert but it just won't run on Linux, along with HRD, N1MM+ and a few others. I switched to Linux earlier this year and have been pretty disappointed in the lack of quality ham radio program options. CQRLog is a pretty good daily logger and WSJT-X works well for JT65/9 but without something like JT-Alert I'm missing all of those useful features you mentioned, which makes operating digital a lot more work and a lot less fun. I suspect that at some point Microsloth is going to end up with my money again.
ReplyDeleteCheers & 73
Chris - KC3DIG
I'd definitely run Linux as a client system if the application software I used was available, but most ham radio software is Windows so I still run it on the desktop and both laptops. I think the first thing that Linux needs to start encroaching on Windows in the ham radio world is to provide a remote (i.e. over an IP connection) interface to rig audio and CAT control. That would at least allow a R-Pi to be used for the connection while the apps still run on Windows, and then permit more and more functionality to be migrated to Linux, and maybe eventually on the client side most applications would be browser based. Dream on.
ReplyDeleteNow that I've used JT-Alert for a while I find it even more useful. The best part is when I'm working at home I can have the rig on all day and on occasions where it says "CQ" then "DX" I can turn my attention to the station without having to compromise my working day - well not too much anyway.
Thanks for stopping by Chris,
73,
Chris