你好，
我们正在使用 u-blox M2-JODY-W377 中的 88W9098，通过 SDIO 以 SDR50 运行。我们有来自 GitHub 的驱动程序/固件版本 lf-6.18.20_2.0.0。我们将其用作 2.4GHz 信道 6 的接入点。
我们遇到一个问题，启用 ed_mac（在 wifi_mod_para.conf 中使用“init_hostcmd_cfg=nxp/ed_mac.bin”，或使用 mlanutl 和 ed_mac_ctrl_V3_909x.conf）会导致我们内部应用程序测试的稳定性/延迟大幅下降：
我无法在这里详细介绍测试内容，但它是对特定内部步骤进行端到端延迟测量，使用了多台机器，中间连接了一个 88W9098 接入点。使用 ed_mac 后，某些曲线的平均延迟不仅比不使用时高出 200-250 毫秒，而且总体而言，它们的延迟波动也更大，并且往往会出现随机的“突发性”延迟增加。
我们尝试调整偏移量“ed_ctrl_2g.offset”并将“ed_ctrl_5g.offset”设置为与默认值 0x8 不同的值，但我们尝试的任何值对测试都没有影响。唯一能产生影响的方法是将 enable (2g/5g) 都设置为 0，或者在启动时不加载该文件。
还有其他方法可以尝试吗？
亲爱的@mjourdan ，
感谢您提供的详细描述和测试数据。鉴于 ed_mac（能量检测 MAC）功能的设计方式，您看到的这种行为实际上是预期的，但有几件事值得检查和澄清。
为什么 ed_mac 会导致 AP 模式下延迟更高
ed_mac 功能是专门为欧盟 ETSI EN 300 328 适应性合规性测试而设计的。其核心机制是当固件检测到信道上的能量超过阈值时，主动抑制传输。在接入点场景中，每当无线电检测到环境能量时，这都会直接延迟缓冲的下行链路数据包，从而导致您正在测量的延迟尖峰和“突发”。调整偏移参数会改变阈值灵敏度（无线电触发的难易程度），但不会消除抑制行为本身——这就是为什么任何偏移值对端到端延迟测试都没有可测量的影响。
配置文件不匹配
我注意到您正在使用 ed_mac_ctrl_V3_909x.conf。根据我们的应用笔记 AN13756，88W9098 的正确配置文件是ed_mac_ctrl_V2_909x.conf （默认值为 ed_ctrl_2g.offset = 0x08 和 ed_ctrl_5g.offset = 0x08）。V3 版本使用了不同的 ed_ctrl_txq_lock 字段值，并且不是此设备的验证配置。请尝试使用 ed_mac_ctrl_V2_909x.conf 并测试延迟影响是否有所改善。
关键问题：您的部署是否需要符合欧盟适应性要求？
ETSI EN 300 328 自适应要求仅适用于在欧盟/欧洲经济区市场运营且声明的最大射频输出功率为 10 dBm EIRP 或以上的设备。请您确认：
- 该设备是否已在欧盟部署并获得 ETSI EN 300 328 认证？
- 您的模块（u-blox M2-JODY-W377）的标称射频输出功率是多少？
如果您的使用场景不需要符合欧盟标准，那么正确的解决方案就是不加载 ed_mac 配置——您已经确认这样做可以完全解决延迟问题。
如果需要合规性，我们建议首先切换到 ed_mac_ctrl_V2_909x.conf，如果延迟问题仍然存在，我们可以探讨是否有更新的固件版本可以改善 AP 模式的行为。
请与我们联系以上问题的答案，我们将据此进行后续跟进。
顺祝商祺！
卫东
谢谢卫东。是的，该产品的输出功率绝对超过 10dBm EIRP，需要符合 EN 300 328 标准。
我尝试过使用 ed_mac_ctrl_V2_909x.conf（ https://github.com/u-blox/u-blox-sho-host-based/blob/main/JODY-W3/txpower_config/ed_mac_ctrl_V2_909x... ），但行为没有任何改变。
我们不明白的是，如果我们用 DoodleLabs 的模块（基于 QCA988X）替换该模块，并在相同的环境下进行相同的测试，它也能满足 EN 300 328 标准，但我们却没有遇到任何延迟问题。所以我想知道为什么 88W9098 的 ed_mac 实现会引发这样的问题，而其他芯片制造商的实现却不会。
除了 lf-6.18.20_2.0.0 版本之外，我们也尝试了 hotfix/lf-6.12.49_2.2.0_hotfix 版本，但问题仍然存在。
更多信息：
* 与 JODY 接入点关联的站点共有 2 个。
* 测试期间，站点与 JODY 之间使用的带宽非常低（~6KiB/s），但由许多小数据包组成，主要在 STA > AP 方向上。
亲爱的@mjourdan ，
我已经将您的问题上报给我们的内部团队。让我们一起等待专家的回复——一旦有任何最新消息，我会立即与您分享。
顺祝商祺！
卫东
亲爱的@mjourdan ，
内部团队正在分析该问题，请您提供以下信息？我从内部团队得到了以下反馈。
======================================================
- 驱动程序加载参数，以及用于重现问题的完整驱动程序加载/卸载命令序列。
- ed_mac_ctrl_V2_909x.conf 配置文件。
- 日志 为进一步调查，在重现问题时捕获了屏幕截图。
- 房东详情，包括：
- 主机平台
- 内核版本
- 驱动程序版本
- 使用的接口（PCIe/SDIO）
这些细节将有助于我们将客户的设置与我们的内部测试进行关联，并加快分析速度。
======================================================
谢谢！
顺祝商祺！
卫东
你好 weidong，我目前正在和 u-blox 一起排查问题，为了避免冲突（万一问题升级到 NXP 也会出现），我暂时只会和他们沟通。感谢您的帮助。
亲爱的@mjourdan ，
有任何进展吗？
谢谢您！
此致，
卫东
亲爱的@mjourdan ，
好的，明白了。
谢谢你的更新。
顺祝商祺！
卫东
亲爱的@mjourdan ，
我们使用版本 SD9098---17.92.1.p149.159-MM6X17552.p22 (FP92) 在 QA 环境中验证了该问题，但该问题无法重现。
观察到的 ping 延迟约为1 到 2 秒。
测试步骤：
- 加载了构建版本，并使用发布配置文件夹中提供的默认 ed_mac_ctrl_V2_909x.conf 启用了 EDMAC。
- 在第6频道提出了APUT问题。
- 连接了两个前STA。
- 从 Ex-STA 到 APUT 执行 ping 测试。
测试场景：
- auto_ds=1，ps_mode=1
- auto_ds=2，ps_mode=2
- APUT 配置了 HT20 和 HT40
- 网络安全模式：开放和 WPA3
- 前STA电源管理功能：启用和禁用
为了帮助我们分析和重现客户遇到的问题，能否请您提供以下信息：
- 加载客户使用的文件/版本详细信息
- 完整的配置和测试环境详情
- 客户设置中观察到的噪声/干扰水平
- 来自客户方的相关日志
一旦我们掌握了这些信息，我们就可以进行更深入的分析并尝试重现该问题。
================================================
谢谢。
顺祝商祺！
卫东