Wiznet makers

Thumbnail Image: AI-generated image

T.E.E.M.O: An ESP32-S3 CanSat Platform Combining 433 MHz Telemetry, Thermal Imaging Logging, and a W5500-Based Camera Link

Introduction

Based on the public repository, the uploaded ZIP snapshot, and the team’s public website, T.E.E.M.O is better understood as a full CanSat avionics platform than as a simple sensor demo. The public GitHub repository itself provides only limited descriptive text, so the actual nature of the project is more clearly visible through its source code, KiCad design files, PlatformIO configuration, and the team’s public project pages. (GitHub)

The available materials show that the repository brings together several system layers at once: an ESP32-S3-based CanSat main unit, 433 MHz telemetry, SD card logging, thermal camera capture, ground-station code, and a separate W5500-based Ethernet camera path. In other words, this is not just a single embedded application. It is closer to a mission-oriented hardware and firmware workspace covering both the flight unit and parts of the supporting ground-side infrastructure.

Quick background / plain-language explanation

What is a CanSat?

A CanSat is a small educational satellite project that compresses the key functions of a real satellite into the approximate size of a soda can. The European Space Agency describes a CanSat as a simulation of a real satellite, with major subsystems such as power, sensors, and communications integrated into a very small volume, then launched or dropped so that the mission can begin. (유럽우주국)

For general readers, T.E.E.M.O can be understood as a small airborne system that tries to do three things at the same time:

• Measure the vehicle’s condition during flight
  It collects orientation, environmental, GPS, light, gas-index, and power-monitoring data.
• Transmit mission data wirelessly
  Its main telemetry path is a 433 MHz radio link.
• Log data internally at the same time
  It writes sensor packets and thermal camera data to an SD card.

This matters because the repository is not just “sensor reading code.” It reflects an attempt to build a small but complete airborne data system, with sensing, transmission, and onboard storage all handled together.

A plain-language explanation of RTSP, NAL, and telemetry

Several technical terms in this project are not familiar to general readers.

Telemetry means operational data sent from a device to another location. In this context, that includes information such as altitude, orientation, temperature, pressure, battery voltage, and other flight-state values.

RTSP is a control protocol commonly used for video streams. It handles the session setup side of streaming, such as requesting a stream, describing it, and starting playback.

NAL packets are pieces of encoded video data. In this project, the W5500-linked camera path receives streamed video data over RTSP/RTP and then repackages that video content into smaller framed chunks for onward handling over another output path.

That makes T.E.E.M.O more than a sensor payload. The available code shows an effort to combine low-bandwidth long-range telemetry and a separate higher-bandwidth video-related data path inside one broader system concept.

What this project is

A short definition

T.E.E.M.O is an ESP32-S3-based CanSat platform that combines multiple sensors, 433 MHz radio telemetry, SD logging, a thermal imaging subsystem, and an optional W5500 Ethernet-based camera link.

AI-generated image

What can be directly confirmed from the repository

In the visible code, the CanSat class directly includes the following building blocks:

• BNO085 IMU/orientation sensing
• BME280 environmental sensing
• VEML7700 light sensing
• SGP41 gas-index sensing
• GPS
• SD card support
• E220-based 433 MHz radio
• INA-based voltage/current monitoring
• a Maincam camera-related path

The main firmware also creates separate FreeRTOS tasks for:

• sensor acquisition
• radio transmission
• SD writing
• thermal camera reading

This is one of the clearest signs that the project is not just an Arduino-style example sketch. It is structured more like a small mission computer, where data collection, logging, and transmission are split into concurrent roles.

Why this looks more like a platform than a single finished product

The repository includes not only the main flight-unit firmware but also separate code areas for related subsystems and experiments:

• src/ESP_CanSat for the main flight firmware
• src/Ground_station/433Mhz for the 433 MHz ground-side implementation
• src/Radios/2.4Ghz for RF24-based 2.4 GHz testing
• src/W5500 for W5500-based RTSP link testing

That structure suggests a broader development workspace for a CanSat mission, rather than a single narrow application. The project appears to cover the flight side, radio links, storage, and at least part of the supporting receiver-side tooling.

An important implementation detail

There is also an important distinction between what exists in the repository and what is currently active in the main flight build. In the visible CanSat::begin() path, the 433 MHz radio configuration is enabled, while CameraBegin() is commented out, and the RF24-based 2.4 GHz path is not active in the same initialization flow. That means the repository clearly contains a W5500 camera-related path and a 2.4 GHz radio experiment, but the currently visible primary flight-side logic is weighted more toward 433 MHz telemetry, SD logging, sensor collection, and thermal capture.

That distinction is important in a curator article. “The repository contains W5500-related code” is not the same as “W5500 is the always-on core path of the current flight firmware.” The available code supports the first statement directly, but the second would overstate what is visible today.

