|
We use UDP/IP as transport mechanism. All measurement data will be broadcast. This allows for redundant data acquisition and storage. Initially, we will not use encryption or authentication, which restricts us to physically isolated networks and physical security.
|
|
We use UDP/IP as transport mechanism. All measurement data will be broadcast. This allows for redundant data acquisition and storage. Initially, we will not use encryption or authentication, which restricts us to physically isolated networks and physical security.
|
|
The microcontroller will do no any pre-processing of the data, but instead will only relay the data onto the network
|
|
The microcontroller will do no any pre-processing of the data, but instead will only relay the data onto the network
|
|
|
|
|
|
**Requirements:**
|
|
# Requirements
|
|
Each packet should contain all necessary information to identify the both the hardware connected, but also the microcontroller hardware itself, and also the software version used. Furthermore, each packet should be self-contained and self-describing, i.e. not only the raw data, but also the description (e.g. a header) should be included.
|
|
Each packet should contain all necessary information to identify the both the hardware connected, but also the microcontroller hardware itself, and also the software version used. Furthermore, each packet should be self-contained and self-describing, i.e. not only the raw data, but also the description (e.g. a header) should be included.
|
|
Ideally data is sent as comma-separated list. This is the case for most (all?) CPCs and similar hardware.
|
|
Ideally data is sent as comma-separated list. This is the case for most (all?) CPCs and similar hardware.
|
|
|
|
|
... | @@ -10,6 +10,43 @@ Ideally data is sent as comma-separated list. This is the case for most (all?) C |
... | @@ -10,6 +10,43 @@ Ideally data is sent as comma-separated list. This is the case for most (all?) C |
|
- message type code? E.g. data, error, device message, …
|
|
- message type code? E.g. data, error, device message, …
|
|
- a data header
|
|
- a data header
|
|
- the data itself, ideally in human readable format
|
|
- the data itself, ideally in human readable format
|
|
-
|
|
|
|
**Open questions:**
|
|
** Proposal **
|
|
|
|
Each packet consists of two sections
|
|
|
|
1. **Header**
|
|
|
|
1. protocol version number (x bytes)
|
|
|
|
1. message type (x bytes)
|
|
|
|
* data
|
|
|
|
* command
|
|
|
|
* announcement
|
|
|
|
1. status byte (1 bytes)
|
|
|
|
* regular message
|
|
|
|
* special (i.e. do not record, for calibration or testing)
|
|
|
|
1. time stamp of sending (x bytes)
|
|
|
|
1. sender information
|
|
|
|
1. target information?
|
|
|
|
1. payload length in bytes (x bytes)
|
|
|
|
3. **Payload** layout depending on message type
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Header
|
|
|
|
## Required information
|
|
|
|
* protocol version (2 byte?)
|
|
|
|
* message type (2 bytes?)
|
|
|
|
* data from device
|
|
|
|
* data from controller
|
|
|
|
* metadata/housekeeping data from device
|
|
|
|
* metadata/housekeeping data from controller
|
|
|
|
* announcement (new device or component online) (or use different port?)
|
|
|
|
* command for device
|
|
|
|
* command for controller
|
|
|
|
* error from device
|
|
|
|
* error from controller
|
|
|
|
* network information command
|
|
|
|
|
|
|
|
* time stamp of sending (x bytes, format?)
|
|
|
|
*
|
|
|
|
|
|
|
|
# Open questions:
|
|
- message length limitation: The maximum safe [UDP payload is 508 bytes](https://stackoverflow.com/a/35697810), is this enough for our purposes or do we need to worry about fragmentation? |
|
- message length limitation: The maximum safe [UDP payload is 508 bytes](https://stackoverflow.com/a/35697810), is this enough for our purposes or do we need to worry about fragmentation? |
|
|
|
\ No newline at end of file |