I. Download of Test Files & Basic Device Information

1. Test File Download

• Test music download: test.wav
• Serial port tool download: MobaXterm_Portable_v23.0_cn.zip

2. Basic Device Information

Item	Details
Device Model	RP01A‑RK3588S2 Development Board (Hardware Version: V1.0A)
System Version	Debian 12 XFCE Desktop (Firmware Version: rk3588‑rp01a‑debian12‑rkr6‑xfce‑20251230‑update‑fw.img)
Kernel Version	Linux 6.1.118

3. Hardware Configuration

Item	Configuration Details
CPU	RK3588S Octa‑core, Cortex‑A76 + Cortex‑A55  Up to 2.4GHz
GPU	Mali‑G610 GPU, supports OpenGL ES 1.1/2.0/3.2, OpenCL 2.2, Vulkan 1.2  Built‑in high‑performance 2D acceleration hardware
Memory (DDR)	LPDDR5X, optional 4G/8G/16G/32G
AI Computing Power (NPU)	6.0 TOPS
On‑board Storage	Supports eMMC 5.1, SDIO 3.0  Optional 16GB/32GB/64GB/128GB

4. Power Supply Parameters

Item	Specification
DC Power Supply Requirement	Input: 12V 2A DC  Connector Spec: 5.5mm × 2.0mm barrel power jack  ⚠️ Note: Input voltage lower than 12V may cause the device to fail to power on

II. Basic Power Supply Test

1.Power Interface Function Verification

 Verify the compatibility, electrical performance and safety of the device power interface to ensure compliance with power supply parameter requirements.

2.Adaptability of Test Environment and Tools

Tool / Environment	Specification
DC Power Adapter	12V 2A DC (compatible with 5.5mm×2.0mm interface)
Multimeter	Supports voltage / current measurement
DUT (Device Under Test)	Target product (with power interface)

3. Standard Basic Test Procedures

(1) DC Power Interface Compatibility Test

 Test Steps:
 Confirm the DC power adapter specification is "12V 2A DC" with a connector size of "5.5mm×2.0mm";
 Connect the adapter to the device power interface, and check whether the device powers on normally after energization.
 Judgment Criteria:
 The connector can be stably plugged in/unplugged, and the device powers on normally without abnormalities.

(2) Input Voltage Lower‑Limit Verification

 Test Steps:
 Use an adjustable DC power supply, set the voltage to 11.5V (lower than 12V), and connect it to the device;
 Observe whether abnormalities such as "failing to power on" occur.
 Judgment Criteria:
 The device cannot power on normally when the voltage is lower than 12V (consistent with the note in power supply parameters).

III. Wired Communication Interface Test

1.Debug Serial Port (UART) Test

Item	Content
Test Purpose	Verify the hardware communication function of the development board Debug serial port (UART), ensure it can normally output kernel boot logs, receive/respond to command‑line instructions, and meet underlying debugging requirements.
Prerequisites	1. The development board is powered off with no external power supply;  2. Prepare tools: USB‑to‑TTL serial cable (3.3V level, compatible with the board’s Debug port), PC‑side serial tools (e.g. MobaXterm, SecureCRT, Putty, Serial Assistant);  3. Confirm pin definition (TX/RX/GND) of the Debug port and check serial parameters (typical: baud rate 1500000, 8 data bits, 1 stop bit, no parity, no flow control);  4. Serial driver is installed on the PC (drivers for USB‑to‑TTL chips such as CH340/PL2303).

Step 1: Hardware Connection

According to the Debug port pinout marked in the development board manual, connect the USB‑to‑TTL serial cable correspondingly:

• Board Debug TX → Serial Cable RX
• Board Debug RX → Serial Cable TX
• Board Debug GND → Serial Cable GND

⚠️ Note: Cross‑connect TX/RX; reverse connection is strictly prohibited. Do not connect a 5V serial cable to the 3.3V‑level Debug port to avoid hardware damage.
 
Plug the USB end of the USB‑to‑TTL cable into a USB port of the PC host.

Step 2: Serial Tool Configuration on PC

Open the serial tool (taking MobaXterm as an example) and configure parameters as follows:

