Go to the Home page
Go to the About section
Go to the Projects section
Go to the Clients section
Go to the Products section
Go to the Links section

Interfacing MacLoggerDX and Digital programs

Fldigi logs QSO to MacLoggerDX

Dave Wright K3DCW: I log directly from Fldigi to MacLoggerDX using my AutoLog script. I find that it works much more smoothly than the other scripts and doesn’t require a macro button to activate: it just works once it is setup. It can be found in the Extras folder of the MacLoggerDX downloaded Disk Image, under /AppleScripts/Fldigi/AutoLogFldigitoMLDX/ along with a PDF showing the setup directions. Note:Tested with macOS Monterey on M1 and Intel Macs 11/2021.

Logging on MacLoggerDX with Fldigi (W6BSD).

MacLoggerDX UDP broadcast to Fldigi

No two applications can control the same Mac serial port, but if MacLoggerDX owns the radio CAT port then Fldigi can ask MacLoggerDX to key the PTT line.

Note from Dave Wright K3DCW on MacHamRadio

The Fl* development team has released version 3.23.08 of Fldigi. This is a major release for fans of MacLoggerDX as this version contains support for the UDP feed from MacLoggerDX's DX Cluster:

  • Added UDP interface to read data exported by MacLogger

The latest version can be downloaded from:

https://sourceforge.net/projects/fldigi/files/fldigi/

In this configuration, MacLoggerDX owns the CAT connection to the radio and broadcasts the VFO values to Fldigi through UDP on your LAN. This allows click and tune operation of Fldigi from DX Cluster Spots in the MacLoggerDX feed. (don’t run udp_listener or MacDopplerRadios on the same Mac at the same time as fldigi, they can steal the packets if run first. You can change the MacLoggerDX UDP broadcast IP address in the Terminal program to a multicast group).

To configure this option go to the Configure dialog, select the Logging tab and the MacLogger sub-tab then enable the Connect to MacLogger and Capture Radio Report check boxes. Make sure the UDP Broadcast check box is enabled in the MacLoggerDX Station preferences.

You should be able to see the MacLoggerDX UDP data stream in the fldigi UDP data stream panel.

Fldigi sends PTT to MacLoggerDX - manual

K3DCW: Both of the scripts (mldx5Key.scpt and mldx5Unkey.scpt from the Extras/V5 Scripts/cocoaModem Scripts folder) work just fine with the PTT between Fldigi and MLDX.

I copied them to the Scripts folder under the .fldigi folder, made them executable from the Terminal (chmod +x mldx5*.scpt), and set up the appropriate macro command:

<EXEC>/usr/bin/osascript $HOME/.fldigi/scripts/mldx5Key.scpt &</EXEC>
<EXEC>/usr/bin/osascript $HOME/.fldigi/scripts/mldx5Unkey.scpt &</EXEC>

... for each of two buttons, labeled PTT ON and PTT OFF.

It works perfectly, at least with my K3 - the PTT method in MacLoggerDX depends on your radio and interface.

To fully automate the process, the user needs to address both scripts in the macro; the PTT on at the beginning and the PTT off at the end.

They also need to use the <TX> macro command to start sending text AFTER the PTT is keyed on, and the <RX> macro command to stop sending text before the PTT is released.

For example, to automatically send a CQ call using something like PSK31, the macro would look like this:

<EXEC>/usr/bin/osascript $HOME/.fldigi/scripts/mldx5Key.scpt &</EXEC>
 <TX>
CQ CQ CQ de AB1CD AB1CD AB1C
CQ CQ CQ de AB1CD AB1CD AB1CD pse k
<RX>
<EXEC>/usr/bin/osascript $HOME/.fldigi/scripts/mldx5Unkey.scpt &</EXEC>

Fldigi sends PTT to MacLoggerDX - auto

Fldigi PTT script from Marc Pauls DJ7AQ

As there is no way to use the EXEC command somehow inline I built a "dirty workaround". This AppleScript just runs the whole time fldigi is opened in the background and detects fldigi's RX/TX status through the XMLRPC interface. According to this status it sends the RX/TX commands to MacLoggerDX.

Fldigi_PTT_DJ7AQ.scpt in MacLoggerDX Extras / Sample Files / Scripts / fldigi scripts / folder.

