Quick and dirty attempt to fix the H1 issue

Author: iriark01

docs/api/api.md

@@ -1,6 +1,6 @@
 # Full API list
 
-## Platform APIs
+# Platform APIs
 
 [Platform APIs](platform.html) provide general purpose MCU management infrastructure, common data structures and a consistent user experience on top of different standard libraries and toolchains.
 
@@ -45,7 +45,7 @@
 </tbody>
 </table>
 
-## Drivers APIs
+# Drivers APIs
 
 [Driver APIs](drivers.html) include analog and digital inputs and outputs on development boards, as well as digital interfaces, which allow your board to interface with a computer or external devices.
 
@@ -99,7 +99,7 @@
 </tbody>
 </table>
 
-## RTOS APIs
+# RTOS APIs
 
 The [Mbed OS RTOS](rtos.html) capabilities include managing objects such as threads, synchronization objects and timers. It also provides interfaces for attaching an application-specific idle hook function, reads the OS tick count and implements functionality to report RTOS errors.
 
@@ -127,7 +127,7 @@ The [Mbed OS RTOS](rtos.html) capabilities include managing objects such as thre
 </tbody>
 </table>
 
-## USB APIs
+# USB APIs
 
 The Mbed OS classes providing USB peripheral functionality, also known as [USB components](../apis/usb.html), inherit from USBDevice and provide specific USB peripherial functionality.
 
