测试音乐下载 ：test.wav
串口工具下载：MobaXterm_Portable_v23.0_cn.zip
| 项目 | 详情 |
|---|---|
| 设备型号 | RP01A-RK3588S2开发板（硬件版本：V1.0A） |
| 系统版本 | Debian12 XFCE 桌面（固件版本：rk3588-rp01a-debian12-rkr6-xfce-20251230-更新fw.img） |
| 内核版本 | Linux 6.1.118 |
| 项目 | 配置详情 |
|---|---|
| CPU | RK3588S Octo-core, Cortex-A76 and Cortex-A55 频率高达2.4GHz |
| GPU | Mali-G610 GPU，OpenGL ES 1.1/2.0/3.2，OpenCL 2.2，Vulkan 1.2 内嵌高性能2D加速硬件 |
| 内存（DDR） | LPDDR5X，4G/8G/16G/32G可选 |
| AI 算力（NPU） | 6.0 Tops |
| 内置存储 | 支持 eMMC5.1，SDIO3.0 16GB/32GB/64G/128G（可选） |
| 项目 | 规格说明 |
|---|---|
| 直流电源要求 | 输入：12V 2A DC 接口规格：5.5mm × 2.0mm 圆柱电源口 ⚠️ 注意：输入电压低于 12V 可能导致设备无法开机 |
| 工具 / 环境 | 规格说明 |
|---|---|
| 直流电源适配器 | 12V 2A DC（匹配 5.5mm×2.0mm 接口） |
| 万用表 | 支持电压 / 电流测量 |
| 待测设备 | 目标产品（含电源接口） |
1.直流电源接口兼容性测试
2.输入电压下限验证
| 项目 | 内容 |
|---|---|
| 测试目的 | 验证开发板 Debug 串口（UART）的硬件通信功能，确保能正常输出内核启动日志、接收 / 响应命令行指令，满足底层调试需求。 |
| 前提条件 | 1. 开发板已断电，无外接电源； 2. 准备工具：USB 转 TTL 串口线（3.3V 电平，匹配开发板 Debug 口）、PC 端串口工具（如MobaXterm、 SecureCRT、Putty、串口助手）； 3. 确认开发板 Debug 口引脚定义（TX/RX/GND），并核对串口参数（常见：波特率 1500000、8 位数据位、1 位停止位、无校验、无流控）； 4. PC 已安装串口驱动（USB 转 TTL 芯片驱动，如 CH340/PL2303）。 |
步骤 1：硬件连接
步骤 2：PC 端串口工具配置
步骤 3：启动日志输出测试
1. 设备连接状态识别
通过以下命令确认设备是否接入系统并获取设备节点信息：
# 查看所有块设备，识别USB对应的设备节点（如/dev/sda1） lsblk # 查看USB设备详细信息，包括控制器和设备ID lsusb |
结果说明：lsusb输出中，ID 1d6b:0002对应 USB2.0 控制器，ID 1d6b:0003对应 USB3.0 控制器，可通过设备挂载的总线判断其关联的 USB 版本。
# 遍历所有USB设备，输出其传输速度
for device in $(ls /sys/bus/usb/devices/); do
if [ -f "/sys/bus/usb/devices/$device/speed" ]; then
speed=$(cat /sys/bus/usb/devices/$device/speed)
echo "Device: $device, Speed: $speed Mbps"
fi
done |
2.通过详细信息验证
# 查看指定USB设备的详细参数，搜索Speed字段 lsusb -v | grep -E "Speed|Device" |
结果说明：输出中Speed: 480Mbit/s对应 USB2.0，Speed: 5000Mbit/s对应 USB3.0。
1.1.挂载 USB 设备：
# 假设通过lsblk确认USB设备节点为/dev/sda1，创建挂载点并挂载 mkdir -p /mnt/usb mount /dev/sda1 /mnt/usb |
1.2. 测试顺序写速率：
# 写入1GB零数据到USB设备，绕过缓存确保结果真实 dd if=/dev/zero of=/mnt/usb/testfile bs=1M count=1024 conv=sync oflag=direct |
1.3.测试顺序读速率：
# 读取USB设备中的测试文件并丢弃，测试读取速度 dd if=/mnt/usb/testfile of=/dev/null bs=1M iflag=direct |
1.4.测试后清理临时文件：
rm /mnt/usb/testfile |
结果说明：命令执行完毕后会显示传输时间和速率，USB2.0 实际写速率通常在 10 - 30MB/s，USB3.0 实际写速率通常在 50 - 150MB/s（受设备本身性能影响）。
2.1.安装 fio：
# Ubuntu/Debian sudo apt install fio -y |
2.2.fio测试命令代码块：
# 顺序写测试 fio -filename=/temp/testfile -direct=1 -ioengine=psync -iodepth 128 -rw=write -bs=1M -size=3G -numjobs=4 -runtime=30 -group_reporting -name=iopstest -time_based=1 # 顺序读测试 fio -filename=/temp/testfile -direct=1 -ioengine=psync -iodepth 128 -rw=read -bs=1M -size=3G -numjobs=4 -runtime=30 -group_reporting -name=iopstest -time_based=1 # 随机写测试 fio -filename=/temp/testfile -direct=1 -ioengine=psync -iodepth 128 -rw=randwrite -bs=1M -size=3G -numjobs=4 -runtime=30 -group_reporting -name=iopstest -time_based=1 # 随机读测试 fio -filename=/temp/testfile -direct=1 -ioengine=psync -iodepth 128 -rw=randread -bs=1M -size=3G -numjobs=4 -runtime=30 -group_reporting -name=iopstest -time_based=1 # 随机读写混合测试（默认读写比例 50:50） fio -filename=/temp/testfile -direct=1 -ioengine=psync -iodepth 128 -rw=randrw -bs=1M -size=3G -numjobs=4 -runtime=30 -group_reporting -name=iopstest -time_based=1 |
1.1. ADB基础连接测试
测试目的：验证 Type‑C 接口可正常建立 ADB 连接，设备可被 PC 识别。
测试步骤：
1.用 Type‑C 数据线连接待测设备与 PC。
2.设备端开启「开发者选项」→「USB 调试」。
3.PC 端执行 adb devices，检查设备是否被识别。
4.执行 adb shell，验证是否可进入设备命令行。
预期结果：
1.adb devices 输出设备序列号，状态为 device。
2.成功进入设备 shell，无连接超时或权限拒绝。
1.2. ADB 核心指令执行测试
测试目的：验证 ADB 核心指令在 Type‑C 链路下可正常执行。
测试步骤：
1.用文件传输：
执行 adb push test_file /data/ 推送文件至设备。
执行 adb pull /data/test_file ./ 拉取文件至 PC。
2.设备控制：
执行 adb reboot 重启设备，重启后重新执行 adb devices。
3.日志抓取：
执行 adb logcat -d > adb_log.txt 抓取系统日志。
预期结果：
1.文件传输无失败，拉取文件与原文件大小一致。
2.重启后 ADB 连接可自动恢复。
3.日志文件非空，包含有效运行日志。
1.3. Type‑C 插拔与稳定性测试
测试目的：验证 Type‑C 接口在插拔、晃动等场景下 ADB 连接的稳定性。
测试步骤：
1.单次插拔：插拔数据线 10 次，每次插拔后执行 adb devices。
2.连续插拔：快速插拔 20 次，间隔 1–2 秒。
3.晃动测试：保持连接状态，轻微晃动数据线，观察连接状态。
预期结果：
1.每次插拔均可正常识别设备，无 offline 状态。
2.晃动过程中 ADB 连接不中断，无 IO 错误。
1.4. Type‑C 插拔与稳定性测试
测试目的：验证高负载场景下 Type‑C ADB 功能的稳定性。
测试步骤：
1.大文件传输：推送 1GB 文件至设备，同时执行 adb logcat。
2.多指令并发：同时执行 adb push、adb shell top、adb logcat。
3.长时间连接：保持 ADB 连接 24 小时，每小时执行 adb devices。
预期结果：
1.大文件传输过程中 ADB 不中断，日志抓取正常。
2.多指令并发无卡死或超时，CPU 占用 ≤ 80%。
3.24 小时内连接状态持续为 device，无自动断开。
2.1 设备识别与兼容性测试前置条件：
1.开发板上电正常，系统启动完成
2.Type-C 转 USB Hub 连接正常
操作步骤：
1.将 Type-C 端插入开发板 Type-C 接口
2.将 USB 设备（U 盘、鼠标、键盘）依次插入 Hub 的 USB 口
3.执行命令 lsusb 查看设备列表
4.查看系统日志 dmesg | grep usb
预期结果：
1.所有 USB 设备均能被系统正确识别，lsusb 输出中可见对应设备 ID
2.系统日志无 USB 设备识别失败或报错信息
3.U 盘可正常挂载 / 读写，鼠标 / 键盘可正常响应
2.2 数据传输速率测试
前置条件：
1.同 2.1
2.准备 1GB 测试文件（test.img）
操作步骤：
1.插入 USB3.0 U 盘并挂载到 /mnt/usb
2.执行文件拷贝命令：
dd if=/dev/zero of=/mnt/usb/test.img bs=1M count=1024 |
3.记录传输耗时，计算速率：速率 = 1024MB / 耗时（秒）
4.反向拷贝回开发板，重复测试 3 次
预期结果：
1.USB3.0 模式下传输速率 ≥ 80MB/s（约 640Mbps）
2.USB2.0 模式下传输速率 ≥ 30MB/s（约 240Mbps）
3.无数据丢失、无传输中断、无文件损坏
2.3 供电能力测试
前置条件：
1.同 3.1
2.准备 2.5 英寸移动硬盘（需 5V/0.5A 以上供电）
操作步骤：
1.将移动硬盘插入 Hub 的 USB 口
2.观察硬盘指示灯是否亮起，执行 lsblk 查看设备节点
3.进行大文件读写操作，持续 10 分钟
4.查看系统日志是否有供电不足或设备掉线信息
预期结果：
1.移动硬盘正常启动，系统可识别并读写
2.长时间读写过程中无设备掉线、无数据损坏
3.系统日志无 over-current 或供电相关报错
2.4. 异常场景测试
1.热插拔测试：在数据传输过程中插拔 USB 设备，验证系统稳定性
2.低电压测试：降低开发板供电电压至 4.5V，验证 USB 设备是否正常工作
3.多设备并发测试：同时插入多个 USB 设备，验证 Hub 负载能力
3.1 视频输出功能测试
前置条件：
1.开发板上电正常，系统启动完成
2.Type-C 转 HDMI/DP 转接器连接正常，显示器通电
操作步骤：
1.将 Type-C 端插入开发板 Type-C 接口，HDMI/DP 端插入显示器
2.执行显示配置命令（Linux：xrandr；Android：系统设置）
3.切换显示输出到 HDMI，设置分辨率为 1080P@60Hz
4.观察显示器画面，检查是否有花屏、黑屏、闪烁
预期结果：
1.显示器自动点亮，显示开发板桌面 / 画面
2.分辨率、刷新率可正常配置，画面清晰无失真
3.无花屏、无黑屏、无闪烁、无延迟
3.2 音视频同步输出测试
前置条件：
1.同 3.1
2.显示器支持 HDMI/DP 音频输出
操作步骤：
1.播放 1080P 测试视频（带音轨）
2.观察画面流畅度，同时监听显示器扬声器
3.检查音画是否同步，有无杂音、断音
预期结果：
1.视频画面流畅，帧率稳定（≥30fps）
2.音画同步，无延迟、无卡顿
3.声音清晰，无杂音、无断音、无爆音
3.3 热插拔测试
前置条件：
同 3.1
操作步骤：
1.先连接 Type-C 转 HDMI/DP，确认显示正常
2.拔掉 HDMI/DP 端，观察系统反应
3.重新插入 HDMI/DP 端，观察系统反应
4.重复热插拔 10 次，记录每次结果
预期结果：
1.拔掉 HDMI/DP 后，系统自动切回板载显示或黑屏（符合设计预期）
2.重新插入后，显示器自动恢复显示，无需手动配置
3.热插拔过程中无系统崩溃、无驱动报错
3.4. 异常场景测试
1.分辨率切换测试：在 720P/1080P/4K 之间切换，验证显示兼容性
2.长时间播放测试：连续播放视频 24 小时，验证稳定性
3.低分辨率输出测试：设置为 480P，验证向下兼容能力
1.规格说明：
| 接口 | 核心规格 | 关键限制 |
|---|---|---|
| HDMI 2.1 | 单接口、支持 8K@30Hz/4K@60Hz、HDCP2.3 | 需 HDMI2.1 认证线缆，最大带宽 48Gbps |
1.显示接口及分辨率列表查询
# 图形界面（X11）- 直观查看支持的分辨率/刷新率/HDCP状态 xrandr --verbose | grep -E "HDMI|DP|3840|7680|HDCP" |
2.音频输出测试步骤（命令行操作）
# 步骤1：通过adb连接设备（确保设备已开启调试模式） adb shell # 步骤2：推送测试音频文件到设备（电脑端执行） adb push C:\Users\Administrator\Desktop\test.wav /test.wav # 步骤3：查看设备音频输出列表（确认card编号对应关系） aplay -l # 步骤4：HDMI0音频输出测试 aplay -D plughw:0,0 /test.wav # 预期现象：HDMI连接的显示设备播放音频 # 步骤5：DP1音频输出测试 aplay -D plughw:4,0 /test.wav # 预期现象：DP连接的显示设备播放音频 |
| 测试目的 | 内容 |
|---|---|
| 测试目的 | 验证开发板 MIPI CSI/USB 摄像头接口的硬件连接有效性及视频采集功能。 |
| 前提条件 | 1. 开发板已上电并进入 Linux系统； 2. 摄像头已正确连接（MIPI CSI 排线插紧）。 |
测试步骤：
步骤1：摄像头设备节点识别测试
1.打开终端，执行以下命令查看系统是否识别到摄像头设备：
ls -l /dev/video* |
2.【补充校验】执行以下命令确认设备可用性（可选，增强严谨性）：
v4l2-ctl --list-devices |
步骤 2：摄像头实时预览测试
1.开发板接有 HDMI显示器，执行以下命令进行实时预览：
gst-launch-1.0 v4l2src device=/dev/video22 ! videoconvert ! autovideosink |
2.观察 HDMI 显示器画面，持续预览 10 秒后，按 Ctrl + C 停止命令。
预期结果：HDMI 显示器上出现清晰、流畅的实时视频画面，无花屏、无卡顿、无黑屏；停止命令后终端无 “Internal data stream error” 类核心报错。
1.测试环境（MPP 视频硬解码设备）
基于 Rockchip MPP（Media Process Platform）框架的硬解码工具信息：
| 项目 | 详情 |
|---|---|
| 工具名称 | ppvidedec |
| 工具版本 | 1.14.4 |
| 依赖库路径 | /usr/lib/aarch64-linux-gnu/gstreamer-1.0/libgstrockchipmpp.so |
| 支持编码格式 | HEVC/H.265、AVC/H.264、VP8、VP9 |
| 解码类型 | 硬件加速解码 |
| 最大解码能力 | 8K 10-bit 视频解码，支持 8K 60Hz 视频输出 |
2.测试步骤：
2.1.准备测试视频：
#1.本地测试视频路径： C:\Users\Administrator\Desktop\test_video\4K_60fps.mp4 # 2.通过 ADB 将视频推送至开发板： adb push "C:\Users\Administrator\Desktop\boot\4K_60fps.mp4" /tmp/ |
2.2.执行硬解码测试（以 H.264 格式为例）
# 使用gst-launch-1.0调用 MPP 硬解码工具，验证解码功能： gst-launch-1.0 filesrc location=/tmp/4K_60fps.mp4 ! \ qtdemux ! \ h264parse ! \ mppvideodec ! \ videoconvert ! \ autovideosink |
2.3.测试验证要点
Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Prerolled, waiting for async message to finish... Setting pipeline to PLAYING ... New clock: GstSystemClock #日志逐行说明： #Setting pipeline to PAUSED ...：GStreamer 管道进入暂停状态，开始初始化音视频解码组件（如 MPP 硬解码器），无报错代表组件加载初始化无异常； #Pipeline is PREROLLING ...：管道进入预滚动阶段，开始读取视频文件并解析码流，为硬解码做数据准备； #Pipeline is PREROLLED ...：预滚动完成，视频码流解析成功，RK3566 的 MPP 硬解码单元已获取有效数据； #Prerolled, waiting for async message to finish...：预滚动完成后等待异步消息确认，是 GStreamer 适配嵌入式设备的正常等待流程，无异常； #Setting pipeline to PLAYING ...：管道切换至播放状态，硬解码开始输出视频帧至显示设备； #New clock: GstSystemClock：系统时钟同步完成，音视频时序匹配，无卡顿、音画不同步风险。 |
（注：配图为视频正常播放时的界面示例，可直观验证画面无畸变、显示正常）
3.开启第二个终端进行cpu占用率监控
3.1操作步骤
# 第一步：进入ADB交互式shell adb shell # 第二步：在shell中执行top命令（此时有TTY环境，可正常运行） top -n1 | head -20 |
3.2系统状态输出示例（终端执行后输出如下，红框为核心监控项）
#
top - 06:01:06 up 17:57, 1 user, load average: 2.10, 2.61, 2.56
Tasks: 276 total, 2 running, 274 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.8 us, 6.0 sy, 0.0 ni, 90.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 3899.3 total, 91.5 free, 822.6 used, 2985.2 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 1694.6 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1981 root 20 0 4747336 266284 215960 R 50.0 6.7 877:37.20 Xorg
2456 blueber+ 20 0 1839264 74872 56884 S 12.5 1.9 60:46.06 xfwm4
2513 blueber+ 20 0 314400 39220 29936 S 12.5 1.0 44:54.98 xfce4-p+
38043 root 20 0 529528 23188 11316 S 12.5 0.6 0:13.87 gst-lau+
38263 root 20 0 9048 3400 2712 R 6.2 0.1 0:00.02 top
1 root 20 0 165012 9932 7220 S 0.0 0.2 5:17.56 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.45 kthreadd
3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp
4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par+
8 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_perc+
9 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_tas+
10 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_tas+
11 root 20 0 0 0 0 S 0.0 0.0 0:04.57 ksoftir+ |
3.3状态分析
| 监控项 | 结果 | 说明 |
|---|---|---|
| CPU 整体负载 | 用户 3.8% + 系统 6.0% + 空闲 90.2% | 空闲占比超 90%，CPU 资源冗余充足；当前高占比进程为桌面服务（Xorg、xfwm4），属于系统基础负载 |
| 内存状态 | 总 3899MB，已用 829MB，可用 2968MB | 内存剩余充足，无内存不足风险 |
| 关键进程 CPU 占比 | 桌面服务（Xorg）占 50%，终端（tilda）占 12.5% | 若此时运行视频播放进程，需重点关注其 % CPU 值（硬解码生效时通常＜10%） |
| 内存占用 | 已用 829MB，缓存占 2864MB | 内存缓存占比高，系统数据读写效率有保障 |
3.4测试结论：视频功能播放正常，无卡顿、花屏现象；CPU 占用率低（硬解码加速生效），系统资源负载符合预期。
声卡编号（card） | 设备标识 | 设备编号（device） | 硬件对应 | 核心功能 | 适用场景 |
|---|---|---|---|---|---|
card 0 | rockchip,es8388-codec | device 0 | 板载 ES8388 音频 Codec | 模拟音频输出（3.5mm 耳机 / 喇叭）+ 音频解码 | 耳机播放（核心设备） |
| card 1 | rockchip,hdmi0 | device 0 | HDMI 接口音频通道 | 数字音频输出（HDMI 显示器 / 电视） | HDMI 音频播放 |
# 步骤1：验证ADB连接（避免设备未连接导致后续操作失败） adb devices # 预期输出：列出设备序列号，状态为device（若显示offline/未列出，重新插拔USB/重启调试） # 步骤2：推送测试音频文件到设备（电脑端执行） adb push C:\Users\Administrator\Desktop\test.wav /test.wav # 步骤3：进入ADB交互式shell（后续命令均在设备端执行） adb shell # 步骤4：查看设备音频输出列表（确认card编号对应关系） aplay -l # 步骤5：HDMI0音频输出测试 aplay -D plughw:1,0 /test.wav # 预期现象：HDMI连接的显示设备播放音频 # 步骤6：板载音频（耳机）输出测试 aplay -D plughw:0,0 /test.wav # 预期现象：3.5mm耳机播放音频 # 步骤7：硬件功能验证（正弦波测试，排除文件本身问题） speaker-test -D hw:1,0 -t sine -f 1000 -c 2 -l 2 # 预期现象：耳机输出1000Hz双声道正弦蜂鸣声 |
测试项 | 操作命令 | 预期结果 |
|---|---|---|
HDMI0 音频输出 | aplay -D plughw:1,0 /test.wav | 显示设备正常播放音频 |
| 板载耳机输出 | aplay -D plughw:0,0 /test.wav | 耳机正常播放音频 |
| 硬件正弦波测试 | speaker-test -D hw:1,0 -t sine -f 1000 -c 2 -l 2 | 耳机输出蜂鸣声 |
1.列出所有音频采集设备
# 查看系统音频设备列表（重点关注“Capture”（输入）设备） arecord -l |
2.典型输出示例
**** List of CAPTURE Hardware Devices **** card 0: rockchipes8388c [rockchip,es8388-codec], device 0: dailink-multicodecs ES8323 HiFi-0 [dailink-multicodecs ES8323 HiFi-0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: rockchipes7210 [rockchip,es7210], device 0: fe480000.i2s-ES7210 4CH ADC 0 ES7210 4CH ADC 0-0 [fe480000.i2s-ES7210 4CH ADC 0 ES7210 4CH ADC 0-0] Subdevices: 1/1 Subdevice #0: subdevice #0 |
| 设备类型 | 设备名 / 驱动 | 设备编号（device） | 硬件对应 | 核心功能 | 能否用于耳机播放 |
|---|---|---|---|---|---|
| card 0 | rockchip,es8388-codec | device 0 | 板载 ES8388 codec音频解码 / 模拟输出 | 音频解码 / 模拟输出（3.5mm 耳机 / 线路输出） | ✅ 是（核心耳机设备） |
| card 2 | rockchip,es7210 | device 0 | ES7210 ADC | 4 通道音频采集（麦克风 / 线路输入） | ❌ 否（仅输入） |
4.录音测试（实时采集+播放）
# 功能：实时采集音频输入（hw:1,0）并输出到音频输出（hw:1,0） # 参数说明： # - arecord端： # -D hw:0,0：指定音频输入设备（需根据实际`arecord -l`结果调整） # -r 48000：采样率48000Hz（适配多数音频设备） # -c 2：立体声采集（若MIC为单声道，可改为-c 1） # -f s16_le：16位小端音频格式（通用兼容格式） # -t raw：以原始格式传输（避免文件编码开销） # - aplay端： # -D hw:1,0：指定音频输出设备（如HDMI/板载扬声器） # - 其余参数与arecord保持一致（确保格式匹配） # - &：后台运行（避免终端阻塞） arecord -D hw:0,0 -r 48000 -c 2 -f s16_le -t raw | aplay -D hw:1,0 -r 48000 -c 2 -f s16_le -t raw & |
1.硬件信息完整性
2.基础连接有效性
1.设备识别验证
# 查看系统是否识别到M.2 SSD lsblk |
预期结果：输出中显示 SSD 对应的磁盘设备（如nvme0n1）。
2.磁盘信息读取
# 查看M.2 SSD的详细信息（如容量、接口协议） sudo fdisk -l |
预期结果：显示 SSD 的容量、分区表类型（如 GPT），PCIe x4 总线 + NVMe 存储协议。
3.读写性能测试
# 安装测试工具 sudo apt install hdparm fio # 测试读取性能 sudo hdparm -tT /dev/nvme0n1 # 替换为实际SSD设备名 # 测试随机读写性能（示例：1GB数据） fio --name=ssd-test --filename=/dev/nvme0n1 --size=1G --rw=randrw --bs=4k --numjobs=4 --iodepth=64 --runtime=30 --time_based |
2.基础连接稳定性
1.启动NetworkManager服务
sudo systemctl start NetworkManager |
2.扫描并连接WiFi网络
sudo nmcli dev wifi rescan # 重新扫描WiFi网络 sudo nmcli dev wifi list # 查看可用WiFi列表（可选） sudo nmcli dev wifi connect "WiFi名称" password "WiFi密码" ifname wlan1 |
3.网络连通性测试
ping www.baidu.com |
4.示例命令
sudo nmcli dev wifi connect "Hi nova 9 Pro" password "12345678" ifname wlan1 |
3.Wi-Fi 网络 TCP/UDP 协议性能测试
1.环境准备：
两台测试设备（如开发板 + PC），确保处于同一网络（WiFi / 以太网）；
安装 Iperf3
# Debian/Ubuntu sudo apt install iperf3 |
2.角色定义：
服务端（Server）：接收数据的设备；
客户端（Client）：发送数据的设备。
3.TCP 带宽测试（常用）
# 服务端默认监听5201端口 iperf3 -s |
# 测试TCP带宽（持续10秒，默认） iperf3 -c [服务端IP] |
# 测试30秒，每2秒输出一次实时数据 iperf3 -c [服务端IP] -t 30 -i 2 # 测试双向带宽（服务端/客户端互传） iperf3 -c [服务端IP] -d |
4.UDP 丢包 / 延迟测试
iperf3 -s |
# 测试UDP（指定带宽100Mbps） iperf3 -c [服务端IP] -u -b 100M |
5.结果解读（示例）
TCP 测试结果
[ 5] local 192.168.1.10 port 5001 connected to 192.168.1.20 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 1.10 GBytes 943 Mbits/sec # 实际带宽：943Mbps |
UDP测试结果
[ 5] local 192.168.1.10 port 5001 connected to 192.168.1.20 port 5201 [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-10.00 sec 119 MBytes 100 Mbits/sec 0.035 ms 0/85000 (0%) # 丢包率：0% |
6.常见场景测试
| 测试目标 | 命令示例 |
|---|---|
| 长连接稳定性（1 小时） | iperf3 -c [IP] -t 3600 |
| 多线程并发测试 | iperf3 -c [IP] -P 4（4 线程） |
| 限制带宽测试 | iperf3 -c [IP] -b 500M（限制为 500Mbps） |
2.进入蓝牙命令模式
# 通过adb连接设备 adb shell # 启动蓝牙控制工具 sudo bluetoothctl |
3.扫描并连接蓝牙设备
scan on # 开启蓝牙扫描（按Ctrl+C停止扫描） trust [设备MAC地址] # 信任目标设备 pair [设备MAC地址] # 配对目标设备 connect [设备MAC地址] # 连接目标设备 |
4.操作示例
# 扫描后，对MAC为7C:B4:37:11:5B:83的设备执行操作 trust 7C:B4:37:11:5B:83 pair 7C:B4:37:11:5B:83 connect 7C:B4:37:11:5B:83 |