Antennino Gateway Guide: How Wireless Sensors Send Their Data

A wireless sensor is useful only when its readings reach somewhere you can use them. Antennino provides one way to build that connection, combining Arduino-style programming with a radio link for exchanging small messages between remote devices and a receiver.

Picture a temperature sensor in a detached garage. The sensor takes a reading, its controller packages the result, and a radio sends it toward a gateway. Software can then turn that message into a temperature chart or an alert.

Understanding those stages helps you choose hardware and diagnose missing readings. This guide explains the Antennino data path, the difference between a local receiver and an internet gateway, and the practical checks that matter when building a U.S. sensor project.

What Antennino Does in a Sensor Network

Antennino is an open-source electronics project built around an ATmega328P microcontroller and an RFM69 radio. The published design uses the 433 MHz band. Its name combines “antenna” and “Arduino,” reflecting its connection to the Arduino programming environment.

The original board includes a DS18B20 temperature sensor and a light-sensitive photoresistor, with connections for additional hardware. Depending on its configuration and firmware, it can operate as a remote node or collect messages from other nodes.

Keep the network roles clear when planning a build. A board collecting radio packets does not automatically have internet access; forwarding those packets to a website requires an additional network connection and suitable software. Choose the receiver around what you need to do with the measurements.

How a Sensor Reading Becomes a Packet

The process begins when firmware asks a sensor for a measurement. The DS18B20 returns digital temperature data over a 1-Wire interface. A photoresistor instead needs an electrical measurement that the controller can interpret as a relative indication of light.

Next, the controller prepares a payload: the information carried inside the radio message. A useful application design might include a node identifier, measurement type, value, battery voltage, and sequence number. These fields are design choices rather than a universal Antennino message format.

Define units before transmitting. For example, a payload could store 20.0°C as the integer 200 if both ends understand that values represent tenths of a degree. The dashboard could display the same reading as 68°F. Without that shared definition, correctly received bytes can still produce an incorrect result. Also distinguish a failed sensor reading from a valid zero.

For repeated transmissions, design a way to recognize the same measurement arriving again. A sequence counter can help, but account for counter resets after a restart so new readings are not accidentally discarded as duplicates.

How the Wireless Link Delivers Data

The RFM69 provides a local packet-radio connection. It uses modulation methods such as FSK; it does not make Antennino a LoRa, Bluetooth, or Wi-Fi device. Sharing a frequency band with another product does not establish compatibility.

Sender and receiver need matching radio settings and compatible firmware. With the RFM69 library, network identifiers and node addresses help organize communication. When encryption is enabled, the participating devices also need the corresponding key configuration.

Acknowledgments can help the sender detect successful radio delivery. The library supports sending a message and retrying when an expected acknowledgment does not arrive. A retry limit keeps an unavailable receiver from causing endless transmissions.

However, a radio acknowledgment covers only that stage of the journey. It does not establish that an internet service saved the reading. For important measurements, track receipt, forwarding, and storage separately rather than treating one successful exchange as proof of complete delivery.

From Local Receiver to Internet Gateway

The documented Antennino internet gateway combines an ESP32 with an RFM69 radio. The RFM69 receives packets from the sensor network, while the ESP32 supplies Wi-Fi connectivity. This separates the local radio connection from the connection to the internet.

In that project, gateway software forwards information to ThingsBoard using MQTT. MQTT uses a publish-and-subscribe model: a client publishes a message under a topic, and a broker routes messages to matching subscribers. The remote sensor itself does not need to run MQTT.

When adapting this architecture, define what happens during an outage. Temporary buffering requires deliberate software and storage support; it should never be assumed. Decide how many readings to retain, when to retry, and whether old measurements remain useful after connectivity returns. Test that behavior by disconnecting the network while leaving the receiver running.

Turning Radio Packets into Useful Dashboard Data

A gateway needs to interpret messages consistently before forwarding them. Use a documented payload layout and check incoming lengths, field types, and device identities. Reject malformed messages instead of allowing unexpected bytes to become plausible-looking measurements.

ThingsBoard supports telemetry for multiple downstream devices through its gateway interface. Messages can carry explicit timestamps; otherwise, the server can assign its reception time. Those options describe different events, especially when readings spend time waiting in a buffer. Preserve measurement time when the application requires an accurate historical record.

For a U.S. dashboard, display familiar units while keeping storage consistent. Label Fahrenheit and Celsius clearly, show when each sensor last reported, and distinguish missing data from a measured zero. Store unambiguous timestamps and convert them for local display. The following fields illustrate a possible application design, not a required packet layout.

Configure a stale-data alert alongside any temperature threshold. A garage reading can remain comfortably within range on screen after its sensor stops reporting; displaying the age of that reading makes the loss of fresh information visible.

Setting Up and Testing a Small Network

Begin with one node and one receiver. Confirm the board revision, radio variant, supply requirements, antenna, and programming connections. An Arduino-compatible processor does not mean every connector has the same electrical characteristics as an Arduino Uno.

