GSSNet & ALERT FM: a replication manual

1. System architecture

GSSNet is a one-way data-distribution system that carries short addressed messages over the standard RDS data subcarrier of ordinary FM broadcast stations. ALERT FM is the alerting application built on it. The core engineering idea is that a single message, uplinked once, reaches every participating FM transmitter simultaneously over satellite, and inexpensive receivers in the field decode and act only on the messages addressed to them.

Three properties define the design and shape every chapter below:

• Push, not poll. The network distributes the same non-repeated data to all edges at once; there is no per-receiver request path. Distribution is strictly one-way (satellite/RF downstream only).
• Bandwidth is conserved by addressing. RDS is a very small channel (~1187.5 bps). The entire addressing scheme — group codes, areas, county-based multicast, encoder filtering — exists to transmit and process the fewest possible messages.
• Intelligence is split across three tiers. The comm server decides who to address; the tower encoder decides whether a message is relevant to its coverage; the receiver decides whether it is for its owner. No single node holds the entire map.

The protocol works with standard, unmodified RDS encoders: GSSNet does not require special encoder hardware, only that the encoder support the RDS Basic Paging Protocol and a configurable group sequence. This is a deliberate cost/availability decision and is foundational to the design.

2. End-to-end signal path

The full chain, from origination to a sounding receiver:

ORIGINATION SOFTWARE  (alert composed; address grammar applied)
      │  one alert → address triples
      ▼
COMM SERVER
      │  expand [address].[service]@[area] → UECP "paging" commands (MEC 1B, 80 char)
      │  ×10 duplication for "urgent"; emit system code + UTC clock + heartbeat
      ▼
SATELLITE UPLINK → DVB-S2 transponder
      │  multicast UDP  224.9.9.9 / 224.12.x.x : port 5401
      ▼
SAT DATA RECEIVER at station  (DVB-S receiver + ~1 m dish)
      │  forwards alert packets on the LAN (UDP)
      ▼
TOWER RDS ENCODER  (standard RDS encoder, Basic Paging)
      │  filter on multicast + site.encoder address → 10-slot paging buffer
      │  emit RDS Group 1A (1/s system code), 4A (1/min UTC), 7A (alert, every 6 s)
      ▼
FM TRANSMITTER  — 57 kHz RDS subcarrier, ~10% injection, locked to 19 kHz pilot
      ▼
RECEIVER  — derive day's system code from 4A, validate 1A, lock; decode 7A;
            filter by serial #/group/geo; sound alert

Every arrow is a point at which a message may be filtered, duplicated, or (on the lossy UDP/satellite leg) dropped. The mental model that governs everything downstream: one originated alert is not one transmission — it fans out into one wire message per [address].[service]@[area] triple, multiplied by ten if marked urgent.

3. Alert origination & the address grammar

Messages originate in software that abstracts the addressing complexity behind a compose form, then hands a structured request to the comm server. Regardless of the front end, every originated message resolves to one or more triples of the form:

[address] . [service] @ [area]

Each triple is exactly one message the comm server must transmit and an encoder must process.

3.1 [address] — serial number vs group code

• On the wire [address] is a decimal number identifying either an individual device serial number or a group address code.
• Origination software typically lets the operator choose the type: a group code is entered in hexadecimal (devices require hex) and converted to decimal for the comm server; a serial number is decimal throughout.
• Group addressing is the bandwidth lever. The replication rule is to provision as few group addresses as possible and minimize serial-number addressing, because each distinct address is a separate transmitted message.

3.2 [service] — timeslot selection

The service code selects which of the ten per-minute RDS timeslots a message uses. The standard service is alert = 40 (a single timeslot). A high-priority message uses the urgent service, which occupies all ten 6-second slots; the comm server therefore emits ten copies of the message, one per slot. Battery receivers that sleep between subscribed slots only reliably catch alerts on slots they subscribe to, which is the functional reason urgent exists.

3.3 [area] — the routing handle

An area is a dotted, domain-like name that resolves (in the comm server) to a network destination plus an encoder address. Origination selects an area; the comm server resolves it (Chapter 6). Length constraints that originate here: a base message is 80 characters; an "extended length" message splices three 80-character fragments for up to 240 characters; geographic/polygon messages are smaller still because the shape consumes payload bytes.

