016c (2/2): Galileo E5 secondary codes (CS4/CS20/CS100, ICD Tables 20-22)

ykp commented

2026-09-24 08:52:28 +02:00

Owner

Second increment of backlog step 016c, stacked on merged 016c-1/2 (PR #22).
(Small process note: the first attempt at this increment branched from a
stale local main and was redone from the fetched PR-#22 merge - no content
difference, just a clean base.)

Data provenance - Galileo OS SIS ICD v2.1 PDF, Tables 20-22:

Fixed codes: CS4_1 = 'E', CS20_1 = '842E9', CS25_1 = '380AD90' - the
ICD's own CS25_1 binary example reproduces exactly from the hex
(MSB-first = first chip in time)
100 per-SVID codes CS100_1..CS100_100 (100 chips each) extracted from
Tables 20/21
Assignment (Table 22): e5a_i -> CS20_1 (all SVIDs), e5a_q -> CS100_n,
e5b_i -> CS4_1 (all SVIDs), e5b_q -> CS100_(n+50)

Implementation

codes.py: GAL_SECONDARY_FIXED, GAL_CS100, _secondary_bits,
galileo_secondary_code(component, prn) - bipolar output
generator.py: gal_e5a/e5b data_mode 'e5' - secondary codes on the
absolute 1 ms epoch grid (one chip per primary code epoch, matching
the ICD's data-bit alignment); data on I, pilot on Q
harness.py: gal_e5a/e5b data replicas carry the matching secondary

Also investigated this increment (documented):

Galileo E1-B/E1-C memory codes: NOT in the v2.1/v2.2 PDFs (electronic
Annex C only; all candidate GSC URLs 404). BUT the codes are baked in
gnss-sdr's Galileo_E1.h (50 PRNs x 4092 chips, E1-B + E1-C) - extracted
and staged for the next increment (016c-3/3, E1 CBOC modulation +
generator integration); provenance and licensing noted there
CS25_1 (E1-C secondary) also baked now for that increment

Tests (4 new): secondary assignment (fixed codes + per-SVID CS100
mapping), per-epoch in-phase correlation proving CS20/CS4/CS100 on the
1 ms grid for e5a-i, e5b-i, e5a-q.

Local verification: pytest 173 passed + 1 gui skip, ruff clean (Python 3.14).

Note (process): NOT to be merged by automation - awaiting manual review/merge.

Second increment of backlog step 016c, stacked on merged 016c-1/2 (PR #22). (Small process note: the first attempt at this increment branched from a stale local main and was redone from the fetched PR-#22 merge - no content difference, just a clean base.) **Data provenance** - Galileo OS SIS ICD v2.1 PDF, Tables 20-22: - Fixed codes: CS4_1 = 'E', CS20_1 = '842E9', CS25_1 = '380AD90' - the ICD's own CS25_1 binary example reproduces exactly from the hex (MSB-first = first chip in time) - 100 per-SVID codes CS100_1..CS100_100 (100 chips each) extracted from Tables 20/21 - Assignment (Table 22): e5a_i -> CS20_1 (all SVIDs), e5a_q -> CS100_n, e5b_i -> CS4_1 (all SVIDs), e5b_q -> CS100_(n+50) **Implementation** - codes.py: GAL_SECONDARY_FIXED, GAL_CS100, _secondary_bits, galileo_secondary_code(component, prn) - bipolar output - generator.py: gal_e5a/e5b data_mode 'e5' - secondary codes on the absolute 1 ms epoch grid (one chip per primary code epoch, matching the ICD's data-bit alignment); data on I, pilot on Q - harness.py: gal_e5a/e5b data replicas carry the matching secondary **Also investigated this increment (documented):** - Galileo E1-B/E1-C memory codes: NOT in the v2.1/v2.2 PDFs (electronic Annex C only; all candidate GSC URLs 404). BUT the codes are baked in gnss-sdr's Galileo_E1.h (50 PRNs x 4092 chips, E1-B + E1-C) - extracted and staged for the next increment (016c-3/3, E1 CBOC modulation + generator integration); provenance and licensing noted there - CS25_1 (E1-C secondary) also baked now for that increment **Tests** (4 new): secondary assignment (fixed codes + per-SVID CS100 mapping), per-epoch in-phase correlation proving CS20/CS4/CS100 on the 1 ms grid for e5a-i, e5b-i, e5a-q. Local verification: pytest 173 passed + 1 gui skip, ruff clean (Python 3.14). Note (process): NOT to be merged by automation - awaiting manual review/merge.

ykp added 1 commit

2026-09-24 08:52:29 +02:00