GridTracker’s alert system pings me when a rare DX entity or a new grid appears. I work the station. Log4OM logs it. Later, when I run a “Missing Grids” report in Log4OM, the data is already there. No reconciliation weekends. No “wait, did I log that?”
It started as a messy pile of digital breadcrumbs. After every contest or casual FT8 session, I’d have a half‑empty ADIF file here, a manual pencil note there, and a GridTracker map full of colorful blips that vanished the moment I closed the window. My logging was a leaky bucket. Something had to change.
Subject:
Then I stumbled on the integration. One toggle. One TCP port. One “aha” moment.
That’s when I discovered the quiet power of connecting to Log4OM . gridtracker log4om
Now, every FT8 decode that I double‑click to answer in WSJT‑X sends a complete QSO packet to GridTracker. GridTracker, in turn, forwards it to Log4OM instantly . Grid, signal report, timestamp, frequency, mode — all captured without me touching a single log field.
At first, I treated them as separate tools: GridTracker for the live, dopamine‑hit visual of chasing grids on a world map, and Log4OM for the serious business of archival logging. But running them in parallel felt like driving with two steering wheels. Duplicate entries. Missing timestamps. The occasional logged QSO that never made it to my master log. GridTracker’s alert system pings me when a rare
In GridTracker → Preferences → Logging, I pointed it to Log4OM’s built‑in UDP server (default port 2333). On the Log4OM side, I enabled “External Services” and allowed incoming connections. Five minutes of config ended two years of friction.