Wiznet makers

Overview

How can a serial field sensor reach a cloud Internet of Things (IoT) service without making the sensor itself speak Ethernet or MQTT? CN114268520A proposes a compact answer: receive sensor data through a 485 interface, pass it to a GD32F303CET6 microcontroller, package the data for MQTT, a lightweight publish/subscribe messaging protocol, and send it through a WIZnet W5500 wired Ethernet path.

Generated illustration: the article cover also serves as a visual introduction to the field-to-cloud protocol bridge.

The filing presents this as a Modbus-to-MQTT gateway. Its practical attraction is the boundary it creates between existing field wiring and cloud messaging. Sensors can remain on a familiar serial network, while the gateway handles protocol packaging and the wired network connection.

Direct answer: The disclosed GD32 microcontroller packages acquired data as MQTT. W5500 then carries that MQTT-formatted data toward the cloud over wired Ethernet using the TCP/IP network stack.

This is a system concept from a published patent application, not a released board or tutorial. That distinction matters because the source names the core parts and data path, but does not provide firmware, a schematic, a bill of materials, cloud configuration, or test results.

Who Filed It and What Happened Next

The application was filed on December 22, 2021, and published on April 1, 2022. The applicant is 蚌埠学院, whose official English site uses the name Bengbu University. Google Patents renders the institution as Bengbu College. The six named inventors are Huang Kaining, Li Chuang, Shi Yan, Fan Wentian, Jia Yu, and Chen Bin.

The university's current Computer and Information Engineering faculty directory lists Huang Kaining and Shi Yan as associate professors in its IoT Engineering teaching section. This places the application within an active IoT teaching environment.

Source-mapped graphic: dates and status events from the Google Patents record, observed July 27, 2026.

Google Patents' summary still shows Pending, while its legal-events table records RJ01, rejection after publication, on March 22, 2024. No B grant publication appears in the listed family. Two later Chinese patent families list this application through examiner citations, extending the topic into the subsequent patent landscape.

Why This Field-to-Cloud Bridge Matters

RS-485, Modbus, MQTT, and Ethernet are related here, but they are not interchangeable terms. RS-485 defines an electrical serial link. Modbus gives devices a field-level application protocol. MQTT is a lightweight publish/subscribe messaging protocol for networked systems. W5500 supplies the hardwired TCP/IP and Ethernet transport used after the gateway has prepared the MQTT-formatted data.

That separation is useful when older sensors or controllers must join a cloud workflow. A gateway can preserve the field bus while translating the collected values into a format the cloud side expects. It also creates one place to manage Ethernet addressing, reconnect behavior, message mapping, and security.

The patent does not specify the Modbus variant, register map, serial settings, MQTT version, broker, topic, payload, Quality of Service (QoS), authentication, or Transport Layer Security (TLS). Those choices would be central to any production implementation, but they should not be invented from this source.

The Data Path Disclosed in the Filing

The only drawing in the official PDF is Figure 1, a four-stage method flow. It begins with sensor collection, passes through 485-level conversion and the gateway MCU, names W5500 for transmission to a cloud IoT platform, and ends with cloud-side analysis and display.

Official source image: Figure 1 from CN114268520A. The Chinese boxes describe sensor collection, gateway packaging, W5500 transmission, and cloud analysis.

The claims make the component chain more specific:

1. A sensor collects a value.
2. A generic sensing-side 485 chip produces the RS-485 electrical level.
3. A gateway-side 485 chip converts the received level to a transistor-transistor logic (TTL) level.
4. The GD32F303CET6 packages the collected data in MQTT format.
5. W5500 sends the formatted data to a cloud IoT platform.
6. A cloud-side product or device is registered, then the data is analyzed and displayed.

Source-mapped graphic: the disclosed data path, with undocumented wiring, protocol, security, and cloud details kept outside the claimed chain.

SHT20 appears in the description as an example temperature and humidity sensor, not as a required claim element. Sensirion identifies SHT20 as a digital I2C sensor, while the patent describes only a sensor and a generic 485 chip on the sensing side. A complete hardware design would add a sensor-side controller or bridge.

