WSJT 1.7.0 for MacOS with an FT-991


Just in case you are still running the older WSJT 10, nows the time to switch to the latest WSJT-X.

Download the install dmg from here: (r7405)

My MacBook is running macOS Sierra 10.12.3 Beta (16D30a), connected to my FT-991 via USB cable, with the Silicon Labs USB driver from:

No audio cables, audio patch boxes, RS232 converters, Level converters, nada. Just one single USB cable. Brilliant!

Install the driver before you connect up your rig.

Once the driver is installed and you connect the radio, a new sound device, called “USB Audio CODEC” will become available. In addition, you will also see the following new devices appear.

$ls /dev | grep -i slab

We will be using one of the ‘tty’ devices for controlling the radio. (The one with the lower number).

Please note that if you change the USB port on you Mac, the numbers are likely to be different.

I sometimes see:  tty.SLAB_USBtoUART5 and tty.SLAB_USBtoUART6 for example….

Not sure why, but I sometimes need to update the configuration of my software to set it to whatever ‘number’ the SILABS driver chose at the time I plug in my radio. If you experience problems between sessions where you have unplugged your radio, or rebooted your MAC, just check that your software is configured to use the correct ‘number’.

Below is how I have WSJT-X configured when hooked up to the FT-991.

pastedgraphic-1 pastedgraphic-2

On the RIG I have:
31-CAT RATE: 38400
32-CAT TOT: 10ms
33-CAT RTS: Enable
01-AGC FAST DELAY      : 20ms
62-DATA MODE.             : OTHERS
63-PSK TONE.                 : 1000
64-OTHER DISKP(SSB)   : 1800Hz
65-OTHER SHIFT(SSB)    : 1800Hz
66-DATA LCUT FREQ      : 100Hz
68-DATA HCUT FREQ     : 4000Hz
73-DATA OUT LEVEL      : 50
On the touch-screen, I have:
WIDTH: 3000Hz
DNR: Off
DNF: Off
MONI: 10 (So I can hear my audio going out)
You will note that I am using the ‘DATA-USB’ mode instead of “Upper Sideband / USB”.
If you go the normal “Upper Sideband” route, its not as convenient as you have to make several adjustments when switching from WSJT to Voice and back. Just not as convenient as using DATA. I guess thats why DATA mode was implemented!
Hope this helps you in hooking up yours!
Best Regards

FM Stereo Reception on RTL2832 DVB dongle

For Mac OSX users with acess to the Realtek RTL2832 based DVB dongle, I am adding a link to a download of a small utility you can use for listening  to FM radio in Stereo. download

The default rtl software library, comes with rtl_fm – and allows you to listen to FM radio stations – but only in MONO.

This allows you to listen to stations in STEREO.

1) Copy the compiled rtlfms executable to your /usr/local/bin
OR you can compile it yourself from the source provided.

2) You need to also have libusb.1.0 installed at /usr/local/lib.
If you dont have it, you can find the source, compile, install
It may also work if you just copy the supplied files in the /usr/local/lib folder accross to your machine.

3) Install ‘sox’ on your machine – we use it to play the audio.

4) Once you have taken care of all the dependencies, this is how you can listen to a FM Stereo station broadcasting on 94.7 MHz.

rtlfms -X -f 94.7M -g 30 -D 0.000015 | play -traw -r48k -es -b16 -c2 -V3 –

Do the usual rtlfms –help for details on the parameter values.

5) The source code for this was discovered on a newgroup paste.
I have not been able to find it anywhere on a git/svn repo.
It is based on the rtl_fm.c from the standard rtl package, but with several enhancements.
The source is included in the src folder here.

You can of course also use the very powerfull Gqrx – but rtlfms is especially ‘lightweight’ and consumes minimal PC processing power and does not put the same drain on a battery as Gqrx would as their approach to decoding is very different. rtlfms uses a lot more of the demodulation capabilities of the dongle itself.




