uart文件下载 :uart
测试音乐下载 :test.wav
串口工具下载:UartAssist.exe
| 项目 | 详情 |
|---|---|
| 设备型号 | EDGE-RK3588 开发板(硬件版本:V1.2A) |
| 系统版本 | Debian11 Xfce(固件版本:rk3588_edge_v12_debain_xfce_rk7_v1.2 中性) |
| 内核版本 | Linux 5.10 |
| 项目 | 配置详情 |
|---|---|
| CPU | 8 核异构架构:4×Cortex-A76(高性能核) + 4×Cortex-A55(能效核),最高主频 2.4GHz |
| GPU | Mali-G610 MP4 图形处理器 支持标准:OpenGL ES 1.1/2.0/3.2、OpenCL 2.2、Vulkan 1.2 |
| 内存(DDR) | LPDDR4X 类型,可选容量:4GB/8GB/16GB |
| AI 算力(NPU) | 6.0 Tops(支持 INT4/INT8/FP16 计算精度) |
| 内置存储 | 支持 eMMC 5.1 / SDIO 3.0 接口 可选容量:16GB/32GB/64GB/128GB |
| 项目 | 规格说明 |
|---|---|
| 直流电源要求 | 输入:12V 2A DC 接口规格:5.5mm × 2.0mm 圆柱电源口 ⚠️ 注意:输入电压低于 12V 可能导致设备无法开机 |
| 扩展供电 | 预留 POE 电源接口,支持外挂 POE 模块供电(需单独配置) |
| 工具 / 环境 | 规格说明 |
|---|---|
| 直流电源适配器 | 12V 2A DC(匹配 5.5mm×2.0mm 接口) |
| 万用表 | 支持电压 / 电流测量 |
| POE 模块(选配) | 适配设备预留 POE 接口型号 |
| 待测设备 | 目标产品(含电源接口) |
1.直流电源接口兼容性测试
2.输入电压下限验证
3.POE 接口扩展供电测试(选配)
RS232对应设备节点:ttyS3(V1.2 版本)/ ttyS4 (V1.4 版本)
测试准备:
1.确认串口节点
# 方法1:查看所有串口 ls -la /dev/ttyS* # 方法2:根据硬件版本确定 # 查看板卡版本标记或运行: cat /proc/device-tree/model # 如果显示包含V1.4,则使用/dev/ttyS4 # 如果显示包含V1.2,则使用/dev/ttyS3 |
2.两分钟回环测试
# 步骤1:硬件短接(必须) # 使用导线短接RS232接口的TX(引脚2)和RX(引脚3) # 步骤2:准备测试工具 # 将uart测试程序上传到设备(如果从Windows传输) adb push C:\Users\Administrator\Desktop\uart ./ # 步骤3:赋予权限 chmod 777 ./uart # 步骤4:执行测试 # 终端1:接收数据 cat /dev/ttyS3 # 终端2:发送数据 ./uart /dev/ttyS3 # 输入测试文本,在终端1查看接收结果 |
输出示例
# 终端2程序输出示例: # fcntl=0 # isatty success! # fd-open=3 # set done! # please input: # 此处等待用户输入(如45 3A F7 98) #终端1接收到终端2输入的数据(如45 3A F7 98) |
1.测试目的
验证 RK3588 设备的 RS485 串口(映射为系统设备/dev/ttyS0)与电脑端 UART Assist 工具的双向数据通信功能,确保串口硬件、驱动及链路的可用性。
2.测试环境
| 设备 / 工具 | 配置信息 |
|---|---|
| RK3588 设备 | 系统:嵌入式 Linux(如 Armbian) RS485 串口: /dev/ttyS0(波特率 115200、8N1) |
| 电脑端 | 工具:UART Assist(串口调试助手) 硬件:USB 转 RS485 模块(如 CH340+MAX485) |
| 链路 | RS485 接线:RK3588 的 RS485_A 接模块 A、RS485_B 接模块 B、共地(GND) |
3.硬件接线
4.测试步骤
# 步骤1:准备测试工具 # 将uart测试程序上传到设备(如果从Windows传输) adb push C:\Users\Administrator\Desktop\uart ./ # 步骤2:赋予权限 chmod 777 ./uart # 步骤3:执行测试 # 终端1:接收数据 cat /dev/ttyS0 # 终端2:运行命令工具配置正确的串口参数 ./uart /dev/ttyS0 |
2.电脑端 UART Assist 输入测试数据(如 “RK3588 RS485 Test”),(如下图)点击 “发送”;

3.观察 RK3588 终端1(如下图),若显示接收的测试数据,则单向接收功能正常。

