Project Overview - rngh-uni/CSSE4011-s1-2025-Project-Fortuna-Gold GitHub Wiki
System Overview
The project idea centers on developing a mobile environmental monitoring system, initially envisioned as an RC car but scalable to aerial drones. The Unmanned Ground Vehicle (UGV), will be equipped with a mobile node (Thingy52) that will collect critical environmental data via the onboard sensors (CO2, TVOC, humidity and temperature). The mobile node will transmit sensor data via bluetooth to a base node (nrf52840 dk) where it's processed and visualized via the viewer (M5 Core2). The base node will forward this data over to the server (PC) via serial communication. To ensure data integrity and trustworthiness, particularly for regulatory and scientific purposes, the server will record the sensor data on an IoT blockchain, which will be viewable via a web dashboard. In practical scaled applications long-range communication methods such as radio telemetry or cellular, would need to be implemented as an alternative to bluetooth communication and additional environmental sensors (PM2.5/ozone/NO2/SO2) could be connected to the mobile node to increase the exhaustiveness of the data collected.
This approach enables efficient data collection in diverse and challenging environments, offering a cost-effective alternative to traditional monitoring stations. For instance, government agencies can use such a system for nationwide air quality monitoring, as demonstrated by programs like those of TERN, which employs drones for detailed ecosystem mapping and monitoring (https://www.tern.org.au/ecosystem-mapping-with-drone-remote-sensing/). The integration of blockchain technology enhances the reliability and transparency of the collected data, making it suitable for applications in regulatory compliance and scientific research. In a scaled application, this project would see an array of UGV’s or aerial drones being deployed each with their own base node, this approach would take advantage of the decentralized nature of blockchain data management systems to boost the integrity of the recorded data.
Finally, the Mobile node will have 2 configurable modes of operation: Discrete and Continuous. In the discrete mode, the mobile node will wait to receive a signal from the base node before collecting and transmitting sensor data. In the Continuous mode, the mobile node will continuously collect and transmit the sensor data to the base node. The web dashboard will feature controls to switch the mode of the mobile node and to prompt the mobile node for a sample.
Block diagrams
Overall System:
Base node:
Mobile node:
Viewer node:
DIKW Pyramid
Sensor Integration
This project will utilise two sensors that are both onboard the Thingy52:
- HTS221
- CCS811
These sensors will collect the following measurements:
HTS221
- Temperature (°C)
- Humidity (%)
CCS811
- C02 (ppm)
- TVOC (ppb)
Both of the sensors can be accessed via the internal I2C bus (I2C_0). The following devices are attached to the bus:
In addition to the raw sensor measurements, each sensor reading will be allocated an ID and a timestamp by the base node.
Wireless Network Communications
The system will use non-connectable undirected Bluetooth advertisements to communicate between the Thingy52 (mobile node) and nrf52840dk (base node), and the same for between the base node and the viewer. The packets will be structured with the iBeacon format.
The base node will send a request for data collection, which the mobile node will receive. It will then collect data at its location, before sending the data for the base node to detect and read. The base node will also continuously broadcast the gathered sensor data for the M5 Core2 (viewer) to read and display the current sensor values.
The base node’s commands to the mobile node will store its instructions in the major and minor bytes of the advertisement data. The sensor data packets will send the sensor data (gathered as a double precision floating point number) stored in 4 bytes of the UUID slots & the major and minor bytes of the packet. Additionally 2 bytes will be used (also from the UUID slots) to mark the exact type of data being sent (which sensor it is from). The same packet structure will be used by the base node to send data to the viewer.
There will also be a continuous data collection mode, in which the mobile node will continuously gather and broadcast data packets without requiring the base node’s input, though the default behaviour will be discrete data collection.
Message Protocol Diagram
Deliverables & Key Performance Indicators (KPI)
1 Communication (base, mobile, viewer): The first KPI will be to establish communication between all the nodes and ensure signals and sensor values can be sent and transferred between all of them via bluetooth iBeacon protocols. This will be achieved when data is being sent between the three nodes.
2 Sensor Data: The next KPI will be to be able to initiate all 4 of the sensors on the device(Temp, Tvoc, CO2, humidity) used for the mobile node and then to have the mobile node be able to move around and record sensor data that will then be sent over bluetooth sequentially.
3 Blockchain: The next KPI is the usage of blockchain to store information. The way it will work is a signal is sent to the RC car from the PC the mobile node will respond by collecting and sending data back to the PC, the whole interaction will be stored into a block and each transactional block will be chained to the block before it. If all these things can be done successfully this will be a fulfillment of this KPI.
4 Web Dashboard: Another KPI will be use of a web dashboard to display the sensor values transmitted to the PC in 4 individual graphs for each of the sensors in order to be able to monitor the sensor values over time visually. Furthermore the dashboard will have controls to control the mobile node mode of operation and the ability to select which sensors are being polled.
5 Viewer This final KPI will be the usage of the screen on the M5 in order to display the data sent to it via bluetooth, this viewer will be used as a simple way of displaying the sensor values received after every transaction made between the mobile and base node. This will be done by using a bar chart that displays an assumed max value for each sensor based on the current environment for testing and then scaling all the values accordingly to be displayed onto one bar chart.
Deliverables: The goal of this project is to have 3 fully functioning nodes that are capable between the three of them of collecting sensor data from different places in a space being observed and sending them off to a base node which will then store the data using blockchain and send each block to be displayed on both a web dashboard and a viewer node.