Implement Galileo E1B I/NAV navigation decoding
This commit is contained in:
@@ -0,0 +1,57 @@
|
||||
# Navigation hardware/software partition
|
||||
|
||||
The measured partition keeps sample-rate work in the tracking IP and performs
|
||||
I/NAV decoding in software. No result in this milestone justifies placing a
|
||||
soft-decision Viterbi decoder or navigation database in RTL.
|
||||
|
||||
## Tracking-IP output contract
|
||||
|
||||
One record is emitted for every 4 ms E1B primary-code epoch:
|
||||
|
||||
| Field | Proposed representation | Meaning |
|
||||
| --- | --- | --- |
|
||||
| PRN/channel | unsigned integer | Logical satellite and component |
|
||||
| start/end timestamp | 64-bit sample counters | Continuous receiver time association |
|
||||
| Prompt I/Q | signed fixed-point accumulators | Unreduced coherent evidence |
|
||||
| carrier phase/frequency | NCO state/measurement words | Reprocessing and phase diagnostics |
|
||||
| code phase | unsigned fixed-point chips | Code-time association |
|
||||
| C/N0 | fixed-point dB-Hz or invalid | Monitoring only |
|
||||
| carrier/code lock | bits | Decoder validity gate |
|
||||
| cycle slip/discontinuity | bits | Immediate symbol/page synchronizer reset |
|
||||
| valid | bit | Transaction validity |
|
||||
|
||||
The interface should use an AXI-Stream-like `valid/ready` transaction. A FIFO
|
||||
must absorb software service latency; backpressure cannot be allowed to stop the
|
||||
sample-rate tracking datapath. At 250 records/s/channel, even 36 active E1B
|
||||
channels produce only 9000 records/s, so a memory-mapped DMA ring is sufficient.
|
||||
|
||||
## Software decoder
|
||||
|
||||
Software retains floating `numpy.float64` prompt/soft values in the reference
|
||||
model and performs:
|
||||
|
||||
```text
|
||||
prompt axis and symbol synchronization
|
||||
-> page synchronization and polarity resolution
|
||||
-> 30x8 deinterleaving
|
||||
-> soft Viterbi decode
|
||||
-> vertical-page assembly and CRC-24Q
|
||||
-> typed word parsing
|
||||
-> atomic IODnav ephemeris assembly
|
||||
-> GST/clock/health navigation database
|
||||
```
|
||||
|
||||
This split keeps policy-rich, low-rate state machines inspectable and updateable.
|
||||
The saved `prompt_epochs.npz` files are the exact boundary between future RTL
|
||||
tracking and the software decoder. HDL verification shall replay the same RF
|
||||
vector, compare each tracking epoch with the bit-true model, then feed the RTL
|
||||
prompt records into this decoder without SignalSim truth.
|
||||
|
||||
## Conditions that could justify later hardware offload
|
||||
|
||||
Only measured CPU load, power, or startup-latency failure should trigger an
|
||||
offload study. Plausible granular offloads are symbol accumulate-and-dump,
|
||||
deinterleaver address generation, or a shared Viterbi accelerator. CRC, word
|
||||
parsing, ephemeris consistency, time rollover handling, and the navigation store
|
||||
remain better software candidates because their throughput is negligible and
|
||||
their standards/policy behavior is state-rich.
|
||||
Reference in New Issue
Block a user