Author & Community / Company background

What kind of team is behind this work?

Public sources reviewed here indicate that T.E.E.M.O is not a commercial product team. It is presented instead as a CanSat team from Jedlik Ányos Technikum in Győr, Hungary. The team’s public website describes the project as a student engineering effort that combines electronics, software, custom PCB design, 3D-printed structure work, and parachute development for CanSat competition use. (Teemo CanSat Team)

The project’s public “About” page also identifies Buda Bálint as a “Software-, PCB-, and electronical designer”, with responsibility for part of the satellite software, electronics-related work, and sensor and camera testing. This is useful context because it shows that the repository comes from a contributor working across both firmware and hardware design, rather than from a software-only background. (Teemo CanSat Team)

What does the author’s public activity suggest?

The public GitHub profile visible here does not show a large portfolio of industrial repositories, but it does show that T.E.E.M.O is part of a broader pattern of student technical work rather than an isolated upload. The team’s own site also links its broader activity to other school-based engineering efforts, including JedlikBots, which points to an environment shaped by robotics, electronics, and project-based technical education. (Teemo CanSat Team)

The available materials do not support describing the author or the team as an established commercial vendor. However, they do support describing the project as a strong student engineering portfolio piece: it combines custom electronics, embedded firmware, radio communication, onboard data logging, and physical-system design in one integrated effort. (Teemo CanSat Team)

Public milestones and external-facing project maturity

The team’s public project page includes a visible milestone timeline. That timeline lists events such as repository creation in November 2025, PDR progress, PCB arrival, data packet generation, thermal camera functionality, telemetry radio bring-up, successful radio reception, and radio-license receipt in January 2026. These milestones indicate that the project is not just conceptual. It has moved through a visible cycle of design, build, bring-up, and subsystem testing. (Teemo CanSat Team)

Why that matters from a curator’s perspective

The external value of T.E.E.M.O is not primarily commercial scale. Its value is clearer in four other areas:

• Educational value
  It brings together sensing, embedded firmware, storage, radio telemetry, and airframe-side systems thinking. (유럽우주국)
• Portfolio value
  It shows evidence of real integration work across PCB design, firmware, and mission-oriented hardware. (Teemo CanSat Team)
• Team engineering value
  The project includes both flight-unit and support-side code, which suggests system-level thinking rather than isolated module development.
• Maker and competition value
  It fits well into the educational aerospace and advanced maker space, where students increasingly build full custom platforms instead of relying only on off-the-shelf demo stacks. (유럽우주국)

How it works for general users / operators

AI-generated image

From an operator’s point of view, T.E.E.M.O behaves like a compact mission payload. On startup, the ESP32-S3-side firmware initializes the sensor set, configures the 433 MHz telemetry radio, opens the SD card file, and then launches separate runtime tasks for sensor collection, radio transmission, SD logging, and thermal camera capture. The visible code shows that this is intended to run as a live mission system rather than as a single blocking loop.

The operator-facing data path is centered on two binary telemetry packet types. One packet carries orientation, inertial, gas-index, and power-monitor data, while the other carries environmental, GPS, and light-related measurements. These packets are transmitted over the E220-based 433 MHz link and also mirrored into the SD logging path, so the project is designed to support both live reception and post-flight review.

The visible ground-station code reinforces that operator model. It is built around the same 433 MHz radio family and exposes practical receive-side indicators such as packet count, CRC errors, and RSSI-linked status display behavior, which is exactly the sort of feedback expected in a field telemetry workflow.

A separate camera-related path also exists, but it should be described carefully. The repository contains W5500-based Ethernet camera code, yet the main flight initialization path currently leaves CameraBegin() commented out. That means the Ethernet camera route is present in the codebase, but it should be treated as an optional or experimental subsystem rather than as the always-active core mission path of the currently visible main build.

How it works for developers

AI-generated image

For developers, the project is most interesting as a data-flow architecture rather than as a collection of isolated drivers. The visible firmware separates acquisition, packetization, transport, and storage into different roles. Sensor-reading functions update packet buffers, the radio task alternates between packet types and transmits them, the SD writer drains a stream buffer into storage, and the thermal camera path appends its own packetized output into that same logging channel. That gives the project a clearer systems-engineering shape than a typical single-file hobby sketch.

The packet layer is also structured with runtime robustness in mind. The code uses packed binary packet structures, CRC generation, double-buffered packet pointers, and mutex protection around shared data. This suggests that the authors were already thinking in terms of concurrent acquisition and transmission, not only in terms of simple sensor polling.