4. The comm server

The comm server is the network's brain. It accepts originated alerts, resolves the areas table, expands each alert into UECP paging commands, duplicates them for urgent service, and emits them as UDP/multicast to the encoders. It also generates the housekeeping streams that keep the network coherent.

4.1 Output: UECP paging commands

The comm server speaks UECP (the RDS Universal Encoder Communication Protocol). A decoded paging command (test message to a group code, site/encoder 55.55) shows the structure:

• FE UECP message start; packed address 0D F7 = first 10 bits site (55), last 6 bits encoder (55).
• 1B = Message Element Code: an 80-character paging command.
• Inside the paging command sits the GSS Payload (defined by the Air Spec): a service ID (e.g. 0F A0 = 4000), a sender ID (0 on the current comm server), a per-message sequence counter that increments every message, an address type/length, and the group/address code (e.g. C0 F8 = 49400).

4.2 Expansion math

One originated alert becomes N comm-server messages, one per [address].[service]@[area] triple; urgent multiplies by 10. Example: an urgent alert to 3 addresses generates 10 × 3 = 30 wire messages. This duplication happens at the comm server, downstream of the origination UI, which is why origination logs show the triples but not the ×10.

4.3 Housekeeping streams

4.4 Transport reliability

The comm server emits UECP over UDP only, with no retransmission. A dropped packet on the satellite/internet path is a lost message with no automatic retry. Verification is done by packet capture: every originated alert should produce a corresponding packet leaving the comm server. There is no documented redundant comm-server cluster; resilience comes from overlapping RF coverage and uplink redundancy.

4.5 Lineage: the original RDS Server

The comm server has a direct technical ancestor: an early Windows "RDS Server / First Alert" application (2005) that already performed the core function — take an addressed message and push it to an RDS encoder over either UDP or a serial COM port (COM1–4 at 9600 baud, default encoder IP 192.168.1.199), tracking sent counts and the encoder response. The production comm server industrialized this same compose→address→emit pattern and added the areas table, multicast fan-out, UECP paging, urgent duplication, and the housekeeping streams. The dual UDP-or-serial encoder link is original to the design.

5. Satellite path & transport

Distribution is a one-way DVB-S multicast: every station's dish sees the same carrier, and addressing decides which packets each site acts on. The space segment was migrated in the 2023–2024 transition from SES-3 (transponder “SES3-22”, 103° W) to SES-1, transponder 15K (“SES1-15K”, 101° W). The current carrier parameters needed to receive the data:

5.1 Satellite data receiver

The station-side unit is a DVB-S data receiver (Westport/Kalipso class, or an integrated SatMaxx-class receiver/monitor) feeding a ~1 m dish. It demodulates the transport stream and forwards the alert packets onto the local LAN over UDP port 5401. Receiver health is read as EbNo and BER.

5.2 IP transport

• UECP commands are carried as multicast UDP (224.x.x.x) on port 5401.
• A once-per-minute heartbeat on 224.9.9.9 confirms the receiver is passing GSS traffic.
• No ARQ: the satellite/IP leg is fire-and-forget. For terrestrial (internet-fed) encoders the same UECP can be delivered to a static public IP, optionally behind a site-to-site tunnel.

6. Satellite addressing & routing

The comm server maintains the areas table that turns an @[area] handle into an actual destination. Each area row resolves to two addressable components:

1. Network-level address — the IP+port over UDP. Satellite-fed encoders use a multicast address (224.x.x.x) so one packet reaches many encoders; terrestrial encoders use a static public IP.
2. RDS encoder address — a site.encoder pair embedded in the UECP command (see Chapter 7).