• Serial Port: Check Ports (COM & LPT) in Windows Device Manager and select the COM port corresponding to the serial cable (e.g. COM3).
• Baud Rate: 1500000 (default Debug port baud rate of the board, consistent with kernel boot parameters)
• Data Bits: 8
• Stop Bits: 1
• Parity: None
• Flow Control: None

Click Session → select Serial, choose the corresponding serial port and baud rate 1500000, then click OK to establish serial connection.

Step 3: Boot Log Output Test

Power on the development board and observe output on the PC‑side serial tool:
 Record complete logs from U‑Boot startup, through kernel initialization, to the system login prompt.
 Focus on checking serial‑related initialization logs such as Serial: xxx and console=ttyS2,1500000.

2. USB 2.0 / 3.0 Interface Test

(1) Device Connection Status Identification

Use the following command to confirm whether the device is connected to the system and obtain device node information:

Result Description

   
In the lsusb output:  
 

• ID 1d6b:0002 corresponds to the USB 2.0 controller
• ID 1d6b:0003 corresponds to the USB 3.0 controller

   
The USB version associated with the device can be determined by the bus it is connected to.  
 

---

2. Compatibility of the Device with the Corresponding USB Version

   
The USB version can be accurately determined by the device speed parameter:  
 

• USB 2.0: High-speed (480 Mbps)
• USB 3.0: Super-speed (5000 Mbps / 5 Gbps)

   
Procedure:  
 

1. Check the Device Speed File

2. Verification via Detailed Information

 # Check detailed parameters of the specified USB device and search for the Speed field lsusb -v | grep -E "Speed|Device"

 
Result Description: In the output, Speed: 480Mbit/s corresponds to USB 2.0, and Speed: 5000Mbit/s corresponds to USB 3.0.

---

3. Transfer Performance Test

 
The transfer rate is the core difference between USB 2.0 and USB 3.0. The theoretical rate of USB 2.0 is 480Mbps, and that of USB 3.0 is 5Gbps. Two common test methods are provided below, suitable for storage devices and network USB devices respectively.

1. Simple Test: dd Command

 
The dd command can quickly test read/write speeds, suitable for preliminary verification. The USB device must be mounted before testing.

1.1 Mount the USB Device: 

# Assuming the USB device node is /dev/sda1 confirmed by lsblk, create a mount point and mount
mkdir -p /mnt/usb
mount /dev/sda1 /mnt/usb

1.2 Test Sequential Write Speed:

# Write 1GB of zero data to the USB device, bypass cache to ensure real results
dd if=/dev/zero of=/mnt/usb/testfile bs=1M count=1024 conv=sync oflag=direct

1.3 Test Sequential Read Speed:

# Read the test file from the USB device and discard it to test read speed
dd if=/mnt/usb/testfile of=/dev/null bs=1M iflag=direct

1.4 Clean Up Temporary Files After Test:

rm /mnt/usb/testfile

