Central website has synced data, but the individual locations should manage their own data by default.
The last synced data may be used if they either: don't want to handle it themselves, or if the ability to access the yvr. subdomain is unavailable.
* Airports
* yyc.BLAH.BLAH
* yvr.BLAH.BLAH
* Other Schools
* sait.BLAH.BLAH
* Museums
* cmch.BLAH.BLAH (Cambridge Museum of Computing History)
* Large Libraries
## How To Do GPS
### Option 1
GPS for all devices.
Advantages:
* Easy to sync
* Can be automatically synced
* Can be made to very rarely have incorrect coordinates.
* Could sync with the rest of the world, if required.
* Can calcualte an average across time and get more accurate. (10-20 seconds, but still useful).
Disadvantages:
* High cost
* (Very) High power consumption
* More likely to require maintainence as more parts are involved.
* Could potentially go out of sync temporarily if automated.
* For example: a chip in a basement could potentially receive bad data due to the concrete/metal between it and a GPS satealite.
### Option 2
* Separate into two models of triangulation chips.
* One with GPS
* One without
* Use the outermost chips as GPS trackers. Get valid data at all times so that they are always in sync.
* Generally outdoors or next to windows.
* Only a few are necessary on the edges, and all other nodes sync by relative coordinates.
### Option 3
* No GPS.
* Allow a GPS connection through USB-C(?)
* Allow the GPS to syncronize *once* per device.
* Potentially high maintainence cost if GPS needs to be recalibrated.
* It shouldn't happen, but if it did... big oof.
* However, due to the meshing capabilities, in theory two to five correctly located notes would be able to cascadingly correct issues further away from the edge nodes (the ones with GPS).
### Option 4
* Use the user's phone to manage GPs locations.
* This can update potentially inaccurate data.
* Find a way to figure out if the phone is providing bad/invalid/inaccurate data.
Tait Hoyem
2 years ago