如何从Arduino Nano 33 BLE采集保存16kHz采样率音频？

核心问题根因：115200波特率的有效传输带宽不足90kbps，而16kHz/16bit单声道音频需要256kbps的净带宽，本身就无法满足传输需求；同时你之前的收发代码存在大量不必要的开销，进一步拉低了实际传输效率。NANO 33 BLE的RAM仅256KB，本地缓存长音频完全不现实，采用流式传输/写入的方案即可实现30-60分钟的连续采集，以下是两种可直接落地的方案：

方案一：高波特率USB串口直传（零额外硬件成本） #

NANO 33 BLE的USB口是原生CDC串口，不存在传统UART的波特率误差问题，可以直接跑2Mbps及以上波特率，有效带宽超200KB/s，完全覆盖32KB/s的音频流带宽需求。

Arduino端修改要点 #

• 串口波特率直接设置为2000000，不要用115200。
• 采用双缓冲机制采集：开2个256字节的RAM缓冲区，PDM采样回调只负责往当前激活的缓冲区填数据，缓冲区写满后立刻切换到另一个空缓冲区，同时在主循环里把写满的缓冲区通过Serial.write(buf, len)批量发送，不要逐字节发送，不要用Serial.print转ASCII。
• 禁止在PDM采样中断回调里做串口发送操作，避免阻塞采样导致丢点。

Python端修改要点 #

• 去掉逐字节读取、逐点写文件、转字符串的冗余逻辑，这些操作的IO开销会直接拖慢读取速度，你之前测出来的每秒5k+采样根本不是串口的真实带宽。
• 读取时用ser.read(ser.in_waiting)一次性把串口缓冲区的所有数据读入内存，攒够16KB以上再批量写入磁盘，减少磁盘IO次数。
• 不要存JSON格式，直接存二进制裸流，或者直接在文件头写入标准WAV格式信息，采集完直接是可播放的音频文件，省去后续转格式的步骤。
• 时间对齐可以在采集启动时读取系统时间戳作为文件名，和本地视频的启动时间戳做对应即可，后续标注直接按时间偏移匹配。

按这个配置，连续采集几小时音频都不会丢数据，60分钟的音频总大小仅115MB左右，普通电脑存储完全无压力。

方案二：外接TF卡本地存储（无需连接电脑，适合移动采集） #

如果不想拖串口线采集，可以花几块钱买SPI接口的TF卡模块，直接把音频流实时写入TF卡，存储时长只受TF卡容量限制，32G的卡可以存几十小时音频。

实现要点 #

• 接线仅需6根：VCC接3.3V、GND接GND、SCK接D13、MOSI接D11、MISO接D12、CS引脚接任意空闲数字IO。
• 代码层面同样用双缓冲采样逻辑，缓冲区写满后批量写入SD卡，不要逐点写。
• 文件存储直接用标准WAV格式：启动采集时先写一个占位的WAV文件头，采集结束后回头更新头文件里的采样数、时长字段，拷出来的文件可以直接导入EdgeImpulse使用，无需转码。
• 时间对齐可以在采集启动时触发LED闪烁或者蜂鸣器提示，后期在视频里找到这个标记点即可对齐音频和视频的时间轴。

之前方案的问题说明 #

• 用Serial.print发ASCII格式的采样值，每个16bit采样值最多要转5个ASCII字符，加上分隔符、换行符，实际带宽需求是原始二进制的4-5倍，115200波特率完全扛不住。
• 逐字节串口发送、逐字节读取、逐点写文件的操作会产生大量函数调用和IO开销，哪怕带宽够，实际跑出来的吞吐量也会远低于理论值。
• 直接把音频存在RAM里的方案完全不可行，NANO 33 BLE除去系统、驱动库占用的RAM，剩余空间不足150KB，仅够存不到5秒的16kHz/16bit音频，流式处理不需要缓存整段音频，仅需几KB的缓冲区即可连续工作。

内容的提问来源于stack exchange，提问作者Francesco Maccantelli