On Windows, reading from or writing to devices over Bluetooth—including traditional SPP “serial port” mode and BLE low-energy mode—can be divided into several steps. The following provides a general workflow overview to help you get started with development.

1. Device Pairing and Driver Preparation

1. Confirm the device can be discovered by Windows

   • For devices supporting traditional Bluetooth (SPP), you can typically search and pair in the “Bluetooth & devices” settings. After successful pairing, Windows maps the device to a virtual serial port (such as COM3, COM4, etc.).
   • For BLE devices, Windows 10 and above natively supports BLE, but discovery and pairing must still be completed in “Bluetooth & devices” (or the device can be searched and connected using BLE APIs in your application).

2. For SPP mode, confirm the virtual serial port number

   • Once pairing succeeds, the system automatically assigns one or more COM ports to the Bluetooth device. You can find the additional COM port under “Ports (COM & LPT)” in Device Manager.
   • In your application, treat this COM port as an ordinary serial port for read and write operations.

3. For BLE mode, use the BLE protocol access method

   • There is no virtual serial port number; instead, interact directly with the device’s services and characteristics through Windows GATT APIs.

2. SPP “Serial Port” Development Workflow

If you choose traditional Bluetooth SPP mode (usually more intuitive for beginners):

1. Install or confirm the device is paired on Windows and obtain the assigned COM port number.

2. Open the COM port in your application:

   • Use any language or library that supports serial port programming, such as C#’s SerialPort class, Python’s pyserial library, or C++ Win32 APIs.

3. Send and receive data:

   • The device vendor typically provides the data protocol or command format (for “pure transparent transmission,” you may simply write commands to the serial port, and the data is forwarded to the target hardware).
   • After writing commands to the serial port, read the response from the serial port.

4. Parse meter data:

   • Parse returned data according to the protocol or format—for example, how start and end markers are defined, how checksums are calculated, and how different data fields are distinguished, as documented in the protocol specification.

3. BLE Low-Energy Development Workflow

If you use BLE mode, or the device does not support SPP and only offers BLE transparent transmission, the workflow differs:

1. Scan and connect to the device at the system level or programmatically:

   • Windows 10 (UWP) and later support APIs under the Windows.Devices.Bluetooth namespace to enumerate current BLE devices and connect using the BluetoothLEDevice class.
   • You can also use C++ (Win32) or other languages (such as C# .NET 6+ combined with Windows BLE APIs) for scanning and connection.

2. Enumerate GATT services and characteristics:

   • Find the corresponding GATT Service UUID and Characteristic UUID exposed by the device.
   • For transparent transmission devices, there is typically a custom Service UUID and a readable/writable Characteristic for data transmission.

3. Perform data communication:

   • To write data over BLE, call WriteValueAsync or similar write operations on the characteristic; to read data, use ReadValueAsync or subscribe to Notification/Indication for asynchronous data reception.
   • Specific read/write methods and maximum data size per transmission depend on the device documentation (some devices support only 20 bytes per transmission and require packet splitting).

4. Parse meter data:

   • As with SPP, parse the byte stream according to the device protocol or transparent transmission format to extract required measurement values or status information.

4. Practical Recommendations

1. Starting with SPP is usually simpler:

   • If the device supports both SPP and BLE, try serial port read/write first to get up and running quickly and verify the device works correctly and data formats are accurate.
   • After gaining serial port experience, consider BLE.

2. Understand the data protocol:

   • Whether using SPP or BLE, the essence is byte stream read/write. The key is knowing which commands to send and what data format the device returns—refer to the hardware or module development documentation.
   • Without documentation, communicate with the hardware vendor or infer the protocol from existing software examples.

3. Use debugging tools effectively:

   • Serial port debugging tools: Use third-party serial tools (such as SSCOM, Termite, PuTTY, etc.) for simple read/write tests to confirm correct device responses.
   • BLE debugging tools: Try applications such as “nRF Connect for Desktop” to scan and read/write characteristics and verify BLE communication.

4. Choose your development language and framework:

   • C#: Use System.IO.Ports for serial port read/write in .NET; use classes under Windows.Devices.Bluetooth for BLE.
   • C++: Use Win32 APIs for serial port read/write and Windows BLE APIs (more complex).
   • Python or other languages: Python can use pyserial (serial port) and third-party BLE libraries (such as bleak), but BLE on Windows may require additional Bleak+WinRT bridging with slightly more complex configuration.

5. Brief Summary

1. Pair the device in Windows “Bluetooth & devices” first and confirm whether a virtual serial port was created (for SPP).
2. For SPP, treat it as an ordinary serial port and perform serial operations using your preferred language or library.
3. For BLE, call the relevant GATT APIs in your application, locate the device and its services/characteristics, and complete data transmission through BLE characteristic read/write.
4. After receiving data, parse the byte stream according to the meter protocol or transparent transmission protocol to obtain the required information.

The above provides a general starting point to help you understand the Bluetooth read/write workflow on Windows. You can then implement and debug further based on your specific programming environment and device protocol. Happy developing!