Update formatting, clarify sentences.

gatt_formats.md

@@ -1,5 +1,6 @@
 # GATT data format
-*Lifecycle: alpha*
+**Lifecycle: alpha**
+
 As there are many different use cases which require different setup from RuuviTags,
 we're building extensible and generic protocol for configuring and reading data from RuuviTag.
 As always, any design decisions are compromises between complexity, reliablity and coverage for
@@ -12,7 +13,7 @@ devices so that they'll better suit your needs without the need of adjusting fir
 
 ## GATT Message Structure
 The GATT messages have a format of 3 bytes of header + 8 bytes payload. This is to be as compatible as possible
-with BLE Mesh which will have a header of C0...FF, FF, 04 and 8 bytes of payload. 
+with BLE Mesh which will have a header of C0...FF, FF, 04 and 8 bytes of payload e.g. `0xC0FF04` + 8 bytes payload. 
 
 The first byte of the header is a `destination`, second byte is a `source` and the third byte is a `type` of the message.
 Messages are routed to application first by their `destination` and then by their `type`. 
@@ -41,7 +42,8 @@ Examples for data exchanges are in the sections below.
 - Sensor log write/read: *alpha*
 
 ### Sensor configuration writing and reading.
-*Lifecycle: planned*
+**Lifecycle: planned**
+
 Sensor configuration message is one standard 8-byte payload.
 After the sensor has been configured, sensor will start sampling, and possibly applies given DSP function to data.
 
@@ -64,17 +66,19 @@ typedef struct __attribute__((__packed__)){
 #### Example - TODO
 
 ### Sensor log write/read
-*Lifecycle: alpha*
+**Lifecycle: alpha**
+
 As of 9/2019 and firmware version 3.26.x logging interval and values are hardcoded. 
 _[Demo](https://www.youtube.com/watch?v=mVeEGJYrvNA&feature=youtu.be)_
-_Try it out: Install [RuuviFW 3.26.0](https://jenkins.ruuvi.com/job/ruuvi.firmware.c/30/artifact/targets/ruuvitag_b/armgcc/ruuvitag_b_armgcc_ruuvifw_test_v3.26.0_full.hex) and read the logs with [RuuviWebBLE](https://ojousima.github.io/ojousima.ruuviwebble.ts/)_
+
+_Try it out: Install [RuuviFW 3.26.0](https://jenkins.ruuvi.com/job/ruuvi.firmware.c/30/artifact/targets/ruuvitag_b/armgcc/ruuvitag_b_armgcc_ruuvifw_test_v3.26.0_full.hex) and read the logs with [RuuviWebBLE](https://ojousima.github.io/ojousima.ruuviwebble.ts/) using Chrome and Web Bluetooth_
 
 The log is read with command that has a header destination set to target value, source to any and type as a log read. The payload is two 32-bit timestamps, seconds since unix epoch. First timestamp is current time, and second time is the lower bound of log data timestamps. For example if the timestamps are 1567047917 and 1566047917 data from time between 2019-08-13 13:18 and 2019-08-29 03:05 is sent.
 The logs are sent in format where header destination is the source of read command, source is the temperature and type is log write. Payload is 4 bytes of timestamp and 4 bytes of int32_t, where unit is dependent on value if being read. On temperature the unit is 0.01C, on humidity the unit is 0.01 RH-% and on pressure the unit is 1 Pa. _TODO: Use milli-SI unit for all values?_
 
 When the log buffer is sent entirely, a special message with the entire payload set to 0xFF is sent. It should be noted that there is no way to send only “missing sections” of data from the middle of the logs, logs are always retrieved to the end of the stored data.
 
-Constants for endpoints and associated units are listed at [Ruuvi Endpoints](./ruuvi_endpoints.md).
+Constants for endpoints and associated units are listed at [Ruuvi Endpoints](./ruuvi-endpoints.md).
 
 ### Example