Updated 5 Customising a Horus Binary v2 Packet (markdown)

5-Customising-a-Horus-Binary-v2-Packet.md

@@ -27,19 +27,21 @@ The information necessary for interpreting the custom data section is contained
 
 An example entry in this file is shown below:
 ```
-"HORUSTEST": {
-    "struct": "<BbBfH",
+"4FSKTEST-V2": {
+    "comment": "Default custom fields for RS41ng",
+    "struct": "<hhBHxx",
     "fields": [
-        ["cutdown_battery_voltage", "battery_5v_byte"],
-        ["external_temperature", "none"],
-        ["test_counter", "none"],
-        ["test_float_field", "none"],
-        ["test_int_field", "none"]
+        ["ascent_rate", "divide_by_100"],
+        ["ext_temperature", "divide_by_10"],
+        ["ext_humidity", "none"],
+        ["ext_pressure", "divide_by_10"]
     ]
 },
 ```
 
-The entry is named with the payload's callsign (in this case `HORUSTEST`), which must match the entry in [payload_id_list.txt](https://github.com/projecthorus/horusdemodlib/blob/master/payload_id_list.txt). 
+The entry is named with the payload's callsign (in this case `4FSKTEST-V2`), which must match the entry in [payload_id_list.txt](https://github.com/projecthorus/horusdemodlib/blob/master/payload_id_list.txt). 
+
+**If no matching callsign entry is found, the metadata for the 4FSKTEST-V2 callsign will be used, which contains the default custom telemetry fields transmitted by the [RS41ng](https://github.com/mikaelnousiainen/RS41ng) firmware. If you are happy with these fields, then you do not need to take any further action.**
 
 ### `struct`
 The `struct` entry tells the decoder how to interpret the 9 bytes, and is a [Python struct 'format string'](https://docs.python.org/3/library/struct.html). The text `<BbBfH` might look a bit arcane, but is a shorthand way of describing packed binary data types. 
@@ -55,15 +57,15 @@ Some common data types that we would expect within high-altitude balloon telemet
 * `x` - A pad byte - not interpreted.
 
 
-For the `HORUSTEST` example, the string is indicating that the 9 bytes contain:
+For the `4FSKTEST-V2` example, the string is indicating that the 9 bytes contain:
 * `<` - Little-endian ordered data (for multi-byte data types - common on most modern platforms)
-* `B` - Byte 1 is a unsigned 8-bit integer (0 - 255).
-* `b` - Byte 2 is a signed 8-bit integer (-128 - 127).
-* `B` - Byte 3 is a unsigned 8-bit integer.
-* `f` - Bytes 4-7 are a 32-bit floating point number.
-* `H` - Bytes 8-9 are a unsigned 16-bit integer (0-65535)
+* `h` - Bytes 1-2 are a signed 16-bit integer (-32768 - 32767) 
+* `h` - Bytes 3-4 are a signed 16-bit integer (-32768 - 32767) 
+* `B` - Byte 5 is a unsigned 8-bit integer (0 - 255).
+* `H` - Bytes 6-7 are a unsigned 16-bit integer (0-65535)
+* `xx` - Bytes 8-9 are unused.
 
-So as an example, if the custom byte area contained the data `0AD87910069E3F162C`, this would be interpreted as values (10, -40, 121, 1.2345600128173828, 11286).
+So as an example, if the custom byte area contained the data `12014AFE0048040000`, this would be interpreted as values (274, -438, 0, 1096). These values are then further adjusted using the field post-processing described below.
 
 ### `fields`
 While the `struct` entry tells us how to split the bytes into different fields, we would like to provide some information as to what each of the fields are, and potentially do some post-processing of the field data.
@@ -78,13 +80,13 @@ Additional post-processing functions can be added if necessary - these would nee
 ### UKHAS Sentence Generation
 Each of the defined fields are appended onto the UKHAS-compliant sentence generated by the decoder. A sentence without any custom fields would look something like this:
 ```
-$$HORUSTEST,700,06:42:14,-34.00000,138.00000,100,0,10,40,3.10*CRC16
+$$HORUS-V2,700,06:42:14,-34.00000,138.00000,100,0,10,40,3.10*CRC16
 ```
 This is the same format produced when decoding a Horus Binary v1 packet.
 
-With the addition of the custom fields in the example above, it would look like:
+With the addition of the custom fields in the example above, it might look like:
 ```
-$$HORUSTEST,700,06:42:14,-34.00000,138.00000,100,0,10,40,3.10,10,-40,121,1.234560,11286*CRC16
+$$HORUS-V2,630,01:29:44,-34.35389,139.96246,16244,66,10,-9,1.31,2.74,-43.8,0,109.6*CRC16
 ```
 You will need to define an appropriate Habitat payload document for the field names to show up correctly on the HabHub tracker.