1、Wi-Fi的调频并不是像蜂窝网那样毫秒级、用户无感地跳频而是在“射频资源调度/优化”这个大机制里按分钟甚至按小时级别、并且只在必要时才让 AP 切换工作信道。正常场景下不会“频繁“切信道原因有三条a、协议层面就没有“跳频”概念802.11工作组从未定义类似蓝牙AFH的“每包跳频”机制。一条BSS一旦 beacon 里宣告了 channel终端会一直驻留该channel直到收到AP发出的 “Channel Switch Announcement” 才整体迁移。b、厂商实现里加了“稳定门限”华为/锐捷/华硕等方案射频调优算法默认30min24h才运行一次单次运行后如果新信道质量没有比当前好到10–20%以上就维持不动。DFS场景下若检测到雷达AP会立即跳走但雷达消失后也不会自动跳回避免再次引发下线。c、切信道代价高一次信道切换 停发beacon踢掉已关联终端等待重新扫描/关联整个过程 1–2 s语音/会议类业务会明显卡顿。厂商算法会把“减少切换”写成优化目标函数宁可牺牲一点吞吐量也要保持 channel 稳定。所以日常家用或企业办公“自动信道”可能一天才变一次甚至数天不变只有下面两种例外会出现“看起来频繁”另外信道跳不跳、什么时候跳”由路由器AP说了算Wi-Fi模组只负责被动跟随。2、蓝牙频偏和wifi的干扰蓝牙频偏不能太大偏离了1M宽的车道就会通信失败和协商的信道不一致。wifi允许的频偏会更大大概60K。频偏如何加剧干扰a.理想情况假设蓝牙完美地在它指定的信道上工作而WiFi工作在信道6中心频率2.437GHz。虽然WiFi信号能量很强但蓝牙可以通过跳频避开WiFi能量最强的中心区域跳到干扰较小的边缘信道从而维持连接。b.实际情况有频偏由于蓝牙存在频偏比如40kHz它本应工作在信道f但实际上却工作在f40kHz。这个偏差可能导致· 撞个正着本来想跳到一个“安全”的信道却因为频偏而跳到了被WiFi强信号覆盖的区域。· 避无可避即使跳到了WiFi信道的边缘频偏也可能把它直接“推”进WiFi的主能量区内。由于WiFi信号功率远大于蓝牙这个微小的频率偏差就足以让蓝牙接收机被强大的WiFi噪声“淹没”无法解析出微弱的蓝牙信号从而导致数据包丢失、连接不稳定、音频卡顿、延迟增高。频偏涉及到发射和接收都会受到影响。wifi和BT谁的发射功率弱谁就容易受影响容易被覆盖一般wifi的发射功率更大。跳频算法“无法自救”是因为蓝牙的“跳频规则”是事先写死的 79 × 1 MHz 棋盘而频偏相当于把整颗棋子“掰歪”了几格棋子一旦落出棋盘AFH 的黑名单机制根本检测不到也屏蔽不了于是每一次跳频都把能量准确地送进 Wi-Fi 的 20 MHz 固定领地算法连“错”都认不出来也就谈不上自救3、2.4G的wifi信道带宽是22M有14个信道有部分不开放会互相重叠完全不重叠的只有1、6、11。5G的wifi信道带宽为20M有25条信道一般情况下不会出现信道重叠。蓝牙是2.4G经典蓝牙信道带宽是1M有79个信道不会互相重叠。没有固定的广播信道在“设备发现”和“等待连接”两个阶段通过跳频方式使用其中的 32 条信道来完成广播/扫描功能。BLE信道带宽是2M有40个信道不会互相重叠。4、“RF 的收和发能不能同时进行”取决于双工方式• 同频→只能分时TDD不能同时• 异频→可以同时进行FDD但占用两条频带• 真正的“同频同时”全双工仍处研究阶段不是 Wi-Fi 或现行蜂窝的常态。5、WIFI低功耗深度睡眠模式wifi连接之前会设置间隔时间多久醒来一次其实就是设置一个独立的RTC每间隔多少个DTIMbeacon信标帧醒来一次。RTC会产生时针中断唤醒MCU唤醒后mcu进入唤醒流程恢复栈给射频基带上电就可以接收到beacon帧以及其他的数据完成数据交互。休眠状态下基本只有一个RTC在工作MCU射频部分都是断电的只有唤醒后才会上电。MCU的系统时针补偿也是用的这个独立的RTC。