Architecture boundary: The patent gives a credible block-level direction. It does not give enough electrical or software detail to wire an SHT20 directly to RS-485 or reproduce the gateway.

What W5500 Actually Contributes

The patent assigns two different jobs to the gateway's named chips. The GD32F303CET6 prepares the MQTT-formatted data. W5500 provides the wired network route that transports it to the cloud.

Source-mapped graphic: official WIZnet device facts surround the wired transport role named by the patent.

WIZnet's official documentation describes W5500 as a hardwired TCP/IP controller with integrated 10/100 Ethernet media access control (MAC) and physical-layer (PHY) blocks, a Serial Peripheral Interface (SPI) host interface, eight hardware sockets, and 32 KB of packet memory. The application leaves socket allocation and the software library as implementation choices.

Source-mapped graphic: each layer's job is separated so that protocol conversion is not incorrectly attributed to W5500.

The patent does not identify the GD32-to-W5500 interface or pins. It also does not describe an MQTT client library, socket allocation, IP configuration, DHCP, retry policy, or network security. The source-backed engineering lesson is the division between application packaging and wired TCP/IP transport.

WIZnet role: W5500 is the Ethernet transport engine in this architecture. It is not presented as the Modbus parser, MQTT application logic, or machine-learning processor.

How the Proposed Cloud Analysis Works

After the data reaches the cloud, the filing proposes a condition-monitoring method built around historical qualified sensor data and key influencing factors. Each historical record becomes a coordinate containing the measured value and its factors.

The analysis then combines two techniques:

1. Historical coordinates are clustered with K-means, and the resulting regions define qualified intervals.
2. A separate convolutional neural network (CNN) or deep neural network (DNN) receives preprocessed grayscale images of coordinate plots and predicts the cluster count k.
3. K-means uses that k to form the qualified regions.
4. New sensor coordinates are compared with those regions and shown in a table or graph.

Generated illustration: the CNN/DNN is shown helping select the K-means cluster count, not directly classifying a sensor fault.

That role boundary is easy to miss. The neural network is not described as the final fault classifier. It selects k for K-means from an image of the coordinate plot. The filing supplies no dataset, sample count, model architecture, training split, code, model artifact, accuracy, latency, or runtime environment.

The published Chinese text also repeats the same outside the qualified interval condition for both the fault and normal outcomes. An implementation would need to clarify the normal-state rule instead of silently choosing one interpretation.

Engineering Value and Source Limits

The reusable idea is a clean system partition: keep field sensors on a serial bus, let an MCU translate collected values into MQTT messages, use a hardwired Ethernet controller for the cloud path, and keep more expensive historical analysis on the cloud side. This pattern can inform environmental monitoring, equipment rooms, buildings, utilities, and industrial retrofits where wired field devices already exist.

Bengbu University's current IoT curriculum and later sensing research place this gateway concept within a broader institutional focus on connected sensing and control.

The missing implementation package remains substantial: no 485 transceiver model, sensor bridge, schematic, PCB, firmware, Modbus map, MQTT schema, cloud API, dataset, trained model, benchmark, deployment, or independent validation is public with the filing.

Source limit: Treat CN114268520A as an architecture reference for a W5500-enabled Modbus-to-MQTT gateway, not as a validated product or build-ready design.

Related WIZnet Maker Reading Path

For the closest implemented gateway comparison, read SRT-MGATE-1210 Modbus IIoT Gateway. It combines an ESP32-S3, two RS-485 ports, W5500 Ethernet, MQTT and HTTP, setup tools, failover, OTA, and source context. It shows the provisioning and field-integration decisions that this patent leaves open.

Industrial IoT Gateway (Field-to-Cloud) Using Dual-Port SP23 is useful when network separation matters. Its real SP2302 implementation places W5500/WIZ850io on the isolated Modbus TCP side and uses a second Ethernet interface for cloud MQTT traffic.

