NR/5G - 工具Bug修复2

今天继续使用DCI format 0-0的工具解析，Bug好几个，下面一一解决。

​

首先，DCI format 0-0中的固定比特数应该为20比特。

HARQ process number大意，被写成了5比特，实际为4比特，导致多了1比特。

其次，还是应该使用高位对齐的方式，而不是使用低位对齐的方式

因为代码中使用的是在高位填‘0’

填‘0’的方式当前的设计是计算出DCI format 0-0的Payload Size大小，然后将输入转换为二进制字符串的时候，Payload Size减去字符串的长度即为需要高位补0的个数。

但是这样设计是存在问题的，需要在输入变量的时候在高位手动输入十六进制0才可以。通常在实际实现的时候，多数使用的是32位的数组保存DCI的Payload。例如在某种配置下DCI format 0-0的Payload Size是37比特，使用2个Uint32数据结构进行保存，uint32[0] = 0x6402103, uint32[1] = 0x80000000, 那么则需要输入框中输入0x0640210380，工具解析是从其中的高位0开始解析的。而如果输入0x640210380，高位补0的方式会出现错误。

上述要求输入之后，设计将其转换为二进制字符串流再逐一按照Field进行读取，但是使用的javascript函数会将高位的0进行丢弃。例如输入0x0A，那么得到的二进制字符串实际为’1010‘，其中高位的‘0000’被丢弃了，也导致解析错误。

现在的关键要解决的问题就是按照DCI的Payload size，将输入的十六进制正确的转换为对应二进制的字符串了。修改方法是直接读取十六进制的字符串，获取字符串的长度，字符串的长度乘以4减去二进制字符串的长度即为后面高位需要补0的个数。

修改函数，输入十六进制高位为0进行验证。

修改整理如下，使用文本编辑器打开“”

1. “低位对齐”修改为“高位对齐”

2. 将红色框中的‘21’修改为‘20’

3. 将红色框中的‘5’修改为‘4’

4. 定义变量“inputHexString”，修改PaddingZeroNum的获得方式

修改后的函数nr_parse_dci_format_0_0共享在链接，打开后替换该函数即可。

https://share.weiyun.com/eorBogAl