top of page

Let's check out the backend!


To begin the data pipeline, the sensor data is initially collected from the ESP32 microcontroller. With Wi-Fi capabilities, the ESP32 can send HTTP requests directly to the backend server located on Heroku, a cloud deployment service. This server was created as a REST API using Flask, a popular Python web framework. After completing a reading, the ESP32 sends an HTTP POST request containing JSON-formatted sensor data to the server. Upon receiving this request, the server cross-checks the data formats and then proceeds to store it in a PostgreSQL database found on Google Cloud.


Here is an example of the sensor data formatted in JSON that would be sent is as:


Database Schema


PostgreSQL allows for the use of multiple tables within a database that share the same schema. In the case of multiple headbands, individual data would be stored in distinct tables. However, to prototype the project, only one headband was utilized, resulting in the employment of a singular table. Here is the SQL syntax for the table schema:


Active Sessions


As long as the Heroku server is up and running, the API can receive requests and store data in the Google Cloud database. To collect data during headband usage, a session must be initiated by the user. During an active session, the front-end dashboard displays live data. Past sessions can be accessed to view data from a specific practice or game.

Initiating a session triggers the launch of a backend server process responsible for computing database values based on values from different rows and columns. One such example is the time_delta column, which records the time differences between current and subsequent timestamps. Despite the system's design to capture measurements at a consistent rate, a distinct time_delta is computed on each occasion to reconcile any differences arising from variations in hardware and network latencies.


Values are produced at 10-second intervals during an active session. The software was designed to carry out these operations periodically. This approach was preferred over calculating values every time a row was added because it is more efficient to perform operations on multiple rows simultaneously rather than on each row individually. This reduces the number of SQL queries sent to the database server. Moreover, the program must account for null values in the first session entry, which complicates the code.


The calculated results are as follows:



3 views0 comments

Comments


bottom of page