[incubator-plc4x] branch master updated: Some super-minor textual changes

[cd...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

cdutz pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-plc4x.git


The following commit(s) were added to refs/heads/master by this push:
     new 001c092  Some super-minor textual changes
001c092 is described below

commit 001c092c488a50845725e6f8beb08deaa0e37f3c
Author: Christofer Dutz <ch...@c-ware.de>
AuthorDate: Mon Aug 13 09:56:54 2018 +0200

    Some super-minor textual changes
---
 src/site/asciidoc/protocols/delta-v/index.adoc | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/site/asciidoc/protocols/delta-v/index.adoc b/src/site/asciidoc/protocols/delta-v/index.adoc
index da1514f..bb5e341 100644
--- a/src/site/asciidoc/protocols/delta-v/index.adoc
+++ b/src/site/asciidoc/protocols/delta-v/index.adoc
@@ -32,7 +32,7 @@ All information we got, we got by inspecting these captures, building hypothesis
 
 Definitely we will not have interpreted everything correct and we'll probably do a lot of updating of this page.
 
-Due to this uncertainty we are only implementing a `promiscuous mode` driver, which is able to read ongoing traffic without the ability to actively interact with the system.
+Due to this uncertainty we are only implementing a `promiscuous mode` driver, which will be able to read ongoing traffic without the ability to actively interact with the system.
 
 === The Wrapper Protocol
 
@@ -78,7 +78,7 @@ But we could be wrong with this assumption and this just being a result of conve
 The 3 bytes after the id seem to relate to a timestamp.
 Inspecting the packets and correlating this to the timestamps in our packet captures, lead us to the assumption that this timestamp uses the first 14 bits for encoding seconds and the last 10 bits for encoding the sub-second fraction.
 While a 3 byte timestamp is only able to measure a 10 minute time-slot and is probably not usable for absolute time measuring, it might be useful to measure transfer times.
-For this a 4 byte value would have been a waste of network capacity and a 2 byte value wouldn't be able to measure up to 16 seconds, which might be too short when taking into account packet resending and network timeouts.
+For this a 4 byte value would have been a waste of network capacity and a 2 byte value wouldn't be able to measure more than 16 seconds, which might be too short when taking into account packet resending and network timeouts.
 So for now we are assuming this format is used.
 
 The following 3 bytes seem to have a constant value of `0x800400` for most packets, except the ones with a type of `0x03` and `0x04`.
@@ -89,11 +89,11 @@ After these mysterious 3 bytes comes the actual payload of the packet.
 The details of these will be discussed later in this document.
 
 At the end comes a short value that seems to be a completely different value for every packet.
-As the message id is incremented every time, we are assuming this is a simple checksum.
-However we currently have no idea on how this is calculated.
+As the message id and timestamp are different for every message, we are assuming this is a simple checksum.
+However we currently have no idea on how this is calculated and we haven't invested any time in finding this out.
 
 UDP being connectionless the DeltaV network protocol seems to require acknowledging.
-This is done by sending a packet back to the originator, but with a length of `0x0000` and the same `type` and mesasge-id`
+This is done by sending a packet back to the originator, but with a length of `0x0000` and the same `type` and mesasge-id` as the packet that is acknowledged.
 
 === High Level View of the Protocol