学习相关算法.pdfVIP

写个故事捧场。上世纪 90 年代， BP 机还很流行，电信是绝对领导地位，用户很多，同频点 发射机也很多。当时有个问题，同一频点的 CALL 台发射机多了以后，由于每个发射机到 交换机的传输延迟不一样，导致覆盖重叠区域，到达用户 BP 机的信号相位差过大，误码很 高。 如果是放在现在，或者当时的欧美（摩托的工程师如是说） ，这个问题解决得很简单也很完 美，就是每个发射机那放个 GPS 时钟，估测个最长延迟，每个发射机加个缓存，全部在同 一时刻发同一条寻呼信息就结了。 可那个年代可还是第一次海湾战争结束不久的年代， GPS 是跟战斧联系在一起的， 是太贵还是怎么， 具体细节不记得了， 总之，这个方案当时不现实。 再强调一次，年代久远，不是直接负责人，细节真不记得了，经不起推敲的不要质疑。但原 则上肯定是没错的，这个项目给我印象太深了。 这个问题讨论后方案的核心就落在如何测量每个发射机链路的延迟上， 这个延迟要测得比较 准，大概是不大于寻呼数据帧每一位的 1/4 位宽，也就是为了保证相位差了。 具体怎么测呢？ 大概就是夜深人静之际， 关掉所有寻呼发射机， 然后逐台发一特殊数据帧， 该帧从传呼中心 交换机 -有线传输链路 -发射机 -空中 -接收机 - 鉴别电路，算出收发时间差。 电信很配合， 与电信相关的几个传输环节的细节都搞得很清楚了， 不会有问题； 空中这一块 直观上， BP 都可以收到，只是重叠区域有误码，那只开一台发射机接收肯定是没问题了。 于是第一方案看上去很朴素， 做一个特定码流发出去， 最后无线解码出来， 允许有一部分被 干扰， 总有没被干扰的。 事实上一个帧重复发几次就行了，是的， 默认的前提就是不能全部 被干扰。找到后测脉冲个数，周期， 与自己发出去的相同则认为真正找到， 自然可测出整个 回路的传输延迟。第一方案看上去也没有什么大问题。 方案定了， 这个东西做起来相对简单，就生成测试码流， 接到传呼中心发出去，无线接收机 是现成的， 然后解码出来的测试码流识别电路搭下。 当然还有花里胡哨的上位机， 测好所有 延迟后在传呼中心建的同步缓冲器。 这个项目做容易，现场测试是个麻烦事。 第一，只能后半夜， 当然电信几乎所有的割接都是 后半夜。第二要关几十台发射机 （真有这么多，我也不知道为什么，印象里好多覆盖全城的 小寻呼台就 1，2 台发射机），动静很大（细节没问） ，每次去都是 10 几个人。第三，每晚只 能中断正常业务 5~10 分钟。总之，边测边调是不现实的。 第一次出师不利，这符合大家的心理预期。有点不妙的是测试数据，跟预期的差得比较大。 由于是第一次测，局方很重视， 给的时间比较多， 那天晚上前后测了半个小时，结果发现几 百次测试数据，只有几次能找到发出的信号，其他要不变形严重，要不干脆就淹没不见了。 恩，看来开始还是太乐观，是按 BP 机都可以正确解码考虑的。我们用的是专用的寻呼检测 接收机，设备应该不是问题，先想到的是改进原来的电路，但方向还是提高信噪比。再试， 检出率高了，但误检率也高了，同个发射机上 10 次检出数据中居然都没有一致的多数。回 来改，再去试，反复多次后，人家脸色都不好看了，这才觉得可能此路不通了。期间请大学 教授，相关厂家，都没有好的解决办法。 写到这里，我觉得这确实是个问题，平时 BP 机都可以正常工作的，怎么专用测试接收机反