BACKGROUND

While physical serial ports are becoming increasingly rare on modern PCs, the serial port has persisted thanks to virtual serial port adaptors like FT232 or CP2102-based USB to UART converters. These converters play crucial roles in embedded systems, handling tasks such as data logging, code debugging, and firmware uploading to MCUs.

In a recent project, we employed a 6 DOF robotic arm for pick-and-place movements. To perform sensing and control, we placed an MCU at the top end of the robotic arm. During the firmware development phase, monitoring the serial logs from the MCU for debugging became essential. Initially, we experimented with a CP2102-based USB to TTL converter connected to the MCU and host system through a USB cable. However, we faced an issue where the USB cable connected to the host system obstructed certain movements of the robotic arm. To overcome this obstacle, we considered implementing a wireless serial connection between the MCU and the host system.

At first, we searched for available solutions in the market. There are certain Wi-Fi to Serial modules available, like this one. However, most of them serve as a bridge between Wi-Fi and the serial port. This means the user needs to connect to module via TCP from the host system or use com0com or similar tools on the host system to translate TCP data to Serial and vice versa. While, for some use cases, this might be perfectly acceptable, there isn't any ready-to-use hardware solution available to address this issue. 

This realization led us to explore the concept of creating a wireless-to-serial bridge hardware. This gave birth to the WiSer project, an acronym for Wireless Serial. Our initial goal was to meet data logging needs, but we soon recognized its potential in remote control and monitoring, remote firmware upgrades, debugging, etc.

---

THOUGHT PROCESS

Initially, we considered designing a wireless device that could be connected to the embedded target device using physical serial pins. For the host system, our plan was to develop a device driver that would connect to this wireless device using the host system's Wi-Fi adaptor. The device driver would be responsible for creating a virtual serial port on the host system and transmitting/receiving data between the virtual serial port and the wireless device using the Wi-Fi protocol. Although this was a good idea, we had concerns about the process of certifying the device driver for various operating systems and potential installation/compatibility issues. Additionally, this approach was making it mandatory for users to have a Wi-Fi adaptor on the host system.

We decided to skip this idea and opted for a two-device solution, as illustrated in the image below.

This approach eliminates the main problem of requiring a custom device driver on the host system. Since most modern operating systems already have a built-in virtual serial port driver, we decided to leverage that advantage. So, the host-side device will act as a USB device with CDC class support. The target-side device will have serial pin connections (TX, RX, RTS, CTS, etc.) tied to to target's serial pins. Both of these devices will communicate wirelessly to exchange data.

For wireless communication, we explored a few options like BLE, Wi-Fi, and Sub-GHz. Although Sub-GHz can provide a longer coverage range compared to BLE or Wi-Fi, as the operating frequency for Sub-GHz varies based on country/region, we ruled out that option. Wanting to support the maximum data speed with these devices prompted us to choose Wi-Fi, as it can provide a higher data throughput rate compared to BLE.

For Wi-Fi, there are ready-to-use Wi-Fi modules available that can be soldered onto the PCB, but we wanted to make the devices as compact as possible, and a Wi-Fi module may hinder this requirement. So, we decided to use Wi-Fi SoC directly instead of a Wi-Fi module/SoM. 

The next step was to select a Wi-Fi SoC for both devices. We went through Wi-Fi offerings from Espressif Systems, TI, and Infineon/Cypress, but in the end, we finalized the ESP32-S2 from Espressif Systems as it meets all technical requirements while remaining cost-effective.

The next decision was how data needs to be exchanged between these two devices. Initially, we thought to create a Wi-Fi access point on one device, and the second device would work in Wi-Fi station mode. The second device should automatically connect every time it's powered on. We would then also need to hide the SSID and add other security mechanisms to prevent users from connecting to this Wi-Fi access point. On top of it, we would also need to use TCP or a similar protocol to exchange the data. Going through the details of the ESP32-S2 MCU, we found out that Espressif provides a wireless communication protocol called ESP-NOW. While we definitely could implement data exchange through TCP over Wi-Fi, we found ESP-NOW to be more suitable as it offers a direct and straightforward method for establishing peer-to-peer communication. This protocol can coexist with nearby Wi-Fi and BLE devices operating on 2.4 GHz. So, we finalized on using the ESP-NOW protocol between the two devices.

---

DETAILS

With several weeks of hard work, we were able to produce these two little devices:

For setup, the user needs to insert the WiSer-USB device into the host system, connect the WiSer-TTL device to the target device, and that's it! No additional driver or software installation is required. The WiSer-USB device functions as a virtual serial port on the host system and establishes a peer-to-peer wireless connection with the paired WiSer-TTL device. The WiSer-USB device is compatible with any serial port software, such as PuTTY, Tera Term, or any other software that supports serial port communication. Users can instantly access the serial port on the host system and perform various tasks using WiSer, just like they do with a typical USB-to-serial converter.

WiSer-USB

The WiSer-USB functions as the host-side device and is equipped with the ESP32-S2 chip for data processing and wireless communication.

A BOOT button is provided to put the device into boot mode for firmware upgrades.

LEDs are incorporated to indicate TX and RX activities.

The FIND PAIR button facilitates the search of paired WiSer-TTL device, particularly useful when multiple WiSer devices are in use. It helps users identify WiSer device pairs through LED indications.

The WiSer-USB device is powered through a USB Type-C male plug when connected to the host system. The decision to use Type-C instead of Type-A was made to align with the increasing use of USB Type-C female connectors in modern computers/devices. Additionally, having a Type-C male plug enables compatibility with phones or tablets.

WiSer-TTL

The WiSer-TTL functions as the target-side device and is also equipped with the ESP32-S2 chip for processing and wireless communication.

Similarly, a BOOT button is provided to put the device into boot mode for firmware upgrades.

LEDs are incorporated to indicate TX, RX, and CONN activities.

The WiSer-TTL device can be powered in multiple ways:

1. Using the USB Type-C female connector.
2. Through dedicated header pins (J2).
3. Via castellated pins (J3).

Power through the USB Type-C female connector can be supplied from power adapters, power banks, or the host system itself using a USB Type-C cable.

Dedicated header pins are also provided to allow power supply through jumper cables.

The WiSer-TTL device can also be mounted directly to a PCB, and power supply and serial connection pins can be directly soldered to PCB traces. The image below shows such an example:

The below image shows the evolution of WiSer devices through various iterations:

---

CURRENT STATUS

The following table illustrates the currently supported serial port features on WiSer:

Host Platforms	Windows, Linux, and Mac host systems, as well as Android phones/tablets
Baud rates	Any standard or custom baudrate upto to maximum 921600 baud
Flow control	software (XON/XOFF), hardware (RTS/CTS), and None
Data bits	6-bit, 7-bit, 8-bit
Parity types	NONE, ODD, EVEN, MARK, and SPACE
Misc. Feature	Equipped with DTR control pin

We attempted to test the WiSer-USB device with an iPad and the latest iPhone equipped with a Type-C female connector, but iOS does not permit it to function as a virtual serial port. Therefore, iPad and iPhone support is not available at the moment.

The WiSer devices are presently undergoing thorough testing across different scenarios. Once testing is completed, the source code and hardware design files will be released under open-source license and uploaded to this repository.

Stay tuned for more updates on WiSer!