返回信息流对于一个线性分组码，接收端采用软判决译码，如何知道译码是否成功或失败？
一般的线性分组码的软判决译码算法，都是从候选码字中选择相关性最强的码字输出，不论对错都是一个码字，接收端如何知道这个译码结果是正确的还是错误的？
之所以问这样的问题，是因为在某个协议中规定需要根据译码是否成功来给某个变量赋不同的值，目前无头绪，看看byr有无大神？
这是一条镜像帖。来源：北邮人论坛 / communications / #23087同步于 2013/9/17
该镜像源已超过 30 天没有更新，可能在源站已被删除。
Communications机器人发帖
接收端信道译码后如何知道译码结果的正确性？
daydayup4u
2013/9/17镜像同步9 回复
订阅后，新回复会通过你的通知中心匿名送达。
9 条回复
线性分组码不是有一定的检错纠错功能么~~~
【 在 daydayup4u (我在南方洗冷水澡) 的大作中提到: 】
: 对于一个线性分组码，接收端采用软判决译码，如何知道译码是否成功或失败？
: 一般的线性分组码的软判决译码算法，都是从候选码字中选择相关性最强的码字输出，不论对错都是一个码字，接收端如何知道这个译码结果是正确的还是错误的？
: 之所以问这样的问题，是因为在某个协议中规定需要根据译码是否成功来给某个变量赋不同的值，目前无头绪，看看byr有无大神？
: ...................
理论上来说在有差错的信道上是不可能100%的纠错甚至是检查错误的。
【 在 daydayup4u 的大作中提到: 】
: 对于一个线性分组码，接收端采用软判决译码，如何知道译码是否成功或失败？
: 一般的线性分组码的软判决译码算法，都是从候选码字中选择相关性最强的码字输出，不论对错都是一个码字，接收端如何知道这个译码结果是正确的还是错误的？
: 之所以问这样的问题，是因为在某个协议中规定需要根据译码是否成功来给某个变量赋不同的值，目前无头绪，看看byr有无大神？
: ...................
理论上讲一个线性分组码可以既纠错又检错。但实际上很多标准里都用是先加上CRC，然后再进行信道编码，所以译码以后正确与否解CRC就可以知道了。而且通常情况下CRC还配合重传机制，在物理层和MAC层都会有独自的CRC和重传机制。还有就是不同的业务对错误率的容忍度也不一样，类似语音的业务就没必要一定传对，只要BER低于一定概率就可以了，反而不能因为重传而增加延时。数据业务就一个bit也不能错，但是延时可以稍微大一些，所以可以多次重传。
是的，当发送码字错成了另外一个码字的时候，接收端就会译成另外一个码字，打死也发现不了也纠不过来
【 在 grapland 的大作中提到: 】
: 理论上来说在有差错的信道上是不可能100%的纠错甚至是检查错误的。
:
没有CRC，就是原始消息bit经过Golay编码后，再交织和扰码，然后发送出去，协议中却说如果成功译码就怎样，如果不能成功译码就怎样。鬼知道译码是不是成功的啊？
【 在 Jaguar 的大作中提到: 】
: 理论上讲一个线性分组码可以既纠错又检错。但实际上很多标准里都用是先加上CRC，然后再进行信道编码，所以译码以后正确与否解CRC就可以知道了。而且通常情况下CRC还配合重传机制，在物理层和MAC层都会有独自的CRC和重传机制。还有就是不同的业务对错误率的容忍度也不一样，类似语音的业务就没必要一定传对，只要BER低于一定概率就可以了，反而不能因为重传而增加延时。数据业务就一个bit也不能错，但是延时可以稍微大一些，所以可以多次重传。
这个应该是指成功解调译码出来。译码成功，且错译成另外一个码的概率应该是很低的。
【 在 daydayup4u 的大作中提到: 】
: 没有CRC，就是原始消息bit经过Golay编码后，再交织和扰码，然后发送出去，协议中却说如果成功译码就怎样，如果不能成功译码就怎样。鬼知道译码是不是成功的啊？
:
这不是技术问题，是对标准的理解问题，你还不如直接问个针对某某标准的问题呢～
【 在 daydayup4u 的大作中提到: 】
: 没有CRC，就是原始消息bit经过Golay编码后，再交织和扰码，然后发送出去，协议中却说如果成功译码就怎样，如果不能成功译码就怎样。鬼知道译码是不是成功的啊？
: