Wiznet makers

W6100 TCP Clients for Air-Quality Packets

WIZnetPicoSDK_GIA is a Raspberry Pi Pico C project that uses a WIZnet W6100 Ethernet controller to send air-quality sensor readings over wired TCP. The repository contains two Pico-side clients: one reads a Sensirion SGP41 sensor and sends VOC/NOx data to TCP port 8888, while the other reads a Sensirion SGP30 sensor and sends TVOC/eCO2 data to TCP port 8889. The technical value is visible in the code rather than the README: both clients use WIZnet ioLibrary socket calls, so the W6100 handles the TCP socket path while the Pico firmware stays focused on sensing, packet preparation, and retry behavior.

The latest repository should be read as a firmware example, not as a complete monitoring product. Earlier versions included a server.c receiver, but the current HEAD deleted that file. The client-side protocol is still clear because the payload structs, server IP, and TCP ports are hardcoded in the two clients. A separate TCP listener is required on the network target.

Code-Verified System Architecture

The top-level CMakeLists.txt selects W6100_EVB_PICO by default and defines _WIZCHIP_=W6100. The application code then configures SPI0 for the W6100 and I2C0 for the gas sensors. Both clients use static network settings and connect to 192.168.1.100, with the SGP41 client using port 8888 and the SGP30 client using port 8889.

the data path is derived from client_sgp41.c, client_sgp30.c, and the CMake board selection.

The W6100 SPI setup is explicit in each client. The code registers chip-select, byte read/write, and burst read/write callbacks with ioLibrary. It allocates socket memory for socket 0, initializes the W6100 with ctlwizchip(CW_INIT_WIZCHIP, ...), unlocks network configuration with NETUNLOCK(), and writes static network information with ctlnetwork(CN_SET_NETINFO, ...).

SGP41 Dual-Core Client

examples/client_sgp41/client_sgp41.c is the richer of the two examples. Core 0 initializes the Sensirion I2C path, performs SGP41 conditioning, reads raw VOC and NOx signals once per second, and processes them through Sensirion's Gas Index Algorithm. The resulting packet contains a measurement counter, raw VOC, raw NOx, VOC Index, and NOx Index.

The Gas Index Algorithm comes from Sensirion's public gas-index-algorithm repository. Sensirion describes it as software that calculates VOC Index and NOx Index outputs from SGP40/41 raw signals, using SRAW_VOC and SRAW_NOX as inputs. In practical terms, it does more than multiply a raw sensor value by a fixed scale. It keeps internal state, estimates the mean and variance of the raw signal over time, applies statistical gain-offset normalization, and smooths the output with an adaptive low-pass filter. In this Pico example, the SGP41 code initializes separate VOC and NOx algorithm instances and calls GasIndexAlgorithm_process() once per second, matching the default sampling interval used by the Sensirion implementation.

The network task runs on core 1. It initializes the W6100, waits for sensor packets on a Pico queue, reconnects when the W6100 socket is not established, and sends a full packed sensor_data_t payload. This split is useful because the sensor timing and the TCP connection state do not have to live in one loop.

the SGP41 path uses two RP2040 cores and a queue, while the SGP30 path is a single measurement and send loop.

SGP30 Single-Loop Client

examples/client_sgp30/client_sgp30.c is simpler. It initializes the SGP30 IAQ mode, starts a measurement once per second, reads the returned words over I2C, checks CRC bytes, prints TVOC and eCO2 to the serial console, and sends a packed struct with timestamp, tvoc, and eco2.

The SGP30 client uses the same W6100 pattern as the SGP41 client: SPI callback registration, W6100 memory initialization, static IP configuration, socket creation, connection to a fixed target, and repeated send() until the complete packet is transmitted.

W6100 Socket API Evidence

In examples/client_sgp41/client_sgp41.c, the TCP connection path uses WIZnet socket calls directly:

if(socket(ETHERNET_SOCKET, Sn_MR_TCP, 0, 0) < 0) {
    return -1;
}

if(connect(ETHERNET_SOCKET, server_ip, SERVER_PORT) != SOCK_OK) {
    close(ETHERNET_SOCKET);
    return -1;
}

Later in the same file, send(ETHERNET_SOCKET, ...) transmits the packed payload. The SGP30 client follows the same pattern with socket(), connect(), getSn_SR(), send(), and close(). That makes the W6100 usage concrete: the examples are not using a software TCP/IP stack such as lwIP for the client data path.

Current Scope and Limits

The project is useful as a compact reference for wired sensor upload, but its current scope is narrow. There is no schematic, BOM, hardware photo, SGP-specific wiring document, dashboard, data storage layer, or included TCP receiver in latest HEAD. Network parameters, MAC addresses, server IP, and ports are hardcoded. The SGP41 example also uses default humidity and temperature compensation ticks instead of measuring those values from a separate sensor.

Generated technical diagram: latest HEAD keeps the Pico clients and removes the earlier receiver source.

These limits do not remove the value of the example. They define its proper use: treat it as a starting point for a W6100-based wired air-quality node. A production monitor would need configurable network settings, documented wiring, calibrated compensation inputs, receiver software, persistence, and a more versioned packet format.

FAQ

What does this project use the W6100 for?

It uses the W6100 as the wired Ethernet controller for TCP client connections from Raspberry Pi Pico firmware. The code initializes the chip through WIZnet ioLibrary, opens TCP sockets, connects to a target IP, and sends packed sensor data with send().

Does the project include the TCP server?

Not in the latest HEAD. The clients still connect to 192.168.1.100 on ports 8888 and 8889, but the older examples/client_sgp41/server.c file was deleted in commit 1c44f1b. A user needs to provide a compatible TCP listener.

Does the project use Wi-Fi?

No. The top-level CMake file sets PICO_BOARD pico_w, but the application examples do not initialize CYW43 Wi-Fi or use a wireless network path. The data path shown in the code is wired Ethernet through the W6100.

What data is sent by the clients?

The SGP41 client sends a packed struct containing a timestamp, raw VOC, raw NOx, VOC Index, and NOx Index. The SGP30 client sends a packed struct containing a timestamp, TVOC, and eCO2.

Can the W6100 networking pattern be reused with other sensors?

Yes. The network side is mostly independent of the sensor type: initialize SPI, register W6100 callbacks, configure static network information, open a TCP socket, connect, and send a packed payload. A different I2C or SPI sensor could reuse the same W6100 client structure with a different packet format.