Informational: Relationship between HFGCS EAMs and GPS Subframe 4, Page 17 data? (none found)

[NEETINTEL]

For the last few years I have worked at a 'professional hobbyist' level on transcribing and analyzing Emergency Action Messages (EAMs) broadcast over the US military's High Frequency Global Communications System (HFGCS). These are encoded alphanumeric messages using a 32-character alphabet (A–Z and the digits 2, 3, 4, 5, 6, 7), read phonetically over shortwave radio, and all or at least some significant portion of them are understood to be involved in USSTRATCOM's nuclear and non-nuclear command-and-control communications.

I've had some success forecasting broadcasts by identifying routines in the traffic, and even anticipating the 'structure' of some of these messages by collecting and analyzing them against pre-defined criteria. I have developed a mostly irreverent method of releasing this information on social media (I consider myself as working on an art project first and a data project second), but much of it is presented in a mostly serious form on GitHub; https://neetintel.github.io/

I was asked by a mutual on Twitter to look at whether there might be any relationship between my EAM data and the data in the GPS Subframe 4, Page 17 "special message" field. I think it's a fair question, given the known and/or potential overlap in the user(s) and use(s) of the two systems.

Bottom line up front: I was unable to find any relationship.

The single most notable observation I can offer is a contrast rather than a connection. With the exception of the things already noted in your article (the sentinels, the substring reappearances) – across the enormous dataset of GPS broadcasts, the field' data appears truly random. My EAM dataset is almost the mirror image: what the general public, and even many hobbyists, perceived as 'random' turns out to have a lot of structure to it after all. So the most interesting thing the cross-comparison produced is that the two are nearly opposite kinds of ...data things.

I came at this from the point of view of whether the GPS data could help me understand or contextualize my own. I used Anthropic's AI (Claude Code, Opus 4.8) to investigate the following.

EAM → GPS

Message volume. One of the things I've wanted to answer with this hobby is the average number of EAMs to expect on a given day. Rather than sporadically noting whatever I happened to hear, I would monitor the HFGCS for stretches of days or weeks (in select cases months) and document every EAM. The average is in the ballpark of 15–20 messages per day, with significant variation — from 0 (perhaps ~10 times a year) to over 100 in a single UTC day (perhaps 1-2 times a year). I've predicted some surges as part of recurring annual events, but there's usually no apparent rhythm to the variation in quantity otherwise.

I couldn't find any relationship between EAM quantity and the GPS data:

"Generated. The result is a clean null — exactly the honest finding: EAM volume is identical on GPS transition vs routine days (median 13 vs 13, p=0.46), and GPS regime-change days fall near EAM surges 34% vs 24% expected, but p=0.13 (not significant)."

Prefix rotations. Even after a handful of messages it becomes obvious that most begin with the same two-character 'prefix'. Over time, that most-commonly-used prefix will 'rotate out' and be replaced by another. Note that there are actually multiple 'groups' of EAMs, each with its own prefix, and the prefix rotations take place independent of each other. None of these rotations appear to follow any consistent rule; so far, I can't successfully predict the rotations as taking place either "after so many days" or "after so many messages."

Could something in the GPS data prompt the rotations? I tested each prefix group separately; no group reached significance (the one that leaned highest was still only ~p=0.16, within noise):

"No coupling — even rotation-to-rotation. Confident EAM prefix rotations fall within ±3 days of a GPS regime change 26% of the time vs 19% expected by chance (permutation p=0.19, not significant). The two systems also run on different clocks: GPS keys rotate every ~3.8 d, EAM Group-2 prefixes every ~26 d — about 7× slower — so no phase-lock is expected. GPS OTAD key distribution and HFGCS prefix tasking appear independent."

SKYMASTER events. I've documented what I call "SKYMASTER events" — an idiosyncratic use of the callsign 'SKYMASTER', heard perhaps ~8–10 days of the year. It's associated as taking place on or around multiple days of 'unusual' EAM traffic, and these "SKYMASTER event" dates tend to recur around the same time each year (https://neetintel.github.io/index.html?skymasters&compare). For the October "SKYMASTER events" it seems harder to not conclude a relationship with the publicly announced Global Thunder exercises. For the the others, even though they're also apparently annual, I've struggled to tie to them to publicly revealed exercises.

I'm very interested in these, so I tried hard to find any relationship at all between them and the GPS data. I fed the AI the list of dates plus context — nothing. I also had it generate calendars flagging the dates alongside GPS behavior so I could eyeball it manually — also nothing.

Other notable dates. I have a handful of other dates/events I consider similarly 'notable'. The AI found no relationship for those, and neither did I by manual methods.

GPS → EAM

TEXT messages. I was fascinated by the appearance of TEXT-prefixed GPS messages and manually checked whether the days they appeared stood out as notable on my end. For days where I did have EAM transcribed, I didn't see any consistent relationship to the type or quantity of EAM traffic. More TEXT messages landed on days I consider notable than not, but in a way far too loose to convincingly explain as significant to anyone else. (As a hobbyist I use that as my bar for whether there's substance to a suspicion. Here, no.)

"Weird days." I asked the AI to identify "weird days" in the GPS data by explaining what I treat as "weird days" in the HFGCS. Independent of your article, it surfaced some of the same notable events (e.g. the sentinel dates); I also had it read through CLAIMS.md. Whether 'objectively' or 'subjectively', I didn't see any correlation between the GPS "weird days" and the HFGCS "weird days".