The W5500-related developer path is separate from the main telemetry loop and is focused on camera transport. In the visible Maincam implementation, the firmware initializes Ethernet, checks W5500 hardware and cable state, opens a TCP connection to an RTSP camera, performs OPTIONS, DESCRIBE, SETUP, and PLAY, then reads interleaved RTP-over-TCP data and reconstructs NAL-related fragments into fixed-size serial output packets. That is a much more specific role than “general Ethernet support.” It is a local wired streaming bridge for a camera subsystem.

This is also where the project becomes technically distinctive. The 433 MHz path handles mission telemetry, while the Ethernet path is assigned to a very different workload: camera session control and stream intake. That transport separation is a strong architectural choice for a student project, because it shows that not all data inside a flight payload has to share the same communications path.

WIZnet role / why WIZnet is used

The WIZnet chip used here is W5500. In the visible design, it sits on the camera-side Ethernet path, not on the primary 433 MHz telemetry path. The schematic shows a W5500IO-style module connected through SPI and control/status signals such as CS, RST, INT, and LINK/ACT, while the code uses that Ethernet path to talk to an RTSP camera over TCP. The data flowing through the W5500 path is therefore camera-related network traffic: RTSP control messages and incoming RTP-over-TCP stream data.

At the silicon level, W5500 is exactly the kind of part that fits this role. WIZnet describes it as a hardwired TCP/IP controller with an SPI host interface, integrated 10/100 Ethernet MAC/PHY, and multiple sockets, which makes it suitable for attaching wired Ethernet capabilities to an external MCU without requiring the MCU to implement the entire Ethernet path itself. (WIZnet Document System)

However, the software stack matters just as much as the chip. In this repository, the visible implementation is not a direct WIZnet ioLibrary Driver integration and it is not an lwIP-based integration. The W5500-related code includes Ethernet.h, uses Ethernet.init(), Ethernet.begin(), EthernetClient, Ethernet.hardwareStatus(), and Ethernet.linkStatus(), and the PlatformIO dependency explicitly points to arduino-libraries/Ethernet @ ^2.0.2. That identifies the active software path as the Arduino Ethernet library path on top of W5500 hardware.

That distinction is important for WIZnet readers. The W5500 itself belongs to the TOE-style hardwired TCP/IP family, and WIZnet’s official ioLibrary_Driver is the company’s direct embedded driver stack for that hardware family. But the visible project code is not calling the ioLibrary APIs directly. Instead, it uses the Arduino Ethernet abstraction layer that supports WIZnet SPI Ethernet chips. In other words: W5500 hardware is present, but the visible software interface is Arduino Ethernet rather than direct ioLibrary Driver usage. (GitHub)

System-level, that choice makes sense. In this project, Ethernet is not the main long-range mission channel. It becomes useful as a wired, LAN-facing subsystem path for camera transport, while the mission telemetry remains on 433 MHz radio. That is a practical division of labor: long-range low-rate telemetry on one side, local wired camera intake on the other.

A compact classification of the visible WIZnet usage is therefore:

• Chip: W5500
• System position: camera-side Ethernet interface
• Traffic over WIZnet path: RTSP control + RTP/TCP video stream intake
• Software path: Arduino Ethernet / EthernetClient
• Direct WIZnet ioLibrary Driver usage visible: No
• lwIP-based integration visible: No
• ESP-IDF Ethernet driver path visible: No

Why it matters

What makes T.E.E.M.O worth curating is not just that it uses many parts. It is that the project shows a recognizable systems split between sensing, telemetry, storage, and optional video transport. Many student embedded projects stop at reading sensors and printing values. This repository goes further by defining packet formats, using concurrent tasks, building a receiver-side path, and experimenting with a second transport for camera data.

It also aligns well with the educational intent of the CanSat ecosystem. ESA describes CanSat as a project in which students design, integrate, test, launch, operate, and analyze a miniature satellite system, and the CanSat 2025–2026 guidance explicitly frames radio telemetry as part of the mission workflow. In that context, T.E.E.M.O is not just a payload. It is a training ground for real systems thinking. (유럽우주국)

For WIZnet-oriented readers, the project is also a useful reminder that Ethernet in embedded systems is not only about web dashboards or cloud publishing. Here, the interesting role of W5500 is as a specialized LAN-facing subsystem interface inside a constrained airborne platform. That is a more concrete and engineering-led use case than a generic “connect to the internet” example. (WIZnet Document System)

Market context / industry fit

AI-generated image

This project fits best into the educational aerospace and competition-driven embedded systems space rather than a clean standalone commercial product category. ESA positions CanSat as a structured school-level engineering program that simulates the lifecycle of a real space project, and the Hungary 2026 competition lists T.E.E.M.O among its finalist teams. That places the project in a real external ecosystem of student aerospace development, not only in a private classroom exercise. (유럽우주국)

From a market-readiness perspective, the repository currently looks more like a competition platform and engineering portfolio asset than a finished commercial device. The codebase, hardware files, and milestone timeline point to active design, integration, and testing work, which is exactly what would be expected from a serious student team preparing for launch and evaluation. (Teemo CanSat Team)