# 步骤1:准备测试工具 # 将uart测试程序上传到设备(如果从Windows传输) adb push C:\Users\Administrator\Desktop\uart ./ # 步骤2:赋予权限 chmod 777 ./uart # 步骤3:执行测试 #发送数据 ./uart /dev/ttyS0 # 输入测试文本(如下图) |
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.规格说明:
| 接口 | 核心规格 | 关键限制 |
|---|---|---|
| HDMI 2.1 | 单接口、支持 8K@30Hz/4K@60Hz、HDCP2.3 | 需 HDMI2.1 认证线缆,最大带宽 48Gbps |
| DP 1.4a(4Lane) | 单接口、支持 4K@60Hz、HDCP2.3 | 4K 可满帧 60Hz |
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连接的显示设备播放音频 |
1.测试准备
1.硬件连接:将有效 HDMI 信号源(如笔记本电脑、HDMI 摄像头、机顶盒等)通过标准 HDMI 线连接至开发板的 HDMI IN 接口;
2.信号源配置:确保 HDMI 信号源已开机,且输出分辨率 / 帧率与开发板 HDMI IN 接口兼容(推荐 1920×1080@60Hz,避免非标准分辨率导致识别失败);
3.系统登录:通过 SSH / 串口 / 本地终端登录开发板系统,建议使用具备图形显示权限的用户(如 blueberry)操作。
# 切换到具备图形显示权限的用户(避免权限不足导致设备访问失败) su - blueberry # 列出 /dev 目录下所有视频相关设备,确认 HDMI IN 对应的设备节点 ls -la /dev/video* |
查询结果:
-rw-rw---- 1 root video 4 Dec 2 02:18 /dev/video-dec0 -rw-rw---- 1 root video 4 Dec 2 02:18 /dev/video-enc0 crw-rw----+ 1 root video 81, 0 Dec 2 02:18 /dev/video0 |
2.查询设备详细信息
执行命令: cat /sys/class/video4linux/video0/name 输出结果: stream_hdmirx 说明: stream_hdmirx 表示这是一个视频流 HDMI 接收设备(hdmirx = HDMI Receiver) |
| 设备节点 | 设备类型 | 功能说明 | 权限 / 设备号 |
|---|---|---|---|
| /dev/video0 | 字符设备(c 开头) | HDMI 输入视频采集设备(核心) | root/video 组可读写;主设备号 81,次设备号 0 |
| /dev/video-dec0 | 普通文件 | 系统视频解码设备 | root/video 组可读写 |
| /dev/video-enc0 | 普通文件 | 系统视频编码设备 | root/video 组可读写 |
3.查询设备驱动信息:
readlink -f /sys/class/video4linux/video0/device/driver |
# 切换到具备图形显示权限的用户 su - blueberry # 配置显示环境变量(指定主屏输出),通过 GStreamer 播放 HDMI 输入视频流 gst-launch-1.0 v4l2src device=/dev/video0 ! videoconvert ! autovideosink |
Setting pipeline to PAUSED ... # 管道状态:暂停中 Using mplane plugin for capture # 采集插件:使用mplane(多平面)模式 Pipeline is live and does not need PREROLL ... # 管道状态:已激活,无需预滚动 Pipeline is PREROLLED ... # 管道状态:完成预滚动(数据已就绪) Setting pipeline to PLAYING ... # 管道状态:播放中 New clock: GstSystemClock # 时钟初始化:使用系统时钟同步 |

| 异常现象 | 可能原因 | 排查方法 |
|---|---|---|
| 终端提示 “No such device” | /dev/video0 节点不存在 | 1.检查 HDMI IN 驱动是否加载:lsmod grep rk_hdmirx
|
| 显示屏无播放窗口 | DISPLAY 环境变量配置错误 | 执行 echo $DISPLAY 确认值为 :0.0,或切换到本地终端执行命令 |
| 画面卡顿 / 花屏 | 信号源分辨率不兼容 | 将 HDMI 信号源输出分辨率调整为 1080P@60Hz 后重新测试 |
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 3.0 x4。
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 |
1.硬件连接说明
通过标准 7Pin SATA3.0 接口连接硬盘,SATA 电源支持 5V 2A 输出
2.硬盘识别与健康状态检测
# 查看硬盘信息及SMART健康状态 fdisk -l #更新软件源(可选,避免安装失败) apt update # 若提示权限不足,先提权(已 root 可跳过) # sudo apt update #安装 smartmontools apt install -y smartmontools # 注:/dev/sda为实际识别的SATA设备节点,需根据系统显示调整 smartctl -a /dev/sda |
1.设备识别状态:fdisk -l 输出中需显示 SATA 硬盘的容量、分区等信息;
2.SMART 健康状态:smartctl -a 输出中SMART overall-health self-assessment test result项需显示为PASSED(如图中红框标注项)。
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 |
验证 4G 模块对应的quectel.service服务的启动、自启配置及网络连通性。
1.检查初始状态
# 查看服务当前状态 systemctl status quectel.service # 检查开机自启配置 systemctl is-enabled quectel.service |
预期结果
服务未运行,开机自启未设置
2.启动服务
# 启动quectel服务 systemctl start quectel.service # 验证服务状态 systemctl status quectel.service |
预期结果
服务状态显示为 active (running)
3.设置开机自启
# 配置服务开机自启 systemctl enable quectel.service # 验证自启配置 systemctl is-enabled quectel.service |
预期结果
自启配置返回 enabled
4.重启验证
# 重启设备 reboot # 重启后检查服务状态 systemctl status quectel.service |
预期结果
设备重启后,服务自动运行,状态显示为 active (running)
# 检查4G模块网络接口(以eth0为例,实际需根据模块接口调整) ifconfig -a # 测试网络连通性(ping公网地址) ping -c 5 8.8.8.8 |
预期结果
4G网络接口正常获取 IP;
ping 测试成功,返回类似如下结果(无丢包):
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=109 time=60 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=109 time=60 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=109 time=60 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=109 time=60 ms 64 bytes from 8.8.8.8: icmp_seq=5 ttl=109 time=60 ms |
1.测试准备
# 步骤1:查看wwan0接口的链路状态(确认接口是否激活) ip link show wwan0 # 步骤2:查看wwan0的IP地址信息(确认网络是否获取到地址) ip addr show wwan0 # 步骤3:测试SIM网络的外部连通性(指定从wwan0接口发起请求) ping -c 4 -I wwan0 www.baidu.com |
3.结果说明
步骤 1 输出中,若wwan0状态为UP,LOWER_UP,表示接口已激活;
步骤 2 输出中,若wwan0存在inet开头的 IP 地址,说明网络已成功分配地址;
步骤 3 若返回64 bytes from xxx.xxx.xxx.xxx,表示 SIM 网络连通正常。