program a "central processing node" that collects and collates data coming in from the various sensors on the monitoring network
Measurements are sent at irregular intervals: each sensor message has time-stamp. The central processing node is responsible for recording and logging these messages so that they can be accessed
it also fields incoming requests for various “summaries” of the data collected.
The central processing node must read these incoming messages and respond back with the necessary data
a hardware engineer has rigged up all incoming communications to be routed into the “standard in (stdin)” and all out-going messages to be collected via the “stdout”
All messages are communicated via an ASCII string, which includes a header byte ‘#’, and are terminated by a new-line byte/character ‘\n’, in the following format:
#ID<sensor_node_id>,time:<timestamp (2dp)>,temp:<temperature (2dp)>,seis:<seismic_data (2dp)>
All floating point values are sent with 2 decimal places.
For example, the following message: #ID20,time:245.50,temp:26.75,seis:0.48
Would indicate that a measurement from station ID 20 was sent at local time 245.50 seconds, the temperature was 26.75 deg C and the average measured seismic activity was 0.48 (arbitrary intensity scale units).
the timestamp data within each message should be used to understand the order in which measurements have been made (not the order in which measurement messages are received)
Incoming requests are routed into the stdin via ASCII messages which include a header byte ‘*’, a request type (as a string) and an optional list of comma-separated data relating to the request. Each request message is terminated by a new-line byte/character ‘\n’. There are several request types:
Request: Send latest temperature (send_latest_temp): The request message is sent as:*send_latest_temp:with no additional request data. When received, the central processing node should return the most recent (according to timestamp) temperature measurement made by any sensor node on the network in the form:
temp: <temperature (2dp)> (ID<sensor_node_id>) where <sensor_node_id> is the sensor ID that made the measurement, and <temperature (2dp)> is the actual temperature to 2 decimal places. For example, if the latest measurement made was from sensor ID 103 with a temperature of 23.4 deg C, the return message would be:
temp: 23.40 (ID103)
Request: Send latest seismic reading (send_latest_seis):
The request message is sent as: *send_latest_seis
with no additional request data. When received, the central processing node should return the most recent (according to timestamp) seismic measurement made by any sensor node on the network in the form:
seis: <seismic (2dp)> (ID<sensor_node_id>)
where <sensor_node_id> is the sensor ID that made the measurement, and <seismic (2dp)> is the actual seismic measurement to 2 decimal places.
Request: Send average temperature (send_average_temp):
The request message is sent as: *send_average_temp,<time1>,<time2>
where <time1> and <time2> are two timestamp values, each sent to 2 decimal places. return an average temperature that is calculated using all available sensor readings, from any station ID, that were made within the time interval between <time1> and <time2>, in the form:
avg. temp: <average temperature (2dp)>
Occasionally, the measurements made by a sensor ID between a given time interval have been corrupted for some reason, and should be discarded. The request message is sent as: *del_measurements,ID<sensor_node_id>,<time1>,<time2>
where ID<sensor_node_id> is the affected sensor node, and <time1> to <time2> is the time interval that the measurements have been corrupted. the central processing node should "remove" any logged measurements made by the affected sensor node between the given time intervals. These measurements should not factor into the responses or calculations used to field any future requests messages recevied.
your program should exit
3 pekerja bebas membida secara purata $120 untuk pekerjaan ini
Hello, my name is tim, id like to work with you on this project. I have worked programming many sensors before including for the vivid light festival. I can deliver you a solution in C# using .net or dot net core