A solar-powered payload samples its position, environment, and power rails. A compact radio packet carries those readings through ground gateways to the dashboard.
Payload
The RAK3172 combines an STM32WLE5 microcontroller and LoRa radio. The microcontroller reads a MAX-M10S GNSS receiver over UART, four sensor ICs over I²C, power rails through its ADC, and a digital microphone through a PDM capture circuit.
Two solar panels feed the BQ25570 harvesting circuit. Its storage rail, VSTOR, feeds the regulated electronics. The field called battery_voltage measures VSTOR, including on a payload built with a supercapacitor.
The hardware guide lists the parts and board connections. The following sections describe what each stream contains and how to use it.
Position and motion
The MAX-M10S reports latitude, longitude, receiver altitude, ground speed, heading, and the number of satellites used. Position tells us where a packet was measured; speed and heading describe horizontal motion. The airborne <4g navigation model allows the receiver to work in the flight regime.
The development firmware reads checksummed UBX-NAV-PVT messages at 9600 baud. It requires valid receiver time, a valid fix flag, at least four satellites, and advancing receiver epochs. It publishes position, height, speed, heading, and satellite count together so fields from different fixes are not combined.
If acquisition fails, the current firmware marks navigation unavailable instead of presenting its cached coordinates as a new fix. Older flight packets can repeat an earlier fix even when reception time advances. See position and altitude for the difference between a received packet, a GPS fix, and a modeled position.
Wire units and GPS resolution
Latitude and longitude use signed 32-bit integers in units of 10⁻⁷ degrees. Height uses a signed 32-bit whole-meter value. Ground speed and heading use unsigned 16-bit values in 0.01 m/s and 0.01° units; satellite count uses one byte. These are encoding steps, not claims about GPS accuracy. The current receiver height comes from NAV-PVT height; it is not the dashboard’s pressure altitude.
Temperature and pressure
The TMP117 normally supplies temperature. The firmware triggers a one-shot conversion and rounds its reading to a signed value in tenths of a degree Celsius. One-shot acquisition avoids leaving the sensor converting throughout sleep.
The MS5611 supplies pressure. The driver checks its factory calibration data, takes pressure and temperature conversions, and applies temperature compensation before packing the result in tenths of a hectopascal. Pressure is useful both as a measurement and as the input to pressure altitude.
If the TMP117 is unavailable, the MS5611 temperature becomes the fallback. The packet does not identify which sensor provided temperature. Both are mounted on the payload; sunlight and board heating can affect them. Read temperature as a payload measurement, not a shielded weather-station air temperature.
Conversion details
The TMP117 output has 128 counts per °C; the firmware rounds it to 0.1 °C and rejects its power-on invalid value. The MS5611 uses OSR 4096 conversions with second-order compensation. The stored pressure unit is hPa; the binary packet contains pressure multiplied by ten. Variable names in older code do not always reflect that scale.
Acceleration and orientation
The LIS2DH12 measures acceleration along the board’s X, Y, and Z axes. These values include gravity. At rest, the vector gives an estimate of the payload’s lean. While it swings or accelerates, that estimate also contains motion.
The radio packet carries one XYZ sample per acquisition cycle, not a continuous vibration recording. A separate accelerometer interrupt can wake the firmware on a low-acceleration event. There is no gyroscope or compass, so these readings cannot provide yaw or a complete attitude solution.
The dashboard converts XYZ into a tilt indicator. Use the raw fields when comparing motion between packets, and do not infer a swing frequency from widely spaced samples.
Sensor precision and packet precision
The configured low-power ±2g mode uses 8-bit samples at 16 mg per count, approximately 0.157 m/s² per count. The packet stores signed hundredths of m/s². Those extra decimal places preserve the conversion; they do not make the sensor more precise. The 100 Hz internal sensor rate supports the interrupt logic, while telemetry still contains just one sampled vector.
Light and sound
The LTR390 alternates between ultraviolet and ambient-light measurements. Ambient light is reported in lux. The UV channel is converted to an integer UV-index estimate using the configured gain and integration time. These readings help compare illumination and solar exposure across a flight.
Lux is weighted for human vision. It is not solar irradiance or charging power. Sensor orientation, shadows, and any covering affect the reading. Unavailable and saturated measurements have distinct packet markers rather than appearing as zero.
The T3902 microphone contributes an acoustic-event flag from a short capture window. The firmware compares that window’s variance with an adaptive quiet baseline. It transmits the threshold result, not audio. A positive flag does not identify an aircraft, animal, or other sound source.
Optical and acoustic acquisition
The UV conversion uses 18× gain and an 18-bit, 100 ms integration, with an integer conversion of raw counts divided by 350. Ambient light uses 1× gain and 0.6 lux per raw count. These settings explain the scale; calibration and optical exposure still limit interpretation.
The microphone path reduces the PDM bitstream to samples, removes DC, and compares variance with a 16× baseline threshold, equivalent to about 4× RMS amplitude. The capture spans about 55 ms after settling. It does not listen continuously between telemetry cycles.
Power and radio
The microcontroller measures storage and solar-input voltage through resistor dividers. It calibrates the ADC scale from its internal voltage reference and sends millivolts in the packet. Voltage helps explain whether the payload could power its sensors, GPS acquisition, and radio transmission. It does not directly measure current, energy, or remaining flight time.
A normal development cycle runs about every 20 minutes: inspect power, acquire a fresh position when permitted, read available sensors, send telemetry, and enter STOP1 sleep. Power gates can suppress work. A missed sensor reading or a longer gap is therefore different from a confirmed payload failure.
LoRaWAN carries short packets through gateways rather than maintaining a continuous connection. The Class A receive windows follow an uplink, allowing the device to receive a downlink without leaving its radio on throughout sleep. A usable uplink alone does not prove the return path works.
The development firmware uses fresh GPS information to authorize a radio region. A cold start without a usable fix or provisioned launch authority can remain silent. Configure the matching TTN plan; supported software regions do not establish that a particular module or antenna is qualified for every band.
Other radio services
Development builds also contain a Meshtastic relay, authenticated balloon-to-balloon messages, and a wildlife-tag listener. They share one radio and depend on the build, power, and regional configuration. They are separate from primary tracking telemetry and are not exposed as ordinary flight positions in the public read API.
What we measured during sleep
A July bench measurement on the v15 firmware recorded a median STOP1 current of 6.688 µA at a 4.660 V supply. This measures the sleeping board, not a complete transmit cycle or overnight endurance.
GPS acquisition, radio activity, and retries add energy outside sleep. Size the store from a measured full cycle, then test the finished assembly through darkness and sunrise. The sleep result alone cannot establish that capacity.
Packets and data flow
- Payload: samples its sensors and packs their readings into a binary uplink.
- Gateway: forwards the received frame to The Things Network with signal and receiver metadata. Several gateways can hear one transmission.
- TTN: validates the session and forwards the application bytes and metadata.
- Ingest service: authenticates the connection, matches its verified application and radio identity to the balloon, decodes the bytes, and stores the packet without duplicating repeat deliveries.
- Dashboard: reads public telemetry, applies display rules, and draws received positions separately from forecasts.
Primary telemetry uses fPort 1. Historical packets contain 35 bytes; the development formats contain 40. Scaled integers and packed status bits keep the transmission small. Invalid-value markers distinguish a missing measurement from a real zero.
The packet does not carry a timestamp for every sensor. Stored time is the TTN reception time. Radio signal strength, signal-to-noise ratio, gateway positions, and reception time come from the network, not onboard sensors. See the API field reference for decoded units.
Status and auxiliary records
The development packet adds boot, GPS-age, server-confirmation, command-acknowledgment, and relay counters. These help diagnose resets and link recovery. The public telemetry endpoint includes these diagnostic fields when the packet supplies them. fPort 11 carries wildlife detections and fPort 12 carries balloon-to-balloon records; neither should be decoded as a primary position packet. Use the matching decoder rather than guessing from payload length alone.
Why keep the original bytes?
Raw packets let us replay a flight when a decoder changes. In an October check, independent Python and JavaScript decoders read all 33 archived uplinks. Of the 32 packets with a stored TTN decode, 30 matched exactly and two differed only in the last binary digit of a derived velocity value. The remaining packet had no stored decode to compare.
Keep the raw payload, fPort, device identity, frame counter, and reception time together. This preserves the transmitted measurements without making a later interpretation permanent.
Interpreting a flight
Packet reception, GPS validity, radio coverage, and balloon status are separate observations. A gateway position is never a substitute for the payload’s position. No packets over an ocean can indicate a coverage gap; it does not prove a landing.
The map joins usable observations and may show modeled tracks through gaps. The timeline provides a way to inspect the original readings. Treat a smooth line as a visualization, not continuous measurement.
Some launch-area positions are deliberately approximate. Those points support a city-level view, not street-level location or precise receiver-distance calculations. Forecast paths describe possible future motion and should remain separate from observed fixes.