Stored row format is name, multicast, site.encoder, "description". Worked rows (encoder/state #52 example):

1.1.pr.us,        224.9.9.9,    1.52,  "individual site"
pr.us,            224.9.9.9,    0.52,  "statewide (time = GMT-240)"
statewide.pr.us,  224.12.52.1,  0.0,   "statewide alerting"

6.1 The multicast map

An encoder can subscribe to a maximum of 50 multicast groups — roughly the number of counties a strong (+60 dBu) signal covers. This cap is why a single encoder is never loaded with all counties.

6.2 Site/encoder numbering plan

• UECP field mapping: UECP "Encoder" = state, UECP "Site" = station.
• Capacity: 63 (+0) Encoder/state addresses and 1023 (+0) Site/station addresses.
• A station's state is defined by where its transmitter sits. Site numbers are assigned incrementally as stations come online (not call-letter based).
• 0 is a wildcard: 0.<state> targets every encoder in a state; 0.0 means "ignore UECP addressing, accept anything matching the multicast."

6.3 Bandwidth strategy

The endgame is national county-based broadcast with edge filtering: every encoder hears every county alert and "votes" on whether its station's coverage contour includes that county before transmitting (Chapter 7). Consolidating onto county multicast keeps satellite bandwidth low while letting many simultaneous alerts coexist. Provisioning a new area is therefore an exercise in minimizing area/group combinations.

7. Tower encoder addressing

At each transmitter site, a standard RDS encoder is the edge router between the IP network and the FM signal. It ingests UECP over UDP and emits the GSSNet RDS groups. Two encoder families are used; both must support the RDS Basic Paging Protocol and a configurable group sequence.

7.1 The two-key acceptance filter

An incoming UECP message is accepted into the encoder's paging buffer only if both match:

1. the encoder is subscribed to the message's multicast address, and
2. the message's site.encoder address (or a wildcard) matches the encoder's configured site/encoder.

Otherwise the message is discarded. This is the mechanism by which a national broadcast is filtered down to locally-relevant alerts — the encoder's subscription set is its coverage definition.

7.2 The paging buffer and "overload"

The paging buffer holds 10 messages, one per 6-second timeslot. If messages arrive while the buffer is full, they are discarded until a slot frees; this full-buffer drop condition is what "encoder overloaded" means. Correct provisioning (few addresses/areas per encoder) is what keeps the buffer from saturating.

7.3 Required encoder configuration

7.4 Encoder families & programming

Port conventions at the encoder: 5401 UECP (GSS), 5402 RadioText/song metadata, 5403 EAS multicast, 5404 alternate alert-data port, 50080→80 web UI, 23 telnet.

8. The over-the-air RDS protocol

Over the air, GSSNet is standard 57 kHz RDS/RBDS. It uses the RDS Basic Paging Protocol (Annex M of IEC 62106:1999) and only redefines how Type 7A group content is interpreted; the underlying RDS block/checkword structure is unchanged, which is what allows standard encoders to carry it.

8.1 The three GSSNet groups

8.2 The per-minute timeslot wheel

A minute is divided into ten 6-second timeslots, mapped one-to-one onto the encoder's 10-message paging buffer. The service code (Chapter 3.2) selects the slot(s): standard alert uses one slot (interval 0, marked by the 4A); urgent uses all ten. Timeslot 0 always begins at the first 6 seconds of the minute.

8.3 1A and 4A group encoding

The GSS-specific redefinition is confined to Group 7A (Chapter 11) and the system code in 1A block 4 (Chapter 9). Everything else in the 1A and 4A groups follows the underlying RDS standard (IEC 62106); the GSS layer only sets it via the encoder's UECP command interface. The operative details:

Group 4A — clock-time / date

• Transmitted as one 4A group at the top of each minute. Enabled on the encoder by CT=1.
• Carries both date and time in UTC. Time is initialized with TIME=HH:MM:SS (or HH:MM); date with DATE=DD/MM/YY (or YYYY; note the day/month order).
• Local time offset is sent per the RDS standard as a signed number of half-hours from UTC, set by CT.OFFSET=x. Example: US Pacific (PST, UTC−8) = CT.OFFSET=-16; US Central (CST) = CT.OFFSET=-12. (The encoder CLI expresses the offset in half-hours; some web UIs show it in whole hours.)
• The offset is updated per state at the day/time of each Daylight Saving change — the mechanism by which non-internet encoders get correct local time.
• The raw field packing (Modified Julian Day, hour, minute, signed half-hour offset) is exactly the standard RDS 4A layout; GSSNet does not alter it.

Group 1A — system code + paging position

• Transmitted once per second; enabled automatically by including one or more 7A groups in the group sequence.
• Block 4 carries the daily system code (Chapter 9). Beyond that, as part of the legacy Radio Paging (RP) protocol, 1A also conveys where in the minute the current second sits, relative to the top-of-minute defined by 4A — this is what aligns the receiver to the 6-second timeslot grid.
• 1A additionally carries the ECC (Extended Country Code) via Slow Labelling Codes, variant 0 (set by the corresponding UECP SLC command). ECC is normally absent on plain RDS but is present when GSS is enabled, because it rides in 1A.

Group sequence

The encoder's group sequence determines the ratio of group types on air. Representative sequences:

no paging:    4A,0A,0A,2A,2A,0A,0A,2A,2A,0A,1A,0A …
with paging:  4A,0A,7A,0A,7A,2A,7A,2A,7A,0A,1A,7A,0A …   (2 of 3 groups = 7A while sending)

9. The system code (daily PIN)

The "system code" (informally the daily PIN) is the value that identifies a valid GSSNet network and gates receiver lock. It is derived from the date, not random:

input string = "GSSNETSYSTEMCODE YYYY-MM-DD"   (UTC date)
CRC-16 over that string   (poly x¹⁶+x¹²+x⁵+1, init 0xFFFF, result inverted)
system code = the 11 least-significant bits of the 16-bit CRC

• The 11-bit code is carried in the last block of Group 1A (the Program Item Number Code), transmitted once per second whenever paging is enabled.
• Because the date is the input, the code changes at 00:00 UTC each day. The encoder stamps the current code into 1A (the comm server pushes it every 10 minutes).
• The network-name part of the string (default GSSNETSYSTEMCODE) is configurable: different strings yield different codes, so multiple parallel GSSNet networks can coexist on air, each invisible to the others' receivers.
• The CRC parameters are identical to the message-payload CRC (Chapter 11.4): a single 16-bit CRC-CCITT definition is reused throughout the system.

10. Receiver lock mechanism

This is the conceptual heart of the system and is easy to get backwards: the daily code is not transmitted to the receiver as a secret to match. The receiver computes the expected code itself and checks the broadcast against its own answer. The code is self-validating.

10.1 The lock decision

1. Get the date from the air. Read Group 4A (UTC clock/date, top of every minute).
2. Compute the expected code. Run CRC-16 (x¹⁶+x¹²+x⁵+1, init 0xFFFF, inverted) over GSSNETSYSTEMCODE YYYY-MM-DD; keep the low 11 bits.
3. Read the broadcast code. Read the 11 LSBs of block 4 of Group 1A (once per second).
4. Compare. If equal, this is a valid station on the right network: lock and stay. Otherwise keep scanning (130-second timeout per channel).

Three ingredients make this work, none of them a transmitted secret: the algorithm (in firmware), the network-name string (in firmware, configurable for parallel networks), and the date (over the air in 4A). Both ends independently derive the same number from the same date, so they always agree without the code ever being delivered to the receiver.

10.2 Acquisition / scan order

On power-up the receiver scans the FM band and ranks candidates: by RSSI, then presence of any RDS, then presence of the 1A beacon, then the correct system code. Finding the valid code is what makes it stop and stay.

10.3 Grace window & the 4A precondition

At the date rollover, the receiver also accepts the previous day's code during the first hour after 00:00 UTC, to tolerate clock skew. And because the receiver needs the time before it can compute the code, 4A sync is a precondition for lock — if it cannot sync to 4A (it scans away after failing twice), it cannot validate the code and will not lock.

11. The 7A message wire format

A GSSNet message is carried across consecutive RDS Type 7A groups (other groups may be interleaved). The format below is the complete bit-level structure required to encode or decode a message.

11.1 The 7A group, redefined

The Paging A/B bit toggles between distinct messages (marks a new/repeated call). The segment address code identifies what blocks 3 & 4 of this group contain. Only codes with the high bit set (1000–1111) are GSSNet.

11.2 The segment cycle

1000 is the header; 1001–1110 are six data segments of 4 bytes each (24 bytes per cycle, index n advancing by 24 each cycle); 1111 ends the message. Maximum message length is 80 characters; a message also ends when the Paging A/B flag flips.

11.3 The header group (segment 1000)

Block 3 = Y1 Y2 Z1 Z2; block 4 = Z3 Z4 + 8 unused bits. All BCD.

• Y1 Y2 Z1 Z2 = Service ID (SID), 0000–9999. Every receiver subscribes to ≥1 SID. Four reserved broadcast SIDs — 0000, 2000, 4000, 7000 — are the "ALL alert" channels: every receiver listens to them in any timeslot.
• Z3 = Key ID (KID), 0–9: 0 = clear text, 1 = receiver individual key, 2–9 = shared key id. In the deployed public system KID = 0 (Chapter 14).
• Z4 = Time Slot (TS), 0–9. Together [Y1 Y2 Z1 Z2 Z3 Z4] form the UGSID (unique global service identity).

11.4 The application message (bytes GSS_1…x)

The data bytes carry a self-describing application message, MSB-first (network order). If KID > 0 the whole field including the CRC is encrypted (unused in practice).

MO │ SEQ │ ADPRE+TYPE │ [ADLEN+ADTYPE │ ADDR] │ LEN │ DATA │ CRC

MO     8 bits   Message Originator (sender ID), 0–255
SEQ    8 bits   Sequence counter, per-MO, 0–255
ADPRE  1 bit    Address present? 1 = ADDRESS FIELD follows; 0 = broadcast
TYPE   7 bits   Message type 0–127 (see 11.5)
ADLEN  4 bits   (opt) length of ADDR in bytes
ADTYPE 4 bits   (opt) address type (0 = numeric)
ADDR   ADLEN B  (opt) the GSSNet address
LEN    8 bits   length of DATA, 0–74 bytes
DATA   LEN B    the application payload (alert text)
CRC    16 bits  CRC-16 (x¹⁶+x¹²+x⁵+1, init 0xFFFF, inverted),
                over MO..DATA; the 7A group-1 address header is excluded

11.5 Message types (TYPE field)

Extended length & multi-loop assembly: a single paging message is 80 characters; up to three are spliced for 240 characters. Crucially, the segment-coded fragments are not required to arrive within one minute. The message repeats in the per-minute loop (Chapter 8.2), and the receiver accumulates fragments across successive 60-second loops: one loop carries the first part, the next appends the remainder, and so on, until the full message is reassembled and its CRC-16 (Chapter 11.4) validates. Only on a passing checksum does the receiver render and alert.

12. Message addressing & geo-targeting

The ADTYPE field selects how the ADDR bytes are interpreted, and is the receiver's filter key.

12.1 Numeric addressing (ADTYPE 0/1)

• ADDR is a number up to 64 bits (8 bytes), used as an individual or group address.
• This is the wire form of the serial-number / group-code split: a serial number selects one device; a group code selects a set.
• FIPS-derived group codes: a county group code is formed as "2" + county FIPS, then converted to hex. Example: "2" + 01073 (Jefferson Co.) = 201073 → 0x31171.
• A broadcast message (ADPRE = 0) carries no ADDR.

12.2 Geographic addressing (ADTYPE 2/3/4)

A single message can target an arbitrary area; each receiver decides locally whether it is inside. The address type selects the shape:

• Reference point (P1) is an absolute longitude/latitude in the address field; remaining vertices are signed x/y offsets (two's-complement) from the previous point.
• SHAPE indicator (4 bits): 0 = circle by radius-in-km from PE (0 ⇒ 500 m, no offsets); 1 = circle, radius from one offset; 2 = square (reference + diagonal offset); 3–15 = polygon with that many vertices.
• Precision/resolution: PREC ∈ {100, 300, 1000, 3000, 10000 m}; RES ∈ {12, 16, 20 bits/point}; special high-precision case ≈ 30 m. Global ~30 m precision uses a 5-byte address.
• A radio-audio control bit can enable the FM audio; an MFI/DFI byte selects a canned message ID (0–63) or a text data field (DFI 64).

13. Receiver decoding & device model

Because the transmit side is standard RDS, any FM/RDS receiver can be a GSSNet device; only the firmware that decodes the GSS-specific parts is GSS-provided.

13.1 The receiver stack (OSI view)

Flow: FM-RDS radio → RDS handler → packet handler → message handler → UI. GSSNet logic lives only in layers 3–4.

13.2 Decode pipeline

1. Acquire/lock per Chapter 10 (4A → compute code → validate 1A).
2. Collect consecutive 7A groups by segment code into the header (SID/KID/TS) plus the GSS byte stream, accumulating fragments across successive per-minute loops until the message is complete (segment 1111 / A-B flip).
3. If KID > 0, decrypt (unused in practice).
4. Verify the CRC-16 over the assembled application message. The receiver holds the partial message and does not render or alert until the checksum passes — this gates against partial or corrupted delivery.
5. Apply the address filter (ADTYPE): numeric match against subscribed serial/group; or, for geographic types, reconstruct the polygon (reference point + offsets) and run a local point-in-polygon test of the device's stored fixed position using the on-device lat/long reference library, at four-decimal-degree precision (~11 m). The device alerts only if it is inside.
6. For TYPE 1/2, render DATA as text and signal per the device's priority profile.

13.3 Device configuration model (BLE)

Receivers are provisioned over Bluetooth Low Energy via a GATT server (base UUID f90aXXXX-21ea-43a5-a81e-43901297b9a7). Pairing requires on-device numeric confirmation (a number shown on the device must match the phone, confirmed with the front button) — standard BLE numeric comparison, giving encryption and MITM protection. Bonding allows reconnect without re-confirmation.

Provisioned objects: an array of Services (each SID 0–9999 + timeslot 0–9, optionally locked), an array of up-to-32-bit Addresses (with a lock bitmask), and up to five Places (Place 0–4) — each a name, a 64-bit lat/long position, and a ZIP code. An incoming alert reports an address-match bitmask (Place 0–4 / address-list / broadcast / no-match). Positions are signed 32-bit lat and long in units of 1/65536 degree, transferred LSB-first.

13.4 Alert rendering profiles

Per-priority profiles (Test / Silent / Normal / High) configure volume (dB offset), LED blink+brightness, backlight, timeout (0 = indefinite), a relay-enable flag, and a siren:

Other config: antenna (internal/external), FM alert volume (0–63), backlight levels (idle-on-power / idle-on-battery / active, 0–5), scroll mode (horizontal/vertical). Devices keep statistics (text/area/heartbeat/other, and matched counts). Firmware updates over BLE use the Nordic DFU bootloader.

13.5 Device variants by capability

14. Security model

ALERT FM is best described as authenticated but unencrypted public broadcast. What binds a receiver to the correct network is the daily system code plus the 4A time (Chapters 9–10): the receiver derives the day's code from the clock and locks only to a station carrying it. The alert payload is then decoded straight from the RDS in the clear.

• The 128-bit KID encryption (Chapter 11.3) is an optional capability for private/individual messaging. In the deployed public system KID = 0; payloads are clear text.
• The system code itself is a CRC-derived code, not a cipher — its purpose is network identification and tamper/health detection, not confidentiality.
• OTA programming of receiver addresses is part of the design, but message confidentiality is not a property the public system provides.

For replication: implement the system-code derivation and the lock check exactly (they are what make the network coherent and self-monitoring); the payload cipher can be omitted entirely without affecting public alerting behavior.

15. Quick reference & glossary

15.1 Addressing cheat-sheet

[address] . [service] @ [area]

[address]  decimal serial # (one device)  OR  group code (hex → decimal on wire)
[service]  alert = 40 (1 slot)  |  urgent = all 10 slots (×10 messages)
[area]     dotted name → network addr: 224.x.x.x (sat) | static IP (terrestrial)
                       → RDS encoder addr: site.encoder  (encoder=STATE, site=STATION, 0=wildcard)

site/encoder packed in UECP: 10 bits site + 6 bits encoder
county group code = ("2" + county FIPS) → hex

15.2 RDS group cadence

1A  every 1 s    system code (11 bits, block 4) — lock gate
4A  every 1 min  UTC clock — slots timeslots, basis for code computation
7A  every 6 s    alert payload (2 of 3 groups while sending)
0A/2A  filler    PS name / RadioText
GRPD=1           required GSS group-designation flag

15.3 7A segment codes

1000        header: SID / KID / TS
1001..1110  six 4-byte data segments (24 bytes/cycle)
1111        end of message
A/B flag    toggles between messages

15.4 Ports & multicast

UDP 5401   UECP alert (GSS)          224.9.9.9        system-wide / all-call / heartbeat
UDP 5402   RadioText/metadata        224.12.1xx.yyy   county (xx = state+100)
UDP 5403   EAS multicast             224.12.<state>.1  statewide
UDP 5404   alt alert-data            224.12.254.254   EAS/IPAWS → ENDEC
TCP 23     telnet (legacy encoder)   50080→80         encoder web UI

15.5 Glossary

16. Open questions

Items previously flagged as incomplete, with their current resolution status:

• 1A/4A encoding — resolved. Apart from the system code in 1A block 4 and the 7A reinterpretation, the 1A and 4A groups use standard RDS (IEC 62106) layouts, driven via the encoder UECP interface (Chapter 8.3): 4A = clock/date in UTC with a signed half-hour local offset (CT.OFFSET), 1A = system code + Radio-Paging position-in-minute + ECC via Slow Labelling Codes variant 0. There is no GSS-specific 1A/4A bit redefinition to reverse-engineer; implement the RDS-standard fields.
• Polygon point-encoding formula — resolved. The two PE formulas in the source are moot for replication: the address only carries the polygon vertices, and the inside/outside decision is computed on the receiver, which holds a lat/long reference library and its own stored position and runs a point-in-polygon test at four-decimal-degree precision (~11 m). Polygon data consumes message length. What matters is reconstructing the vertices and testing locally, not the exact PE byte packing (Chapters 12.2, 13.2).
• Message encryption — resolved (confirmed absent). An exhaustive search of the full archive (~2.1 GB plus ~16.9 GB of mail) finds no encryption specification, no “GSS-06.003,” no cipher algorithm/mode/key-schedule, and no KID>0 traffic — not as code and not even as discussion. The KID field exists in the wire format, but the optional cipher was never implemented. The only confidentiality/validity mechanism on the message path is the daily system code (Chapter 9). The public system is clear-text (Chapter 14); replication can omit the cipher entirely.
• Over-the-air data rate — resolved. The OTA rate is standard RDS (~1187.5 bps); there is no faster carrier. The higher “data rates” in early material describe effective message throughput, which is built by polling and combining message fragments across successive 60-second loops: the first loop carries the first part of a message, the next loop appends the remainder, the receiver verifies the checksum, and on a pass it displays the message and notifies the user (Chapters 11.5, 13.2). Capacity is gained over time, not over bandwidth.

17. Source specifications

This manual is built from the GSSNet/ALERT FM specification set and supporting technical material:

• GSSNet Interface Protocol for Third Party Devices — the Type 7A wire format, segment codes, header, application message, CRC, addressing types (the basis of Chapters 11–12).
• GSSNet System Code — the daily system-code CRC algorithm and 1A carriage (Chapter 9).
• GSSNet Polygon Addressing — the geographic/Grid Alert addressing extension (Chapter 12.2).
• RDS Implementation in GSSNet Receivers — transmitter/receiver model and the OSI mapping (Chapters 1, 13).
• Warner/Wallmer BLE Specification — receiver provisioning, configuration objects, and alert profiles (Chapter 13).
• UECP / RDS standards — the encoder command layer and the RDS Basic Paging Protocol (Annex M, IEC 62106 / RDS).
• Supporting RF/transport parameters and addressing conventions reconstructed from internal engineering analysis.

External standard references used for definitions: the RDS/RBDS standard and NWS SAME/event codes (for FIPS/event-code context only).