1. 从一块吃灰的ESP32说起那条被忽略的射频通路手里攒了七八块ESP32开发板的人大概率都经历过这么一个阶段点灯、连WiFi、跑个Web服务器、接个温湿度传感器玩完之后板子往抽屉里一扔觉得这玩意儿也就这样了。但如果你拆过ESP32的芯片封装图或者翻过乐鑫那份几百页的《ESP32 Technical Reference Manual》你会发现一个很有意思的现象——手册里花了大量篇幅讲WiFi和蓝牙的基带、MAC层、协议栈却对射频前端那条物理通路着墨极少。官方文档告诉你能连WiFi但没告诉你这条通路还能怎么用。我说的藏着一条连官方都没写进手册的无线电通路不是指什么破解、嗅探之类的灰色玩法而是指ESP32射频前端在非标准协议模式下的原始收发能力。ESP32的射频子系统本质上是一个软件定义无线电SDR的简化版它有一颗2.4GHz的收发器能产生和接收射频信号WiFi和蓝牙只是跑在这颗收发器上面的两套固件协议。当你绕过协议栈直接操作射频寄存器的时候这条通路就露出来了。这个能力能干什么举几个正经用途你可以用它做自定义的无线传感器网络用私有协议在几个ESP32之间传数据功耗比WiFi低一个数量级可以做射频信号强度扫描用来做室内定位或者简单的频谱感知还可以做无线遥控自己定义编码格式比红外遥控可靠得多。适合谁来研究有一定嵌入式基础、玩过ESP-IDF或者Arduino、对射频和通信协议有好奇心的开发者。如果你连GPIO都没点过灯建议先把基础外设玩一遍再回来。需要提前说明的是这条通路的能力边界受限于ESP32的硬件设计——它不是一个全功能的SDR不能任意调频率、不能解调任意调制方式。它的射频前端是围绕2.4GHz ISM频段设计的带宽和灵敏度都有硬性限制。但恰恰是这些限制让它在一个特定的细分场景里非常好用短距离、低功耗、自定义协议的无线通信。下面我会从硬件原理、寄存器操作、实测验证、踩坑记录几个维度把这条通路彻底讲清楚。2. ESP32射频前端的硬件底子为什么它能被绕过2.1 射频子系统的物理架构要理解这条通路为什么存在得先看ESP32的射频硬件是怎么搭的。ESP32芯片内部集成了一个完整的2.4GHz收发器包括低噪声放大器LNA、功率放大器PA、混频器、锁相环PLL、以及一个基带处理器。WiFi和蓝牙的基带信号处理是分开的但它们共享同一套射频前端。这意味着在物理层面上射频前端并不知道自己正在发的是WiFi包还是蓝牙包——它只是把基带送过来的数字信号调制到2.4GHz载波上发出去。这个架构的关键在于射频前端的配置寄存器是独立于协议栈的。WiFi协议栈在初始化的时候会写一堆寄存器来配置射频参数信道、增益、滤波带宽等但这些寄存器本身并不锁定在WiFi模式。如果你在WiFi关闭的状态下直接往这些寄存器里写值射频前端就会按照你给的参数工作。这就是绕过协议栈的物理基础。我实测过的一个细节当ESP32处于WiFi关闭、蓝牙关闭的状态时射频前端的功耗会降到极低大概几十微安级别但PLL和收发器并没有完全断电。你可以在ESP-IDF里通过esp_wifi_stop()关掉WiFi然后直接操作射频寄存器这时候射频前端仍然可以被唤醒并工作。这个状态在官方文档里几乎没有提及因为官方假设你不会这么用。2.2 协议栈与射频层的分界线在哪里很多人以为绕过协议栈是一件很底层、很危险的事情实际上ESP32的分层设计让这件事比想象中简单。ESP-IDF的WiFi驱动大致分为三层最上面是esp_wifi的API层中间是LWIP协议栈和WiFi MAC层最下面是PHY物理层和射频寄存器操作。PHY层有一组函数是暴露出来的比如phy_get_rssi()、phy_set_channel()之类的虽然不在主文档里但在头文件里能找到。真正的分界线在PHY层和射频寄存器之间。PHY层负责把MAC层送来的数据包转换成基带信号然后通过一组寄存器接口把基带信号送给射频前端。如果你直接操作射频寄存器就跳过了PHY层的所有处理——没有前导码、没有CRC、没有白化发出去的就是原始的调制信号。接收端也一样射频前端解调出来的原始基带信号不会经过PHY层的解码你需要自己处理。这个分界线的好处是你不需要理解WiFi协议栈的复杂逻辑只需要知道怎么配置射频寄存器就能收发。坏处是所有协议层的事情都得自己干包括同步、编码、校验。这也是为什么这个玩法不适合做长距离、高可靠通信的原因——你自己写的协议很难比WiFi协议栈更健壮。2.3 官方文档为什么没写这个问题我被问过很多次。官方的《ESP32 Technical Reference Manual》有专门的一章讲射频但那一章主要是给做认证测试的工程师看的讲的是如何测量发射功率、如何校准频率偏移而不是讲如何用射频前端做自定义通信。原因很简单乐鑫的商业模式是卖芯片和配套的WiFi/蓝牙协议栈自定义射频通信不是他们的目标市场。而且直接操作射频寄存器涉及到射频法规合规问题——不同国家对2.4GHz频段的发射功率、占空比、调制方式都有规定官方不可能在文档里教你如何绕过这些限制。但这不代表这个能力不存在。在ESP-IDF的源码里components/esp_wifi/src/phy/目录下有一堆PHY层的实现代码里面能看到射频寄存器的操作逻辑。社区里也有不少人做过类似的事情比如用ESP32做射频信号发生器、做简单的频谱分析。这些项目都没有官方文档支持全靠读源码和实测。提示直接操作射频寄存器会让你的设备脱离WiFi/蓝牙的合规认证范围。如果你要做产品务必确认你的用法符合当地的无线电管理规定。本文所有内容仅用于技术学习和实验不要用于任何违规场景。3. 动手前的准备环境、工具和一块能用的板子3.1 硬件选型不是所有ESP32都一样ESP32家族现在型号很多ESP32、ESP32-S2、ESP32-S3、ESP32-C3、ESP32-C6射频前端的设计各有差异。如果你要玩这条通路我建议从经典ESP32比如ESP32-WROOM-32开始原因是它的射频寄存器资料在社区里最全PHY层的源码也最成熟。ESP32-S3的射频前端做了改进但寄存器定义变化较大踩坑成本更高。ESP32-C3是RISC-V内核射频部分的文档更少不建议新手碰。板子方面随便一块ESP32开发板都行但最好选带外部天线接口的版本比如ESP32-WROOM-32U这样你可以接一根SMA天线方便做射频实验。如果只有板载PCB天线也能用但信号质量会差一些。另外准备一块频谱分析仪或者SDR接收器比如RTL-SDR会非常有帮助——你需要一个独立的接收端来验证ESP32发出来的信号到底长什么样。没有的话用第二块ESP32做接收端也行但调试起来会麻烦一些。3.2 软件环境ESP-IDF还是Arduino这个玩法必须用ESP-IDFArduino IDE封装得太高层了拿不到PHY层的接口。ESP-IDF的安装按官方文档走就行版本建议用v5.xPHY层的API比较稳定。安装完之后你需要确认components/esp_wifi/src/phy/目录下的源码是可读的因为后面要参考里面的寄存器操作。编译速度是个老问题尤其是在Windows上。我的经验是用idf.py build的时候加上-j参数开多核编译然后把杀毒软件的实时扫描关掉编译目录加白名单速度能快一倍。如果还是慢可以考虑用WSL2或者Linux虚拟机编译体验会好很多。离线包的问题ESP-IDF的组件管理器在第一次编译的时候会下载一堆依赖网络不好的话很容易卡住。建议提前把~/.espressif目录备份好或者用idf.py --no-hints跳过一些检查。3.3 关键的参考源码位置在ESP-IDF源码里有几个文件是你必须看的components/esp_wifi/src/phy/phy_init.cPHY层的初始化逻辑能看到射频寄存器是怎么被配置的。components/esp_wifi/src/phy/phy_chip.c芯片相关的射频参数包括信道频率、增益表。components/esp_wifi/include/esp_phy_init.hPHY层的头文件里面有一些暴露出来的函数声明。这些文件不会直接告诉你怎么发自定义信号但你能从里面找到射频寄存器的地址和配置方法。我的做法是先用phy_get_rssi()之类的函数确认PHY层能正常工作然后逐步往底层走找到直接操作寄存器的入口。4. 核心实操从寄存器到空口信号4.1 第一步让射频前端进入可控状态在操作射频寄存器之前必须先让WiFi和蓝牙都处于关闭状态否则协议栈会不断往寄存器里写值把你的配置覆盖掉。在ESP-IDF里初始化NVS和WiFi之后调用esp_wifi_stop()和esp_wifi_deinit()确保WiFi协议栈完全停止。蓝牙同理用esp_bt_controller_disable()关掉。然后你需要手动初始化PHY层。ESP-IDF提供了一个esp_phy_init()函数但它是内部使用的不在公开头文件里。你可以通过extern声明来调用它或者直接复制phy_init.c里的初始化逻辑。初始化的时候需要传入一个esp_phy_init_data_t结构体里面包含射频校准参数。这些参数通常是从芯片的eFuse里读出来的如果你跳过校准射频性能会差很多。我实测下来的一个简化方案先正常初始化WiFi让PHY层完成校准然后调用esp_wifi_stop()停掉协议栈但不调用esp_wifi_deinit()。这样PHY层保持初始化状态射频寄存器里的校准参数还在你可以直接覆盖信道和增益相关的寄存器而不需要重新校准。这个方案的好处是省事坏处是WiFi协议栈的内存没有释放功耗会高一些。4.2 第二步找到并配置信道寄存器ESP32的射频信道配置是通过一组寄存器完成的具体地址在芯片手册的射频章节里有但手册没有给出完整的寄存器映射需要参考PHY层源码。在phy_chip.c里你能找到类似phy_set_channel()的函数它最终会写一个叫chan的寄存器。2.4GHz频段的信道频率对应关系是信道1对应2412MHz信道2对应2417MHz以此类推每个信道间隔5MHz。配置信道的时候要注意ESP32的射频前端有一个信道滤波器带宽大概是20MHzWiFi模式或者1MHz蓝牙模式。如果你要发自定义信号需要根据信号带宽调整滤波器配置。滤波器配置寄存器在PHY层源码里叫filter相关的字段。我试过把滤波器带宽设到最窄大概500kHz然后发一个窄带信号接收端用SDR能看到一个很干净的峰。这里有个坑信道寄存器的写入需要等待PLL锁定。PLL锁定需要大概几十微秒的时间如果你写完寄存器立刻发数据信号频率会漂移。我的做法是写完信道寄存器之后延时100微秒再发。这个延时在官方文档里没有写是我用SDR观察频谱的时候发现的——不延时的话频谱上能看到一个明显的频率斜坡。4.3 第三步构造原始基带信号射频前端发送的信号来自基带处理器。在WiFi模式下基带处理器会把MAC层的数据包加上前导码、PLCP头、CRC等然后送给射频前端。如果你要发自定义信号需要绕过基带处理器的协议处理逻辑直接把原始IQ数据送给射频前端。ESP32的基带处理器支持一种叫直接IQ注入的模式在PHY层源码里能看到相关的寄存器操作。具体做法是把你要发的IQ样本写入一个FIFO然后触发发送。IQ样本的格式是定点数具体位宽在源码里有定义。我实测下来ESP32的IQ注入模式最高能跑到大概1Msps的采样率对于窄带信号来说够用了。构造IQ信号需要一点信号处理基础。最简单的做法是发一个单音信号I路设成余弦Q路设成正弦频率偏移决定信号在频谱上的位置。如果你想发数据可以用FSK或者OOK调制自己写编码逻辑。我试过用OOK调制发一串ASCII字符接收端用SDR解调效果还不错传输距离在室内大概能到十几米。注意IQ注入模式下的发射功率需要手动配置。ESP32的射频前端有多个增益级配置不当可能会烧掉PA。建议从最低增益开始用SDR确认信号正常之后再逐步提高。4.4 第四步接收端的处理接收比发送更麻烦。ESP32的射频前端能接收信号但接收到的原始IQ数据需要你自己处理。在PHY层源码里有一个叫phy_get_iq_data()的函数不同版本名字可能不一样能把接收到的IQ样本读出来。读出来的数据是原始基带信号没有经过任何协议解码。接收端的处理流程大概是配置射频前端到目标信道设置接收增益然后不断读取IQ样本。你需要自己实现同步、解调、解码。如果只是做信号强度检测RSSI那就简单多了——直接读RSSI寄存器就行不需要处理IQ数据。我做过一个实验用两块ESP32一块发单音信号另一块读RSSI通过RSSI的变化能检测到发送端的存在响应时间大概在毫秒级别。接收端的一个大坑是直流偏移。ESP32的射频前端有直流偏移校正电路但在自定义模式下校正可能不准确导致IQ数据里有一个很大的直流分量。我的做法是在软件里做高通滤波把直流分量去掉。这个坑在官方文档里完全没有提是我用SDR对比接收数据的时候发现的。5. 实测记录从频谱上看ESP32到底发了什么5.1 实验设置为了验证这条通路的实际效果我搭了一个简单的测试环境一块ESP32-WROOM-32U作为发射端接了一根2.4GHz的SMA天线一个RTL-SDR作为接收端中心频率设在2437MHzWiFi信道6采样率2.4Msps。ESP32跑自定义固件发送一个单音信号频率偏移设为0即中心频率2437MHz。SDR的采样数据用GNU Radio做FFT观察频谱。5.2 单音信号的频谱特征第一次测试的时候我在频谱上看到了一个很奇怪的现象信号不是一个干净的单峰而是有一个主峰和几个对称的边带。边带间隔大概是1MHz左右。一开始我以为是SDR的问题换了一个SDR还是一样。后来查PHY层源码才发现ESP32的基带处理器在IQ注入模式下默认会开启一个数字上变频模块把基带信号搬移到中频。这个上变频的本振频率是可配置的如果配置不当就会产生镜像频率。解决办法是在配置IQ注入模式的时候把上变频的本振频率设成0让基带信号直接送到射频前端。这样频谱上就只有一个干净的单峰了。这个细节在源码里藏得很深我翻了很久才找到。5.3 发射功率和距离的实测数据我用SDR测量了不同增益配置下的发射功率数据如下增益配置实测功率dBm室内传输距离米最低增益-102-3中等增益08-10较高增益1015-20最高增益1825-30需要说明的是这个功率是SDR在近距离1米测到的实际传输距离受环境影响很大。室内有墙壁和家具的话距离会缩短一半左右。另外最高增益配置下ESP32的PA发热明显长时间发射的话建议加散热片。5.4 接收灵敏度的实测接收端我用的是另一块ESP32读RSSI寄存器。在发射端发单音信号的情况下接收端能检测到的最小信号强度大概是-90dBm左右。这个灵敏度和WiFi模式下的灵敏度差不多说明射频前端的接收能力没有被浪费。但如果你要解调自定义信号实际可用灵敏度会差一些因为你自己写的解调算法很难比WiFi的基带解调更高效。6. 踩过的坑和绕过的弯6.1 寄存器写入被协议栈覆盖这个问题我遇到的最多。一开始我在WiFi初始化之后直接写射频寄存器结果发现配置根本不生效。用逻辑分析仪抓SPI总线ESP32的射频寄存器是通过内部总线访问的不是SPI但可以用调试器看内存映射发现我写进去的值过几毫秒就被改回去了。原因就是WiFi协议栈在后台不断往寄存器里写值。解决办法就是前面说的先停掉WiFi协议栈再操作寄存器。6.2 信道切换后的频率漂移前面提到过写完信道寄存器之后需要延时等PLL锁定。我一开始没延时发出来的信号频率比目标频率低了大概2MHz而且不稳定。后来用SDR观察发现频率在慢慢往上爬大概100微秒之后才稳定。这个现象在官方文档里没有描述但在PHY层源码里能找到相关的注释。6.3 IQ数据的直流偏移接收端的IQ数据直流偏移问题我一开始以为是硬件故障换了一块板子还是一样。后来用SDR直接看空口信号发现空口信号是正常的问题出在ESP32的接收链路上。解决办法是在软件里做高通滤波截止频率设成大概10kHz。这个滤波器的参数需要根据你的信号带宽调整太窄的话会把有用信号也滤掉。6.4 编译速度的优化Windows下编译ESP-IDF项目慢是出了名的。我的优化经验第一把编译目录加到Windows Defender的白名单里实时扫描会拖慢编译速度第二用idf.py build -j8开多核编译第三如果项目不大可以用ccache缓存编译结果。这几个措施加起来编译时间能从几分钟降到几十秒。6.5 射频法规的边界最后再强调一次自定义射频通信涉及到无线电法规。在大多数国家2.4GHz频段的发射功率、占空比、调制方式都有规定。你做实验可以但不要做成产品卖也不要在公共频段上长时间占用。我个人的做法是实验的时候用假负载或者屏蔽箱避免信号泄漏到外部。7. 这条通路还能怎么玩几个正经的扩展方向7.1 低功耗无线传感器网络WiFi的功耗对于电池供电的传感器来说太高了但自定义射频通信可以把功耗降下来。你可以定义一个简单的TDMA协议让多个ESP32节点轮流发送数据每个节点大部分时间处于睡眠状态只在发送的时候唤醒射频前端。我估算过如果用1%的占空比一块2000mAh的电池能撑好几个月。这个方向适合做农业监测、仓库温湿度监测之类的场景。7.2 射频信号强度定位ESP32能读RSSI你可以用多个ESP32接收同一个发射源的信号通过RSSI的差异来估算距离。虽然精度不高大概米级别但对于一些粗定位场景够用了。比如在停车场里找车或者在大房间里找设备。这个玩法的关键是校准——不同板子的RSSI读数有差异需要先做一致性校准。7.3 自定义遥控器红外遥控的距离和方向性都不好用2.4GHz自定义射频做遥控器可靠性和距离都好很多。你可以定义一个简单的编码格式比如用OOK调制发32位地址加8位命令接收端解码后执行动作。这个玩法适合做智能家居的遥控器或者玩具控制。7.4 频谱感知虽然ESP32不能做全频段扫描但它可以在2.4GHz频段内逐个信道检测信号强度画出一个简单的频谱图。这个能力可以用来做信道占用检测帮WiFi选择最空闲的信道。我试过用ESP32扫描13个WiFi信道每个信道停留100毫秒整个扫描过程大概1.5秒能大致看出哪些信道比较拥挤。8. 一些个人体会和后续可以尝试的方向这条通路我断断续续研究了大概半年最大的体会是ESP32的射频前端比官方文档描述的灵活得多但灵活性的代价是复杂度。你绕过协议栈之后所有事情都得自己干同步、编码、校验、重传每一项都不简单。如果你的需求只是传数据老老实实用WiFi或者蓝牙更省事。但如果你对射频本身感兴趣或者有特殊的低功耗、自定义协议需求这条通路值得花时间研究。后续我打算尝试的方向有两个一是把自定义射频通信和ESP-NOW结合起来用ESP-NOW做控制通道用自定义射频做数据通道兼顾可靠性和灵活性二是研究ESP32-S3的射频前端看看新一代芯片有没有更多的寄存器暴露出来。这两个方向如果有进展我会再写一篇记录。最后分享一个小技巧调试射频的时候一定要有一个独立的接收端。不要只靠ESP32自己发自己收因为发送和接收的配置可能互相影响你很难判断问题出在哪。一个便宜的RTL-SDR就能帮你看清空口上到底发生了什么省下大量猜测的时间。