For an algorithmic contrast, Advanced Real-Time Diagnosis of Broken Rotor Bar Faults in Induction Motors uses W5500 to stream current data from an FPGA to a PC for deterministic signal analysis. It reaches a fault-monitoring goal without the Modbus, MQTT, and cloud-clustering path proposed here.

Source-Backed Summary

CN114268520A describes a gateway that receives sensor data through 485 interfaces, uses GD32F303CET6 to package it in MQTT format, and relies on W5500 for the wired Ethernet path to a cloud IoT platform. Cloud analysis then proposes K-means qualified regions, with CNN/DNN used only to select k from a processed coordinate image.

Its value is the separation of field protocol handling, MQTT packaging, Ethernet transport, and cloud analysis. Its limits are equally clear: one flowchart, no implementation files, no reproducible ML package, a contradictory normal/fault condition, and a legal-events record that shows rejection after publication.

FAQ

Q. Is CN114268520A a commercial W5500 gateway? No. It is a published Chinese patent application that describes an architecture. No product page, PCB, firmware, prototype photo, or deployment was found.

Q. Does W5500 perform the Modbus-to-MQTT conversion? The filing assigns MQTT packaging to the GD32F303CET6. W5500 carries the formatted data over wired Ethernet and TCP/IP.

Q. Is SHT20 required? No. SHT20 is an example sensor in the description. The claims use a generic sensor and generic 485 interface.

Q. Does the neural network detect sensor faults directly? Not as disclosed. CNN/DNN predicts the K-means cluster count k; new sensor coordinates are then compared with qualified cluster regions.

Q. Can this application be reproduced from the public filing? Not completely. The source omits the sensor-side bridge, exact wiring, firmware, protocol settings, security design, cloud API, dataset, trained model, and validation results.

한국어 (Korean)

개요

직렬 방식의 현장 센서가 Ethernet이나 MQTT를 직접 지원하지 않아도 클라우드 사물인터넷(IoT) 서비스에 연결할 수 있을까요? CN114268520A는 간결한 구조를 제안합니다. 485 인터페이스로 센서 데이터를 받고, GD32F303CET6 마이크로컨트롤러가 경량 publish/subscribe 메시징 프로토콜인 MQTT 형식으로 데이터를 패키징한 다음, WIZnet W5500 유선 Ethernet 경로로 전송합니다.

생성 일러스트레이션: 기사 커버를 현장-클라우드 프로토콜 브리지의 시각적 도입부로 함께 사용했습니다.

출원 문서는 이를 Modbus-to-MQTT 게이트웨이로 설명합니다. 기존 현장 배선과 클라우드 메시징 사이에 명확한 경계를 만든다는 점이 실용적입니다. 센서는 익숙한 직렬 네트워크에 그대로 두고, 게이트웨이가 프로토콜 패키징과 유선 네트워크 연결을 담당합니다.

핵심 답변: 공개된 구조에서는 GD32 마이크로컨트롤러가 수집 데이터를 MQTT 형식으로 패키징합니다. W5500은 그 데이터를 유선 Ethernet과 TCP/IP 네트워크 스택으로 클라우드에 전달합니다.

이 자료는 공개 특허출원에 담긴 시스템 개념이며 출시된 보드나 튜토리얼이 아닙니다. 핵심 부품과 데이터 경로는 명시하지만, 펌웨어, 회로도, 부품표, 클라우드 설정, 테스트 결과는 제공하지 않습니다.

출원 주체와 이후 공개 이력

이 출원은 2021년 12월 22일 제출되어 2022년 4월 1일 공개됐습니다. 출원인은 蚌埠学院이며 공식 영문 사이트는 기관명을 Bengbu University로 표기합니다. Google Patents는 Bengbu College로 번역합니다. 발명자는 Huang Kaining, Li Chuang, Shi Yan, Fan Wentian, Jia Yu, Chen Bin 등 6명입니다.

대학의 현재 Computer and Information Engineering 교수진 페이지는 Huang Kaining과 Shi Yan을 IoT Engineering 교원으로 소개합니다. 이 출원은 현재의 IoT 교육 환경과도 자연스럽게 연결됩니다.