@@ -150,7 +150,7 @@ The Mbed OS classes providing USB peripheral functionality, also known as [USB c
 </tbody>
 </table>
 
-## Network socket APIs
+# Network socket APIs
 
 [Network socket APIs](network-socket.html) include the application programming interface for IP networking. In Mbed OS, this API supports both TCP and UDP protocols.
 
@@ -171,7 +171,7 @@ The Mbed OS classes providing USB peripheral functionality, also known as [USB c
 </tbody>
 </table>
 
-## Network interfaces APIs
+# Network interfaces APIs
 
 [Network interfaces](network-interfaces.html) are the application level APIs where users choose the driver, connectivity method and IP stack. These include ethernet, Wi-Fi, cellular and mesh interfaces.
 
@@ -189,7 +189,7 @@ The Mbed OS classes providing USB peripheral functionality, also known as [USB c
 </tbody>
 </table>
 
-## Bluetooth Low Energy (BLE) APIs
+# Bluetooth Low Energy (BLE) APIs
 
 [Bluetooth low energy (BLE)](bluetooth.html) is a low power wireless technology standard for building personal area networks. Typical applications of BLE are health care, fitness trackers, beacons, smart home, security, entertainment, proximity sensors, industrial and automotive.
 
@@ -210,7 +210,7 @@ The Mbed OS classes providing USB peripheral functionality, also known as [USB c
 </tbody>
 </table>
 
-## LoRaWAN APIs
+# LoRaWAN APIs
 
 Arm Mbed OS provides a native network stack for [LoRaWAN](lorawan.html). LoRaWAN is a technology designed for low-power battery-powered devices. These devices operate in an unlicensed spectrum, creating high density wide-area networks.
 
@@ -225,7 +225,7 @@ Arm Mbed OS provides a native network stack for [LoRaWAN](lorawan.html). LoRaWAN
 </tbody>
 </table>
 
-## NFC APIs
+# NFC APIs
 
 You can use [Near-Field Communication (NFC)](nfc.html), a short-range radio technology, to enable use cases such as contactless payments, access control and device pairing.
 
@@ -243,7 +243,7 @@ You can use [Near-Field Communication (NFC)](nfc.html), a short-range radio tech
 </tbody>
 </table>
 
-## Security API
+# Security API
 
 With [Arm Mbed TLS](security.html), a comprehensive SSL/TLS solution, you can include cryptographic and SSL/TLS capabilities in your code.
 
@@ -261,7 +261,7 @@ With [Arm Mbed TLS](security.html), a comprehensive SSL/TLS solution, you can in
 </tbody>
 </table>
 
-## Storage APIs
+# Storage APIs
 
 The [storage APIs](storage.html) include file system APIs, for file system operations, and block devices, which provide the raw storage for the file systems.
 

docs/api/bluetooth/BLE.md

@@ -8,7 +8,7 @@ Arm Mbed BLE, also called `BLE_API`, is the Bluetooth Low Energy software soluti
 
 Mbed’s `BLE_API` interfaces with the BLE controller on the platform. It hides the BLE stack’s complexity behind C++ abstractions and is compatible with all BLE-enabled Mbed platforms. The Mbed OS `BLE_API` automatically configuring the clocks, timers and other hardware peripherals to work at their lowest power consumption.
 
-## `BLE_API`, bridges and stacks
+# `BLE_API`, bridges and stacks
 
 <span class="images">![](../../images/BLEDiagram.png)</span>
 
@@ -18,7 +18,7 @@ You can build a BLE application using Mbed OS, `BLE_API` and a controller-specif
 - The bridge software is specific to each vendor’s platform. It provides the instantiations for the interfaces `BLE_API` offers and helps drive the underlying controller and Bluetooth stack.
 - The Bluetooth stack implements the Bluetooth protocol and is specific to the controller, so a vendor using different controllers may provide different stacks.
 
-## Inside `BLE_API`
+# Inside `BLE_API`
 
 <span class="images">![](../../images/Inside_API.png)</span>
 
@@ -28,7 +28,7 @@ You can build a BLE application using Mbed OS, `BLE_API` and a controller-specif
 
 1. Classes under `ble/services` to offer reference implementations for many of the commonly used GATT profiles. The code under 'services/' isn't essential, but it’s a useful starting point for prototyping. We continue to implement the standard GATT profiles.
 
-## The BLEDevice class and header
+# The BLEDevice class and header
 
 The entry point of Mbed's `BLE_API` is the BLE class accessible using the header `ble/BLE.h`. This class allows you to obtain a BLE object that includes the basic attributes of a spec-compatible BLE device and can work with any BLE radio:
 
@@ -44,31 +44,31 @@ The class's member functions can be divided by purpose:
 
 1. Accessor to Bluetooth Modules that manage GAP, GATT or the security.
 
-## Usage
+# Usage
 
 1. Set up advertising and connection modes.
 1. Assign UUIDs to the service and its characteristic.
 1. Create an input characteristic.
 1. Construct a service class and add it to the BLE stack.
 1. Push notifications when the characteristic's value changes.
 
-## BLE class reference
+# BLE class reference
 
 [![View code](https://www.mbed.com/embed/?type=library)](https://os.mbed.com/docs/development/mbed-os-api-doxy/class_b_l_e.html)
 
-## Example: BLE beacon
+# Example: BLE beacon
 
 Here is an example demonstrating how you can create a BLE beacon.
 
 [![View code](https://www.mbed.com/embed/?url=https://github.com/ARMmbed/mbed-os-example-ble/blob/master/BLE_Beacon/source)](https://github.com/ARMmbed/mbed-os-example-ble/blob/mbed-os-5.14/BLE_Beacon/source/main.cpp)
 
-## Example: BLE heart rate monitor
+# Example: BLE heart rate monitor
 
 Here is an example demonstrating how to build a heart rate sensor that can be connected and monitored by a BLE client such as your phone.
 
 [![View code](https://www.mbed.com/embed/?url=https://github.com/ARMmbed/mbed-os-example-ble/blob/master/BLE_HeartRate/source)](https://github.com/ARMmbed/mbed-os-example-ble/blob/mbed-os-5.14/BLE_HeartRate/source/main.cpp)
 
-## Related content
+# Related content
 
 - Mbed Enabled [targets and components](https://os.mbed.com/platforms/?mbed-enabled=15&connectivity=3) that support BLE.
 - [BLE tutorial](../tutorials/ble-tutorial.html).

docs/api/bluetooth/BatteryService.md

@@ -1,19 +1,19 @@
-## BatteryService
+# BatteryService
 
 It is often a requirement for devices operating on battery to report the battery charge level to the user.
 
 The [Bluetooth Battery Service](https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=245138) defines how to expose a battery charge level through a BLE link. It allows a client - usually a smartphone application - of a device to read the current battery charge level and follow its evolution.
 
 The BatteryService class implements the Bluetooth Battery Service as defined by the Bluetooth SIG. Makers of BLE devices operating on battery can use the API to expose interoperably the charge level of their products.
 
-### BatteryService class reference
+## BatteryService class reference
 
 [![View code](https://www.mbed.com/embed/?type=library)](https://os.mbed.com/docs/mbed-os/development/mbed-os-api-doxy/class_battery_service.html)
 
-### BatteryService example
+## BatteryService example
 
 [![View code](https://www.mbed.com/embed/?url=https://github.com/ARMmbed/mbed-os-example-ble/blob/master/BLE_BatteryLevel/source)](https://github.com/ARMmbed/mbed-os-example-ble/blob/mbed-os-5.14/BLE_BatteryLevel/source/main.cpp)
 
-### Related content
+## Related content
 
 - [Bluetooth Battery Service](https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=245138) specification.

docs/api/bluetooth/EnvironmentalService.md

@@ -1,11 +1,11 @@
-## EnvironmentalService
+# EnvironmentalService
 
 [Add description here.]
 
-### EnvironmentalService class reference
+## EnvironmentalService class reference
 
 [![View code](https://os.mbed.com/docs/development/mbed-os-api-doxy/class_environmental_service.html)
 
-### EnvironmentalService example
+## EnvironmentalService example
 
 [Add example here.]

docs/api/bluetooth/Gap.md

@@ -1,4 +1,4 @@
-## GAP
+# GAP
 
 <span class="notes">**Note:** Some functions, variables or types have been deprecated. Please see the class reference linked below for details.</span>
 
@@ -12,19 +12,19 @@ The other side of the process is the act of scanning, which listens for advertis
 
 Advertising, scanning and connection all have parameters that let you find a compromise between desired power consumption levels, latency and efficiency of these processes.
 
-### Advertising
+## Advertising
 
 Advertising consists of broadcasting at a regular interval a small amount of data containing valuable information about the device. Peer devices listening on BLE advertising channels may scan these packets.
 
 Scanners may also request additional information from device advertising by sending a scan request. If the broadcaster accepts scan requests, it can reply with a scan response packet containing additional information.
 
-### Scanning
+## Scanning
 
 Scanning consists of listening for peer advertising packets. From a scan, a device can identify devices available in its environment.
 
 If the device scans actively, it sends scan request to scannable advertisers and collects their scan responses.
 
-### Extended and periodic advertising
+## Extended and periodic advertising
 
 BLE controllers supporting Bluetooth 5.0 may offer additional advertising and scanning options. Use `isFeatureSupported()` to check feature availability.
 
@@ -36,13 +36,13 @@ There may be many advertising sets active at one time on a single advertiser. Th
 
 Devices that do not support extended and periodic advertising will not see these advertisements. You may use legacy advertising alongside extended advertising, running at the same time, to support older devices in the environment.
 
-### Privacy
+## Privacy
 
 Privacy is a feature that allows a device to avoid being tracked by other (untrusted) devices. The device achieves it by periodically generating a new random address. The random address may be a resolvable random address, enabling trusted devices to recognize it as belonging to the same device. These trusted devices receive an Identity Resolution Key (IRK) during pairing. The SecurityManager handles this and relies on the other device accepting and storing the IRK.
 
 You need to enable privacy by calling `enablePrivacy()` after initializing the SecurityManager because privacy requires SecurityManager to handle IRKs. Set the behavior of privacy enabled devices by using `setCentralPrivacyConfiguration()`, which specifies what the device should be with devices using random addresses, and `setPeripheralPrivacyConfiguration`. Random addresses that privacy enabled devices generate can be of two types: resolvable (by devices who have the IRK) and unresolvable. You can't use unresolvable addresses for connecting and connectable advertising; therefore, use a resolvable one for these, regardless of the privacy configuration.
 
-### Modulation schemes
+## Modulation schemes
 
 When supported by the host and controller, you can select different modulation schemes:
 
@@ -56,7 +56,7 @@ You may set preferred PHYs (separately for RX and TX) using `setPreferredPhys()`
 
 You may query the currently used PHY using `readPhy()`, which returns the result through a call to the registered event handler. You may register the handler with `setEventHandler()`. The events inform about the currently used PHY and of any changes to PHYs, which the controller or the peer may trigger autonomously.
 
-### Data length (over-the-air MTU)
+## Data length (over-the-air MTU)
 
 In addition to modulation schemes, Maximum Transmission Unit (MTU) size also strongly affects throughput. Newer controllers allow you to negotiate bigger MTUs. Because each packet contains overhead, bigger packets maximize throughput.
 
@@ -66,11 +66,11 @@ The default value of data length supported by all controllers is 23 octets. If b
 
 `ATT_MTU` and data length are independent of each other.
 
-### GAP class reference
+## GAP class reference
 
 [![View code](https://www.mbed.com/embed/?type=library)](https://os.mbed.com/docs/development/mbed-os-api-doxy/class_gap.html)
 
-### GAP example
+## GAP example
 
 Here is an example demonstrating how to use the GAP API to advertise, scan, connect and disconnect and how parameters influence efficiency of these actions.
 

docs/api/bluetooth/GattClient.md

@@ -1,24 +1,24 @@
-## GattClient
+# GattClient
 
 <span class="notes">**Note:** Some functions, variables or types have been deprecated. Please see the class reference linked below for details.</span>
 
 You can use Generic Attribute Profile (GATT) to discover services, characteristics and descriptors and to perform operations on them. The interaction happens between two peers, one of which is the client (which initiates interactions) and the other is the server (which responds). You can use Attribute Protocol (ATT) to implement this interaction. `GattClient` defines procedures required for interacting with a remote `GattServer`.
 
-### Discovery procedures
+## Discovery procedures
 
 A GattServer hosts a fixed set of services. These services are a logical composition of characteristics that may be discovered, read or written and can broadcast their state to a connected client. These characteristics may also contain metainformation and named characteristic descriptors. A characteristic descriptor may indicate the unit used for a characteristic value, describe the characteristic purpose in a textual form or allow a client to register for update notifications for the characteristic value.
 
 Prior to any interaction with a server characteristic, a GattClient discovers the layout of the services and characteristics present on the server.
 
 The layout of the descriptors of a characteristic may also be issued as an extra discovery step.
 
-### Attribute manipulation
+## Attribute manipulation
 
 As a result of the discovery process, the client can start interacting with the characteristic discovered. Depending on the characteristic properties (acquired during discovery), a client can read or write the value of a given characteristic.
 
 Mbed BLE abstracts read and write operations to offer a single API that can be used to read or write characteristic values. The application code does not have to handle the necessary fragmentation or reassembly process if the attribute value to be transported can't fit in a single data packet.
 
-### Attribute Protocol Maximum Transmission Unit (ATT_MTU)
+## Attribute Protocol Maximum Transmission Unit (ATT_MTU)
 
 `ATT_MTU` is the maximum size of the attribute protocol packet. Operation on attributes too large to fit into a single packet are split across multiple operations.
 
@@ -28,16 +28,16 @@ Only `GattClient` can trigger the exchange of `ATT_MTU` between client and serve
 
 `ATT_MTU` is at least 23 octets by default. If a larger size is negotiated, the user application will be informed through the `onAttMtuChange` function called in the `GattClient::EventHandler`. (`GattServer::EventHandler` is also informed.)
 
-### Server initiated events
+## Server initiated events
 
 When a server updates a characteristic value, it can forward the new value to any registered clients. Clients may register for these updates on a per-characteristic basis. The server sends the updates by using notifications (no confirmation from client) or indications (client confirms receipt). This mechanism minimizes the number of transactions between a client and a server by avoiding polling.
 
 Clients register for these updates by setting the Client Characteristic Configuration Descriptor (CCCD) value. This is an attribute, and the client needs to discover its descriptor. It is present in the characteristic if its notify or indicate properties are set.
 
-### GattClient class reference
+## GattClient class reference
 
 [![View code](https://www.mbed.com/embed/?type=library)](https://os.mbed.com/docs/development/mbed-os-api-doxy/class_gatt_client.html)
 
-### GattClient example
+## GattClient example
 
 [![View code](https://www.mbed.com/embed/?url=https://os.mbed.com/teams/mbed-os-examples/code/mbed-os-example-ble-GattClient/)](https://os.mbed.com/teams/mbed-os-examples/code/mbed-os-example-ble-GattClient/file/38639a71a0f1/source/main.cpp)