Context
A tracker expected to conserve energy for days has different needs from one that sends positions throughout a workout. The team explored GNSS and cellular modes, and different paths for small and larger amounts of data.
Approach
I worked on the microcontroller firmware and integration with AWS IoT Core and Lambda. I describe the rest of the web and cloud architecture as team work, not as my individual implementation.
System
- Tracker: Arduino MKR Zero with ATSAMD21G18 (ARM Cortex-M0+), GNSS, sensors and Quectel BG96 for GSM, LTE-M and NB-IoT
- Firmware: real-time and power-saving modes, deep sleep, MQTT and HTTP
- Small payloads: HTTP/API Gateway; larger measurement streams: AWS IoT Core and MQTT
- Cloud: Mode Handler Lambda, SQS buffer and Data Handler Lambda
- Team web system: Vue.js, Node.js/Express and MongoDB/Mongoose with REST APIs and repeated position polling
Engineering decisions
- Choose the transport path and location strategy according to data volume and use case.
- Replace asynchronous fire-and-forget processing with SQS so messages are not lost when a Lambda execution ends.
- Account for JWT authentication, salted password hashes, authorization middleware and resource ownership in the team system.
What did not work
The first asynchronous version could lose data when a process ended before outstanding work completed. SQS gave messages a durable buffer. The project explored different transport options; its documentation does not establish production fleet or business metrics.
Result
The documented design connects two tracker modes to HTTP/API Gateway or AWS IoT Core/MQTT, then decouples processing through Lambda and SQS. The web application presents positions, routes and geofences.
What stayed with me
The queue was not architecture decoration. It addressed a specific failure mode: a message needed somewhere to wait until the next processing step had actually taken ownership of it.
My contribution
My CV attributes C/C++ microcontroller firmware and integration with AWS IoT Core and AWS Lambda to me. Vue, Node.js/Express, MongoDB, authentication and deployment belong to the team architecture; I do not claim them all as my individual work.
Two paths through the cloud
The tracker could send small payloads over HTTP/API Gateway. Larger measurement streams used MQTT through AWS IoT Core. A Mode Handler routed the data according to the selected mode. SQS accepted messages for processing, and a Data Handler could work through them independently of the original execution.
Why a queue appeared
The first fire-and-forget version started asynchronous work and ended the process without waiting for every outstanding step. If the execution ended, data could be lost. With SQS, a message remained available until another handler processed and acknowledged it.
The team web application
The overall system included a Vue.js frontend, Node.js/Express, MongoDB with Mongoose and REST APIs. The interface showed trackers, routes, geofences and measurements; positions were polled repeatedly. The documentation also describes JWT, hashed passwords, authorization, separate Docker containers and deployment on AWS EC2.