출처 기반 그래픽: 2026년 7월 27일 확인한 Google Patents의 날짜와 상태 이벤트를 정리했습니다.

Google Patents 상단 요약에는 Pending이 남아 있지만 법적 이벤트 표에는 2024년 3월 22일 공개 후 거절을 뜻하는 RJ01이 기록돼 있습니다. 특허 패밀리에는 B 등록 공보가 보이지 않습니다. 이후 두 개의 중국 특허 패밀리가 이 출원을 심사관 인용으로 참조하며 후속 특허 지형으로 주제를 이어갑니다.

현장-클라우드 브리지가 필요한 이유

RS-485, Modbus, MQTT, Ethernet은 이 구조에서 연결되지만 같은 개념은 아닙니다. RS-485는 전기적 직렬 링크를 정의합니다. Modbus는 장치 사이의 현장 응용 프로토콜입니다. MQTT는 네트워크 시스템을 위한 경량 publish/subscribe 메시징 프로토콜입니다. W5500은 게이트웨이가 MQTT 형식 데이터를 준비한 뒤 사용하는 하드와이어드 TCP/IP 및 Ethernet 전송을 제공합니다.

이 역할 분리는 오래된 센서나 컨트롤러를 클라우드 워크플로에 연결할 때 유용합니다. 게이트웨이는 현장 버스를 유지하면서 수집 값을 클라우드가 처리할 메시지로 바꿀 수 있습니다. Ethernet 주소, 재연결 동작, 메시지 매핑, 보안을 한곳에서 관리할 수도 있습니다.

특허는 Modbus 변형, 레지스터 맵, 직렬 설정, MQTT 버전, 브로커, 토픽, 페이로드, 서비스 품질(QoS), 인증, 전송 계층 보안(TLS)을 명시하지 않습니다. 실제 제품에서는 중요한 선택이지만 이 출원만으로 임의로 채울 수는 없습니다.

출원 문서에 공개된 데이터 경로

공식 PDF의 유일한 도면은 4단계 방식 흐름을 담은 Figure 1입니다. 센서 수집에서 시작해 485 레벨 변환과 게이트웨이 MCU를 지나고, W5500을 통해 클라우드 IoT 플랫폼으로 전송한 뒤 분석과 표시로 끝납니다.

공식 출처 이미지: CN114268520A Figure 1입니다. 중국어 상자는 센서 수집, 게이트웨이 패키징, W5500 전송, 클라우드 분석을 설명합니다.

청구항은 부품 연결을 더 구체적으로 적습니다.

1. 센서가 값을 수집합니다.
2. 센싱 모듈의 일반적인 485 chip이 RS-485 전기 레벨을 만듭니다.
3. 게이트웨이의 485 chip이 수신 레벨을 TTL 논리 레벨로 변환합니다.
4. GD32F303CET6이 수집 데이터를 MQTT 형식으로 패키징합니다.
5. W5500이 형식화된 데이터를 클라우드 IoT 플랫폼에 전송합니다.
6. 클라우드에서 제품 또는 장치를 등록하고 데이터를 분석해 표시합니다.

출처 기반 그래픽: 공개된 데이터 경로만 연결하고 배선, 프로토콜, 보안, 클라우드 세부 사항은 미공개 항목으로 남겼습니다.

SHT20은 상세 설명에 온습도 센서 예시로 등장하며 필수 청구 요소가 아닙니다. Sensirion은 SHT20을 디지털 I2C 센서로 설명하지만, 출원은 센서 쪽에 센서와 일반적인 485 칩만 적습니다. 완전한 하드웨어 설계에서는 센서 측 컨트롤러나 브리지를 추가해야 합니다.

아키텍처 경계: 이 특허는 블록 수준의 방향을 제시하지만 SHT20을 RS-485에 직접 배선하거나 동일한 게이트웨이를 재현할 만큼의 전기·소프트웨어 세부 정보는 제공하지 않습니다.

