Add DD-domain pilot pattern design for OTFS integrated comm/nav (LEO …#2
Open
Hubeidiyishenqing wants to merge 21 commits intobb16177:masterfrom
Open
Add DD-domain pilot pattern design for OTFS integrated comm/nav (LEO …#2Hubeidiyishenqing wants to merge 21 commits intobb16177:masterfrom
Hubeidiyishenqing wants to merge 21 commits intobb16177:masterfrom
Conversation
…satellite) - pilotPatternDD.m: Impulse pilot + rectangular guard band placement on DD grid, with configurable Doppler/delay guard widths and pilot power boost - ddChannelEstimate.m: Channel estimation from pilot response in DD domain, extracts navigation info (path delays, Doppler shifts, gains) - otfsEqualiserDD.m: MMSE equalization via TF-domain with DD channel estimate - main.m: Added OTFS-Pilot simulation section comparing BER with pilot scheme - plotGraphs.m: Updated to display OTFS-Pilot BER curves alongside originals https://claude.ai/code/session_01Vnn71c3fAhWvb3LertJiCS
Author
|
update |
Convert delay/Doppler bin indices to physical quantities (ns, Hz, m, m/s) and compare estimated velocity with the true simulation velocity. Prints LoS path analysis and all detected paths with physical values. https://claude.ai/code/session_01Vnn71c3fAhWvb3LertJiCS
…mation With M=14, Doppler resolution was ~1001 Hz (85.77 m/s per bin), far too coarse to detect the true max Doppler shift of 389 Hz (120 km/h). The LoS path Doppler was quantized to 0 bins, giving 100% velocity estimation error. With M=40, Doppler resolution improves to ~350 Hz (~30 m/s per bin), which is fine enough to resolve the 389 Hz Doppler shift into at least 1 bin. https://claude.ai/code/session_01Vnn71c3fAhWvb3LertJiCS
The interpolation sample points (columns 1, 7, 14) were hardcoded for ofdmSym=14. With ofdmSym=40 this caused array size mismatch. Now uses dynamic midpoint and linspace for any ofdmSym value. https://claude.ai/code/session_01Vnn71c3fAhWvb3LertJiCS
Jake's model (Vi = fd*cos(...)) distributes Doppler symmetrically around 0, which is correct for terrestrial scattering but wrong for LEO satellites. In LEO, all paths share a bulk Doppler shift fd from satellite motion, with only small perturbations from multipath scattering. This caused the LoS path to have Doppler=0 and velocity estimate=0 (100% error). https://claude.ai/code/session_01Vnn71c3fAhWvb3LertJiCS
Jake's model (Vi = fd*cos(...)) distributes Doppler symmetrically around 0, which is correct for terrestrial scattering but wrong for LEO satellites. In LEO, all paths share a bulk Doppler shift fd from satellite motion, with only small perturbations from multipath scattering. This caused the LoS path to have Doppler=0 and velocity estimate=0 (100% error). https://claude.ai/code/session_01Vnn71c3fAhWvb3LertJiCS
The DD-pilot OTFS path was calling equaliser() before SFFT, which removed the channel (including Doppler shifts) before DD-domain estimation. This caused the LoS path to always show Doppler=0, making velocity estimation impossible (100% error). Fix: feed raw received signal directly to OFDM demod -> SFFT, so DD-domain pilot estimation sees the actual channel response. Also add parabolic interpolation for fractional Doppler/delay estimation to improve accuracy beyond integer-bin resolution. https://claude.ai/code/session_01Vnn71c3fAhWvb3LertJiCS
Three root causes of incorrect velocity estimation: 1. multipathChannel.m generated L≈77 paths with 2.3μs delay spread (~36 delay bins), but guard band was only lGuard=2 (5 bins). Data symbols leaked into the guard region, corrupting pilot estimation. 2. All path gains were random (-3 to -7 dB) with no dominant LoS. Unable to identify the line-of-sight path for velocity estimation. 3. Guard band sizing was hardcoded without matching channel parameters. Fixes: - multipathChannel.m: LEO Rician channel model - Cap delay spread at 500 ns (realistic LEO ground reflections) - Cap at 6 paths (LoS + 5 scattered) - Rician K-factor = 10 dB (dominant LoS component) - Exponentially decaying NLOS path gains - main.m: Dynamic guard band sizing - lGuard = ceil(maxDelaySpread / delayResolution) ≈ 8 bins - kGuard = ceil(fd / dopplerResolution) + 1 ≈ 3 bins - Matches channel parameters automatically https://claude.ai/code/session_01Vnn71c3fAhWvb3LertJiCS
…domain The channel H(n,m) was a TF-domain transfer function but was being multiplied element-wise with the time-domain signal after modOFDM. This domain mismatch caused Doppler information to be lost in the DD domain, resulting in 99.7% velocity estimation error. Fix: Apply channel in the TF domain (after ISFFT, before modOFDM) for all three simulation paths (OFDM, OTFS, OTFS-pilot). The multipathChannel function now returns a 2D TF matrix H(subcarrier, symbol) instead of a serialized time-domain vector. https://claude.ai/code/session_01Vnn71c3fAhWvb3LertJiCS
1. SFFT sign fix: MATLAB's IFFT maps positive physical Doppler to negative DD bins. Negate DD Doppler when converting to physical values: nu = -dopplerShift * delta_nu. 2. Replace parabolic interpolation with Quinn's estimator for fractional Doppler/delay. Quinn's method uses complex DFT values (not just magnitudes) and is optimal for single-tone frequency estimation, giving much better accuracy for OTFS sinc-shaped peaks than parabolic fitting. https://claude.ai/code/session_01Vnn71c3fAhWvb3LertJiCS
- scs: 15kHz -> 120kHz (NR-NTN standard) - Bw: 10MHz -> 100MHz - ofdmSym: 40 -> 128 (accommodate large Doppler guard band) - velocity: 120 -> 26000 km/h (LEO relative speed) - fc: 3.5GHz -> 2GHz S-band (reduce Doppler, match LEO) - Update fc in multipathChannel.m to match https://claude.ai/code/session_01Vnn71c3fAhWvb3LertJiCS
…GYqQ Adapt parameters for LEO satellite (26000 km/h)
The TF-domain element-wise channel model (channelTF .* signal) breaks down when fd/scs is large (0.40 at 26000 km/h). It ignores inter-carrier interference, causing the DD-domain pilot response to be completely wrong and velocity estimation error >105%. Fix: apply channel as 2D circular convolution in the DD domain, which is exact for any Doppler shift. Add noise directly in DD domain (equivalent to time-domain AWGN since SFFT/ISFFT are unitary transforms). - New applyChannelDD.m: DD-domain circular convolution channel model - multipathChannel.m: also return chInfo struct with physical parameters - main.m: OTFS-pilot path uses DD-domain channel instead of TF model Expected: Doppler bin ~55 (was 3), velocity error <1% (was 105%). https://claude.ai/code/session_01Vnn71c3fAhWvb3LertJiCS
…GYqQ Fix velocity estimation: DD-domain channel for high Doppler
With fd=48148 Hz and M=128 Doppler bins, the channel shift (55 bins) occupies 43% of the grid, causing data symbols to wrap into the guard region and corrupt pilot detection (3215 false paths detected). Fix: implement Doppler pre-compensation (standard in NR-NTN): - applyChannelDD.m: subtract bulk Doppler (from ephemeris) before computing bin indices, leaving only residual scatter (~3 bins) - main.m: reduce kGuard from 56 to ~8 (residual only), double lGuard for data protection, add back bulk Doppler in velocity estimation Expected: residual Doppler ~0 bins for LoS, velocity error <1%. https://claude.ai/code/session_01Vnn71c3fAhWvb3LertJiCS
Hubeidiyishenqing
force-pushed
the
claude/analyze-project-jGYqQ
branch
from
218904f to
1caa34a
Compare
…GYqQ Add Doppler pre-compensation for LEO-NTN velocity estimation
Root cause: guard region scanning detected 900+ false "paths" because: 1. Scanned symmetric delay range [-lGuard, +lGuard] but channel delays are non-negative — negative delay detections are pure data leakage 2. Threshold based on median of contaminated guard is useless 3. No physical bounds on scanning region Fix in ddChannelEstimate.m: - Restrict delay scan to [lp, lp + maxDelayBins] (non-negative only) - Restrict Doppler scan to [kp ± maxDopplerBins] (residual range) - Use pilot-relative threshold (-8 dB) instead of noise-relative - Add maxDelayBins/maxDopplerBins fields to pilotInfo for scan bounds Fix in main.m: - Pass physical channel bounds (maxDelayBins, maxDopplerBins) to estimator Expected: ~6 detected paths (matching actual channel) instead of 900+. https://claude.ai/code/session_01Vnn71c3fAhWvb3LertJiCS
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
…satellite)
https://claude.ai/code/session_01Vnn71c3fAhWvb3LertJiCS