You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
80 lines
2.5 KiB
Plaintext
80 lines
2.5 KiB
Plaintext
time to plan
|
|
|
|
terms
|
|
|
|
RLC - reactor level coordinator (Beagleboard)
|
|
RH - Reactor Handler (goroutine)
|
|
SH - sensor handler (gourtine)
|
|
Reactor Side:
|
|
|
|
needs
|
|
- way to discover active sensors
|
|
- spin up goroutine for each sensor responsible for keeping status and logs
|
|
- way to read back and truncate logs for safe data delivery to servr
|
|
- routing requests from reactor level coordinator to relevant sensor
|
|
- internal memory sharing and channels for reactor level coordination
|
|
|
|
thoughts
|
|
- maybe the RLC can be responsible for packaging data for coordinator response
|
|
adv:
|
|
- clears up the network
|
|
- simplifies pinging
|
|
- keeps the data aributrary
|
|
cons:
|
|
- unknown data size
|
|
- how to coordinate data structure
|
|
|
|
Server Side:
|
|
|
|
needs
|
|
- way to look into a config file for active reactors
|
|
- should then spin up a goroutine for each reactor
|
|
- responsible for recovery and consistent communication
|
|
- individual database entries
|
|
- API?
|
|
- use gRPC for comms between server and BB
|
|
- each reactor handler needs mechanism for pinging, recovery, and database correctness
|
|
-
|
|
|
|
message PingRequest {
|
|
// do we even need anything in a ping request?
|
|
}
|
|
|
|
message PingResponse {
|
|
repeated Sensor sensor = 1;
|
|
}
|
|
|
|
message Sensor {
|
|
string type = 1;
|
|
bool status = 2;
|
|
byte data = 3;
|
|
}
|
|
|
|
sensors := [string]q
|
|
|
|
6/23 TODO:
|
|
|
|
X- BBB mem fix
|
|
- 32 gig for the main but where to put the OS?
|
|
- obv in EMMC but how to init sd card? (probably dev tree :( )
|
|
Y- Server side impl
|
|
Y - Need a struct for the RC
|
|
X - Should we store and load configs based on IDs? (efficiency of this vs performance increases i.e. bandwidth vs storage)
|
|
Y/X - Who should kill the RC and how do we know its dead? (Garbage collection to the rescue hopefully)
|
|
|
|
X- UPDATE PRES
|
|
- Add bottle necks for each part in that section
|
|
- I2C: 128 addrs and ~90 bytes/s per device at 128 devs optimally
|
|
- BB: Hardware is upgradeable even customizable ;)
|
|
- Server: Its overkill as is, can benchmark with a rudementary go overload once its completed
|
|
- Sensor configs
|
|
- how to store sensor info efficiently and searchably lol
|
|
- who needs to know what the sensor is? (Just the SM? Even the SM?)
|
|
X- TUI
|
|
- pls this would be so sick
|
|
TODO: 6-24
|
|
|
|
Y - Pres stuff from yesterday + python gRPC abstraction
|
|
Y - RPI flash
|
|
- Add resiliance to coordinator process (aka error handley blech)
|