W5500이 실제로 담당하는 역할

특허는 게이트웨이의 두 핵심 칩에 다른 역할을 부여합니다. GD32F303CET6은 MQTT 형식 데이터를 준비하고, W5500은 이를 클라우드까지 운반하는 유선 네트워크 경로를 제공합니다.

출처 기반 그래픽: WIZnet 공식 부품 정보와 특허가 명시한 유선 전송 역할을 함께 정리했습니다.

WIZnet 공식 문서는 W5500을 10/100 Ethernet 매체 접근 제어(MAC)와 물리 계층(PHY), 직렬 주변기기 인터페이스(SPI), 하드웨어 소켓 8개, 32 KB 패킷 메모리를 통합한 하드와이어드 TCP/IP 컨트롤러로 설명합니다. 소켓 할당과 소프트웨어 라이브러리는 실제 구현에서 선택할 항목입니다.

출처 기반 그래픽: 프로토콜 변환을 W5500 역할로 잘못 해석하지 않도록 각 계층의 기능을 분리했습니다.

특허는 GD32와 W5500 사이의 인터페이스나 핀을 명시하지 않습니다. MQTT 클라이언트 라이브러리, 소켓 할당, IP 설정, DHCP, 재시도 정책, 네트워크 보안도 설명하지 않습니다. 원문으로 확인되는 엔지니어링 가치는 응용 패키징과 유선 TCP/IP 전송의 역할 분리입니다.

WIZnet 역할: 이 구조에서 W5500은 Ethernet 전송 엔진입니다. Modbus 파서, MQTT 응용 로직, 머신러닝 프로세서로 제시되지 않습니다.

제안된 클라우드 분석 방식

데이터가 클라우드에 도착하면 출원은 과거의 qualified 센서 데이터와 주요 영향 요인을 사용하는 상태 모니터링 방식을 제안합니다. 각 과거 레코드는 측정값과 영향 요인을 포함한 좌표로 바뀝니다.

분석은 두 기법을 결합합니다.

1. 과거 좌표를 K-means로 군집화하고 그 영역을 적격 구간으로 정합니다.
2. 별도의 합성곱 신경망(CNN) 또는 심층 신경망(DNN)이 전처리된 좌표 플롯의 흑백 이미지를 받아 군집 수 k를 예측합니다.
3. K-means는 그 k로 적격 영역을 만듭니다.
4. 새 센서 좌표를 해당 영역과 비교하고 표나 그래프로 표시합니다.

생성 일러스트레이션: CNN/DNN은 센서 고장을 직접 분류하지 않고 K-means 군집 수 선택을 돕는 것으로 표현했습니다.

이 역할 경계는 놓치기 쉽습니다. 신경망은 최종 고장 분류기로 설명되지 않습니다. 좌표 플롯 이미지에서 K-means의 k를 고르는 역할입니다. 출원은 데이터셋, 샘플 수, 모델 구조, 학습 분할, 코드, 모델 파일, 정확도, 지연시간, 실행 환경을 공개하지 않습니다.

중국어 공개 원문은 고장과 정상 결과에 같은 적격 구간 밖 조건을 반복합니다. 실제 구현에서는 어느 한쪽을 임의로 선택하지 말고 정상 상태 규칙을 명확히 해야 합니다.

엔지니어링 가치와 자료 한계

재사용하기 좋은 핵심은 시스템 분할입니다. 현장 센서는 직렬 버스에 유지하고, MCU가 수집 값을 MQTT 메시지로 변환하며, 하드와이어드 Ethernet 컨트롤러가 클라우드 경로를 담당하고, 계산량이 큰 과거 분석은 클라우드에 둡니다. 환경 모니터링, 설비실, 빌딩, 유틸리티, 산업 설비 개조처럼 기존 유선 현장 장치가 있는 곳에서 참고할 수 있는 패턴입니다.

Bengbu University의 현재 IoT 교육과 이후 센싱 연구는 이 게이트웨이 개념을 연결형 센싱과 제어라는 더 넓은 기관 연구 맥락에 놓습니다.