Hi All,

There are some radio amateurs that may still need/want to run the original WSJT on their Mac’s. WSJT-X and MAP65 has been available for a while now with a native build for OSX, but you may want to use a WSJT mode not yet covered by these two.

To get all the dependencies set up and compile WSJT from scratch can be a challenge for non programmers. The libraries also change all the time and there are inter-dependencies that come into play that can make this a frustrating experience.a

So I few years ago I created a set of scripts to automate the build process for 9.5. I noticed the other day that many updates later we are now at 10.0. So I went back to those and rebuilt from the latest source. So we now have a fresh dmg install image which make installing WSJT dead simple.

WSJT10 Install



As the install image is not coming as a ‘signed’ install from the Apple store, when you run it the first time you will probably get a security warning. Temporarily disable that as showed below by changing the ‘Allow apps downloaded from’ to Anywhere, run WSJT once and then set it back to its original setting.


Below is how what WSJT looks like on my El Capitan Macbook.


And using FSK441 mode as below.

WSJT10.0 FSK441

To take the guesswork out of setting up your sound card. Run WSJT once. This creates a new ‘wsjt’ folder in your home folder. You then simply ‘cd ~/wsjt’ and then run ‘./start’. This brings up the display below. From that you can then pick out the sound device numbers. Then go to your ‘Setup -> Options’ and set the ‘Audio In’ and ‘Audio Out’ numbers accordingly.


By default, the PTT port is set as /dev/null which allows your to test WSJT without any PTT device connected, using only the audio. But you will want to go change this value to whatever the device is called on your machine. You can do a ‘ls /dev’ to get a list of all the devices recognized on your machine.

On my FT-991, with the correct drivers installed for the FT-991, mine shows up as ‘/dev/tty.SLAB_USBtoUART6’. So thats what I have configured under Options-PTT Port (with RTS ticked, Audio In=3, Audio Out=2) on the old mac in the shack. One USB cable between the MAC and the FT-991 takes care of audio and PTT. No need for any other box inbetween – fantastic!

Note the warning in the ‘start’ script above about support for the ‘Carbon Comonent Manager’. For now its not an issue, but we will have to see when Apple eventually removes support for this. In some future OS version they will, which will then completely break WJST in its current build. But I am hoping that will be some years away.

You can download the install dmg from one of the following:



I hope this is usefull for you.









People have asked me what path my calculations indicate the plane must have flown.

The track is shown in the image below.


But it better to load the KMZ into Google Earth and you can then zoom in to see more detail.


My track estimation is based for the most part on the Inmarsat Doppler Data. (reading values off of their graph)

I am 99% certain that the GREEN track is accurate. The differences in the doppler values calculated for this track and speed, matches Inmarsat’s published data exactly. This puts the plane at the ‘DA_START_12000’ position at 19:40.

The plane’s speed travelling through this point was relatively slow at Mach 0.39.

So the plane had 2 hours and 10 minutes to get here from its last known radar position close to AGARI. Assuming a maximum speed of Mach 0.81, the plane can cover about 2000Km within the available timeframe. Which makes it impossible for the plan to have first flown way off towards the west, then only to return and fly south. Its just impossible given the time and max speed constraints.

So the plane must have simply turned around 180 degrees, flying back towards and overshooting Kuala Lumpur. Still at max speed and 35/38K ft in altitude. The Inmarsat ping doppler data for 18:22, corresponds with the plane flying on a heading of 202.5 degrees (Mach 0.81, 38 000ft) – which supports this theory.

At 18:24 the plane is banking left and has already completed the turn by the next ping at 18:30. Again the doppler values observed at these times, correspond with calculations exactly.

At some point within the next hour the plane drops its speed significantly, which implies it must have also dropped in altitude.

The next Inmarsat data point is at 19:40, at which point the plane was already travelling at the slower Mach 0.39, track 182 degrees.

