Wiznet makers

A note on what this entry actually is

This Makers entry is built on a Japanese-language research article posted on Qiita in late April 2026, not on a public GitHub repository. The author, writing under the handle yoshiyakato, frames the piece explicitly as an engineering "diary" — a structured technical survey of next-generation drone subsystems, with a follow-up hands-on integration article (combining Pixhawk, optical fiber, Starlink Mini, and LTE) announced for the next installment.

In other words, the WIZ-IP20 use case described below is a design proposal with engineering rationale, not a verified flight test. We're surfacing it because the analysis is concrete enough to be useful: it covers integration pitfalls, network-layer trade-offs, and form-factor reasoning at a level that goes well beyond a casual mention.

Why this analysis stands out

Drone-side telemetry over public cellular or satellite networks runs into a structural problem: the airborne unit usually sits behind Carrier-Grade NAT (CGNAT), which means a ground operator cannot initiate a session toward the drone the way they would on a private network. Most maker-grade drone tutorials skip past this, but yoshiyakato's article tackles it head-on — and arrives at WIZ-IP20 not as a generic recommendation, but as a specific answer to that specific problem.

Where WIZ-IP20 fits in the architecture

The article positions the module as a serial-device-server bridge between the Pixhawk flight controller and an IP backhaul (LTE, 5G, or Starlink). The flight controller emits MAVLink packets over its UART telemetry port; the bridge encapsulates them into a TCP or UDP session over Ethernet; the cellular or satellite modem carries them onward.

Three properties of WIZ-IP20 are highlighted as the reasons this works for an airborne payload:

1. A combined RP2040 + W5500 single-package MCU (W55RP20). The author notes the integration of an ARM Cortex-M0+ dual-core with hardware TCP/IP in one chip, packaged into a MAG-JACK form factor of roughly 32.5 × 16.5 × 17.3 mm. For a payload-constrained F450/F550-class airframe, every gram and every cubic centimeter spent on the comms stack matters.
2. Industrial temperature range (−40 °C to +85 °C). Drone electronics in the bay can see significant thermal swing during ascent, and the author explicitly cites this rating as the reason the module is acceptable for outdoor and altitude use, where consumer-grade serial-to-Ethernet adapters tend to fail.
3. TCP Client mode with auto-connect on boot. This is the part doing the heavy lifting on CGNAT traversal. On power-up (or on link recovery), WIZ-IP20 can be configured to dial a fixed remote IP/DDNS-resolved hostname and port, opening the session from the airborne side. Once the SYN goes out and the carrier NAT records the flow state, the ground station can reach in through that same flow — the wall is now bidirectional.

The TCP-vs-UDP trade-off the author actually engages with

What lifts this article above a typical product mention is that the author doesn't stop at "use TCP Client and you're done." He follows the chain of consequences: TCP guarantees delivery via retransmission, but a single dropped packet can stall the queue behind it (head-of-line blocking), and on a control-loop carrying real-time MAVLink, a sudden latency spike is a flight-safety event, not just a glitch.

The article therefore proposes a more robust variant: use WIZ-IP20's UDP mode and implement UDP hole-punching logic on the companion computer side. This keeps the no-retransmission, low-latency property of UDP while still solving the NAT-traversal problem at a higher layer. Both options are presented as valid, with the choice tied to which channel — command, telemetry, or video — is being carried.

Hardware integration: the 3.3 V warning

A surprisingly practical detail the article spends time on: WIZ-IP20 expects a strict 3.3 V VCC (typ. 3.3, max. 3.6), while the Pixhawk telemetry connector outputs 5 V. Wiring them directly will destroy the module on power-up. The recommended fix is a small LDO step-down on the input rail; the UART signal lines themselves (TXD/RXD) are 3.3 V TTL on the Pixhawk side and can be connected directly. This is the kind of footnote that signals the author has actually thought about wiring this on a real airframe, rather than copying a datasheet.

System diagram (conceptual, per the article)

 

Honest limitations of this source

Three things should be clear before anyone treats this as a build guide:

• No public source code, no GitHub repository. The entire WIZ-IP20 use case is described in prose, with one external link to the Akizuki Denshi distributor page. There is no firmware, no schematic file, no PCB layout to clone.
• No measured latency, throughput, or thermal data. The performance claims (e.g., "low-latency MAVLink path with UDP") are reasoned, not benchmarked.
• The hands-on integration is announced for a follow-up article. The author commits in Section 9 to publishing an actual Pixhawk + optical fiber + Starlink Mini + LTE integration test as the next post — that piece, when it appears, would be the natural follow-up Makers entry.

What's interesting for the WIZnet maker ecosystem

Even with those caveats, the article is a useful artifact for the catalog. It shows a Japanese engineer reasoning from first principles — payload, latency, NAT structure, voltage levels — and arriving at WIZ-IP20 as the bridge component, while citing a Japanese hobbyist distributor (Akizuki Denshi) as the procurement path. That's a different and complementary signal compared to the existing Pico/STM32-centric Makers entries: it's WIZnet hardware being evaluated for an airborne, bandwidth-asymmetric, NAT-constrained use case, in the language and supply context of a Japanese maker community.