미공개 구현 항목은 많습니다. 485 트랜시버 모델, 센서 브리지, 회로도, PCB, 펌웨어, Modbus 맵, MQTT 스키마, 클라우드 API, 데이터셋, 학습 모델, 벤치마크, 배치 사례, 독립 검증이 공개 패키지에 없습니다.

자료 한계: CN114268520A는 W5500 기반 Modbus-to-MQTT 게이트웨이의 아키텍처 참고 자료로 보는 것이 적절하며, 검증된 제품이나 바로 제작 가능한 설계로 볼 수는 없습니다.

함께 읽으면 좋은 WIZnet Maker 글

가장 가까운 실제 게이트웨이 비교는 SRT-MGATE-1210 Modbus IIoT Gateway입니다. ESP32-S3, RS-485 포트 2개, W5500 Ethernet, MQTT와 HTTP, 설정 도구, 장애 우회, OTA, 소스 맥락을 결합합니다. 특허가 비워 둔 프로비저닝과 현장 통합 결정을 확인할 수 있습니다.

네트워크 분리가 중요하다면 Industrial IoT Gateway (Field-to-Cloud) Using Dual-Port SP23이 유용합니다. 실제 SP2302 구현에서 W5500/WIZ850io는 격리된 Modbus TCP 측을 담당하고, 두 번째 Ethernet 인터페이스는 MQTT 클라우드 트래픽을 맡습니다.

알고리즘 관점의 대조 사례로는 Advanced Real-Time Diagnosis of Broken Rotor Bar Faults in Induction Motors가 있습니다. FPGA의 전류 데이터를 W5500으로 PC에 스트리밍해 결정론적 신호 분석을 수행합니다. 여기서 제안한 Modbus, MQTT, 클라우드 군집 경로 없이 고장 모니터링 목표에 접근합니다.

소스 기반 요약

CN114268520A는 485 인터페이스로 센서 데이터를 받고, GD32F303CET6이 MQTT 형식으로 패키징하며, W5500이 유선 Ethernet 경로로 클라우드 IoT 플랫폼에 전달하는 게이트웨이를 설명합니다. 클라우드 분석은 K-means 적격 영역을 제안하며, CNN/DNN은 전처리한 좌표 이미지에서 k를 선택하는 역할만 맡습니다.

가치는 현장 프로토콜 처리, MQTT 패키징, Ethernet 전송, 클라우드 분석의 역할 분리에 있습니다. 한계도 분명합니다. 도면은 흐름도 1장뿐이고 구현 파일과 재현 가능한 ML 패키지가 없으며, 정상·고장 조건이 모순되고 공개 후 거절 이벤트가 기록돼 있습니다.

FAQ

Q. CN114268520A는 상용 W5500 게이트웨이인가요? 아닙니다. 아키텍처를 설명하는 공개 중국 특허출원입니다. 제품 페이지, PCB, 펌웨어, 시제품 사진, 배치 사례는 확인되지 않았습니다.

Q. W5500이 Modbus-to-MQTT 변환을 수행하나요? 출원은 MQTT 패키징을 GD32F303CET6에 할당합니다. W5500은 형식화된 데이터를 유선 Ethernet과 TCP/IP로 운반합니다.

Q. SHT20이 필수인가요? 아닙니다. SHT20은 설명에 나온 예시 센서입니다. 청구항은 일반적인 센서와 485 인터페이스를 사용합니다.

Q. 신경망이 센서 고장을 직접 검출하나요? 공개된 방식에서는 아닙니다. CNN/DNN은 K-means 군집 수 k를 예측하고, 새 센서 좌표는 이후 적격 군집 영역과 비교됩니다.

Q. 공개 문서만으로 동일한 시스템을 재현할 수 있나요? 완전하게는 어렵습니다. 센서 측 브리지, 정확한 배선, 펌웨어, 프로토콜 설정, 보안 설계, 클라우드 API, 데이터셋, 학습 모델, 검증 결과가 빠져 있습니다.