-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathProject Notes
More file actions
52 lines (46 loc) · 2.43 KB
/
Copy pathProject Notes
File metadata and controls
52 lines (46 loc) · 2.43 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
Goal: “Develops the collection device that aggregates all of the data from the microbits, and uploads the data to a server"
-- Needed: 1 Working Project Director, 1 Python Programmer, 1 Database Specialist, 1 Web Programmer
What needs to be done:
- Get data from the centralized micro bit through the bluetooth connection
- Talk/communicate with the micro bit... If the data is not being sent, contact someone/send some signal to the micro bit administrator
- Store data in the database
Tasks:
- Get the detailed data format(decimal points, data type, ...etc)/how often the data is sent
- Research on how to get data from the micro bit through bluetooth
- Decide how to store the data ... on database? on laptop?
Use Cases:
- Store data in the database
- View stored data
SCRUM Requirements Meeting Notes:
- Hardware needed
- Laptop/microbit
- Software needed
- MongoDB
- Python Shell
- Tasks/Subtasks/Plans
- Design the database (Logan/Parker)
- Build the database (Logan/Parker)
- learn how to pull data from the microbit (Ruby/Tomoki)
- Format data (Ruby/Tomoki)
- Add data to tables (All)
- Figure out the data the other groups will get (Tomoki)
- Items to purchase
- None
Final Design:
Since we know that we will receive only 4 digit integers as inputs in all three scenarios, we will test various data-input frequencies
and the database storage volume, and that will be our test for all three scenarios.
- Data Input Frequency/Speed Constraints
The centralized microbit can take inputs up to every 2 milliseconds and send the data to our laptop without any data loss,
and the data can be stored in our database.
- Database Storaga Volume
Using MongoDB, our database is stored internally/locally on our computer so we can expand the storage size as needed.
To do after the senario is chosen:
- Figure out how to tell which sensor the data is coming from and if the data should be stored or ignored??
- Team Storage will recieve only the duration data(in secounds) so we do not need to worry about simultaneous inputls from
multiple sensors.
- Final data format decisions
- 4 digit integers(secounds)
- Time function ... When to check the time? When they sense the person entering? OR when our laptop recieves the data?
- No need to worry about this because the Team Sensor will calculate run time.(Exsit time - Enter time)
- Make sure with the networking group that the two data will not come in at the same time.
- We will not get this issue.