You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we have a list of mac address device id's for each central node, lora node, utd node, etc in the network. The problem is that individual devices are exchanged when nodes come in for repair and nodes themselves often move physical location between westec, the lab, and out in the field. To make interfacing with the data simpler, we should generate a data table with the physical addresses for each node together with the date ranges at that address. This will further facilitate the reports as what we really want it to analyze the AQ data at a given location regardless of which nodes/sensors are placed there.
The text was updated successfully, but these errors were encountered:
A file with "nice names" (perhaps using LaTeX strings) for each sensor. Example pm2_5$\longrightarrow$PM 2.5 as well as supplied instrument uncertainty information
A file matching mac addresses to node names (we already have this in the AirQualityAnalysisWorkflows repo)
A file containing street address together with latitude, longitude, altitude, and some kind of name for each deployment location (e.g. Westech, Joppa, etc...)
We can then use these files when formatting graphs, loading data, etc...
Generates a table on OSN for AirQualityNetwork/data/location/plus_code/year/month/day with links to all relevant time series for that day at that location.
We should make the code coarse enough that the exact location is not easily identifiable.
Currently we have a list of mac address device id's for each central node, lora node, utd node, etc in the network. The problem is that individual devices are exchanged when nodes come in for repair and nodes themselves often move physical location between westec, the lab, and out in the field. To make interfacing with the data simpler, we should generate a data table with the physical addresses for each node together with the date ranges at that address. This will further facilitate the reports as what we really want it to analyze the AQ data at a given location regardless of which nodes/sensors are placed there.
The text was updated successfully, but these errors were encountered: