Projet

Général

Profil

Localisation blue tooth » Fonctions.md

Guillaume Sion, 11/09/2022 19:29

 

Hammer project

Locate lost objects in a workshop

Word used

  • Device : Is called a device each object that has to be located througt this system

  • Ground station :

  • Operator :

  • Main system : The server which receive the data and process it

Device

Hardware

ESP 32 or NRF51 or NRF52
Cheap hardware with with high availability and well documented with plug and play codes

Temp sensor ?
Humidity sensor ?
Reed switch ?

2 versions ?
Button cell and lithium battery with more capacity

Functions

Send message to groud station with optional sensor data and battery status
Send selected range in meters

Choices

Eddystone (over bluetooth). Developped by Google against Apple iBeacon protocol, this standard allow more data to be sent to the server than other methods
Still well supported by libraries

Not directly LoRa beacause of price. Same price than ESP32 or NRF5x but need an additionnal MCU

Main system (aka brain)

Hardware

Linux computer, probably Single Board Computer (RPi like)

Function

Provide User Interface
Provide search fonction
Store data
Show data on a map or a picture with scale (in order to show estimated position)
Display battery alerts
Provide external API

Database

To be discused
A first idea can be the fllowing table, where every row is a device

| Id  | deviceId | averageTimestamp | Ground stations | sensor data |
|-----|----------|------------------|-----------------|-------------|
| INT | INT      |    timestamp     | STRING          | STRING      |

Here the issue is that the device itself does not send data
Instead, the grounds stations will send the data

Because the system may find other uses and, we may want to store string in sensor data column
Moreover, we don't know how many ground stations will be seen
We may be somewhere between SQL and NoSQL, but maybe closer to SQL

A second idea is to sort by ground station. Each device will appear several time and sensor data will be hard to process and store in an intuitive way

| Id  | groundStation | timestamp | FoundDevices |
|-----|---------------|-----------|--------------|
| INT | INT           | timestamp | STRING       |

A third idea is to store everything in a JSON NoSQL way

In conclusion, what can be a good solution is the combination of two tables
One to find easily the last position of the sensor, updated with the last 5 ground stations and some sensor data

| Id  | deviceId | groundStation1           | gS2 | gS3 | gS4 | gS5 | Temperature | Battery lvl  | Humidity | Other  |
|-----|----------|--------------------------|-----|-----|-----|-----|-------------|--------------|----------|--------|
| INT | INT      | STRING, name + timestamp | "   | "   | "   | "   | INT         | INT          | INT      | STRING |

And one where a search can be more difficult for log purposes

| Id  | groundStation | timestamp | FoundDevices |
|-----|---------------|-----------|--------------|
| INT | INT           | timestamp | STRING       |
(2-2/4)