The most realistic external-value interpretation is therefore not “mass-market product,” but rather one of three adjacent fits:

• a student aerospace training platform
• a subsystem prototype for telemetry, logging, or compact payload instrumentation
• a portfolio-grade integration project showing readiness for embedded, electronics, or avionics-related work (유럽우주국)

If developed further, the most credible productization direction would likely be at the subsystem level rather than as a fully general consumer product: for example, a compact telemetry/logger board, a field-test payload controller, or a small wired camera-bridge node for robotics or experimental payload work. That is an inference from the current architecture, not a claim that the team is already commercializing it. (Teemo CanSat Team)

Quick notes / caveats

The public repository does not provide a very detailed top-level narrative, so this curation relies heavily on the visible code, PlatformIO files, and schematic materials rather than on polished README-style explanation. That is worth stating because the architecture is clearer in the source tree than on the repository front page.

The W5500 path should also be described with precision. The available materials clearly show W5500-related code and hardware, but the currently visible main flight initialization path leaves the camera initialization disabled. So the strongest evidence supports describing Ethernet video as an available subsystem path, not as the proven always-on center of the current flight firmware.

A second caveat is that the camera path appears lab-oriented rather than fully deployment-polished. The visible code contains hard-coded MAC values, static IP settings, explicit camera IP/port values, and an embedded authorization header string. That is normal for bring-up and controlled testing, but it is not yet the same as a generalized field-deployable network configuration layer.

Finally, the project should not be oversold as a fully hybrid high-bandwidth mission stack already proven in one integrated release. The repository clearly contains multiple communications ideas, but the currently visible active baseline is still led by the 433 MHz telemetry path, SD logging, and sensor/thermal acquisition.

My apologies! You are absolutely right. Since the source text and target audience for the maker site are in English, the FAQ should definitely be in English as well.

Here is the AEO-optimized FAQ in English, keeping it concise and structured for easy reading:

Q. What is the T.E.E.M.O project?

A. T.E.E.M.O is an educational CanSat (miniature satellite) platform developed by a student team from Hungary. Based on the ESP32-S3, it acts as a complete mission-oriented avionics system that integrates sensor data collection, 433 MHz radio telemetry, SD data logging, and a thermal imaging subsystem into a soda-can-sized unit.

Q. What are the core functions of this CanSat during flight?

A. It tries to accomplish three main tasks simultaneously: measuring the vehicle's condition (altitude, orientation, temperature, gas index), wirelessly transmitting that mission data to a ground station via a 433 MHz radio link, and internally logging all sensor packets and thermal camera data to an SD card.

Q. How is the WIZnet W5500 chip used in this system? 

A. The W5500 chip acts as a wired LAN interface for an optional Ethernet-based camera link. It is specifically used to handle RTSP control messages and receive RTP/TCP video streams from a camera. Notably, it utilizes the Arduino Ethernet library rather than direct WIZnet ioLibrary drivers.

Q. Is T.E.E.M.O a commercially available product? 

A. No, it is a student engineering project built for a CanSat competition by a team from Jedlik Ányos Technikum. Rather than a mass-market product, it serves as an impressive engineering portfolio piece that demonstrates real integration work across custom PCB design, embedded firmware, and physical system architecture.

Q. What makes its software architecture interesting for developers? 

A. Instead of using a simple, single-loop Arduino sketch, the firmware is structured like a small mission computer. It uses separate FreeRTOS tasks to handle sensor acquisition, radio transmission, and SD logging concurrently. It also smartly separates transport paths: using a 433 MHz link for low-bandwidth, long-range telemetry, and reserving the Ethernet path for specific high-bandwidth camera transport.

References

• T.E.E.M.O official project website and team background — team overview, milestones, and role descriptions. (Teemo CanSat Team)
• CanSat Hungary 2026 official competition site — competition structure and finalist list including T.E.E.M.O. (CanSat 2026)
• ESA CanSat overview and 2025–2026 mission guidance — background on the CanSat ecosystem and the radio-telemetry mission model. (유럽우주국)
• WIZnet W5500 official documentation — W5500 hardwired TCP/IP, SPI, MAC/PHY, and socket capabilities. (WIZnet Document System)
• WIZnet ioLibrary Driver official repository and driver documentation — reference point for what direct ioLibrary usage would look like. (GitHub)
• Arduino Ethernet library sources and release notes — relevant for identifying the visible software path used in this project. (GitHub)
• Repository source evidence — main ESP32 CanSat firmware, packet layer, thermal camera path, 433 MHz ground-station code, W5500 camera code, and KiCad schematic.

If you’d like, the next step can be a full polished single-piece English curator article that merges Part 1 and Part 2 into one WIZnet Maker Site-ready post.