雪峰 赖
- 注册于: 2024-09-19
- 最后登录: 2026-07-31
问题
项目
- 解决方案集成测试 (开发人员, 2024-09-19)
- eMBB2.0 BBIT (开发人员, 2024-09-19)
- STE (开发人员, 2024-09-19)
- 研发产品测试 (开发人员, 2024-09-19)
- 2.0基站产品化测试 (开发人员, 2024-09-19)
- STUE(国产化平台) (开发人员, 2024-09-19)
- 3.0基站产品测试 (开发人员, 2024-09-19)
- B5G_UE (开发人员, 报告人员, 2025-01-06)
- FirstCall (开发人员, 报告人员, 2024-11-28)
- 基站横联 (开发人员, 报告人员, 2025-04-17)
活动
2026-07-31
- 15:58 B5G_UE 错误 #5599 (转测试): 自同步测试过程中, MSG3 无法发出
- 原来测试协议栈Ul_Tb_req下发的时机是在ul_grant_ind的下一个Slot，代码设计也是按照这个来的，现在测试发现是在同一个Slot下发的，修改代码后，问题消失
2026-07-15
- 09:21 FirstCall 错误 #2868 (转测试): EVMT基站自研板与终端自研板发送PRACH现象不一致
- 09:20 FirstCall 错误 #2868: EVMT基站自研板与终端自研板发送PRACH现象不一致
- 正确设置uldelay 1400 以下。如果出现发送preamble 0, 接收到Preamble 1, 往小调整uldelay
2026-06-03
- 11:41 B5G_UE 错误 #5358: 当前上行PUS DMRS port配置打桩写死，而不是从调度信息中获取并配置
- 这块原来STE没有实现，需要根据协议38.212，7.3.1.1.2 根据协议栈下发的Bit长度，进行开发
2026-05-30
- 15:19 B5G_UE 错误 #5344: 【B5g_ue】V0.0.1_T07__Alpha25,链式拓扑与三角拓扑转换过程，增加98侧衰减，未进入OC-UE，概率性发生
- 这是因为PUSCH 处理超时，没来得及释放DM3空间，时间到点被优先级更高的L1C打断
2026-05-09
- 10:41 B5G_UE 错误 #5217 (审视): UE反复接入释放几次后gNB无法接收UE发出的preamble，PRACH 任务调度不起来
- 这是个概率现象,概率为2%。30%失败的原因是PUSCH 和 PUCCH的DM空间分配失败直接导致Core4挂死，50%的概率是能够正常Prach接入，20%会由于板子挂死，Msg3接收不到跑不下去。 由于PUSCH和PUCCH的任务...
2026-05-06
- 16:21 B5G_UE 错误 #5217: UE反复接入释放几次后gNB无法接收UE发出的preamble，PRACH 任务调度不起来
- 任务的Stack地址被改写为0x9d006094, 这个是DDR地址
2026-04-28
- 15:01 B5G_UE 错误 #5217: UE反复接入释放几次后gNB无法接收UE发出的preamble，PRACH 任务调度不起来
- 这个现象和当年无法Trigger PUSCH的现象一样， 任务已经注册，第一次能够Trigger， 后面Trigger后PRACH无法启动，怀疑PRACHIM空间被改写，建议平台先看看
2026-04-27
- 09:51 B5G_UE 错误 #5132 (转测试): 整机测试，基于t07_alpha19版本，AMC打开，mcs max=9，做下行灌包业务但mcs很快降为0【S slot不能调度PDS，特殊时隙需配置3:9:2】
- 采用规避方法，进行测试
2026-04-24
- 15:08 B5G_UE 错误 #5132 (审视): 整机测试，基于t07_alpha19版本，AMC打开，mcs max=9，做下行灌包业务但mcs很快降为0【S slot不能调度PDS，特殊时隙需配置3:9:2】
- 这个问题需要PDSCH的负责人来解决，特殊时隙挂死问题，现在采用规避
导出 Atom