Result Description: The command will display the transfer time and speed upon completion. The actual write speed of USB 2.0 is usually 10 - 30MB/s, and USB 3.0 is usually 50 - 150MB/s (affected by the device's own performance).

2. Professional Test: fio Tool

 
The fio tool supports complex IO scenario testing with more comprehensive results, suitable for in-depth performance evaluation.

2.1 Install fio:

# Ubuntu/Debian
sudo apt install fio -y

 2.2 fio Test Commands:

# Sequential Write Test
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

# Sequential Read Test
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

# Random Write Test
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

# Random Read Test
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

# Random Read/Write Mixed Test (default 50:50 ratio)
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

 

---

IV. Type-C Interface Test

1. ADB Function Test

1.1 ADB Basic Connection Test

 
Test Purpose: Verify that the Type-C interface can establish an ADB connection normally and the device can be recognized by the PC.
 
Test Steps:

1. Connect the device under test and the PC with a Type-C data cable.
2. Enable Developer Options → USB Debugging on the device.
3. Execute adb devices on the PC to check if the device is recognized.
4. Execute adb shell to verify access to the device command line.

 
Expected Results:

1. adb devices outputs the device serial number with status device.
2. Successfully enter the device shell without connection timeout or permission denial.

1.2 ADB Core Command Execution Test

 
Test Purpose: Verify that core ADB commands can be executed normally over the Type-C link.
 
Test Steps:

1. File Transfer:

   • Execute adb push test_file /data/ to push a file to the device.
   • Execute adb pull /data/test_file ./ to pull the file to the PC.

2. Device Control:

   • Execute adb reboot to restart the device, then run adb devices again after reboot.

3. Log Capture:

   • Execute adb logcat -d > adb_log.txt to capture system logs.
       
     Expected Results:

4. File transfer succeeds without failure; the pulled file matches the original size.

5. ADB connection automatically recovers after reboot.

6. Log file is not empty and contains valid runtime logs.

1.3 Type-C Plugging & Stability Test

Test Purpose: Verify the stability of the ADB connection during plugging/unplugging and cable movement.
 
Test Steps:

1. Single Plug/Unplug: Repeat 10 times, run adb devices after each.
2. Continuous Plug/Unplug: Rapidly repeat 20 times with 1–2 second intervals.
3. Movement Test: Gently shake the cable while connected and observe the connection.

Expected Results:

1. Device is recognized normally every time, no offline status.
2. ADB connection remains stable without IO errors during movement.

1.4 Type-C High-Load Stability Test

Test Purpose: Verify ADB stability under high-load scenarios.
 
Test Steps:

1. Large File Transfer: Push a 1GB file while running adb logcat.
2. Concurrent Commands: Run adb push, adb shell top, and adb logcat simultaneously.
3. Long-Term Connection: Maintain ADB connection for 24 hours, run adb devices hourly.

Expected Results:

1. ADB remains stable during large file transfers; log capture works normally.
2. No freezes or timeouts under concurrency; CPU usage ≤ 80%.
3. Connection status stays device for 24 hours without disconnection.

2. Type‑C to Hub (USB) Test

2.1 Device Recognition and Compatibility Test

 
Prerequisites:

1. The development board is powered on normally and the system startup is completed.
2. The Type‑C to USB Hub is connected properly.

 
Test Steps:

1. Insert the Type‑C end into the Type‑C port of the development board.
2. Plug USB devices (USB flash drive, mouse, keyboard) into the USB ports of the Hub in sequence.
3. Run the command lsusb to view the device list.
4. Check system logs with dmesg | grep usb.

 
Expected Results:

1. All USB devices are correctly recognized by the system, and corresponding device IDs can be seen in the lsusb output.
2. There are no USB device recognition failures or error messages in system logs.
3. The USB flash drive can be mounted/read/written normally; the mouse and keyboard can respond properly.

2.2 Data Transfer Speed Test

 
Prerequisites:

1. Same as 2.1.
2. Prepare a 1GB test file (test.img).

 
Test Steps:

1. Insert a USB 3.0 flash drive and mount it to /mnt/usb.

2. Execute the file copy command:

3. Record transmission time and calculate speed: Speed = 1024MB / Time Consumed (seconds)

4. Copy files back to the development board in reverse direction and repeat the test 3 times.

 
Expected Results:

1. Transmission speed ≥ 80MB/s (approx. 640Mbps) under USB 3.0 mode.
2. Transmission speed ≥ 30MB/s (approx. 240Mbps) under USB 2.0 mode.
3. No data loss, transmission interruption or file corruption.

2.3 Power Supply Capacity Test

 
Prerequisites:

1. Same as 2.1.
2. Prepare a 2.5‑inch portable hard disk (requiring power supply above 5V/0.5A).

 
Test Steps:

1. Plug the portable hard disk into the USB port of the Hub.
2. Check whether the hard disk indicator light is on, and run lsblk to view device nodes.
3. Perform large‑file read‑write operations for 10 minutes continuously.
4. Check system logs for under‑power or device disconnection information.

 
Expected Results:

1. The portable hard disk starts normally and can be recognized, read and written by the system.
2. No device disconnection or data corruption during long‑time read‑write operations.
3. No over‑current or power‑supply‑related errors in system logs.

2.4 Abnormal Scenario Test

1. Hot‑swap Test: Plug and unplug USB devices during data transmission to verify system stability.
2. Low‑voltage Test: Reduce the power supply voltage of the development board to 4.5V to verify whether USB devices work normally.
3. Multi‑device Concurrency Test: Plug in multiple USB devices simultaneously to verify the load capacity of the Hub.

3. Type‑C to HDMI/DP Output Test

3.1 Video Output Function Test

Prerequisites:

1. The development board is powered on normally and the system startup is completed.
2. The Type‑C‑to‑HDMI/DP adapter is properly connected, and the monitor is powered on.

Test Steps:

1. Insert the Type‑C end into the Type‑C port of the development board, and connect the HDMI/DP end to the monitor.
2. Execute display configuration commands (Linux: xrandr; Android: System Settings).
3. Switch display output to HDMI and set the resolution to 1080P@60Hz.
4. Observe the monitor screen and check for screen tearing, black screen or flickering.

Expected Results:

1. The monitor lights up automatically and displays the development board desktop/image.
2. Resolution and refresh rate can be configured normally with clear and undistorted images.
3. No screen tearing, black screen, flickering or lag.

3.2 Audio‑Video Synchronous Output Test

Prerequisites:

1. Same as 3.1.
2. The monitor supports HDMI/DP audio output.

Test Steps:

1. Play a 1080P test video (with audio track).
2. Observe video smoothness and listen to the monitor speaker simultaneously.
3. Check audio‑video synchronization and whether there is noise or audio dropout.

Expected Results:

1. Smooth video playback with stable frame rate (≥30fps).
2. Audio‑video synchronization with no delay or stuttering.
3. Clear sound with no noise, audio dropout or popping noise.

3.3 Hot‑Plug Test

Prerequisites:
 Same as 3.1.
 
Test Steps:

1. Connect the Type‑C‑to‑HDMI/DP adapter first and confirm normal display.
2. Unplug the HDMI/DP end and observe system response.
3. Re‑insert the HDMI/DP end and observe system response.
4. Repeat hot‑plug operation 10 times and record each result.

Expected Results:

1. After unplugging HDMI/DP, the system automatically switches back to on‑board display or goes black (consistent with design expectations).
2. After re‑insertion, the monitor automatically resumes display without manual configuration.
3. No system crash or driver errors occur during hot‑plugging.

3.4 Abnormal Scenario Test

1. Resolution Switching Test: Switch among 720P/1080P/4K to verify display compatibility.
2. Long‑Duration Playback Test: Play video continuously for 24 hours to verify stability.
3. Low‑Resolution Output Test: Set resolution to 480P to verify downward compatibility.

IV. Display and Video Interface Test

1. HDMI Output Test

1. Specification Description

Interface	Core Specifications	Key Limitations
HDMI 2.1	Single‑port, supports 8K@30Hz / 4K@60Hz, HDCP2.3	Requires HDMI 2.1 certified cable; maximum bandwidth 48Gbps

2. Resolution Verification (Including 8K/4K)

1. Query of Display Interfaces and Resolution List

2.Audio Output Test Steps (Command-Line Operation)

2.Camera Function Test

Item	Content
Test Purpose	Verify the hardware connection validity and video capture function of the development board’s MIPI‑CSI / USB camera interface.
Prerequisites	1. The development board is powered on and enters the Linux system.  2. The camera is properly connected (MIPI‑CSI cable is firmly inserted).

Test Steps:
 
Step 1: Camera Device Node Identification Test

1. Open the terminal and run the following command to check whether the system recognizes the camera device:

测试步骤： 步骤1：摄像头设备节点识别测试 1.打开终端，执行以下命令查看系统是否识别到摄像头设备：

2.[Supplementary Verification] Execute the following commands to confirm device availability (optional, for enhanced rigor):

Step 2: Camera Real-Time Preview Test

1. Connect the development board to an HDMI monitor, and execute the following command for real-time preview:

Observe the picture on the HDMI monitor, press Ctrl + C to stop the command after continuous preview for 10 seconds.
 Expected Result: Clear and smooth real‑time video appears on the HDMI monitor without screen tearing, stuttering or black screen; no core errors such as "Internal data stream error" are displayed in the terminal after stopping the command.

3. Video Hard Decoding Performance Test

1. Test Environment (MPP Video Hard Decoding Device)
    Hard decoding tool information based on Rockchip MPP (Media Process Platform) framework:

Item	Details
Tool Name	ppvidedec
Tool Version	1.14.4
Dependency Library Path	/usr/lib/aarch64-linux-gnu/gstreamer-1.0/libgstrockchipmpp.so
Supported Encoding Formats	HEVC/H.265, AVC/H.264, VP8, VP9
Decoding Type	Hardware‑accelerated decoding
Maximum Decoding Capability	8K 10‑bit video decoding, supports 8K@60Hz video output

Test Steps:  
 2.1 Prepare test videos:

 2.2.Perform hardware decoding test (take H.264 format as an example)

2.3 Test Verification Points

 Video playback status: No abnormalities such as screen tearing, green screen, or stuttering shall occur;
 Log information: No errors including decode error, Resource not found, or pipeline doesn't want to preroll shall appear in the terminal output. A normal startup process shall be displayed (example shown below);
 Display effect: After executing the playback command, the display interface shall present a complete and clear video image (no image distortion or color distortion caused by decoding exceptions).
 
Example of normal log output (description)

(Note: The attached picture is an example of the interface during normal video playback, which can intuitively verify that the picture is free of distortion and displayed normally.)

3. Open a second terminal to monitor CPU usage

3.1 Operation Steps

  3.2 Example of system status output (the following content is displayed after terminal execution; core monitoring items are marked in the red box)

 3.3 Status Analysis

 

Monitoring Item	Result	Description
Overall CPU Load	User 3.8% + System 6.0% + Idle 90.2%	Idle ratio exceeds 90%, sufficient CPU resource redundancy; current high-ratio processes are desktop services (Xorg, xfwm4), belonging to basic system load
Memory Status	Total 3899MB, Used 829MB, Free 2968MB	Sufficient remaining memory, no risk of insufficient memory
Key Process CPU Ratio	Desktop Service (Xorg) 50%, Terminal (tilda) 12.5%	When running the video playback process, focus on its % CPU value (usually <10% when hardware decoding takes effect)
Memory Usage	Used 829MB, Cache 2864MB	High memory cache ratio ensures efficient system data read/write

3.4 Test Conclusion: The video plays normally without stuttering or screen tearing. The CPU usage is low (hardware decoding acceleration is effective), and the system resource load meets expectations.

V. Audio Interface Test

This test targets the device’s audio output interfaces (including onboard Codec and HDMI), and clarifies the hardware mapping relationship of each interface:

Sound Card Number (card)	Device Identifier	Device Number (device)	Hardware Correspondence	Core Function	Application Scenario
card 0	rockchip,es8388‑codec	device 0	On‑board ES8388 audio Codec	Analog audio output (3.5mm headphone/speaker) + audio decoding	Headphone playback (core device)
card 1	rockchip,hdmi0	device 0	HDMI interface audio channel	Digital audio output (HDMI monitor/TV)	HDMI audio playback

1. Test Preparation

1.1 Tools / Files

 
Test audio file: test.wav (recommended format: 16bit, 44.1kHz, stereo)
 
Debugging tools:

• PC side: adb (environment variables required)
• Device side: aplay (pre‑installed)

1.2 Hardware Connection

• For HDMI audio test: Connect an HDMI cable between the device’s HDMI port and an audio‑enabled display device (e.g., a monitor with built‑in speakers).
• For onboard audio test: Plug a 3.5 mm headphone into the onboard audio jack.

1. Audio Output Function Verification

Test Result Recording

Test Item	Operation Command	Expected Result
HDMI0 Audio Output	aplay -D plughw:1,0 /test.wav	Audio plays normally on the display device
On‑board Headphone Output	aplay -D plughw:0,0 /test.wav	Audio plays normally through headphones
Hardware Sine Wave Test	speaker-test -D hw:1,0 -t sine -f 1000 -c 2 -l 2	Beep sound outputs from headphones

2. Audio Input Function Verification

1. List all audio capture devices

2.Typical Output Example

3. Result Analysis

Device Type	Device Name / Driver	Device Number (device)	Hardware Correspondence	Core Function	Available for Headphone Playback
card 0	rockchip,es8388‑codec	device 0	On‑board ES8388 codec	Audio decoding / analog output (3.5 mm headphone / line‑out)	✅ Yes (core headphone device)
card 2	rockchip,es7210	device 0	ES7210 ADC	4‑channel audio capture (microphone / line‑in)	❌ No (input‑only)

4.Recording Test (Real-time Capture + Playback)

Test Operations and Result Verification

 Execute Command: Enter the above command in the terminal and press Enter.
 Trigger Audio Input: Speak into the MIC or play audio.
 Verify Effect: Real‑time captured sound can be heard from audio output devices (speakers/headphones). The test passes if there is no noise, stuttering or delay (<200 ms).
 Stop Test: Run kill %1 (background task ID) to terminate real‑time capture.

Notes

• If the error Device or resource busy occurs: Run killall arecord aplay first to close processes occupying audio devices, then retest.
• If no sound is heard: Check the device ID for the -D parameter (confirm correct input/output devices via arecord -l/aplay -l).
• If there is excessive noise: Change -c 2 to -c 1 (mono), or adjust the sampling rate to 44100.

VI. Storage Interface Test

M.2 Interface Test

1. Hardware Information Integrity

 Interface Type: PCIE 2.0 ×1 M.2 M‑Key, 5 Gbps
 Hardware Installation: Insert the M.2 SSD into the M.2 slot on the development board.

2. Basic Connection Validity

1. Device Identification Verification

Expected Result: The corresponding disk device of the SSD (e.g., nvme0n1) is displayed in the output.

2.Disk Information Reading

Expected Result: Display SSD capacity, partition table type (e.g., GPT), PCIe x4 bus and NVMe storage protocol.
 3. Read‑Write Performance Test

VII. Wireless Communication Module Test

1. Wi‑Fi Test

1. Hardware Specification Compliance

 
Wi‑Fi Model: AP6256, dual‑band Wi‑Fi 5 wireless network access compliant with IEEE 802.11a/b/g/n/ac.
 2. Basic Connection Stability

1. Start the NetworkManager Service

2.Scan and connect to Wi‑Fi networks

3.Network Connectivity Test

4.Sample Commands

3. Wi-Fi Network TCP/UDP Protocol Performance Test

1. Environment Preparation:

Two test devices (e.g., development board + PC), ensure they are on the same network (Wi-Fi/Ethernet);
 
Install Iperf3

3.Wi-Fi 网络 TCP/UDP 协议性能测试 1.环境准备： 两台测试设备（如开发板 + PC），确保处于同一网络（WiFi / 以太网）； 安装 Iperf3

2. Role Definition

 Server: Device receiving data
 Client: Device sending data

3. TCP Bandwidth Test (Commonly Used)

 
Step 1: Start the server

Step 2: Initiate the test from the client

Extended Commands (Custom Parameters)

Extended Commands (Custom Parameters)

Test for 30 seconds, output real‑time data every 2 seconds

 
iperf3 -c [Server IP] -t 30 -i 2
 Test bidirectional bandwidth (data transmission between server and client)

 
iperf3 -c [Server IP] -d

4. UDP Packet Loss / Latency Test

 Step 1: Start the server
 iperf3 -s
 
Step 2: Initiate test from the client

Test UDP (bandwidth limited to 100 Mbps)

 
iperf3 -c [Server IP] -u -b 100M

5. Result Interpretation (Examples)

TCP Test Result

 [ 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 # Actual bandwidth: 943 Mbps

UDP Test Result

 [ 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%) # Packet loss rate: 0%

6. Common‑Scenario Tests

 
表格
 
 

Test Target	Sample Command
Long‑connection stability (1 hour)	iperf3 -c [IP] -t 3600
Multi‑thread concurrency test	iperf3 -c [IP] -P 4 (4 threads)
Bandwidth‑limited test	iperf3 -c [IP] -b 500M (limited to 500 Mbps)

2. Bluetooth Connection Test

1. Hardware Description

 
AP6256 is a Wi‑Fi 5 + Bluetooth dual‑mode module launched by AMPAK, supporting Bluetooth 5.2.

2. Enter Bluetooth Command Mode

Connect to the device via ADB

 
adb shell

Launch Bluetooth control utility

 
sudo bluetoothctl

3. Scan and Connect Bluetooth Devices

 scan on # Enable Bluetooth scanning (press Ctrl+C to stop scanning)
 trust [Device MAC Address] # Trust the target device
 pair [Device MAC Address] # Pair with the target device
 connect [Device MAC Address] # Connect to the target device

4. Operation Example

Perform operations on the device with MAC 7C:B4:37:11:5B:83 after scanning

 trust 7C:B4:37:11:5B:83
 pair 7C:B4:37:11:5B:83
 connect 7C:B4:37:11:5B:83

5. Test Result Judgment

 
After executing the connect command, the terminal outputs [CONN] Device 7C:B4:37:11:5B:83 Connected: yes, indicating successful Bluetooth connection.