Since setting up the new HAM station here in the UK the one band I’ve not yet got back onto is 160m, one of my most favourite bands in the HF spectrum and one that I was addicted to when I live in France (F5VKM).
Having such a small garden here in the UK there is no way I can get any type of guyed vertical for 160m erected and so I needed to come up with some sort of compromise antenna for the band.
Only being interested in the FT4/8 and CW sections of the 160m band I calculated that I could get an inverted-L antenna up that would be reasonably close to resonant. It would require some additional inductance to get the electrical length required and some impedance matching to provide a 50 Ohm impedance to the transceiver.
Measuring the garden I found I could get a 28m horizontal section in place and a 10m vertical section using one of my 10m spiderpoles. This would give me a total of 38m of wire that would get me fairly close to the quarter wave length.
For impedance matching I decided to make a Pi-Network ATU. I’ve made these in the past and found them to be excellent at matching a very wide range of impedances to 50 Ohm.
M0AWS Homebrew Pi-Network ATU
Since I still had the components of the Pi-Network ATU that I built when I lived in France I decided to reuse them as it saved a lot of work. The inductor was made from some copper tubing I had left over after doing all the plumbing in the house in France and so it got repurposed and formed into a very large inductor. The 2 x capacitors I also built many years ago and fortunately I’d kept locked away as they are very expensive to purchase today and a lot of work to make.
Getting the Inverted-L antenna up was easy enough and I soon had it connected to the Pi-Network ATU. I ran a few radials out around the garden to give it something to tune against and wound a 1:1 choke balun at the end of the coax run to stop any common mode currents that may have appeared on the coax braid.
Connecting my JNCRadio VNA I found that the Inverted-L was naturally resonant at 2.53Mhz, not too far off the 1.84Mhz that I needed. Adding a little extra inductance and capacitance via the ATU I soon had the antenna resonant where I wanted it at the bottom of the 160m band.
M0AWS 160m Inverted L Antenna SWR Curve
With the SWR being <1.5:1 across the CW and FT8 section of the band I was ready to get on 160m for the first time in a long.
Since it’s still summer in the UK I wasn’t expecting to find the band in very good shape but, was pleasantly surprised. Switching the radio on before full sunset I was hearing stations all around Europe with ease. In no time at all I was working stations and getting good reports using just 22w of FT8. FT8 is such a good mode for testing new antennas.
As the sky got darker the distance achieved got greater and over time I was able to work into Russia with the longest distance recorded being 2445 Miles, R9LE in Tyumen Asiatic Russia.
In no time at all I’d worked 32 stations taking my total 160m QSOs from 16 to 48. I can’t wait for the long, dark winter nights to see how well this antenna really performs.
M0AWS Map showing stations worked on 160m using Inverted L Antenna
The map above shows the locations of the stations worked on the first evening using the 160m Inverted-L antenna. As the year moves on and we slowly progress into winter it will be fun to start chasing the DX again on the 160m band..
UPDATE 6th October 2023. Been using the antenna for some time now with over 100 contacts on 160m. Best 160m DX so far is RV0AR in Sosnovoborsk Asiatic Russia, 3453 Miles using just 22w. Pretty impressive for such a low antenna on Top Band.
Following on from my initial article on plotting realtime WSJT-X decodes on a Node Red map I’ve made a few enhancements to the flow so that it includes even more data then before.
The additions to the flow now enables collection of status information from WSJT-X so that the flow is able to capture the frequency that the radio is tuned to and also the mode that WSJT-X set to. Neither of these two bits of data are in the decode message payload and so a separate mini-flow has to be created to collect the data from the status payload along side the other main flow.
Node Red flow showing additional sub flow in the top left corner of the flow editor screen
Since the status information needs to be available to all other flows I used flow variables to store the status information in so that it can be addressed directly from any of the other flows in the Node Red app.
If you’d like to use the flow in your radio room then I have put a download link below for a file that you can import into Node Red and build the flow in an instant.
Following on from my other Node Red exploits I’ve put together a flow that creates an interactive map of contacts that is generated from the WSJT-X ADI log file.
The flow is fairly straight forward and self explanatory so I won’t go into detail here but, will make a copy of the flow available for download at the end of this article.
Node Red Flow for processing the WSJT-X ADI Log file
The flow is incredibly quick at generating the map with all the pins on it, one for each station worked. The pins are colour coded, blue for FT8 and green for FT4. If you want to add other modes then just create a new colour entry in the Dynamic Icon Colour function.
The resultant map is fully interactive with each pin being clickable showing the QSO information in a tiny popup.
Node Red map generated from the WSJT-X ADI Log file
You can download the flow and try it yourself using the link below.
Following on from my previous article on Enhancing Digital modes with Node Red I’ve now got to a point where I have realtime decode information from the WSJT-X digital application being plotted on a Node Redworld map not just for CQ calls but, for stations in conversation too.
The flow has become somewhat more complex than it was originally as more and more functionality has been added. I have deliberately split out the flow process into more nodes than are really necessary so that the flow is easier to understand. Anyone from a programming background like myself will soon realise that a lot of the nodes could actually be combined into one big node however, the overall flow process wouldn’t be so easy to understand for the Node Red newcomer and would possibly put people off from trying it out.
Current WSJT-X Node Red flow
Above is a screenshot of the flow as it currently stands. It’s pretty easy to understand what is happening in the flow due to the fact that the processes are broken out into small, easy to digest blocks.
From the top down we connect to WSJT-X via UDP port 2237 and listen for the data stream. As the data is received it’s passed directly into the WSJT-X-Decode node that converts the information into a Node Red compatible format. The data is then filtered with only the information required being passed onto the next node. There are two outputs from the filter node as we require two different streams of information, namely “CQ” and “TX1” data. All the rest of the data from WSJT-X is ignored as it’s not required at this time.
The “Get freq & SNR + Others” node builds a decode message payload with all the correct data, in the right format ready to be passed on along the flow. This node also sets a number of parameters required by the map node to be able to control the display of the data.
The next node along is “Set msg.payload”, this brings together all the necessary data into a single message payload that is then worked on by all the nodes further along the flow.
The next 3 nodes perform the simple task of moving some of the data into the objects defined by the world map node, if the data isn’t moved into these specific objects the map will not plot anything.
Now we get onto the slightly more difficult bit that might put off those who aren’t from a programming background. The next 7 nodes are all javascript functions which I have created to perform tasks that cannot be done via the standard Node Red pallet.
At this point it’s worth noting that I’m not a javascript programmer, I’ve used Python, Rust, Go, C and many other languages during my 40 plus year career but, javascript has never been one of them. I’m sure any seasoned javascript programmer will most likely raise an eyebrow at my attempt at javascript programming but, you need to remember that I’m doing this in my retirement and my enthusiasm for learning yet another programming language has wained somewhat!
So, getting back to the flow, each javascript function does just one task each of which is as follows:
Set rx_time – Sets the time the data was received/processed
Remove RR73 in tx1 – Remove decodes where RR73 is in TX1 instead of a valid callsign
Set Dynamic Icon Colour – Sets the icon colour depending on what type of call is decoded
Maidenhead to LON/LAT – Converts Maidenhead locator codes into LAT/LON Coordinates
Calc Distance – Calculates the distance between “My QTH” and the DX station
Calc Bearing – Calculates the bearing/beam heading to the DX Station from “My QTH”
Generate Search URLs – Generates the URLs for QRZ and my own online log lookups
Editing the Calc Distance function with debug info in the far right panel
Once all the functions have run the resultant data set is forwarded on to the WSJT-X Stations Map node where it is plotted real time on a world map.
To view the map point your web browser at your PC running Node Red as follows:
http://radiopc.your.domain:1880/worldmap/
Or if you haven’t got a DNS setup at home then just use the IP Address of the PC instead:
http://192.168.100.10:1880/worldmap/
Don’t forget that for all of this to work you must configure WSJT-X to send data via UDP on port 2237 otherwise the flow won’t be able to connect and listen for the decode data.
You may have noticed that there are 3 other nodes that I haven’t mentioned yet. The two green greyed out nodes are Debug nodes that can be enabled when required to help see what is going on in the flow. These debug nodes will display data in the debug panel on the right of the flow editor screen when they are enabled, they are extremely useful for debugging!
The third is the blue My QTH node, this contains data pertaining to my QTH that is plotted on the map using an orange icon. You can easily edit this node to point to your QTH instead.
WSJT-X Node Red map showing orange icon denoting my QTH
Once the flow is deployed you’ll be surprised how quickly the data starts to be plotted on the map. Stations calling “CQ” are shown by Green icons and stations that are in a QSO with another station are denoted by the Red icons.
Each icon is clickable and will present all the information collected by WSJT-X for each station viewed.
WSJT-X Node Red World Map showing FT8 stations realtime on the 12m Band
The popup also has two clickable entries, one will take you to the qrz.com page for the station being viewed and the other will search my logs to see if I have worked that station already and if so it will open a new tab showing the information.
Node Red Function Editor showing the Generate Search URLs function
You can edit the “Generate Search URLs” node so that it points to your online logs search engine so that you can view your own log data instead of mine.
Below is a close up of the popups that are displayed when each icon on the map is clicked. The popups show the information collected from WSJT-X for each station plotted on the map.
Left – Green “CQ” Popup and Right – Red “TX1” in QSO popup
If you fancy trying this out for yourself but, don’t fancy creating all the nodes in the flow manually then I have made an export of the flow available for download. All you have to do is download the file, unzip it and then import it to Node Red and you’ll have everything built ready to play with.
For a couple of weeks now I’ve been playing with Node Red to add functionality to my digital mode applications.
To get to know how it all works I initially used Node Red to create a series of dash boards for my servers and virtual machines to show realtime information on CPU temperature, CPU load, memory usage and storage etc.
Node Red Flow to collect information from a virtual machine (VM)
This worked very well and I was soon able to generate the information I needed in a palatable format. This was a great way to get to know Node Red flow building and introduced me to using gauge and graph nodes in flows.
The resultant Node Red Dashboard for one of my Virtual Machines
Once I had mastered creating dashboards for servers/virtual machines (VMs) I then started to investigate using Node Red to plot data from WSJT-X on a map.
I currently use the PSKReporter website to see stations that I hear on a map as WSJT-X sends the data to the site automatically however, this information is always 5mins or more old. For some time I’ve been wanting to see the information realtime as it is received and so I was hoping to be able to achieve this via Node Red.
Node Red has nodes available for a multitude of applications all easily installed via the Manage Palette menu in the flow editor.
I installed the WSJT-X Decode and World-Map nodes and set about building a flow to capture the data and plot it on a world map.
Building a Node Red Flow to decode WSJT-X data and plot it on a World Map
Putting the building blocks of the flow together is fairly straight forward and easily achieved using the excellent flow editor built into Node Red.
I configured WSJT-X to make the decode data available via UDP on port 2237 and then started the flow by creating a UDP node that connects to WSJT-X using the same port. The data immediately started flowing and I could see the information via a debug node.
I can’t stress enough how useful debug nodes are in Node Red. You can add debug nodes onto any output on any other node to capture the data as it flows. This gives you the ability to check what you’re getting is what you expected and also to see the format the data is in. The debug data is displayed in the debug panel on the right of the flow editor in realtime and gives you a great view of what is going on in your flow.
I decided to start with capturing the data for stations calling CQ as this was easily identifiable in the JSON object coming out from WSJT-X.
Passing the output from the WSJT-X-Decode node into a switch node I added a rule that filtered out data containing “type: “cq” and passed it onto the next switch node that created a payload consisting of the station callsign, maidenhead grid square and type so that it could be passed onto the next node for processing.
The next node in the flow is a function, this is where it gets a bit tricky. To be able to plot data on the map we need the Lat/Lon coordinates of the station making the CQ call. Since WSJT-X uses maidenhead locator data I needed to convert this to Lat/Lon coordinates before passing the data to the map node to be plotted.
Since Node Red is written in Java all the functions have to be written in javascript. The problem here is that I am not a javascript programmer and so this meant I’d need to learn yet another programming language. Unfortunately Node Red doesn’t allow functions to be written in C, Rust, Go or Python, all languages that I know well and after retiring from over 40 years in the UNIX/Linux/IT world my enthusiasm for learning yet another programming language has wained somewhat.
Being so close to having a working solution I pressed on and after much head scratching I finally put together some javascript that converts the maidenhead locator information in to good old fashioned Lat/Lon coordinates. I’m sure a seasoned Javascript developer wouldn’t be impressed with my code but, it works and does what I need and so I’m happy with it for the time being.
WSJT-X FT8 stations calling CQ on the 60m Band plotted on a Node Red World Map
Once I had the location information converted it was just a matter of passing the data to the world map node in the correct format for it to be plotted realtime.
As you can see on the screenshot of the map above, it worked extremely well with stations popping up as they were decoded by WSJT-X.
I now need to refine the data sent to the map so that it shows the frequency the station is calling on, the time they made the CQ call and the mode (FT8/FT4 etc) being used.. I would also like to add the distance from my QTH to the station calling CQ to round the information off however, this will mean writing another javascript function which, I’m not sure I want to dive into just yet.
I also need to add into the mix stations that aren’t calling CQ but, who’s callsign and grid square are passed on from WSJT-X. This will mean I will then be able to add to the map those stations that are actively working other stations and maybe I might even be able to show a line between the two stations that are in QSO.
This has been a fun but, steep learning curve however, it will certainly add some great functionality into my radio room and enhance my radio HAM addiction even further.
Many years ago I purchased a Funcube Dongle Pro+ (FCD) SDR. Since it’s arrival it has just been stored in my “Get round too it” drawer.
It’s been many years but, today is the day it comes out into the light and finally gets powered up.
Funcube Dongle Pro+ USB SDR
I’m hoping to be able to use the FCD as the receiver in my QO-100 satellite ground station setup.
The output from the 10Ghz dish mounted LNB is around 739Mhz, well within the FCD receiver range of 150khz to 2Ghz. This will save me from having to transvert from 739Mhz to 430Mhz (70cm band) on the receive path.
This will also give me full duplex operation as I will use my Icom IC-705 on the 2m band (144-146Mhz) to drive the 2.4Ghz transverter for the satellite uplink whilst listening to my own signal via the 10Ghz downlink fed into the FCD.
Before I can even start to build the QO-100 satellite ground station I need to get to grips with the FCD, get the software installed, configured, resolve audio routing via virtual audio cables and get it decoding FT8/JS8/WSPR etc.
Checking the Ubuntu repo’s I found that GQRX v2.12 is available for installation.
sudo apt install gqrx-sdr
Once installed I fired up GQRX and set about configuring it. Initially it appeared to have automatically detected and configured the FCD however, when I started the FCD the software ran for 5 seconds and then just hung.
Diving into the configuration settings I found that the FCD actually appears twice in the list of available devices and all I had to do was select the other one in the list and start the software again and all was well.
I connected my 20m Band EFHW Vertical antenna and trawled up and down the band. The receiver performed well even with fairly strong signals so, I spent some time listening to a few of the stations coming in from the USA.
Next I wanted to sort out the configuration for digital modes. I already have a couple of virtual audio cables in the form of loopback audio devices configured on my Kubuntu PC as this is how I connect the audio between WFView for the IC-705 and WSJT-X/JS8CALL.
Sadly, GQRX doesn’t recognise the loopback audio devices that already exist and so I had to do a little further research to get to the bottom of the issue.
Digging deeper I discovered that GQRX requires loopback audio devices created using Pulse Audio and not the kind I had already created at the O/S level. A quick read of the pactl man page and some further searching online I found all the info I needed to create the correct kind of loopback audio devices.
Two commands are required to create the pulse audio server audio loopback devices:
Once I’d created the loopback audio devices I was able to select the gq2jt devices in both GQRX and WSJT-X/JS8CALL so that the audio was routed correctly.
GQRX SDR and WSJT-X working with the Funcube Dongle Pro+
The overall solution works well and doesn’t put much load on the CPU of my Kubuntu PC, leaving plenty of horse power for me to do other things at the same time.
So I now have the Funcube Dongle Pro+ working perfectly on my Kubuntu PC, all I need now is a 1.2m dish, a 10Ghz LNB and some high quality coax cable.
UPDATE: I decided to leave the FCD connected to the 20m Band EFHW Vertical overnight and monitor FT8 on the 40m band. The EFHW antenna isn’t anywhere near resonant on the 40m band and so I thought it would be interesting to see how well the FCD performed on a completely non-resonant antenna.
To my surprise it did exceptionally well, stations from all over the world were heard with ease, the FCD really is an excellent little SDR receiver.
Map showing stations heard on 40m Band FT8 over night 16/17 Jan 2023
If you’re looking for a relatively cheap but, effective receiver for FT8/WSPR monitoring then I can highly recommend the FCD. If paired with a RaspberryPi then it would be a really cheap to purchase/operate solution for any HAM operator or short wave listener (SWL).
The 2023 new year has got off to a great start here at the M0AWS radio shack with my first QSO with New Zealand since setting up the new radio room.
It’s been almost a year now since I started putting the radio room together and throughout all this time I’d not been able to secure a complete QSO with New Zealand.
Well today was the day that I finally achieved what seemed like the impossible.
M0AWS WSJT-X QSO Map as of 3rd January 2023
ZL4AS was the first New Zealand station that I’d managed to complete a full QSO with, up until now I’d made a few ZL contacts but, never managed to complete the QSO due to conditions on various bands.
The band of choice today was 17m, a great WARC band that has provided me with much of the DX over the last year. This band really does give full global comms when it’s open.
With a new longest distance of 11776 Miles to ZL4AS in Balclutha New Zealand, I’m looking forward to see what new countries 2023 brings to the M0AWs radio room.
Now that I’ve got my new radio shack up and running I decided to give my Icom IC-705 QRP rig an outing and see if I could work a distance of 2000 miles with 1w output.
This is something I’ve been wanting to do for a while but, only being able to sit at the picnic table in the garden or in the summer wasn’t particularly conducive to a long stint on the radio.
Icom IC-705 wirelessly connected to my MacBook Pro
For this challenge I decided to use FT4 or FT8, whichever was active on the bands. This is a great mode for QRP operations and can get a tiny signal through when other more traditional modes fail.
I used both my EFHW vertical for 20m/10m and my EFHW vertical for 30m that can also be tuned on most of the other HF bands too. This gave me most of the HF bands for the challenge.
Initially I worked a lot of stations in the 600-700 mile range, conditions weren’t brilliant and there was a lot of deep QSB.
My first notable distance QSO was with YO4DG near Mangalia Romania at 1383 miles, this equates to 0.72mW/Mile, my lowest mW/Mile achievement up until this point.
Not long afterwards I saw SV8DCY on the WSJTX waterfall, I wasn’t sure if he’d hear me or not but, I gave a call. To my surprise he came back and became the longest distance QSO for a short time. At 1485 Miles to Kalloni Lesvos Island, Greece this equates to a new low of 0.67mW/Mile.
I then went on to work a bunch of stations in the 1000 miles or less range for a while as conditions on the bands were up and down. It’s amazing how many times I got an answer from a station only for them to disappear completely before the QSO was completed.
The next contact of note was with CU3HN in the Azores, 1713 Miles at 0.58mW/Mile, a new lowest mW/Mile record set. it’s amazing how far you can get a signal with such a tiny amount of power.
RV6F in the Stavropol region of Russia was the next big mile marker, 1932 miles at 0.51mW/Mile. It took a number of attempts to get the QSO to complete as we kept losing each other due to the deep QSB that was between us on the 20m band but, with a little patience and persaverance we eventually got the QSO to complete and it was in the log.
At this point I decided to switch over to the 10m band to see if it had opened up to more than just Europe. When I checked earlier there were only European stations being heard, most being well under 1000 miles. Sure enough the band had indeed opened up and I was hearing stations out to the east that were in excess of 2000 miles.
PSKReporter map showing signals heard on the 10m band
After tuning up and listening for a bit my first call was to RL9F in Perm Russia. This was the one that I’d been looking for, 2084 miles at 0.47mW/Mile this was the one that could complete the challenge.
After a few failed attempts due to deep QSB we eventually got a complete QSO in the log finishing the challenge.
2000 miles using 1w is a lot of fun, frustrating at times when you’re being heard by stations on the east coast USA but, none are answering your reply to their CQ calls.
PSKReporter has proven invaluable, being able to see who can hear you makes a big difference when trying to eek out the last mile when using next to no power.
In total 31 stations were worked over a 9 hour period, not huge numbers but, for many an M0AWS call sign isn’t exotic enough to answer and so many of my calls to stations were ignored. Sad really.
You can view all the log entries for the 2000 Mile 1 Watt challenge on my WSJTX Log.
So, what next? Well I guess it has to be 3000 miles or more using just 1w from my trusty Icom IC-705.
I’ve had a few messages of late asking how I generate my WSJT-X log web pages for my website. The answer is pretty simple, I use a little BASH script that I started writing some time back and have gradually improved over the last few months.
If you have a PC running Linux or a RaspberryPi running any of the normal Debian/Ubuntu/Redhat/Fedora based Linux distro’s that are available today then, this script should work just fine.
I originally wrote this program using Python but, a friend of mine bet me that I couldn’t write it in BASH and so, I took up the challenge and this is the result. It’s pretty simple and uses all the normal UNIX command line goodies like grep, sed and awk.
The script also uses WWL to calculate the distance between two Maidenhead locator grid squares and so it’s important to have it installed before running the script. (The script checks for it at runtime and will exit if it is not installed!). You can install WWL using your package manager on your Linux distro or from the command line directly. Details are in the READ-ME.txt file.
Screen grab from my M0AWS WSJT-X Log web page
It’s important that you READ the READ-ME.txt included in the zip file before trying to run any of the scripts included as it details the variables that you need to enter values for to make the script run on your PC/Server. (Example entries are in place as supplied).
The variables are mainly just paths to files on your system and whether you want distances calculated in miles or kilometres. Other than that there’s nothing else required for it to run.
I’ve also included details on how to run the script automatically from a crontab so that your webpage can be updated automatically every few minutes/hours etc.
The script also includes code to add a PNG map file into the generated webpage so that there is a graphical representation of all your QSOs. The map isn’t generated by the script (something I need to add in the coming few months) so you’ll need to generate it yourself and then add it to the website either via the crontab script included in the zip file or manually.
I use the QSOMap website to generate my map image files and then have them uploaded to my web server via the crontab script.
The script processes 100 entries per second on my web server (Headless virtual machine running Ubuntu Server 64bit Edition) and so should be pretty fast on most PCs. It will run somewhat slower on a RaspberryPi so be patient!
You can download the script and associated information using the button below.
Since getting my Icom IC-705 I’ve had problems with computer noise causing interference when connected via USB. I solved the problem mostly by winding both the USB and coax cables around 240-31 ferrite toroids. This resolved the problem nicely on all HF bands except 10m. With further investigation I realised that the 240-31 ferrite toroid doesn’t provide much choking resistance at 28mhz and so a 240-43 would be better for the higher bands. This would mean I’d need a longer USB cable and coax to the AH-705 so that there was enough cable to wind around two ferrite toroids to cover all the HF bands.
Whilst this will almost certainly provide a complete solution to the problem there is of course another way around this issue. The IC-705 is a rare beast in that it has wifi capability built in. The wifi on the IC-705 is capable of operating in one of two different modes, Access Point (AP) and Station, a host on an existing wifi network.
Since I connected my IC-705 to my in-shack wifi I am using the radio in station mode for connectivity via wifi. By connecting it this way my MacBook Pro will also have access to the internet at the same time as connecting to the radio giving me the best of both worlds.
You can of course put the radio into AP mode and connect your computer directly to it via wifi however, you won’t have any internet access from the computer as it will be connected directly to the radio. This is how it will be used when in the field for portable operations unless you have a portable 3/4/5g wifi router.
Getting the radio connected to my shack wifi was easy, just go into the IC-705 menus, switch the WLAN on, pick the SSID of my wifi router and enter the password, the radio connects immediately. You will also need to switch on the network control option and also set up a user and password that is used when connecting to the radio from your computer. Refer to the IC-705 manual on how to do this if you haven’t done it already.
To be able to use the radio wirelessly from any Apple Mac computer you will need 2 applications, WFview and Blackhole. Both of these applications are Opensource Software, I’m a huge fan of Opensource Software and have over the years been involved in a number of opensource projects.
I’m fully aware that there is an application called SDR Control available on the Apple App Store for around £90.00 that can be used instead to connect to the IC-705 wirelessly however, I prefer to use Opensource software where possible.
Before proceeding with the instructions below make sure you have an up to date backup of your system. This installation and configuration shouldn’t cause any issues at all, it worked fine on my MacBook Pro but, it’s always best to backup before you install more complex software like this.
First you need to download WFView from the Download page, make sure to download the MacOS Universal package which was v1.1 at the time writing this article. Do **not** install WFView yet, the sequence of installation is important!
WFView Download page showing the MacOS (Universal) Package v1.1
Next download the Blackhole Virtual Audio Cable application from the download page. You will need to enter an email address and your name to be able to download the application. It’s not clear how much email/spam will be sent to you but, you will need to get at least one email to obtain the download link with the authorisation code in it.
Once you’ve entered the information and submitted it you will get an email with a URL enclosed, click the URL and goto the download page. On the page there are 3 options available for download, select the “Blackhole 2 Ch” option only. At the time of writing this v0.2.10 was the current version available.
Blackhole Download page showing the 3 options available
Once downloaded you need to install the Blackhole application first as it will create the necessary virtual audio cable for WFView to use to provide sound to WSJT-X and other digital mode applications. Installation is simple and follows the normal MacOS installation process. Double click the installation package and follow the prompts accordingly.
Once installed reboot your Apple computer to make sure it starts up OK with the new kernel module installed. When your system comes back up, login and open the “Audio Midi Setup” application. (The Midi app is in Applications >> Utilities)
Once the application opens you should see that you have a new audio device called “Blackhole 2ch”. On both the Input and Output tabs set the format to 48,000Hz. This setting will get the best results when using applications like WSJT-X for FT4/8 digital modes.
Apple Audio Midi Setup showing 48,000Hz selected
Leave everything else as default setting in the Audio Midi App, nothing else needs changing. Leave the Master volume at the default max as levels are controlled from the other apps.
Once you’ve set the 48,000Hz on the two tabs quit the audio midi app as it’s no longer required.
Next you need to copy the WFView app that you downloaded into the Applications folder on your Mac. Once in the applications folder you can create a shortcut to it on the dock by dragging and dropping the app icon onto your dock bar.
Next goto your IC-705 and go into the WLAN settings and make a note of the IP Address assigned to the radio from your wifi router. You will need this IP Address later.
At this point you are half way to having wireless control of your IC-705.
Start the WFView application and goto the settings tab.
The following settings need to be made:
1: Set Data Mod Input to LAN
2: Click the Connect Over LAN radio button.
3:Enter the IP Address from your IC-705 into the Radio IP Address field.
4: Make sure Radio Control Port is set to 50001
5: Enter the Username you configured on your IC-705 into the Username field
6: Enter the Password you configured on your IC-705 into the Password Field
7: Set Sample Rate to 48000
8:Set Audio Output and Input fields to BlackHole 2ch
9: Select the first option available in the Virtual Serial Port field. This should be as shown below:
Leave all other settings as default and click Save Settings and then Exit Program.
You must exit the application in order to restart it with all the new settings.
WFView Settings tab showing all the necessary settings whilst connected to the radio
Start the WFView application again and goto the Settings tab. Click on the Connect Button.
Once it has connected to the radio you will see the RX Latency details etc on the bottom right of the window. Click on the View tab and you should now have an active waterfall.
At this point you have full control of your IC-705 wirelessly. Have a play with the application and get familiar with it.
Fully operational WFView connected to my IC-705 receiving FT8 on 10m
Once I had WFView operational I set about getting WSJT-X connected to the radio wirelessly. This is actually really simple to do and just needs a couple of changes to the settings to make it work.
Start up the WSJT-X application and goto the Radio Settings tab. On this page you need to set the radio to IC-705, serial port to that shown below (Also shown in point 9 in the WFView section above) and Baud Rate to 38400.
Next select the WSJT-X Audio Settings tab and set the soundcard Input/Output fields to Blackhole 2ch. Set both Input and Output to Mono as shown below.
WSJT-X Audio settings
Click OK and return to the WSJT-X main screen. You should now be fully operational for WSJT-X digital modes.
WSJT-X transmitting through WFView to the IC-705
Once I’d made a few contacts with WSJT-X in FT8 mode I went on to try and get FLDigi working with WFView as well.
Unfortunately at the moment I cannot get CAT control working in either FLDigi or FLRig, neither will accept the /dev/ttys000 as the serial device however, I was able to get the audio working into FLDigi and even decoded some morse with it. I need to do little more work to fathom out why the CAT control doesn’t work in these two applications. I’m sure there is a way to resolve this but, I just need to put in a little more time to find the solution.
FLDigi decoding Morse code via WFView
UPDATE: There was some concern in one of the IC-705 Facebook groups that Blackhole wouldn’t work after a MacOS update. I’ve just upgraded my Macbook Pro to MacOS 11.6.6 and BlackHole is still fully functional afterwards. The MacOS update has no effect on the BlackHole service whatsoever. So you can rest easy!
More soon …
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.Ok
