|
|
|
|
|
|
55
|
value, and the device uses this salt for all further communication until the next
|
55
|
value, and the device uses this salt for all further communication until the next
|
|
56
|
reset, increasing the salt value by one for each packet sent. This scheme removes
|
56
|
reset, increasing the salt value by one for each packet sent. This scheme removes
|
|
57
|
the need for the device to generate random numbers, as microcontrollers commonly
|
57
|
the need for the device to generate random numbers, as microcontrollers commonly
|
|
58
|
-are not capable of generation of high-quality ranodm numbers.
|
|
|
|
|
|
58
|
+are not capable of generation of high-quality random numbers.
|
|
59
|
|
59
|
|
|
60
|
The packet sent from the device to the base station to request a salt consists of
|
60
|
The packet sent from the device to the base station to request a salt consists of
|
|
61
|
a single byte with the sender ID and is recognized by the base station by its
|
61
|
a single byte with the sender ID and is recognized by the base station by its
|
|
|
|
|
|
|
93
|
3. Values: Reply to a `GetValues` packet containing the requested information.
|
93
|
3. Values: Reply to a `GetValues` packet containing the requested information.
|
|
94
|
|
94
|
|
|
95
|
The 3 most significant bits of the field encode the element count for packets
|
95
|
The 3 most significant bits of the field encode the element count for packets
|
|
96
|
- which can holt multiple elements (as described below).
|
|
|
|
|
|
96
|
+ which can hold multiple elements (as described below).
|
|
97
|
|
97
|
|
|
98
|
4. Packet payload (always 21 bytes, padded with zero bytes)
|
98
|
4. Packet payload (always 21 bytes, padded with zero bytes)
|
|
99
|
|
99
|
|
|
|
|
|
|
|
106
|
possible value types and the corresponding value size are listed below.
|
106
|
possible value types and the corresponding value size are listed below.
|
|
107
|
* GetValues: The payload consists of a list of value types. It is the sender's
|
107
|
* GetValues: The payload consists of a list of value types. It is the sender's
|
|
108
|
responsibility to ensure that the resulting response fits into one packet.
|
108
|
responsibility to ensure that the resulting response fits into one packet.
|
|
109
|
- If too many values are requested, the base station will ignore the request.
|
|
|
|
110
|
- * Values: The payload consists of a list of (value type, report time, value)
|
|
|
|
111
|
- tuples. The report time is the unix time of the last report of the
|
|
|
|
112
|
- corresponding sensor node.
|
|
|
|
|
|
109
|
+ If too many values are requested, the base station will ignore the request.
|
|
|
|
110
|
+
|
|
|
|
111
|
+ TODO: Describe the network topology above and specify which payload type is
|
|
|
|
112
|
+ used by which device for which purpose.
|
|
|
|
113
|
+
|
|
|
|
114
|
+ TODO for GetValues: There should be a way for a device to request
|
|
|
|
115
|
+ the value from a certain source (e.g. the termperature of the living room).
|
|
|
|
116
|
+
|
|
|
|
117
|
+ TODO for GetValues: There should be an answer packet to signal that the
|
|
|
|
118
|
+ requested source is not available.
|
|
113
|
|
119
|
|
|
114
|
5. CRC-16-CCITT checksum
|
120
|
5. CRC-16-CCITT checksum
|
|
115
|
|
121
|
|
|
116
|
### Value types:
|
122
|
### Value types:
|
|
117
|
|
123
|
|
|
118
|
-0. Time (4 bytes): The value is a unix time in seconds.
|
|
|
|
|
|
124
|
+0. Time (8 bytes): The value is a unix time in seconds.
|
|
119
|
1. Temperature (2 bytes): The value is a temperature value in tenths of degrees
|
125
|
1. Temperature (2 bytes): The value is a temperature value in tenths of degrees
|
|
120
|
celsius.
|
126
|
celsius.
|
|
121
|
2. Pressure (4 bytes): The value is a pressure in pascal.
|
127
|
2. Pressure (4 bytes): The value is a pressure in pascal.
|
|
122
|
3. Humidity (2 bytes): The value is the relative humidity in tenths of a percent.
|
128
|
3. Humidity (2 bytes): The value is the relative humidity in tenths of a percent.
|
|
123
|
|
129
|
|
|
|
|
130
|
+# Data handling:
|
|
|
|
131
|
+
|
|
|
|
132
|
+The base station collects all needed data from the sensors and other sources and
|
|
|
|
133
|
+acts as a server for all devices.
|
|
|
|
134
|
+
|
|
|
|
135
|
+- The base station shall contain a list of all devices on the network.
|
|
|
|
136
|
+- The base station shall have an interface where devices can be added and removed
|
|
|
|
137
|
+ from the network.
|
|
|
|
138
|
+- Every sensor shall be registered using a (module id, location) tuple.
|
|
|
|
139
|
+- The base station shall monitor the update rates of the devices.
|
|
|
|
140
|
+- Every device shall be assigned a threshold of missed updates after which it is
|
|
|
|
141
|
+ considered to be offline.
|
|
|
|
142
|
+- The base station shall indicate that a device is offline if another device
|
|
|
|
143
|
+ requests a report from the offline device.
|
|
|
|
144
|
+
|
|
124
|
# License
|
145
|
# License
|
|
125
|
|
146
|
|
|
126
|
The hardware contained in this repository is licensed under the [CERN Open Hardware Licence Version 2 - Weakly Reciprocal](cern_ohl_w_v2.txt), and the software is licensed under the [GNU General Public License v3](gpl-3.0.md).
|
147
|
The hardware contained in this repository is licensed under the [CERN Open Hardware Licence Version 2 - Weakly Reciprocal](cern_ohl_w_v2.txt), and the software is licensed under the [GNU General Public License v3](gpl-3.0.md).
|