★ FEATURED ARTICLE 每次拿到一台需要做外场验证的终端样机我第一件事不是看吞吐也不是看信令流程而是把物理层日志打开盯着小区搜索这一段看它从开机到驻留花了多久、中间有没有反复重搜。LTE小区搜索这个过程协议文本摊开来看并不算多——36.211管同步信号36.212和36.213管PBCH36.331管小区选择和驻留——但真落到代码里它是整个物理层最脏的一段。没有先验信息、没有信道估计、没有反馈你要在一堆噪声里把定时、频率、小区身份、系统带宽、天线端口数一个一个抠出来抠错一个后面全盘皆输。这篇文章我打算按工程实现的顺序把这条链路拆开讲PSS怎么在未知频偏下把5ms定时抓住SSS怎么把小区组、帧定时和CP类型一起解出来CRS和PBCH怎么把PCI变成能用的MIB最后怎么判断这个小区到底能不能驻留。刚接触物理层的新人可以把这当成一份实现路线图做了很久上层协议的同行也能从这里看清楚底下到底发生了什么。文中涉及的参数取值和门限都是我实际调过的不同芯片平台会有差异但思路是通的。1. 小区搜索到底在解决什么问题1.1 一台终端从两眼一抹黑到能解一个比特终端刚上电那一刻它对网络的认知基本是零不知道中心频点在哪、不知道子帧边界在哪、不知道自己的晶振偏了多少、不知道小区ID是几、不知道带宽是1.4MHz还是20MHz、不知道是TDD还是FDD、不知道基站几个天线端口。这些量全都得从空口那点广播信号里猜出来而且不能瞎猜得按协议规定好的层次一层一层剥。LTE设计者在这里做了一个很聪明的取舍PSS和SSS只占用中心62个子载波也就是大约1.08MHz。这个决定意味着无论系统带宽是6个RB还是100个RB同步信号永远落在频谱正中间终端可以用一个固定的低采样率去做搜索根本不需要先知道带宽。反过来想如果同步信号铺满整个带宽终端在不知道带宽的前提下就没法做相关整个流程会陷入死循环。同步信号还承担了另一个隐含任务给终端一个频率锚点。终端本振的初始偏差可能达到十几ppm在2GHz频段就是几十kHz而LTE子载波间隔只有15kHz频偏超过7.5kHz就会开始破坏子载波正交性。所以小区搜索的第一要务不是解出信息而是先把频率拉回到能解调的范围内然后再谈其他。1.2 四个阶段和各自的产出物把整条链路摊开小区搜索可以分成四级台阶每一级都建立在前一级的产出之上顺序不能乱。我把每一级的输入、输出和典型耗时整理成下面这张表方便对照自己的实现看卡在哪一步。阶段依赖信号解决的核心问题输出结果典型耗时量级第一级PSS5ms 半帧定时、频偏粗估3 个 N_ID_2 假设、时域峰位置几十毫秒第二级SSS10ms 帧定时、CP 类型、小区组PCI504 选 1、TDD/FDD 判定几十毫秒第三级CRS精定时、精频偏、RSRP时频偏修正量、信道估计十几毫秒第四级PBCH/MIB带宽、PHICH 配置、SFN 高位系统信息入口40ms 量级后续PDCCH/PDSCHSIB1 读取PLMN、TAC、接入控制参数80ms 量级为什么这个顺序不能调换因为SSS的检测需要知道PSS给出的5ms边界和N_ID_2PBCH的解调需要知道PCI才能生成解扰序列和CRS位置SIB1的调度又依赖MIB里的带宽和PHICH配置。每一级都在给下一级解锁一个未知量。我见过有团队为了省时间想跳过SSS直接从PSS硬解PBCH结果就是解扰序列错了CRC永远过不了。还有一个容易被忽略的点这四级台阶并不是严格串行的。实际实现里PSS检测通常会保留多个候选峰每个峰都往下走一遍SSS最后按PBCH的CRC通过率反选。这种多假设并行、末端校验的结构比一级一级往下传单一结果要稳得多尤其是在多径严重或者存在同频邻区干扰的场景下。2. PSS检测把5ms定时和N_ID_2先攥在手里2.1 ZC序列的三个根和它的好脾气PSS用的是频域Zadoff-Chu序列长度63实际映射62个点中间那个直流子载波空着不用。序列由根索引u决定LTE定义了三个根25、29、34分别对应N_ID_2等于0、1、2。这三个根不是随便挑的它们之间的互相关峰值明显低于自相关峰值终端做三路并行相关时不容易互相串扰。ZC序列有两个性质对同步特别友好。第一是恒幅频域上每个点的模都是1这意味着PSS在时域上的峰均比可控基站的功放压力小。第二是理想周期自相关序列和自己的循环移位正交除了零点之外相关值都是零。第二条直接决定了定时估计的精度——相关峰极窄多径环境下主峰和次峰能分得开。更关键的是ZC序列在存在频偏时相关峰不会立刻塌掉。频偏会造成峰值幅度的轻微下降和相位的匀速旋转但峰的位置基本不动。这就是为什么LTE敢让终端在频偏完全未知的情况下先做定时同步——先抓住时间再慢慢修频率两件事解耦了。三个根的具体生成方式我按协议写了一段生成代码实际工程里可以直接查表没必要每次现算import numpy as np def gen_pss_freq(u): 生成 62 点频域 PSS 序列u 取 25 / 29 / 34 d np.zeros(62, dtypecomplex) for n in range(31): d[n] np.exp(-1j * np.pi * u * n * (n 1) / 63) for n in range(31, 62): d[n] np.exp(-1j * np.pi * u * (n 1) * (n 2) / 63) return d def map_to_grid(d, n_fft128): 把 62 点映射到 128 点 IFFT 的中心跳过直流 grid np.zeros(n_fft, dtypecomplex) half len(d) // 2 # 31 grid[1:1 half] d[:half] # 正频率 grid[n_fft - half:] d[half:] # 负频率 return grid这段代码里有个细节值得说正负频率的映射顺序必须和协议一致否则生成出来的时域序列和基站侧对不上相关峰直接消失。我自己就被这个问题坑过一次排查了大半天才发现是频谱搬移的方向搞反了。2.2 时域滑动相关的采样率取舍PSS只占1.08MHz理论上用1.92MHz采样就够了对应128点FFT子载波间隔15kHz。实际产品里几乎都是这个配置先把宽带信号降采样到1.92MHz在这个低速率上做全窗口滑动相关找到候选位置之后再升采样做精处理。这么做的好处很直接。以20MHz带宽为例30.72MHz采样下5ms窗口有153600个点直接做时域相关运算量惊人降到1.92MHz之后只有9600个点运算量降了256倍而PSS的信息一点没丢。这是典型的用带宽换算力代价是对定时精度的分辨率下降到约0.52微秒不过这个损失在后面用CRS精同步能补回来。滑动相关的实现有两种常见写法。一种是直接时域卷积用三个本地PSS模板分别和接收数据做相关取模平方另一种是转到频域做乘法再IFFT。后者在长窗口下更快尤其是用FFT做分段重叠的时候。我一般倾向于频域实现代码更短而且天然支持批量处理多个候选频点。搜索窗的长度至少要覆盖一个PSS周期也就是5ms。但实际实现里通常取10ms原因是要覆盖完整的无线帧方便后续和SSS做联合判决。如果终端刚上电时频偏极大我甚至见过取20ms窗口做多次非相干累加的做法牺牲一点时延换检测概率。门限的设定是个经验活。教科书上写的是取相关峰最大值但实际信号里经常出现多个幅度接近的峰单纯取最大值很容易锁到邻区或者噪声上。我的做法是归一化把每个位置的峰值功率除以窗口内的平均功率得到一组比值然后取比值超过某个绝对门限的所有峰作为候选通常保留前4到8个。这个门限在不同场景要调——空旷外场可以设高一点室内或者强干扰环境要放低否则真实小区会被漏掉。提示多径环境下同一个PSS的相关峰会扩展成一簇主峰旁边跟着几个衰减的次峰间隔通常在一个CP长度以内。做候选选取时必须先做峰合并把CP窗内的所有峰归并成一个否则后面的SSS检测会重复处理同一小区白白浪费算力。2.3 频偏粗估相关峰的相位怎么用定时抓到了接下来要解决频率。频偏粗估有几种常用手段各有各的适用区间。第一种是利用PSS在时域上的重复性。PSS每5ms出现一次两次之间隔了5毫秒用相邻两个PSS相关峰的相位差可以估频偏公式是Δf Δφ / (2π·T)T等于5ms。这个方法的精度很高理论上能做到几十Hz但测量范围被相位卷绕限制住了——相位差超过π就分不清是正偏还是负偏对应最大可测频偏只有100Hz。它适合在已经粗同步之后做微调不适合初始捕获。第二种是利用PSS序列自身的结构。时域PSS具有一定程度的对称性把接收到的PSS分成前后两半做相关相位差能反映频偏可测范围扩大到±7.5kHz左右正好覆盖一个子载波间隔的一半。这是初始搜索阶段最常用的做法。第三种是频域移位搜索。检测到PSS位置后对那一段做FFT观察62个非零子载波的频谱是否整体偏移偏移量就是频偏的估计。这个方法的范围可以做到±15kHz以上代价是要多做几次FFT复杂度高一些。实际工程里通常是组合使用先用频域移位或者半段相关做粗估把频偏压到±2kHz以内再用CRS做精估。我调过的平台大多在粗估阶段就能把残余频偏控制在1kHz以下后面CRS精估只是锦上添花。这里有一个必须注意的边界条件当真实频偏接近或超过7.5kHz时PSS相关峰会明显降低超过15kHz时可能完全检测不到。所以初始搜索必须假设一个较大的频偏范围不能想当然认为晶振是准的。我遇到过一批样机晶振批次一致性差常温下就偏了12kHz用标准流程死活搜不到小区最后是把粗估范围放大到±20kHz才解决。3. SSS检测10ms帧定时、CP类型和小区组3.1 交织的m序列结构和168个假设PSS只告诉了终端每5ms有个边界和小区ID模3的余数剩下的小区组信息、10ms帧边界、CP类型全在SSS里。SSS和PSS占同样的频域位置——中心62个子载波——但它是频域交织结构偶数子载波上放一个长度31的m序列奇数子载波上放另一个两个序列各自做循环移位移位量由小区组编号N_ID_1决定。N_ID_1的取值范围是0到167一共168个小区组乘以PSS给出的3个N_ID_2正好凑成504个物理小区ID。这个数字不是随便定的——504在保证相邻小区PCI不同的前提下还能让终端做相关时的复杂度可控。SSS在时域上的位置是子帧0和子帧5的倒数第二个OFDM符号常规CP下也就是每个无线帧出现两次。但这两次的序列并不相同子帧0和子帧5的SSS在第二个m序列上做了不同的加扰这个差异正是终端区分半帧、进而确定10ms帧边界的依据。我见过不少人第一次看这段协议会绕进去觉得既然PSS已经给了5ms为什么还要SSS来定10ms。原因是PSS每5ms重复一次从PSS本身根本分不出这是帧头还是帧中。SSS的两次不同版本才提供了这个区分度。这也是为什么小区搜索必须PSS和SSS配合缺一不可。3.2 相干还是非相干先活下来再谈性能SSS的检测算法分两派非相干和相干。非相干检测的做法是分别对偶数子载波和奇数子载波上的序列做相关两路结果取模平方再相加。它不需要任何信道相位信息所以对残余频偏和定时误差都不敏感鲁棒性极好。代价是损失了约2到3dB的检测性能因为两路信号的能量没有做相干合并。相干检测则先用PSS或者CRS做信道估计把接收信号的信道相位补偿掉再做相关。性能能提升几个dB但对定时精度和频偏残余非常敏感——如果精同步没做好相干合并反而会互相抵消效果比非相干还差。初始小区搜索阶段的现实是此时还没有CRS可用因为PCI还没定PSS给出的相位参考又受频偏影响所以绝大多数实现都选非相干。等到PCI解出来、CRS能生成了后面做邻区测量或者重选时可以切到相干检测提升灵敏度。我的建议是不要在初始搜索阶段追求那2dB。真正决定成败的是能不能在弱信号下把小区搜出来而不是搜出来之后解得多干净。与其在算法上抠相干合并不如把非相干的相关窗口做长一点、做几次跨帧累加收益更明显。3.3 半帧判决与CP类型盲检的联合处理SSS检测要处理的假设空间比PSS大得多168个小区组、2个半帧位置、2种CP类型理论上672种组合。如果再加上TDD和FDD的盲检假设数还要翻倍。但实际实现不会真的穷举。PSS已经给出了N_ID_2SSS的相关只需要在168个N_ID_1上做半帧位置只有两种可以用一次相关同时得到两个位置的度量。CP类型的处理稍微麻烦一点因为常规CP和扩展CP下SSS与PSS的相对符号间隔不同常规CP下SSS在PSS前一个符号扩展CP下间隔也不一样。一个实用的简化是先按常规CP做检测因为现网绝大多数宏站和小站都用常规CP扩展CP主要出现在特定场景比如多径时延特别大的覆盖场景。只有常规CP下所有假设都失败才去试扩展CP。这样能把平均搜索时间压下来。TDD和FDD的盲检也类似。FDD下PSS在子帧0和5的最后一个符号TDD下PSS在子帧1和6的特殊时隙里两者在帧内的绝对位置不同。终端在初始搜索时确实不知道网络制式必须两种都试。好在两种制式下PSS的序列完全一样区别只在相对位置所以可以在PSS检测阶段就让每个候选峰同时保留FDD和TDD两种解释交给SSS去甄别。注意CP类型判错的后果很隐蔽。你会看到PSS和SSS都能解出来PCI也是对的但后面解PBCH时CRC一直不过因为OFDM符号的边界整体偏了。排查时不要只盯着PBCH的编码链路先把CP类型打出来确认一下。4. CRS与PBCH把PCI变成可用的系统信息4.1 CRS精同步与频偏精估到这一步终端手里已经有了PCI和10ms帧定时接下来可以用小区专用参考信号做精细化处理。CRS的序列由PCI和时隙号共同决定在频域上是伪随机的QPSK符号终端本地可以完全复现。用本地CRS和接收信号做最小二乘信道估计能得到几样东西。第一是精定时把频域信道估计变换到时域冲激响应的第一个有效抽头位置就是精确的符号边界精度可以做到采样点级别。第二是精频偏同一时隙内不同CRS符号之间的相位差反映了频率偏差公式还是Δf Δφ/(2π·Δt)只不过这里的Δt是两个CRS符号的间隔大约是0.286毫秒对应的可测范围约±1.75kHz精度能到几十Hz。第三是RSRP用CRS上的接收功率做线性平均这就是终端上报的参考信号接收功率。这套流程里有个容易踩的坑定时精度的基准。PSS相关给出的定时精度受采样率限制在1.92MHz下是半个采样点量级换算成时间大概0.26微秒对应距离约78米。这个误差在普通场景下无所谓但在多小区交界处会影响后续的测量上报。所以精同步这一步不能省尤其是要做邻区测量和切换的场景。另外一个细节是多普勒。高速移动下CRS的相位在每个符号之间都在旋转简单的相邻符号相位差会低估频偏因为相位卷绕了。这时候要用多个符号做联合估计或者用PSS的5ms间隔做粗估、CRS做细调的级联结构。我处理过高铁场景的数据时速300公里下多普勒频移能到2kHz以上单靠CRS的短间隔估计会误判方向。4.2 PBCH盲检天线端口、SFN和带宽PBCH是小区搜索里最后一个硬骨头。它承载MIB位置固定在子帧0的第二个时隙占用中心6个RB的前4个OFDM符号扣除CRS占用的资源后剩下240个资源粒子QPSK调制后每帧480比特四个无线帧凑成1920比特做一次完整的速率匹配。终端要解PBCH必须同时猜对三件事天线端口数、加扰序列版本、以及部分编码参数。天线端口数的盲检靠CRC掩码实现。协议规定用不同的掩码对PBCH的CRC做异或1端口、2端口、4端口各对应一种掩码组合。终端把这三种实际上是四种还有一种保留假设都试一遍哪个CRC能过就是哪个。这个设计很巧妙用一次CRC校验同时完成了信道解码和数据校验。加扰序列版本对应的是SFN的低2位。PBCH的加扰序列由PCI和SFN模4的结果共同决定所以40ms周期内的四个帧虽然承载相同的MIB内容但加扰不同。终端通过尝试不同的解扰序列可以反推出当前帧在40ms周期里的位置从而补齐SFN的低位。带宽信息则直接编码在MIB的前3个比特里编码规则是固定的六档6个RB、15个RB、25个RB、50个RB、75个RB、100个RB对应000到101。终端解出这3个比特立刻就知道后面PDCCH该按多大的带宽去盲检。实测下来PBCH的盲检是整条链路里最耗时的一步。40ms的周期意味着终端最坏要等四个帧才能凑齐一次完整解码加上前面的同步和SSS从开机到拿到MIB快的话一百多毫秒慢的话能到五六百毫秒。优化手段主要是复用已解码的软比特做增量合并而不是每个40ms都从头解。4.3 从MIB到SIB1驻留判决的最后一公里MIB只是入场券真正决定能不能驻留的是SIB1。SIB1的调度信息隐含在MIB的PHICH配置里终端按固定规则算出SI-RNTI加扰的PDCCH搜索空间在子帧5上盲检解出PDSCH才能拿到PLMN列表、跟踪区码、小区禁止标志、接入等级禁止列表这些关键参数。拿到这些之后驻留判决按S准则做Srxlev Qrxlevmeas - (Qrxlevmin Qrxlevminoffset) - Pcompensation Squal Qqualmeas - (Qqualmin Qqualminoffset) Pcompensation max(PEMAX - PPowerClass, 0)举个实际算例。假设测得的RSRP是-85 dBmSIB1里广播的Qrxlevmin是-60信令单位是2dBm实际是-120 dBmQrxlevminoffset为0PEMAX和终端功率等级都是23dBm那么Pcompensation等于0Srxlev -85 - (-120) - 0 35 dB大于0判决通过。这套公式看起来简单实际配置里有不少门道。比如Qrxlevminoffset只在周期性搜索高优先级PLMN时才用平时是0Pcompensation在终端功率等级低于基站允许的最大发射功率时才非零这时候弱覆盖边缘的终端会更难驻留这是设计意图——避免上行受限的终端死抱着一个小区不放。还有一类情况容易被忽略小区禁止和PLMN选择是两回事。S准则通过只代表射频条件够如果这个小区的PLMN不在终端的等效PLMN列表里或者cellBarred标志置位照样不能驻留。我在外场调过一台样机死活驻不上某个小区查了半天射频指标都正常最后发现是这个小区广播了cellBarred属于规划内的禁止接入跟终端没关系。5. 常见问题速查与实测避坑5.1 一张表对完大部分现场问题小区搜索的问题表现得很集体要么啥也搜不到要么搜到了但后面解不开。我把这些年遇到过的高频问题整理成下表按现象倒查原因能省不少时间。现象高概率原因排查手段完全搜不到 PSS频偏超出粗估范围、增益设置不当、采样时钟配置错误打印相关峰最大值与平均功率比手动扫频偏PSS 有峰但 SSS 全失败CP 类型判错、半帧假设错、定时偏差超过 CP强制指定 CP 类型重跑检查符号边界PCI 正确但 PBCH CRC 全错天线端口数盲检范围不足、CRS 位置算错把四种 CRC 掩码的软比特都打出来对比MIB 偶尔能解但误码率高频偏残余过大、信道估计没做时域滤波看频偏估计的收敛曲线加长 CRS 平滑窗驻留失败但信号很好小区禁止、PLMN 不匹配、接入等级限制解 SIB1 打印 cellBarred 和 PLMN 列表小区搜到后频繁重搜测量门限配置不合理、Srxlev 抖动看 RSRP 的方差检查迟滞和偏置参数这张表里最值得展开的是第二行。PSS有峰而SSS全失败十有八九是CP类型的问题。因为PSS的检测本身对CP不敏感它只关心序列相关但SSS的位置依赖CP类型一旦判错采集窗口就整体偏了相关值自然上不去。我的经验是只要SSS全军覆没第一件事就是把CP类型强制成另一种再跑一遍五分钟能定位的问题不要花五小时。第四行也常见。频偏残余会让PBCH的星座点缓慢旋转短时间内CRC可能还能过但误码率会明显偏高。这种情况下不要怀疑编码链路先去看频偏估计是不是收敛了。我一般会在日志里同时打印粗估和精估的结果两者的差值如果超过500Hz基本可以确定是估计环节出了问题。5.2 几个只有踩过才知道的细节第一个细节是关于相关峰的门限归一化。很多人用绝对功率做门限结果换一个增益档位就要重新调参。正确做法是用窗口内的平均功率做归一化得到一个无量纲的比值这样增益变化不会影响判决。但归一化的分母也有讲究如果用整个窗口的平均功率强干扰环境下门限会被抬高弱小区漏检我的做法是用中值滤波后的噪声底估计做分母抗突发干扰能力强一些。第二个细节是采样时钟偏差。终端晶振和基站晶振的频率不可能完全一致采样时钟的偏差会在长时间接收中累积成定时漂移。小区搜索阶段通常只有几百毫秒影响不明显但如果要做长时间的测量或者多小区联合处理就必须做采样时钟跟踪。我见过一个案例终端在弱信号下反复重搜最后定位到是采样时钟偏差导致定时逐渐滑出CP窗口加了一个简单的定时跟踪环就解决了。第三个细节是关于多假设的排序。假设空间大的时候先试哪个后试哪个直接影响平均搜索时间。合理的顺序是先试概率最高的组合常规CP、FDD、半帧0再逐步扩展到低概率组合。现网里TDD和扩展CP的占比都不高把它们排在后面能显著降低平均时延。当然这个顺序要根据目标网络的实际情况调整不能照搬。第四个细节是RSRP的测量带宽。协议允许在多个带宽上做RSRP测量窄带测量的结果和宽带测量可能差好几个dB。做驻留判决时要用和SIB1里配置一致的测量带宽否则会出现测量值够但驻不上的诡异现象。这个问题在异构网络里特别容易碰到因为宏站和小站的发射功率、带宽配置都不一样。6. 一套可复现的验证方案6.1 采样率、搜索窗与门限的工程取值如果要在自己的平台上复现这套流程下面这组参数可以直接拿来当起点我调过的几个平台基本都是在这个附近微调。参数推荐取值说明初始采样率1.92 MHz对应 128 点 FFT覆盖中心 1.08 MHzPSS 搜索窗10 ms覆盖完整无线帧便于和 SSS 联合PSS 候选数4 到 8 个按归一化峰值排序保留峰合并窗1 个 CP 长度常规 CP 约 4.7 微秒粗频偏范围±20 kHz覆盖晶振偏差和多普勒精频偏范围±2 kHzCRS 相邻符号相位差SSS 假设数168 × 2 半帧按 CP 类型分两轮PBCH 盲检维度4 种 CRC 掩码 × 4 种加扰合计 16 种组合采样率的选择有一个权衡1.92MHz足够覆盖PSS和SSS但做不了全带宽的RSRP测量。实际实现通常是双速率结构——低速率做同步搜索同步完成后切到高速率做PBCH解调和测量。切换的时机要选在SSS解出PCI之后因为PBCH的解调需要PCI来生成解扰序列。门限的设定没有普适值必须结合自己平台的噪声系数和AGC策略来调。一个比较稳妥的办法是先在实验室用信号源做灵敏度扫描把不同SNR下的相关峰比值统计出来画一条ROC曲线然后按目标检测概率反推门限。这个过程看起来繁琐但一次做完能管很久。6.2 用软件无线电搭一个最小闭环想真正搞明白这套流程光看协议不够得自己跑一遍。用一块通用的软件无线电板卡加一台信号源就能搭出最小验证环境。第一步是产生基带信号。可以自己按协议生成PSS、SSS、CRS和PBCH也可以抓一段现网的空口数据回放。自己生成的好处是所有参数都可控能很方便地构造极端场景比如人为加大频偏、改CP类型、换天线端口数。第二步是接收和解调。把板卡采到的数据降采样到1.92MHz按前面说的顺序做PSS相关、SSS相关、CRS信道估计、PBCH盲检。建议把每一步的中间结果都存下来包括相关峰的位置和幅度、SSS的度量值、PBCH各假设的CRC结果。这些数据在排查问题时比最终结果有用得多。第三步是做参数扫描。把频偏从-20kHz扫到20kHz步进500Hz记录每个点的PSS检测概率把SNR从-10dB扫到10dB记录PCI正确率和MIB正确率。这两条曲线做出来你对这套流程的理解会比读十遍协议都深。我自己做这套验证的时候最大的收获不是算法本身而是发现了几个协议里没写、但实际实现必须处理的边界情况。比如当两个候选PSS峰的间隔恰好等于CP长度时峰合并的逻辑会失效导致同一个小区被当成两个又比如当频偏接近子载波间隔的一半时SSS的非相干检测会出现系统性的偏差需要用频偏补偿后的数据重做一遍。这些问题在仿真里很难复现只有在真实信号上跑才会暴露。如果手上没有硬件退一步用开源的空口数据集做离线分析也行虽然少了射频链路的影响但同步和盲检的逻辑是一样的。关键是不要只看最终结果要把中间量都打出来搞清楚每一步的判决是怎么来的。小区搜索这段代码写出来容易调稳定难绝大部分功夫都花在那些看起来应该没问题的地方。
阅读完成 · 觉得有帮助？