Fldigi_PTT_KA3DHV.scpt in MacLoggerDX Extras / Sample Files / Scripts / fldigi scripts / folder was added to fix a problem with the IC-7300


Dave Wright K3DCW January 6, 2020...

Because of the nature of these scripts, the only effective way to use them is to turn them into an app and run them. It is not effective trying to run it from within Fldigi. If you are trying to use the KA3DHV script, then here’s what you need to do.

Open the script using macOS’s Script Editor. Go to the “File” menu, choose “Export.”  Give the file a name (FLDIGI-PTT or whatever else you might want to call it), choose the Applications folder under the “Where” pulldown, and under the File Format pulldown choose Application. Save the new application. Now, go to your Applications folder and start MLDX, then Fldigi, and lastly your new app.  It should stay active and keep monitoring for the PTT signal from Fldigi until you close Fldigi, at which point it will shutdown.

Depending upon the digital mode you prefer to use, you may want to adjust the script a bit to give more responsive PTT.  Right now, it looks for and detects PTT commands from Fldigi every 1 second. Previously when I used these scripts, I had set my delay to 0.5 seconds in order to get a more response PTT action. This is probably more important for modes like RTTY than for things like Olivia or PSK. However, if you want to make this adjustment, then you’ll need to do it before you compile to an application.  Simply open the script in the macOS Script Editor, scroll to the bottom where there is the line “delay (1)” and change the (1) to something like (0.5) to check every half-second, or to (0.1) to check PTT status every 1/10th of a second.  

The K7UF script does the same thing as the KA3DHV script, and also needs to be run as an application, except that it also incorporates an error check and defaults to 0.5 second checks of PTT.  Where the KA3DHV (and DJ7AQ) scripts will crash when Fldigi ends (without causing any harm — they simply crash when the XML-RPC feed is cut), the K7UF script also performs a check and will terminate once the XML-RPC feed is cut. It also has a shorter delay setting of 0.5 seconds.  If you wish to use this script, the only change that I recommend you make is to the line that reads “set maxErrors to 5”.  I would change the maxErrors value to 10, so that it would read “set maxErrors to 10” to give yourself a bit of time on either the startup or shutdown sequence of Fldigi.


We try to make it easy for any program to interface with MacLoggerDX.

Besides being able to import ADIF log files from any program, MacLoggerDX has been a standard Apple scriptable application since Version 5.0 was released.

MacLoggerDX supports an open and documented AppleScript interface for logging.

AppleScript is the standard for Mac interprocess communication and even though Fldigi does not provide this capabilty it can pass information to an AppleScript with the EXEC macro.

UDP Broadcast

MacLoggerDX also broadcasts UDP packets over your LAN when the connected radio VFO changes or a QSO is logged (Enable UDP Broadcast check box in Station Prefs). The udp_listener application (a sample application provided for illustration) in the Download Extras folder will display radio report packets that MacLoggerDX transmits on UDP Port 9932 whenever the connected radio VFO changes. Source code for udp_listener is available here.

MacLoggerDX and WSJT-X

MacLoggerDX and WSJT-X setup.

WSJT-X can control your radio directly or through MacLoggerDX.

In either case MacLoggerDX will log QSOs from WSJT-X, fill in any missing data from your Call Book (i.e. QRZ XML) and then optionally upload them to LoTW, eQSL etc.

MacLoggerDX will look up the WSJT-X DX Call when it changes. Spots are posted to the DXClusters/Spots table for all WSJT-X CQ and heard messages. These spots can be combined with the DXCluster or extra_cluster spots and you can set Alarms for these spots as well as setting Auto Lookup just as you would for dxcluster spots.

JT-Bridge by Anders Östlund SM0THU displays CQs from the WSJT-X activity file.The CQ callers are looked up in the MacLoggerDX database to see if they or the DXCC entity have been worked or confirmed before. It can also log QSOs from WSJT-X to MacLoggerDX

Note: "Make sure you are using MacLoggerDX’s importADIF function so that data will be taken from JT-Bridge and WSJT-X only - it’s enabled with the option “Don’t let the logging application fill in data when logging a QSO” in JT-Bridge. For new installations of JT-Bridge this is now the default." - Anders.