Substring alignment. The 'substring alignment' your article notes is something I've also found in EAMs. But where it's rare in the GPS data (instances years apart), in EAMs it's far more common — handfuls of examples are findable in most years, weeks/months or sometimes only days apart (and only within certain groups, where it's a known property). So no alignment between the GPS dates and the EAM dates was possible to find.

What I did not check for

• Whether the GPS data might serve as a 'seed' for some element of EAM generation/encoding/encryption. This is terribly open-ended and I wouldn't know where to begin.
• Whether portions of the GPS data ever appear in the EAMs. Given the 32-character set (A–Z, 2–7), even with the TEXT messages in the GPS data, I frowned/shrugged at trying to find even partial matches.

A note on the dataset

A weakness of my dataset is that EAMs have to be heard on a shortwave receiver and then transcribed (and ideally recorded for verification). I have several near-continuous monitoring stretches longer than a handful of days (including but not limited to June 23 2023 – Feb 1 2024, Apr 9–28 2024, June 1 – June 30 2024, Oct 1 – Nov 30 2024, {...} Jan 1 – Jan 13 2026, May 30 – June 21 2026). That made it difficult to test cleanly across "all of 2023–2026"; I often had to bound any potential finding to the monitored periods, then ask whether it still made sense if extrapolated outside them.

[NEETINTEL]

I 'hijacked' one of my tools I used to find structure in HFGCS EAMs and look for sign of any structure.

The 'heatmap' approach is basically looking for multiple messages to see if they have repeating characters or segments in similar positions. For example, if I had two EAMs that looks like this

ABCDEFDNPQRS
HIJKLMKTUVWX

both have matches for an X__X pattern (i.e. regex (.)(.)(.)\1) and so you would highlight the relevant positions of both messages (the Ds in message 1, the Ks of message 2). Across multiple messages, you'd expect a lot of false positives to show up, and so to avoid a mess of highlights that blur together into a meaningless mess of colors, I needed to impose some sort of minimum threshold. Among other things, I valued regular expression matches when they occurred in the same position across multiple messages. Matches for (.)(.)(.)\1 are increasingly likely to occur by chance the more messages there are, but if your X__X are occurring in the same positions, they should be scored higher. There are some other things I added in to guard against false positives, etc.

A very simple example is the 'heatmap' for 29 character EAMs; here or else here

Applying this approach to the entire set of data found nothing. The first thought I had was "well, that is to be expected, these are probably keys after all" and while I still think that's almost certainly the case, my second thought was "if there is any structure among any subset of these messages, it would be drowned out" and the TEXT messages immediately came to mind as something that must've been 'drowned out' – even though the 'TEXT' prefix effectively is a structure, it is cancelled out by being a handful among such a volume of messages.

For example, the 29 character EAM patterns wouldn't be found had I thrown all the EAMs into a single dataset. The structure of 29 character EAMs is different from that of other EAMs of different lengths. This is a convenient and immediately self-defining group.

Defining the TEXT-prefixed messages of the GPS payload as their own self-defined group predictably highlights T__T, but unfortunately I don't see anything meaningful flagged in the balance of their data;

Now, what about the rest of the data? Unlike EAMs, which have properties that allowed me to predefine discrete groups in a consistent manner, and structures immediately popped up on my very first test, there is nothing that occurs to me when I look through the GPS payloads so as to partition them into smaller groups. This is probably expected – IMO these payloads are probably keys, and not messages, and so I could run any iteration and conclude "well, there you go". However, if I was wrong, and some subset of these are messages with structure, then I have to anticipate that group to find that structure.

Since 'heatmap' tool is kind of-sort of a crude visualizer of the entropy measure of messages, so I thought I should check if low entropy messages have structure that can be found;

Eyeballing this, there is no consistency across these messages, so I wouldn't be able to identify any structure.

I've taken only a couple random stabs in the dark – group by year, group by first character, look only at those messages broadcast by a single PRN – and eyeballed the heatmaps generated based on the and have found nothing I'd considered worth writing about. The only criteria that's occurred to me thus far that yielded any results that caught my attention at all was to subdivide by year, and then also by whatever PRN broadcast the message first.

(Messages in 2007 that first broadcast on PRN01; for 3 of 9 messages, characters 12 and 20 are the same) (Messages in 2015 that first broadcast on PRN03; for 3 of 4 messages, characters 17 and 18 are the same) (Messages in 2016 that first broadcast on PRN02; for 3 of 4 messages, characters 2 and 11 are the same) (Messages in 2019 that first broadcast on PRN26; for 2 of 2 messages, characters 5 and 20 are the same) (Messages in 2020 that first broadcast on PRN03; for 3 of 8 messages, characters 5 and 17 are the same) (Messages in 2024 that first broadcast on PRN03; for 3 of 10 messages, characters 3 and 19 are the same) (Messages in 2025 that first broadcast on PRN10; for 2 of 2 messages, characters 1 and 16 are the same)

I've excluded the TEXT messages from the above, but where relevant, yes, they were flagging for characters 1 and 4 being identical.

I really doubt any of these would survive a statistical analysis, and patterns are being identified only because the selection criteria is creating relatively small groups, and it's inevitable some of those groups would end up flagging as having structure. While I suppose it is possible and I don't feel strongly inclined to reject the possibility there is some way to identify and meaningfully define some methodology of identifying 'groups' within the dataset that could identify structure after all, I imagine this is in fact more evidence that the GPS payload data really is random.