Programming Design of an STM32-Based Positioning Information Acquisition and Upload System

Wang Sen

doi:10.54254/2755-2721/2025.LD27215

1. Introduction

With the rapid expansion of the IoT, field terminals must localize and report data reliably while operating on tight energy budgets and under intermittent connectivity. NB-IoT offers wide-area reach but can exhibit higher per-uplink energy and coverage gaps in practice [1]. LoRa provides very low-power links but requires a nearby gateway and careful payload sizing [2,3]. To reconcile these constraints, we adopt a dual-uplink architecture: a GNSS-enabled terminal that prioritizes NB-IoT for direct cloud upload and transparently falls back to a LoRa-to-Ethernet gateway when cellular service is unavailable. The design emphasizes RTC-scheduled duty cycling, compact JSON Lines messages for streaming [4], and power-domain control to enable long-life, unattended positioning at low cost.

2. System overview

Table 1. Overall architecture and topology
Subsystem / Item	Components / Steps	Purpose / Notes
Hardware system	Terminal + Gateway	Two-tier topology: a battery-powered terminal reports to a gateway for aggregation and backhaul.
Software workflow	1) Exit low-power → 2) Acquire GPS → 3) Upload data → 4) Enter low-power	Duty-cycled loop that minimizes energy use while ensuring periodic positioning and uplink.
Power-management system	(1) Ultra-long standby (2) MCU low-power modes	Long-life operation via aggressive sleep states and coordinated wake/sleep scheduling.

Table 2. Hardware architecture and key designs
Terminal	(1) Main MCU: STM32F103C8T6(2) GPS: AT6558R (5N32 package)(3) NB-IoT modem: QS100(4) LoRa transceiver: LLCC68	MCU orchestrates sensing, positioning, and communications; GPS provides position fix; NB-IoT offers cellular uplink; LoRa enables low-power local relay when needed.
Gateway	LLCC68 LoRa radio + W5500 Ethernet controller (W5500 is gateway-side only; the gateway transparently bridges bytes to the TCP server without parsing application semantics.)	Aggregates LoRa frames from terminals and forwards them to the server via Ethernet backhaul.

2.1. Main controller (STM32F103C8T6)

The STM32F103C8T6 (72 MHz; 64 KB Flash; 20 KB RAM) orchestrates GNSS, NB-IoT, and LoRa via UART/SPI/I²C. Designed for battery-powered deployments, the MCU spends most of its time in sleep and wakes on an RTC alarm or external interrupt to acquire a fix, package a record, upload, and return to sleep. Ethernet (W5500) is implemented on the gateway only; the terminal never interfaces with W5500. This separation simplifies the terminal’s hardware, tightens its power budget, and clarifies responsibilities between terminal and gateway.

2.2. Software architecture and task orchestration

Application layer:Schedules a duty-cycled loop (wake–acquire–package–upload–sleep), selects NB-IoT with automatic LoRa fallback, and handles timeouts/retries/resume.Communication layer: Exposes two paths—UART→QS100→TCP (NB-IoT) and SPI→LLCC68→gateway→W5500→TCP (LoRa→Ethernet)—and provides NB-IoT attach & sockets, LoRa RF setup & framing, and gateway socket & forwarding.Driver layer: Initializes and power-sequences GNSS/LoRa/NB-IoT/W5500/RTC, with interrupts and buffer/DMA support.

Common services: Logging and timestamps, ID/UUID, integrity checks, parameter loading, and staging buffers.

2.3. Data model and communication protocols

2.3.1. Application-layer data model ( JSON packaging )

To balance readability and backend parsing, a minimal JSON schema is used—only essential fields (latitude/longitude, hemisphere, timestamp, etc.) are transmitted. Field minimization reduces air-interface load and serial congestion. Each record is emitted as a JSON Line (newline-delimited JSON), with uuid + dateTime used for de-duplication.

"uuid": "device-unique-identifier",