The plane remains flying track 182 degrees through to -27.836 South, from where it sends the final complete ping.

Then 8 minutes later, the partial ping is registered by Inmarsat.

The most plausible explanation for why a ping would have occured at this time, is that the fuel must have run out moments before, resulting in a total electrical system failure, effectively turning the Inmarsat router off. The emergency generator in the tail of the plane (which runs off a separate fuel supply )would then kick in automatically. The Inmarsat unit was just starting to initiate the handshake to sign back onto the network – immediately after having booted up after power had been restored. But it never got to complete this process. Most likely due to the fact that the plane by now was in a steep dive and its antennas poorly oriented towards the satellite. Alternatively it may have impacted the water at that exact moment, preventing the ping from completing successfully.


If Inmarsat’s doppler data includes some offset value, the angle of the southernly track changes.

If the real doppler values were more negative by some X degrees, the further west the starting point of the Yellow track becomes – and the track then becomes < 182 degrees. But the speed does not change much. The time available to get to the start of this last ‘straight’ part of the flight, is very limited and so the further west the start point becomes, the more improbable the route becomes, until very quickly these route options becomes impossible.


Partial Ping Update


New information was released about a ‘partial ping’ 8 minutes after the last full ping.

This is consistent with the plane running out of fuel, then the independent auxilary power generator kicking in automatically. When this happens, the COMSAT would power up again and try and establish the satellite link. But without pilots, when the fuel runs out the plane would most likely go straight down, interfering with the comsat’s ability to re-establish the link. This could be due to the angle of the plane and its comsat antenna as its going down, or just that it impacted the water before the communications exchange has been complete.

Based on this, I believe the target area is exactly below.


The plane must have been flying very close to exactly due South for the last hours of the flight.

So the only remaining fuzzy variable here is really the exact value of the ‘arc’ – determined by the last ping timing.

From the graphs I have seen, my guess is that the longitude where this arc crosses the equator is 107.5 degrees.

The impact points moves around slightly if this is a bit more left or right.




Fresh Analysis of MH370’s crash location based on fresh Inmarsat Data released yesterday.

Inmarsat finally released some additional information yesterday about the pings.




The doppler information is absolutely crucial. Its the missing information without which its been mostly educated guesswork.

Now using the additional doppler information, I have been able to calculate where I believe the plane must have come down. The location is showed below. It appears the plane must have been flying quite slowly for the majority of the trip.

It MUST have flown the route below through the ‘DA_START_10000’ marker – otherwise the doppler values are all wrong.


My model tells me the plane flew only at Mach 0.394 (260 knots) – not the 450 indicated above.



At the ‘DA_END_10000’ button, the plane still sent through its normal ‘ping’ via the Inmarsat COMSAT. But an hour later (the bottom button) – no ping was received. Apparently there was a ‘communication attempt’ about 10 minutes after the very last successful ping. Which may have been triggered by a power failure – but the ping did not go through 100%. Inmarsat registered that there was some attempt to communicate.

Python’s ‘ephem’ library was used together with the following keps:

1 23839U 96020A 14082.92914473 -.00000008 00000-0 10000-3 0 2891
2 23839 1.6697 73.1023 0005489 286.4812 220.7448 1.00274299 65821

This allowed me to provide for the satellite’s own orbit which is not 100% circular and either adds or subtracts to the doppler effect though out the day. So using only the doppler information and the known ‘arc’ on which the very last ping was received, the code I knocked together this evening does the math and says thats where it is! So regardless of what initial route it took after liftoff – thats where it absolutely must have ended up at. (if the Inmarsat data is correct of course – not to mention my code!)

The ‘possible turn’ they are referring to above must be right of course. But notice how fast the doppler was increasing there just before the turn? To cause that level of doppler, the plane must have really gunned it. I will try figure that part out tomorrow.

So it took them so long to do the math I really can not figure out here. They must have had the doppler data within days. So why did they just sit on it? The math is not that hard.