Prepare the firmware environment before adding dashboard features. The original programming workflow distinguishes installing a bootloader from uploading an application sketch. Installing the bootloader requires an appropriate programming interface; a serial adapter alone does not perform that initial task. Keep a record of the library versions used in a working build.

Once permitted radio operation has been established, test a known, simple payload. Record what the sender transmits and compare it with what the receiver decodes. Then add the network connection and check the stored telemetry against the same original value.

Expand only after the complete path works consistently. Give each node a unique identity, save the working configuration, and test recovery after restarting the gateway. This makes later failures easier to locate and reduces repeated setup work.

• Nothing reaches the receiver: Check power, antenna connections, radio settings, and firmware compatibility.
• Packets arrive but values look wrong: Check payload layout, numeric scaling, and units.
• Local data appears but the dashboard stays empty: Check network access, credentials, topics, and server responses.
• Readings appear twice: Compare sequence numbers and review retry handling before storing duplicates.

Battery Life, Placement, and Reliable Range

Battery life depends on the complete operating cycle: starting up, powering sensors, measuring, transmitting, waiting for replies, and sleeping. Antennino includes power-management options, but a low standby current quoted for one component cannot establish the consumption of an assembled node.

Measure current during both active and inactive periods. As an illustrative calculation, a 2,000 mAh battery supplying an average 0.2 mA would provide 10,000 hours, or about 417 days, under ideal assumptions. Actual runtime also depends on usable battery capacity, temperature, voltage limits, and self-discharge. This calculation is an example, not a measured Antennino battery-life claim.

Treat range as a site measurement. Test with the intended antenna, enclosure, mounting height, and obstacles, then log unique packets received against messages sent. Receiving 980 of 1,000 test messages gives 98% delivery in that trial; it does not establish reliability under every condition or identify the cause of losses.

Security and U.S. Radio Requirements

The RFM69 library supports hardware AES encryption, but encryption alone does not establish a complete security design. Protect keys, replace published example credentials, and decide how the application will recognize unauthorized or repeated messages. Review wireless firmware updates separately; remote programming capability does not prove firmware authenticity.

Secure the internet connection as well. ThingsBoard supports MQTT over TLS and several authentication methods. Configure certificate validation and appropriate credentials, then test connection failures. A protected radio link does not extend its protection across an independently configured internet connection.

For U.S. operation, do not assume the documented 433 MHz design is automatically suitable for unrestricted sensor reporting. FCC requirements depend on the applicable rule, equipment, emissions, and transmission behavior. Part 15 provisions impose specific conditions; frequency alone cannot establish compliance. Confirm the authorization basis and permitted operation before choosing reporting intervals or transmitting.

Final Thoughts

A useful Antennino system makes every step visible: measurement, packet creation, radio reception, gateway forwarding, and storage. Giving each stage a clear responsibility helps explain failures and prevents a successful radio exchange from being mistaken for a complete data record.

Start with a small network and a documented payload. Verify values and units, measure delivery performance, and test recovery from interrupted power or connectivity before adding more nodes.

The result should be more than a chart that updates occasionally. Aim for a system that shows where readings came from, when they were measured, and whether any information is missing.

FAQs

What is an Antennino gateway?

An Antennino gateway collects messages from compatible wireless sensor nodes and makes their readings available for further use. A local collector may display or pass along received data. Internet access requires additional networking hardware and software. The documented internet gateway uses an ESP32 and RFM69 to connect the sensor network to ThingsBoard.

Does Antennino connect directly to Wi-Fi?

The original Antennino board communicates through an RFM69 radio rather than built-in Wi-Fi. In the documented internet gateway, a separate ESP32 provides the Wi-Fi connection. This lets remote nodes exchange small radio messages while the gateway handles communication with the network service.

Can Antennino sensors send data without the internet?

Yes. Compatible nodes and a receiver can exchange radio packets without an internet connection.

What happens afterward depends on the receiver’s hardware and firmware. Local display or storage must be implemented. Remote access through an online service requires a working network connection somewhere along the data path.

How far can Antennino transmit sensor readings?

There is no single dependable distance for every Antennino installation.

Radio configuration, antennas, placement, obstacles, interference, and receiver conditions all influence the usable connection. Test delivery at the intended locations and repeat the trial under realistic conditions. A distance claim alone says little about missing readings.

Can Antennino run on batteries?

Yes. The original board design includes an option for two AA batteries.

Runtime depends on the assembled hardware, firmware, sensing schedule, radio activity, and battery characteristics. Measure average consumption across a full operating cycle before estimating battery life. Include failed transmissions and retries in that assessment.

Why do readings reach the gateway but not the dashboard?

Successful radio reception confirms only the local portion of the connection.

The gateway may still have a network failure, rejected credentials, an incorrect MQTT topic, or a payload the service cannot interpret. Compare receiver logs, publishing results, and stored telemetry to locate the first stage where the expected reading disappears.