"lat": 0.000000,

"lon": 0.000000,

"latDir": "N|S",

"lonDir": "E|W",

"dateTime": "YYYY-MM-DD HH:MM:SS" // UTC

2.4. Low-power strategy and energy budget

Strategies: peripheral power-gating on demand; MCU clock gating / frequency scaling; immediate sleep after task completion; GPS warm/hot start to shorten time-to-fix and reduce active duration.

3. Hardware implementation and software integration

3.1. System-level collaboration (terminal — gateway — server)

The terminal operates a duty-cycled loop—wake → acquire → package → upload → sleep—driven by the RTC. The state machine is illustrated in Figure 2. Payloads are emitted as newline-delimited JSON objects (JSON Lines) so that the server can stream-parse records regardless of LoRa frame or TCP segment boundaries [4]. The gateway performs byte-transparent forwarding from LoRa to a persistent TCP client without interpreting application semantics. This collaboration proved stable in field tests and keeps terminal hardware and firmware minimal.

3.2. Hardware-to-software mapping and timing

GPS (AT6558R):The terminal drives the AT6558R through a dedicated UART, powers it only during the acquisition window, and leverages hot/warm start to shorten time-to-fix. In low-power mode the GNSS rail is fully gated by the MCU; on wake, the firmware allows a short stabilization interval before reading NMEA frames into a staging buffer and packaging them as a JSON record. The start/backup behaviors and timing choices follow the vendor datasheet recommendations [5].

NB-IoT (QS100). Session setup follows the AT sequence summarized in Figure 3: check attachment (AT+CGATT? → +CGATT:1), create a TCP stream socket (AT+NSOCR=STREAM,6,0,0), then connect (AT+NSOCO=<id,ip,port>). On failure, apply retry-with-exponential-backoff; after the retry budget is exhausted, automatically switch to the LoRa path. Data-plane send/acknowledgment uses AT+NSOSD with a sequence ID and polling via AT+SEQUENCE.

Figure 1. NB-IoT client setup with minimal AT commands

LoRa (LLCC68): The terminal connects an LLCC68-class transceiver (MS21SF1) over SPI and uses it only as a fallback path when the NB-IoT uplink is unavailable. LoRa PHY/MAC settings (channel plan, data rate, RX/TX windows) follow the LoRaWAN L2 1.0.4 specification, while the driver abstracts IRQ-driven reception into a simple “copy-to-app-buffer and signal-ready” primitive [6,7].

4. Software implementation (specific collaboration among terminal, gateway, and cloud)

4.1. Main workflow

Figure 2. Terminal–LoRa gateway–server topology with NB-IoT primary, LoRa fallback

4.2. NB-IoT connection establishment and session initialization

We employ a blocking AT helper that writes a command, aggregates UART responses via HAL_UARTEx_ReceiveToIdle, and returns on OK/ERROR/timeout. The deployed QS100 firmware exposes the NSO* socket family (AT+NSOCR/NSOCO/NSOSD/NSORF/NSOCL). Client setup proceeds as: (1) verify attachment, (2) open stream socket, (3) connect. Treat only OK as success; otherwise close with AT+NSOCL to avoid half-open sockets. On repeated failures, back off and then hand over to the LoRa fallback. The resulting flow is depicted in Figure 3.

Figure 3. Blocking AT helper and response-parsing implementation

4.3. LoRa channel coordination: terminal fragmentation, gateway reception, ethernet forwarding

4.3.1. Terminal: 255-B fragments

Terminal fragmentation. Each record is sliced into ≤255-byte frames (leaving headroom for headers/CRC at the chosen modulation). The gateway forwards raw bytes immediately on reception. On the server, a record is reconstructed by concatenating bytes until a newline (\n) is observed, then parsing one JSON object—independent of LoRa frame or TCP segment boundaries [4]. This streaming-safe packaging is shown in Figure 4.

Figure 4. LoRa TX fragmentation: send payload in 255-byte chunks, then the remainder

4.3.2. Gateway: forward LoRa to Ethernet

Gateway and Ethernet forwarding. The LoRa gateway maintains a persistent TCP client and transmits only in the ESTABLISHED state. Ethernet is provided by a W5500 hardwired TCP/IP offload device; the firmware opens a socket, reconnects on drop, and forwards the application buffer verbatim without interpreting JSON or fragment semantics [8].

Figure 5. Interrupt-driven LoRa RX: service IRQ, copy to app buffer, set size, null-terminate, forward

5. Experimental results

5.1. Data transmission via NB-IoT

We first established the TCP client and verified reachability of the server endpoint. After connecting, the terminal transmitted the payload and we confirmed reception on the TCP monitoring page.

5.2. Transmission via LoRa gateway

When the NB-IoT module failed to create or connect the client, the gateway fallback path was used. We re-validated end-to-end connectivity and confirmed that the payloads were forwarded to the server.

6. Conclusions and outlook

The proposed dual-mode, RTC-duty-cycled design achieves a clear separation of concerns and robust, energy-efficient uploads across heterogeneous links. Future work will consolidate lightweight protocols, refine power domains, harden security/FOTA, and extend multi-GNSS positioning at fleet scale

References

[1]. D. Yang et al., “Understanding Power Consumption of NB-IoT in the Wild, ” Proc. MobiCom, 2020.

[2]. S. Ould et al., “Energy Performance Analysis and Modelling of LoRa, ” Sensors, 2021.

[3]. L. Casals et al., “Modeling the Energy Performance of LoRa, ” Sensors, 2017.

[4]. JSON Lines, “JSON Lines — Newline-Delimited JSON, ” n.d.

[5]. Hangzhou Zhongke Microelectronics Co., Ltd., “AT6558R BDS/GNSS Satellite Positioning SoC Chip Datasheet, ” n.d.

[6]. MinewSemi, “MS21SF1 (LLCC68/SX1262) LoRa Module Datasheet, ” 2024-06-06.

[7]. LoRa Alliance, “LoRa® L2 1.0.4 Specification (TS001-1.0.4), ” 2020/2023.

[8]. WIZnet, “W5500 Datasheet, ” v1.0.9, 2025-08-14.

Cite this article

Sen,W. (2025). Programming Design of an STM32-Based Positioning Information Acquisition and Upload System. Applied and Computational Engineering,184,65-71.

Data availability

The datasets used and/or analyzed during the current study will be available from the authors upon reasonable request.

Disclaimer/Publisher's Note

The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of EWA Publishing and/or the editor(s). EWA Publishing and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

About volume

Volume title: Proceedings of CONF-MLA 2025 Symposium: Intelligent Systems and Automation: AI Models, IoT, and Robotic Algorithms

ISBN：978-1-80590-307-9(Print) / 978-1-80590-308-6(Online)

Editor：Hisham AbouGrad

Conference website: https://www.confmla.org/

Conference date: 17 November 2025

Series: Applied and Computational Engineering

Volume number: Vol.184

ISSN：2755-2721(Print) / 2755-273X(Online)

© 2024 by the author(s). Licensee EWA Publishing, Oxford, UK. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license. Authors who publish this series agree to the following terms:
1. Authors retain copyright and grant the series right of first publication with the work simultaneously licensed under a Creative Commons Attribution License that allows others to share the work with an acknowledgment of the work's authorship and initial publication in this series.
2. Authors are able to enter into separate, additional contractual arrangements for the non-exclusive distribution of the series's published version of the work (e.g., post it to an institutional repository or publish it in a book), with an acknowledgment of its initial publication in this series.
3. Authors are permitted and encouraged to post their work online (e.g., in institutional repositories or on their website) prior to and during the submission process, as it can lead to productive exchanges, as well as earlier and greater citation of published work (See Open access policy for details).