+
+ | Message field
+ |
+ Description
+ |
+
+
+ | Type
+ |
+ Message type. 1 byte value.
+ |
+
+
+ | rDevEUI
+ |
+ A random device EUI for the current device. 8 bytes long.
+ |
+
+
+ | devPubKey
+ |
+ The ECDH public key generated by device. 64 bytes long.
+ |
+
+
+ | serverPubKey
+ |
+ The ECDH public key generated by the server. 64 bytes long.
+ |
+
+
+ | version
+ |
+ Protocol version. Value is 0x01. 1 byte value.
+ |
+
+
+ | provisionIdHash
+ |
+ Hashed Provision ID. 32 bytes long.
+ |
+
+
+ | serverNonce
+ |
+ Random value for verifyCode generation. 4 bytes long.
+ |
+
+
+ | devNonce
+ |
+ Random value for verifyCode generation. 4 bytes long.
+ |
+
+
+ | devEUI
+ |
+ The assigned Device EUI for the device. 8 bytes long.
+ |
+
+
+ | verifyCode
+ |
+ Verification code. 16 bytes long.
+ |
+
+
+
+### ECDH
+
+In our example device source code, we used the following C source at GitHub for the ECDH.
+
+https://github.com/kokke/tiny-ECDH-c
+
+The compiled size is as small as 1.4KiB for ARM Thumb Code. It minimized the extra cost for fitting into an MCU.
+
+The ECDH key exchange will use the NIST K-233 curve. Private key size is 32 bytes, public key size is 64 bytes.
+
+
+### Key generation
+
+The keys used for LoRaWAN are generated inside the device instead of sending via the air. After the ECDH key exchange (Hello message), both device and server will hold a sharedKey in the same value. Then it will use the following calculation to derive to several keys.
+
+When the authentication is done, the derived AppKey and NwkKey should be stored in FLASH for later LoRaWAN OTAA use.
+
+
+```
+ AppKey = aes128_encrypt (sharedKey[0..15], rDevEUI | pad 0x01)
+
+ NwkKey = aes128_encrypt (sharedKey[32..47], rDevEUI | pad 0x02)
+
+ ProvKey = aes128_encrypt (sharedKey[16..23] | sharedKey[48..55], rDevEUI | pad 0x03)
+```
+
+
+AppKey and NwkKey are the keys for OTAA on LoRa communication.
+
+For 1.0.x LoRa, NwkKey will be used as AppKey for OTAA.
+
+ProvKey is used as the key for payload encryption of Auth messages and responses.
+
+Example:
+
+
+```
+// Input
+ sharedkey = {0x57, 0x57, 0x3A, 0x81, 0xE2, 0x7E, 0x48, 0x26, 0xFA, 0x8E, 0x18, 0x70, 0xCD,
+ 0x6B, 0x66, 0x40, 0xF3, 0x90, 0x5D, 0x98, 0x40, 0xF4, 0x12, 0xFA, 0xAE, 0x74,
+ 0x0B, 0x12, 0xE0, 0x01, 0x00, 0x00, 0xC4, 0xD8, 0x27, 0xA9, 0x37, 0x49, 0xEE,
+ 0x44, 0xEA, 0x1B, 0xAC, 0x1C, 0x18, 0x8C, 0x03, 0xAA, 0x6B, 0x02, 0xDA, 0x1C,
+ 0x68, 0xE9, 0xE8, 0xE6, 0xCA, 0xB9, 0xD1, 0xED, 0x91, 0x01, 0x00, 0x00};
+
+// Output
+ appkey = {0xFC, 0x3B, 0xDD, 0x59, 0x22, 0x87, 0xD9, 0x73
+ 0x48, 0xC0, 0x0B, 0xAC, 0x46, 0xB3, 0x05, 0x79};
+ nwkkey = {0x5B, 0x87, 0x83, 0xAF, 0x06, 0xFF, 0xB3, 0x62,
+ 0x9D, 0x03, 0x77, 0x9B, 0xF3, 0x4E, 0x12, 0x89};
+ provkey = {0x29, 0x53, 0x01, 0x98, 0x2D, 0x35, 0xC7, 0x2F,
+ 0x71, 0x42, 0xB9, 0xDD, 0x07, 0xFE, 0x1D, 0xEF};
+```
+
+
+
+
+
+## Request for Provision ID (CSV file)
+
+This is the CSV file you need to send to us to request for the Provision ID.
+
+
+```
+ MatchX Device Provisioning,,,,,
+ manufacturerName,MatchX GmbH,,,,
+ provisionId,model,serialNumber,fixedDevEUI,devEUI,appEUI
+ ,M-1234,S000000,Y,000000fffe000000,0000000000000000
+ ,M-1234,S000001,Y,000000fffe000001,0000000000000000
+ ,M-1234,S000002,Y,000000fffe000002,0000000000000000
+ ,M-1234,S000003,Y,000000fffe000003,0000000000000000
+ ,M-1234,S000004,Y,000000fffe000004,0000000000000000
+ ,M-1234,S000005,Y,000000fffe000005,0000000000000000
+ ,M-1234,S000006,Y,000000fffe000006,0000000000000000
+ ,M-1234,S000007,Y,000000fffe000007,0000000000000000
+```
+
+
+The first line is the signature, please don’t modify it.
+
+The second line is the name of the device manufacturer. Modify it to your company name.
+
+The third line is the header, please don’t modify it.
+
+Starting from the fourth line, it is the list of device information you need for a Provision ID.
+
+“provisionId” is the Provision ID, we will generate one for you if it is blank.
+
+“model” is the model number of your device.
+
+“serialNumber” is the serial number of your device.
+
+When your device has its own MAC address and is willing to use it as the Device EUI on LoRa, you should set the “fixedDevEUI” to “Y” and fill the “fixedDevEUI”.
+
+“appEUI” is not used at the moment, please fill it with “0000000000000000”.
+
+Here is the view when you use a spreadsheet program to edit the file.
+
+
+
+
+
+
+
+
+48-bits MAC to 64-bits EUI
+
+To convert a 48-bits MAC address into a 64-bits EUI, you need to insert a “0xff 0xfe” in the middle of it.
+
+For example:
+
+
+```
+ MAC = 01 02 03 04 05 06
+ EUI = 01 02 03 ff fe 04 05 06
+```
+
+
+
+
+After the request is approved, we will send you back the report file in CSV format. Here is an example for the report that is viewed with a spreadsheet program.
+
+
+
+
+
+The important parts are the “provisionId” and “provisionIdHash”. You need to program this information to the device. For the device with MAC and using fixed Device EUI, you need to take care of the “devEUI” and make sure the Provision ID is programmed to the corresponding device.
+
+Here is an example CSV file for the device that will use a random Device EUI. The “fixedDevEUI” will set to “N” and “deviceEUI” is blank. A random device EUI will assign to the device after provisioning.
+
+
+```
+ MatchX Device Provisioning,,,,,
+ manufacturerName,MatchX GmbH,,,,
+ provisionId,model,serialNumber,fixedDevEUI,devEUI,appEUI
+ ,M-1234,S000000,N,,0000000000000000
+ ,M-1234,S000001,N,,0000000000000000
+ ,M-1234,S000002,N,,0000000000000000
+ ,M-1234,S000003,N,,0000000000000000
+ ,M-1234,S000004,N,,0000000000000000
+ ,M-1234,S000005,N,,0000000000000000
+ ,M-1234,S000006,N,,0000000000000000
+ ,M-1234,S000007,N,,0000000000000000
+```
+
+
+
+
+
+
+
+
From 7d3f44089bc30a805886255825cfae4f2ec0c7c3 Mon Sep 17 00:00:00 2001
From: jeffstahlnecker <45363541+jeffstahlnecker@users.noreply.github.com>
Date: Mon, 5 Jul 2021 20:27:20 +0200
Subject: [PATCH 072/234] New translations miner-health.mdx (Chinese
Traditional)
---
.../current/tutorials/m2-pro/miner-health.mdx | 48 +++++++++++++++++++
1 file changed, 48 insertions(+)
create mode 100644 i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/m2-pro/miner-health.mdx
diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/m2-pro/miner-health.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/m2-pro/miner-health.mdx
new file mode 100644
index 0000000..8e488ac
--- /dev/null
+++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/m2-pro/miner-health.mdx
@@ -0,0 +1,48 @@
+---
+sidebar_position: 4
+---
+
+# Miner Health
+
+Miner Health rewards users for placing their miner in a fashion that will provide a strong LoRa signal. These are the six items that make up miner health:
+* Fuel (Live)
+* Uptime (Live)
+* GPS Signal
+* Orientation
+* Proximity
+* Altitude
+
+## Miner Health Grace Period
+Each M2 Pro Miner has a 90-day grace period that begins with the initial registration of the miner. During this period of time, health will not affect the mining potential of the M2 Pro. After the grace period is over, the current health of the miner will be applied.
+
+If the fuel tank is empty after the grace period, mining efficiency will be reduced by 50% (see Fuel).
+
+## Fuel (Live)
+Each miner has a fuel tank. This tank is equal to the size of all the MXC mined by this miner. So a miner mined 10 MXC, the tank size would then be 10 MXC.
+
+*Fuel has a 50 percent influence on your mining potential*
+
+### How does this work?
+
+As a miner mines, it maintains the fuel tank. All newly mined MXC are added to the tank to ensure it continues to mine at peek efficiency. When MXC is removed from the fuel tank, the miner will mine at a reduced efficiency. For example, if all MXC would be removed from the fuel tank, the miner would mine at 50% efficiency.
+
+### Fuel percentage increases over time
+As a miner mines, it continues to add MXC. If a miner's tank size is 99 MXC, and all the fuel is removed from the tank, then the fuel percentage would be zero. However, if the miner mines one MXC on the following day, the fuel balance increases by one MXC, as does the tank size, resulting in a 1% fuel capacity. Naturally this version of "refilling" the tank takes time, however it ensure that the M2 Pro retains its value after all fuel is removed.
+
+## Uptime
+Uptime is a reliability metric calculated using the average reliability of the miner over the past 7 days. Uptime as a whole, has a 20 percent influence on miner health.
+
+## GPS Signal
+GPS is another form of wireless signal. Therefore we can *assume* that if the miner has a strong GPS signal, it's positioned well enough to provide an excellent wireless network. *GPS has a 10 percent influence on miner health.*
+
+## Orientation
+An M2 Pro antenna provides a wireless signal to the sides of the miner. If the miner is mounted horizontally, the network that it provides will be extremely limited (i.e. airplanes and moles would benefit when they pass overhead or underneath the miner). Therefore, orientation ensures a miner is mounted vertically as designed, with the antenna facing upwards. *Orientation has an 8 percent influence on miner health.*
+
+## Proximity
+In order to achieve a broad wireless network, and in doing so get the most possible coverage, proximity rewards users for spreading out their miners. If a miner is in close proximity with another miner, then it will receive a proximity hit on miner health. *Proximity has a 7 percent influence on miner health.*
+
+## Altitude
+A miner placed in a higher position is more likely to provide a wireless network that transverses physical obstacles. Altitude is measured by using the pressure sensor in the miner itself, and combining it with a terrain elevation database to determine how high above ground level the miner is. This is then cross referenced with the elevation of nearby miners to determine whether the miner is ideally placed. *Altitude has a 5 percent influence on miner health.*
+
+### Proposed alternative to altitude
+As altitude is extremely difficult to measure, we are considering a method for users to manually measure the signal strength of a miner.
From 6dfcc16bfada6104b973005711bfe1761904c2f4 Mon Sep 17 00:00:00 2001
From: jeffstahlnecker <45363541+jeffstahlnecker@users.noreply.github.com>
Date: Mon, 5 Jul 2021 20:27:21 +0200
Subject: [PATCH 073/234] New translations payload.md (Chinese Traditional)
---
.../current/tutorials/devices/payload.md | 194 ++++++++++++++++++
1 file changed, 194 insertions(+)
create mode 100644 i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/devices/payload.md
diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/devices/payload.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/devices/payload.md
new file mode 100644
index 0000000..733d9ab
--- /dev/null
+++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/devices/payload.md
@@ -0,0 +1,194 @@
+---
+title: Payload Format
+sidebar_label: Payload Format
+---
+
+## Uplink Payload Data Format
+
+The payload is consisting of several commands in a Type-Length-Value (TLV) format. The first byte is consisting of Type (bits [7:4]), defining the command, and Length (bits [3:0]), the length of the arguments in bytes. If the Length bits are 0xF (binary 1111), the command has its length specified in bits [5:0] of the second byte.
+
+| Number | Name | Length | Description |
+| ------ | --------------- | ------ | ------------------------------------------------------------------------------------------------- |
+| 0 | Param value | >=2 | Response to the "Get params" command. The first byte is the param number, the rest are the value. |
+| 1 | Sensor data | >=1 | Sensor data. |
+| 2 | Battery level | 1 | Battery level in 10mV steps from 2V (0 = 2V, 255 = 4.55V). |
+| 3 | Battery Percent | 1 | Battery level in percent (0 to 100). |
+| 4 | Event data | >=1 | Event data |
+
+
+
+### Sensor Data
+
+Sensor data consists of a byte signifying the sensor type, and zero or more bytes of sensor data. The defined types and corresponding data formats are:
+
+| Number | Name | Length | Description |
+| ---------- | ----------- | ----------- | ---------------------------------------------------------------------------------------- |
+| 0 (0x00) | unknown | 0 | No data. |
+| 1 (0x01) | gps | 1 or 11 | GPS coordinates. |
+| 2 (0x02) | temp | 1 or 2 or 4 | Temperature in degrees Celsius. |
+| 3 (0x03) | humi | 1 or 2 or 4 | Relative humidity in %RH. |
+| 4 (0x04) | pressure | 4 | Barometric pressure in hPa. |
+| 5 (0x05) | pm10 | 4 | PM10 Concentration in μg/m3. |
+| 6 (0x06) | pm2.5 | 4 | PM2.5 Concentration in μg/m3. |
+| 7 (0x07) | tvoc | 4 | VOC Concentration in ppb. |
+| 8 (0x08) | no2 | 4 | Nitrogen Dioxide Concentration in ppm. |
+| 9 (0x09) | co2 | 4 | Carbon Dioxide Concentration in ppm. |
+| 10 (0x0a) | airFlow | 4 | Air Flow Rate (Wind Speed) in m/s. |
+| 11 (0x0b) | voltage | 1 or 2 or 4 | Voltage in V. |
+| 12 (0x0c) | current | 1 or 2 or 4 | Electric Current in A. |
+| 13 (0x0d) | power | 1 or 2 or 4 | Electric Power in W. |
+| 14 (0x0e) | powerUsage | 4 | Electric energy usage in kWh. |
+| 15 (0x0f) | waterUsage | 4 | Water usage in Kilolitres. |
+| 16 (0x10) | speed | 4 | Movement Speed in m/s. |
+| 17 (0x11) | rotation | 4 | Rotational speed in RPM. |
+| 18 (0x12) | counter | 4 | A generic counter in a 32-bits unsigned value. |
+| 19 (0x13) | digital | 1 | A generic digital value.
+
+ | Message field
+ |
+ Description
+ |
+
+
+ | Type
+ |
+ Message type. 1 byte value.
+ |
+
+
+ | rDevEUI
+ |
+ A random device EUI for the current device. 8 bytes long.
+ |
+
+
+ | devPubKey
+ |
+ The ECDH public key generated by device. 64 bytes long.
+ |
+
+
+ | serverPubKey
+ |
+ The ECDH public key generated by the server. 64 bytes long.
+ |
+
+
+ | version
+ |
+ Protocol version. Value is 0x01. 1 byte value.
+ |
+
+
+ | provisionIdHash
+ |
+ Hashed Provision ID. 32 bytes long.
+ |
+
+
+ | serverNonce
+ |
+ Random value for verifyCode generation. 4 bytes long.
+ |
+
+
+ | devNonce
+ |
+ Random value for verifyCode generation. 4 bytes long.
+ |
+
+
+ | devEUI
+ |
+ The assigned Device EUI for the device. 8 bytes long.
+ |
+
+
+ | verifyCode
+ |
+ Verification code. 16 bytes long.
+ |
+
+
+
+### ECDH
+
+In our example device source code, we used the following C source at GitHub for the ECDH.
+
+https://github.com/kokke/tiny-ECDH-c
+
+The compiled size is as small as 1.4KiB for ARM Thumb Code. It minimized the extra cost for fitting into an MCU.
+
+The ECDH key exchange will use the NIST K-233 curve. Private key size is 32 bytes, public key size is 64 bytes.
+
+
+### Key generation
+
+The keys used for LoRaWAN are generated inside the device instead of sending via the air. After the ECDH key exchange (Hello message), both device and server will hold a sharedKey in the same value. Then it will use the following calculation to derive to several keys.
+
+When the authentication is done, the derived AppKey and NwkKey should be stored in FLASH for later LoRaWAN OTAA use.
+
+
+```
+ AppKey = aes128_encrypt (sharedKey[0..15], rDevEUI | pad 0x01)
+
+ NwkKey = aes128_encrypt (sharedKey[32..47], rDevEUI | pad 0x02)
+
+ ProvKey = aes128_encrypt (sharedKey[16..23] | sharedKey[48..55], rDevEUI | pad 0x03)
+```
+
+
+AppKey and NwkKey are the keys for OTAA on LoRa communication.
+
+For 1.0.x LoRa, NwkKey will be used as AppKey for OTAA.
+
+ProvKey is used as the key for payload encryption of Auth messages and responses.
+
+Example:
+
+
+```
+// Input
+ sharedkey = {0x57, 0x57, 0x3A, 0x81, 0xE2, 0x7E, 0x48, 0x26, 0xFA, 0x8E, 0x18, 0x70, 0xCD,
+ 0x6B, 0x66, 0x40, 0xF3, 0x90, 0x5D, 0x98, 0x40, 0xF4, 0x12, 0xFA, 0xAE, 0x74,
+ 0x0B, 0x12, 0xE0, 0x01, 0x00, 0x00, 0xC4, 0xD8, 0x27, 0xA9, 0x37, 0x49, 0xEE,
+ 0x44, 0xEA, 0x1B, 0xAC, 0x1C, 0x18, 0x8C, 0x03, 0xAA, 0x6B, 0x02, 0xDA, 0x1C,
+ 0x68, 0xE9, 0xE8, 0xE6, 0xCA, 0xB9, 0xD1, 0xED, 0x91, 0x01, 0x00, 0x00};
+
+// Output
+ appkey = {0xFC, 0x3B, 0xDD, 0x59, 0x22, 0x87, 0xD9, 0x73
+ 0x48, 0xC0, 0x0B, 0xAC, 0x46, 0xB3, 0x05, 0x79};
+ nwkkey = {0x5B, 0x87, 0x83, 0xAF, 0x06, 0xFF, 0xB3, 0x62,
+ 0x9D, 0x03, 0x77, 0x9B, 0xF3, 0x4E, 0x12, 0x89};
+ provkey = {0x29, 0x53, 0x01, 0x98, 0x2D, 0x35, 0xC7, 0x2F,
+ 0x71, 0x42, 0xB9, 0xDD, 0x07, 0xFE, 0x1D, 0xEF};
+```
+
+
+
+
+
+## Request for Provision ID (CSV file)
+
+This is the CSV file you need to send to us to request for the Provision ID.
+
+
+```
+ MatchX Device Provisioning,,,,,
+ manufacturerName,MatchX GmbH,,,,
+ provisionId,model,serialNumber,fixedDevEUI,devEUI,appEUI
+ ,M-1234,S000000,Y,000000fffe000000,0000000000000000
+ ,M-1234,S000001,Y,000000fffe000001,0000000000000000
+ ,M-1234,S000002,Y,000000fffe000002,0000000000000000
+ ,M-1234,S000003,Y,000000fffe000003,0000000000000000
+ ,M-1234,S000004,Y,000000fffe000004,0000000000000000
+ ,M-1234,S000005,Y,000000fffe000005,0000000000000000
+ ,M-1234,S000006,Y,000000fffe000006,0000000000000000
+ ,M-1234,S000007,Y,000000fffe000007,0000000000000000
+```
+
+
+The first line is the signature, please don’t modify it.
+
+The second line is the name of the device manufacturer. Modify it to your company name.
+
+The third line is the header, please don’t modify it.
+
+Starting from the fourth line, it is the list of device information you need for a Provision ID.
+
+“provisionId” is the Provision ID, we will generate one for you if it is blank.
+
+“model” is the model number of your device.
+
+“serialNumber” is the serial number of your device.
+
+When your device has its own MAC address and is willing to use it as the Device EUI on LoRa, you should set the “fixedDevEUI” to “Y” and fill the “fixedDevEUI”.
+
+“appEUI” is not used at the moment, please fill it with “0000000000000000”.
+
+Here is the view when you use a spreadsheet program to edit the file.
+
+
+
+
+
+
+
+
+48-bits MAC to 64-bits EUI
+
+To convert a 48-bits MAC address into a 64-bits EUI, you need to insert a “0xff 0xfe” in the middle of it.
+
+For example:
+
+
+```
+ MAC = 01 02 03 04 05 06
+ EUI = 01 02 03 ff fe 04 05 06
+```
+
+
+
+
+After the request is approved, we will send you back the report file in CSV format. Here is an example for the report that is viewed with a spreadsheet program.
+
+
+
+
+
+The important parts are the “provisionId” and “provisionIdHash”. You need to program this information to the device. For the device with MAC and using fixed Device EUI, you need to take care of the “devEUI” and make sure the Provision ID is programmed to the corresponding device.
+
+Here is an example CSV file for the device that will use a random Device EUI. The “fixedDevEUI” will set to “N” and “deviceEUI” is blank. A random device EUI will assign to the device after provisioning.
+
+
+```
+ MatchX Device Provisioning,,,,,
+ manufacturerName,MatchX GmbH,,,,
+ provisionId,model,serialNumber,fixedDevEUI,devEUI,appEUI
+ ,M-1234,S000000,N,,0000000000000000
+ ,M-1234,S000001,N,,0000000000000000
+ ,M-1234,S000002,N,,0000000000000000
+ ,M-1234,S000003,N,,0000000000000000
+ ,M-1234,S000004,N,,0000000000000000
+ ,M-1234,S000005,N,,0000000000000000
+ ,M-1234,S000006,N,,0000000000000000
+ ,M-1234,S000007,N,,0000000000000000
+```
+
+
+
+
+
+
+
+
From 43c3657bdb9a43b0621f3cb44941f3f881e48d51 Mon Sep 17 00:00:00 2001
From: jeffstahlnecker <45363541+jeffstahlnecker@users.noreply.github.com>
Date: Mon, 5 Jul 2021 20:27:26 +0200
Subject: [PATCH 078/234] New translations miner-health.mdx (Chinese
Simplified)
---
.../current/tutorials/m2-pro/miner-health.mdx | 48 +++++++++++++++++++
1 file changed, 48 insertions(+)
create mode 100644 i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/m2-pro/miner-health.mdx
diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/m2-pro/miner-health.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/m2-pro/miner-health.mdx
new file mode 100644
index 0000000..8e488ac
--- /dev/null
+++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/m2-pro/miner-health.mdx
@@ -0,0 +1,48 @@
+---
+sidebar_position: 4
+---
+
+# Miner Health
+
+Miner Health rewards users for placing their miner in a fashion that will provide a strong LoRa signal. These are the six items that make up miner health:
+* Fuel (Live)
+* Uptime (Live)
+* GPS Signal
+* Orientation
+* Proximity
+* Altitude
+
+## Miner Health Grace Period
+Each M2 Pro Miner has a 90-day grace period that begins with the initial registration of the miner. During this period of time, health will not affect the mining potential of the M2 Pro. After the grace period is over, the current health of the miner will be applied.
+
+If the fuel tank is empty after the grace period, mining efficiency will be reduced by 50% (see Fuel).
+
+## Fuel (Live)
+Each miner has a fuel tank. This tank is equal to the size of all the MXC mined by this miner. So a miner mined 10 MXC, the tank size would then be 10 MXC.
+
+*Fuel has a 50 percent influence on your mining potential*
+
+### How does this work?
+
+As a miner mines, it maintains the fuel tank. All newly mined MXC are added to the tank to ensure it continues to mine at peek efficiency. When MXC is removed from the fuel tank, the miner will mine at a reduced efficiency. For example, if all MXC would be removed from the fuel tank, the miner would mine at 50% efficiency.
+
+### Fuel percentage increases over time
+As a miner mines, it continues to add MXC. If a miner's tank size is 99 MXC, and all the fuel is removed from the tank, then the fuel percentage would be zero. However, if the miner mines one MXC on the following day, the fuel balance increases by one MXC, as does the tank size, resulting in a 1% fuel capacity. Naturally this version of "refilling" the tank takes time, however it ensure that the M2 Pro retains its value after all fuel is removed.
+
+## Uptime
+Uptime is a reliability metric calculated using the average reliability of the miner over the past 7 days. Uptime as a whole, has a 20 percent influence on miner health.
+
+## GPS Signal
+GPS is another form of wireless signal. Therefore we can *assume* that if the miner has a strong GPS signal, it's positioned well enough to provide an excellent wireless network. *GPS has a 10 percent influence on miner health.*
+
+## Orientation
+An M2 Pro antenna provides a wireless signal to the sides of the miner. If the miner is mounted horizontally, the network that it provides will be extremely limited (i.e. airplanes and moles would benefit when they pass overhead or underneath the miner). Therefore, orientation ensures a miner is mounted vertically as designed, with the antenna facing upwards. *Orientation has an 8 percent influence on miner health.*
+
+## Proximity
+In order to achieve a broad wireless network, and in doing so get the most possible coverage, proximity rewards users for spreading out their miners. If a miner is in close proximity with another miner, then it will receive a proximity hit on miner health. *Proximity has a 7 percent influence on miner health.*
+
+## Altitude
+A miner placed in a higher position is more likely to provide a wireless network that transverses physical obstacles. Altitude is measured by using the pressure sensor in the miner itself, and combining it with a terrain elevation database to determine how high above ground level the miner is. This is then cross referenced with the elevation of nearby miners to determine whether the miner is ideally placed. *Altitude has a 5 percent influence on miner health.*
+
+### Proposed alternative to altitude
+As altitude is extremely difficult to measure, we are considering a method for users to manually measure the signal strength of a miner.
From c5ccdef5c8f4a61159c9aae37ece21ec1dfda882 Mon Sep 17 00:00:00 2001
From: jeffstahlnecker <45363541+jeffstahlnecker@users.noreply.github.com>
Date: Mon, 5 Jul 2021 20:27:27 +0200
Subject: [PATCH 079/234] New translations payload.md (Chinese Simplified)
---
.../current/tutorials/devices/payload.md | 194 ++++++++++++++++++
1 file changed, 194 insertions(+)
create mode 100644 i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/devices/payload.md
diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/devices/payload.md b/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/devices/payload.md
new file mode 100644
index 0000000..733d9ab
--- /dev/null
+++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/devices/payload.md
@@ -0,0 +1,194 @@
+---
+title: Payload Format
+sidebar_label: Payload Format
+---
+
+## Uplink Payload Data Format
+
+The payload is consisting of several commands in a Type-Length-Value (TLV) format. The first byte is consisting of Type (bits [7:4]), defining the command, and Length (bits [3:0]), the length of the arguments in bytes. If the Length bits are 0xF (binary 1111), the command has its length specified in bits [5:0] of the second byte.
+
+| Number | Name | Length | Description |
+| ------ | --------------- | ------ | ------------------------------------------------------------------------------------------------- |
+| 0 | Param value | >=2 | Response to the "Get params" command. The first byte is the param number, the rest are the value. |
+| 1 | Sensor data | >=1 | Sensor data. |
+| 2 | Battery level | 1 | Battery level in 10mV steps from 2V (0 = 2V, 255 = 4.55V). |
+| 3 | Battery Percent | 1 | Battery level in percent (0 to 100). |
+| 4 | Event data | >=1 | Event data |
+
+
+
+### Sensor Data
+
+Sensor data consists of a byte signifying the sensor type, and zero or more bytes of sensor data. The defined types and corresponding data formats are:
+
+| Number | Name | Length | Description |
+| ---------- | ----------- | ----------- | ---------------------------------------------------------------------------------------- |
+| 0 (0x00) | unknown | 0 | No data. |
+| 1 (0x01) | gps | 1 or 11 | GPS coordinates. |
+| 2 (0x02) | temp | 1 or 2 or 4 | Temperature in degrees Celsius. |
+| 3 (0x03) | humi | 1 or 2 or 4 | Relative humidity in %RH. |
+| 4 (0x04) | pressure | 4 | Barometric pressure in hPa. |
+| 5 (0x05) | pm10 | 4 | PM10 Concentration in μg/m3. |
+| 6 (0x06) | pm2.5 | 4 | PM2.5 Concentration in μg/m3. |
+| 7 (0x07) | tvoc | 4 | VOC Concentration in ppb. |
+| 8 (0x08) | no2 | 4 | Nitrogen Dioxide Concentration in ppm. |
+| 9 (0x09) | co2 | 4 | Carbon Dioxide Concentration in ppm. |
+| 10 (0x0a) | airFlow | 4 | Air Flow Rate (Wind Speed) in m/s. |
+| 11 (0x0b) | voltage | 1 or 2 or 4 | Voltage in V. |
+| 12 (0x0c) | current | 1 or 2 or 4 | Electric Current in A. |
+| 13 (0x0d) | power | 1 or 2 or 4 | Electric Power in W. |
+| 14 (0x0e) | powerUsage | 4 | Electric energy usage in kWh. |
+| 15 (0x0f) | waterUsage | 4 | Water usage in Kilolitres. |
+| 16 (0x10) | speed | 4 | Movement Speed in m/s. |
+| 17 (0x11) | rotation | 4 | Rotational speed in RPM. |
+| 18 (0x12) | counter | 4 | A generic counter in a 32-bits unsigned value. |
+| 19 (0x13) | digital | 1 | A generic digital value.
+
+ | Message field
+ |
+ Description
+ |
+
+
+ | Type
+ |
+ Message type. 1 byte value.
+ |
+
+
+ | rDevEUI
+ |
+ A random device EUI for the current device. 8 bytes long.
+ |
+
+
+ | devPubKey
+ |
+ The ECDH public key generated by device. 64 bytes long.
+ |
+
+
+ | serverPubKey
+ |
+ The ECDH public key generated by the server. 64 bytes long.
+ |
+
+
+ | version
+ |
+ Protocol version. Value is 0x01. 1 byte value.
+ |
+
+
+ | provisionIdHash
+ |
+ Hashed Provision ID. 32 bytes long.
+ |
+
+
+ | serverNonce
+ |
+ Random value for verifyCode generation. 4 bytes long.
+ |
+
+
+ | devNonce
+ |
+ Random value for verifyCode generation. 4 bytes long.
+ |
+
+
+ | devEUI
+ |
+ The assigned Device EUI for the device. 8 bytes long.
+ |
+
+
+ | verifyCode
+ |
+ Verification code. 16 bytes long.
+ |
+
+
+
+### ECDH
+
+In our example device source code, we used the following C source at GitHub for the ECDH.
+
+https://github.com/kokke/tiny-ECDH-c
+
+The compiled size is as small as 1.4KiB for ARM Thumb Code. It minimized the extra cost for fitting into an MCU.
+
+The ECDH key exchange will use the NIST K-233 curve. Private key size is 32 bytes, public key size is 64 bytes.
+
+
+### Key generation
+
+The keys used for LoRaWAN are generated inside the device instead of sending via the air. After the ECDH key exchange (Hello message), both device and server will hold a sharedKey in the same value. Then it will use the following calculation to derive to several keys.
+
+When the authentication is done, the derived AppKey and NwkKey should be stored in FLASH for later LoRaWAN OTAA use.
+
+
+```
+ AppKey = aes128_encrypt (sharedKey[0..15], rDevEUI | pad 0x01)
+
+ NwkKey = aes128_encrypt (sharedKey[32..47], rDevEUI | pad 0x02)
+
+ ProvKey = aes128_encrypt (sharedKey[16..23] | sharedKey[48..55], rDevEUI | pad 0x03)
+```
+
+
+AppKey and NwkKey are the keys for OTAA on LoRa communication.
+
+For 1.0.x LoRa, NwkKey will be used as AppKey for OTAA.
+
+ProvKey is used as the key for payload encryption of Auth messages and responses.
+
+Example:
+
+
+```
+// Input
+ sharedkey = {0x57, 0x57, 0x3A, 0x81, 0xE2, 0x7E, 0x48, 0x26, 0xFA, 0x8E, 0x18, 0x70, 0xCD,
+ 0x6B, 0x66, 0x40, 0xF3, 0x90, 0x5D, 0x98, 0x40, 0xF4, 0x12, 0xFA, 0xAE, 0x74,
+ 0x0B, 0x12, 0xE0, 0x01, 0x00, 0x00, 0xC4, 0xD8, 0x27, 0xA9, 0x37, 0x49, 0xEE,
+ 0x44, 0xEA, 0x1B, 0xAC, 0x1C, 0x18, 0x8C, 0x03, 0xAA, 0x6B, 0x02, 0xDA, 0x1C,
+ 0x68, 0xE9, 0xE8, 0xE6, 0xCA, 0xB9, 0xD1, 0xED, 0x91, 0x01, 0x00, 0x00};
+
+// Output
+ appkey = {0xFC, 0x3B, 0xDD, 0x59, 0x22, 0x87, 0xD9, 0x73
+ 0x48, 0xC0, 0x0B, 0xAC, 0x46, 0xB3, 0x05, 0x79};
+ nwkkey = {0x5B, 0x87, 0x83, 0xAF, 0x06, 0xFF, 0xB3, 0x62,
+ 0x9D, 0x03, 0x77, 0x9B, 0xF3, 0x4E, 0x12, 0x89};
+ provkey = {0x29, 0x53, 0x01, 0x98, 0x2D, 0x35, 0xC7, 0x2F,
+ 0x71, 0x42, 0xB9, 0xDD, 0x07, 0xFE, 0x1D, 0xEF};
+```
+
+
+
+
+
+## Request for Provision ID (CSV file)
+
+This is the CSV file you need to send to us to request for the Provision ID.
+
+
+```
+ MatchX Device Provisioning,,,,,
+ manufacturerName,MatchX GmbH,,,,
+ provisionId,model,serialNumber,fixedDevEUI,devEUI,appEUI
+ ,M-1234,S000000,Y,000000fffe000000,0000000000000000
+ ,M-1234,S000001,Y,000000fffe000001,0000000000000000
+ ,M-1234,S000002,Y,000000fffe000002,0000000000000000
+ ,M-1234,S000003,Y,000000fffe000003,0000000000000000
+ ,M-1234,S000004,Y,000000fffe000004,0000000000000000
+ ,M-1234,S000005,Y,000000fffe000005,0000000000000000
+ ,M-1234,S000006,Y,000000fffe000006,0000000000000000
+ ,M-1234,S000007,Y,000000fffe000007,0000000000000000
+```
+
+
+The first line is the signature, please don’t modify it.
+
+The second line is the name of the device manufacturer. Modify it to your company name.
+
+The third line is the header, please don’t modify it.
+
+Starting from the fourth line, it is the list of device information you need for a Provision ID.
+
+“provisionId” is the Provision ID, we will generate one for you if it is blank.
+
+“model” is the model number of your device.
+
+“serialNumber” is the serial number of your device.
+
+When your device has its own MAC address and is willing to use it as the Device EUI on LoRa, you should set the “fixedDevEUI” to “Y” and fill the “fixedDevEUI”.
+
+“appEUI” is not used at the moment, please fill it with “0000000000000000”.
+
+Here is the view when you use a spreadsheet program to edit the file.
+
+
+
+
+
+
+
+
+48-bits MAC to 64-bits EUI
+
+To convert a 48-bits MAC address into a 64-bits EUI, you need to insert a “0xff 0xfe” in the middle of it.
+
+For example:
+
+
+```
+ MAC = 01 02 03 04 05 06
+ EUI = 01 02 03 ff fe 04 05 06
+```
+
+
+
+
+After the request is approved, we will send you back the report file in CSV format. Here is an example for the report that is viewed with a spreadsheet program.
+
+
+
+
+
+The important parts are the “provisionId” and “provisionIdHash”. You need to program this information to the device. For the device with MAC and using fixed Device EUI, you need to take care of the “devEUI” and make sure the Provision ID is programmed to the corresponding device.
+
+Here is an example CSV file for the device that will use a random Device EUI. The “fixedDevEUI” will set to “N” and “deviceEUI” is blank. A random device EUI will assign to the device after provisioning.
+
+
+```
+ MatchX Device Provisioning,,,,,
+ manufacturerName,MatchX GmbH,,,,
+ provisionId,model,serialNumber,fixedDevEUI,devEUI,appEUI
+ ,M-1234,S000000,N,,0000000000000000
+ ,M-1234,S000001,N,,0000000000000000
+ ,M-1234,S000002,N,,0000000000000000
+ ,M-1234,S000003,N,,0000000000000000
+ ,M-1234,S000004,N,,0000000000000000
+ ,M-1234,S000005,N,,0000000000000000
+ ,M-1234,S000006,N,,0000000000000000
+ ,M-1234,S000007,N,,0000000000000000
+```
+
+
+
+
+
+
+
+
From 088197cce0f45cc853abc666f93433c6d74830c7 Mon Sep 17 00:00:00 2001
From: jeffstahlnecker <45363541+jeffstahlnecker@users.noreply.github.com>
Date: Mon, 5 Jul 2021 20:27:31 +0200
Subject: [PATCH 083/234] New translations miner-health.mdx (Korean)
---
.../current/tutorials/m2-pro/miner-health.mdx | 48 +++++++++++++++++++
1 file changed, 48 insertions(+)
create mode 100644 i18n/ko/docusaurus-plugin-content-docs/current/tutorials/m2-pro/miner-health.mdx
diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/m2-pro/miner-health.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/m2-pro/miner-health.mdx
new file mode 100644
index 0000000..8e488ac
--- /dev/null
+++ b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/m2-pro/miner-health.mdx
@@ -0,0 +1,48 @@
+---
+sidebar_position: 4
+---
+
+# Miner Health
+
+Miner Health rewards users for placing their miner in a fashion that will provide a strong LoRa signal. These are the six items that make up miner health:
+* Fuel (Live)
+* Uptime (Live)
+* GPS Signal
+* Orientation
+* Proximity
+* Altitude
+
+## Miner Health Grace Period
+Each M2 Pro Miner has a 90-day grace period that begins with the initial registration of the miner. During this period of time, health will not affect the mining potential of the M2 Pro. After the grace period is over, the current health of the miner will be applied.
+
+If the fuel tank is empty after the grace period, mining efficiency will be reduced by 50% (see Fuel).
+
+## Fuel (Live)
+Each miner has a fuel tank. This tank is equal to the size of all the MXC mined by this miner. So a miner mined 10 MXC, the tank size would then be 10 MXC.
+
+*Fuel has a 50 percent influence on your mining potential*
+
+### How does this work?
+
+As a miner mines, it maintains the fuel tank. All newly mined MXC are added to the tank to ensure it continues to mine at peek efficiency. When MXC is removed from the fuel tank, the miner will mine at a reduced efficiency. For example, if all MXC would be removed from the fuel tank, the miner would mine at 50% efficiency.
+
+### Fuel percentage increases over time
+As a miner mines, it continues to add MXC. If a miner's tank size is 99 MXC, and all the fuel is removed from the tank, then the fuel percentage would be zero. However, if the miner mines one MXC on the following day, the fuel balance increases by one MXC, as does the tank size, resulting in a 1% fuel capacity. Naturally this version of "refilling" the tank takes time, however it ensure that the M2 Pro retains its value after all fuel is removed.
+
+## Uptime
+Uptime is a reliability metric calculated using the average reliability of the miner over the past 7 days. Uptime as a whole, has a 20 percent influence on miner health.
+
+## GPS Signal
+GPS is another form of wireless signal. Therefore we can *assume* that if the miner has a strong GPS signal, it's positioned well enough to provide an excellent wireless network. *GPS has a 10 percent influence on miner health.*
+
+## Orientation
+An M2 Pro antenna provides a wireless signal to the sides of the miner. If the miner is mounted horizontally, the network that it provides will be extremely limited (i.e. airplanes and moles would benefit when they pass overhead or underneath the miner). Therefore, orientation ensures a miner is mounted vertically as designed, with the antenna facing upwards. *Orientation has an 8 percent influence on miner health.*
+
+## Proximity
+In order to achieve a broad wireless network, and in doing so get the most possible coverage, proximity rewards users for spreading out their miners. If a miner is in close proximity with another miner, then it will receive a proximity hit on miner health. *Proximity has a 7 percent influence on miner health.*
+
+## Altitude
+A miner placed in a higher position is more likely to provide a wireless network that transverses physical obstacles. Altitude is measured by using the pressure sensor in the miner itself, and combining it with a terrain elevation database to determine how high above ground level the miner is. This is then cross referenced with the elevation of nearby miners to determine whether the miner is ideally placed. *Altitude has a 5 percent influence on miner health.*
+
+### Proposed alternative to altitude
+As altitude is extremely difficult to measure, we are considering a method for users to manually measure the signal strength of a miner.
From ca7082b61acb2f057ee9549e2c35831aca9da1fb Mon Sep 17 00:00:00 2001
From: jeffstahlnecker <45363541+jeffstahlnecker@users.noreply.github.com>
Date: Mon, 5 Jul 2021 20:27:34 +0200
Subject: [PATCH 084/234] New translations payload.md (Korean)
---
.../current/tutorials/devices/payload.md | 194 ++++++++++++++++++
1 file changed, 194 insertions(+)
create mode 100644 i18n/ko/docusaurus-plugin-content-docs/current/tutorials/devices/payload.md
diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/devices/payload.md b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/devices/payload.md
new file mode 100644
index 0000000..733d9ab
--- /dev/null
+++ b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/devices/payload.md
@@ -0,0 +1,194 @@
+---
+title: Payload Format
+sidebar_label: Payload Format
+---
+
+## Uplink Payload Data Format
+
+The payload is consisting of several commands in a Type-Length-Value (TLV) format. The first byte is consisting of Type (bits [7:4]), defining the command, and Length (bits [3:0]), the length of the arguments in bytes. If the Length bits are 0xF (binary 1111), the command has its length specified in bits [5:0] of the second byte.
+
+| Number | Name | Length | Description |
+| ------ | --------------- | ------ | ------------------------------------------------------------------------------------------------- |
+| 0 | Param value | >=2 | Response to the "Get params" command. The first byte is the param number, the rest are the value. |
+| 1 | Sensor data | >=1 | Sensor data. |
+| 2 | Battery level | 1 | Battery level in 10mV steps from 2V (0 = 2V, 255 = 4.55V). |
+| 3 | Battery Percent | 1 | Battery level in percent (0 to 100). |
+| 4 | Event data | >=1 | Event data |
+
+
+
+### Sensor Data
+
+Sensor data consists of a byte signifying the sensor type, and zero or more bytes of sensor data. The defined types and corresponding data formats are:
+
+| Number | Name | Length | Description |
+| ---------- | ----------- | ----------- | ---------------------------------------------------------------------------------------- |
+| 0 (0x00) | unknown | 0 | No data. |
+| 1 (0x01) | gps | 1 or 11 | GPS coordinates. |
+| 2 (0x02) | temp | 1 or 2 or 4 | Temperature in degrees Celsius. |
+| 3 (0x03) | humi | 1 or 2 or 4 | Relative humidity in %RH. |
+| 4 (0x04) | pressure | 4 | Barometric pressure in hPa. |
+| 5 (0x05) | pm10 | 4 | PM10 Concentration in μg/m3. |
+| 6 (0x06) | pm2.5 | 4 | PM2.5 Concentration in μg/m3. |
+| 7 (0x07) | tvoc | 4 | VOC Concentration in ppb. |
+| 8 (0x08) | no2 | 4 | Nitrogen Dioxide Concentration in ppm. |
+| 9 (0x09) | co2 | 4 | Carbon Dioxide Concentration in ppm. |
+| 10 (0x0a) | airFlow | 4 | Air Flow Rate (Wind Speed) in m/s. |
+| 11 (0x0b) | voltage | 1 or 2 or 4 | Voltage in V. |
+| 12 (0x0c) | current | 1 or 2 or 4 | Electric Current in A. |
+| 13 (0x0d) | power | 1 or 2 or 4 | Electric Power in W. |
+| 14 (0x0e) | powerUsage | 4 | Electric energy usage in kWh. |
+| 15 (0x0f) | waterUsage | 4 | Water usage in Kilolitres. |
+| 16 (0x10) | speed | 4 | Movement Speed in m/s. |
+| 17 (0x11) | rotation | 4 | Rotational speed in RPM. |
+| 18 (0x12) | counter | 4 | A generic counter in a 32-bits unsigned value. |
+| 19 (0x13) | digital | 1 | A generic digital value.
+
+ | Message field
+ |
+ Description
+ |
+
+
+ | Type
+ |
+ Message type. 1 byte value.
+ |
+
+
+ | rDevEUI
+ |
+ A random device EUI for the current device. 8 bytes long.
+ |
+
+
+ | devPubKey
+ |
+ The ECDH public key generated by device. 64 bytes long.
+ |
+
+
+ | serverPubKey
+ |
+ The ECDH public key generated by the server. 64 bytes long.
+ |
+
+
+ | version
+ |
+ Protocol version. Value is 0x01. 1 byte value.
+ |
+
+
+ | provisionIdHash
+ |
+ Hashed Provision ID. 32 bytes long.
+ |
+
+
+ | serverNonce
+ |
+ Random value for verifyCode generation. 4 bytes long.
+ |
+
+
+ | devNonce
+ |
+ Random value for verifyCode generation. 4 bytes long.
+ |
+
+
+ | devEUI
+ |
+ The assigned Device EUI for the device. 8 bytes long.
+ |
+
+
+ | verifyCode
+ |
+ Verification code. 16 bytes long.
+ |
+
+
+
+### ECDH
+
+In our example device source code, we used the following C source at GitHub for the ECDH.
+
+https://github.com/kokke/tiny-ECDH-c
+
+The compiled size is as small as 1.4KiB for ARM Thumb Code. It minimized the extra cost for fitting into an MCU.
+
+The ECDH key exchange will use the NIST K-233 curve. Private key size is 32 bytes, public key size is 64 bytes.
+
+
+### Key generation
+
+The keys used for LoRaWAN are generated inside the device instead of sending via the air. After the ECDH key exchange (Hello message), both device and server will hold a sharedKey in the same value. Then it will use the following calculation to derive to several keys.
+
+When the authentication is done, the derived AppKey and NwkKey should be stored in FLASH for later LoRaWAN OTAA use.
+
+
+```
+ AppKey = aes128_encrypt (sharedKey[0..15], rDevEUI | pad 0x01)
+
+ NwkKey = aes128_encrypt (sharedKey[32..47], rDevEUI | pad 0x02)
+
+ ProvKey = aes128_encrypt (sharedKey[16..23] | sharedKey[48..55], rDevEUI | pad 0x03)
+```
+
+
+AppKey and NwkKey are the keys for OTAA on LoRa communication.
+
+For 1.0.x LoRa, NwkKey will be used as AppKey for OTAA.
+
+ProvKey is used as the key for payload encryption of Auth messages and responses.
+
+Example:
+
+
+```
+// Input
+ sharedkey = {0x57, 0x57, 0x3A, 0x81, 0xE2, 0x7E, 0x48, 0x26, 0xFA, 0x8E, 0x18, 0x70, 0xCD,
+ 0x6B, 0x66, 0x40, 0xF3, 0x90, 0x5D, 0x98, 0x40, 0xF4, 0x12, 0xFA, 0xAE, 0x74,
+ 0x0B, 0x12, 0xE0, 0x01, 0x00, 0x00, 0xC4, 0xD8, 0x27, 0xA9, 0x37, 0x49, 0xEE,
+ 0x44, 0xEA, 0x1B, 0xAC, 0x1C, 0x18, 0x8C, 0x03, 0xAA, 0x6B, 0x02, 0xDA, 0x1C,
+ 0x68, 0xE9, 0xE8, 0xE6, 0xCA, 0xB9, 0xD1, 0xED, 0x91, 0x01, 0x00, 0x00};
+
+// Output
+ appkey = {0xFC, 0x3B, 0xDD, 0x59, 0x22, 0x87, 0xD9, 0x73
+ 0x48, 0xC0, 0x0B, 0xAC, 0x46, 0xB3, 0x05, 0x79};
+ nwkkey = {0x5B, 0x87, 0x83, 0xAF, 0x06, 0xFF, 0xB3, 0x62,
+ 0x9D, 0x03, 0x77, 0x9B, 0xF3, 0x4E, 0x12, 0x89};
+ provkey = {0x29, 0x53, 0x01, 0x98, 0x2D, 0x35, 0xC7, 0x2F,
+ 0x71, 0x42, 0xB9, 0xDD, 0x07, 0xFE, 0x1D, 0xEF};
+```
+
+
+
+
+
+## Request for Provision ID (CSV file)
+
+This is the CSV file you need to send to us to request for the Provision ID.
+
+
+```
+ MatchX Device Provisioning,,,,,
+ manufacturerName,MatchX GmbH,,,,
+ provisionId,model,serialNumber,fixedDevEUI,devEUI,appEUI
+ ,M-1234,S000000,Y,000000fffe000000,0000000000000000
+ ,M-1234,S000001,Y,000000fffe000001,0000000000000000
+ ,M-1234,S000002,Y,000000fffe000002,0000000000000000
+ ,M-1234,S000003,Y,000000fffe000003,0000000000000000
+ ,M-1234,S000004,Y,000000fffe000004,0000000000000000
+ ,M-1234,S000005,Y,000000fffe000005,0000000000000000
+ ,M-1234,S000006,Y,000000fffe000006,0000000000000000
+ ,M-1234,S000007,Y,000000fffe000007,0000000000000000
+```
+
+
+The first line is the signature, please don’t modify it.
+
+The second line is the name of the device manufacturer. Modify it to your company name.
+
+The third line is the header, please don’t modify it.
+
+Starting from the fourth line, it is the list of device information you need for a Provision ID.
+
+“provisionId” is the Provision ID, we will generate one for you if it is blank.
+
+“model” is the model number of your device.
+
+“serialNumber” is the serial number of your device.
+
+When your device has its own MAC address and is willing to use it as the Device EUI on LoRa, you should set the “fixedDevEUI” to “Y” and fill the “fixedDevEUI”.
+
+“appEUI” is not used at the moment, please fill it with “0000000000000000”.
+
+Here is the view when you use a spreadsheet program to edit the file.
+
+
+
+
+
+
+
+
+48-bits MAC to 64-bits EUI
+
+To convert a 48-bits MAC address into a 64-bits EUI, you need to insert a “0xff 0xfe” in the middle of it.
+
+For example:
+
+
+```
+ MAC = 01 02 03 04 05 06
+ EUI = 01 02 03 ff fe 04 05 06
+```
+
+
+
+
+After the request is approved, we will send you back the report file in CSV format. Here is an example for the report that is viewed with a spreadsheet program.
+
+
+
+
+
+The important parts are the “provisionId” and “provisionIdHash”. You need to program this information to the device. For the device with MAC and using fixed Device EUI, you need to take care of the “devEUI” and make sure the Provision ID is programmed to the corresponding device.
+
+Here is an example CSV file for the device that will use a random Device EUI. The “fixedDevEUI” will set to “N” and “deviceEUI” is blank. A random device EUI will assign to the device after provisioning.
+
+
+```
+ MatchX Device Provisioning,,,,,
+ manufacturerName,MatchX GmbH,,,,
+ provisionId,model,serialNumber,fixedDevEUI,devEUI,appEUI
+ ,M-1234,S000000,N,,0000000000000000
+ ,M-1234,S000001,N,,0000000000000000
+ ,M-1234,S000002,N,,0000000000000000
+ ,M-1234,S000003,N,,0000000000000000
+ ,M-1234,S000004,N,,0000000000000000
+ ,M-1234,S000005,N,,0000000000000000
+ ,M-1234,S000006,N,,0000000000000000
+ ,M-1234,S000007,N,,0000000000000000
+```
+
+
+
+
+
+
+
+
From 17c30e07728be7ea1b24a34090104b988dd175e9 Mon Sep 17 00:00:00 2001
From: jeffstahlnecker <45363541+jeffstahlnecker@users.noreply.github.com>
Date: Mon, 5 Jul 2021 20:27:39 +0200
Subject: [PATCH 089/234] New translations miner-health.mdx (German)
---
.../current/tutorials/m2-pro/miner-health.mdx | 48 +++++++++++++++++++
1 file changed, 48 insertions(+)
create mode 100644 i18n/de/docusaurus-plugin-content-docs/current/tutorials/m2-pro/miner-health.mdx
diff --git a/i18n/de/docusaurus-plugin-content-docs/current/tutorials/m2-pro/miner-health.mdx b/i18n/de/docusaurus-plugin-content-docs/current/tutorials/m2-pro/miner-health.mdx
new file mode 100644
index 0000000..8e488ac
--- /dev/null
+++ b/i18n/de/docusaurus-plugin-content-docs/current/tutorials/m2-pro/miner-health.mdx
@@ -0,0 +1,48 @@
+---
+sidebar_position: 4
+---
+
+# Miner Health
+
+Miner Health rewards users for placing their miner in a fashion that will provide a strong LoRa signal. These are the six items that make up miner health:
+* Fuel (Live)
+* Uptime (Live)
+* GPS Signal
+* Orientation
+* Proximity
+* Altitude
+
+## Miner Health Grace Period
+Each M2 Pro Miner has a 90-day grace period that begins with the initial registration of the miner. During this period of time, health will not affect the mining potential of the M2 Pro. After the grace period is over, the current health of the miner will be applied.
+
+If the fuel tank is empty after the grace period, mining efficiency will be reduced by 50% (see Fuel).
+
+## Fuel (Live)
+Each miner has a fuel tank. This tank is equal to the size of all the MXC mined by this miner. So a miner mined 10 MXC, the tank size would then be 10 MXC.
+
+*Fuel has a 50 percent influence on your mining potential*
+
+### How does this work?
+
+As a miner mines, it maintains the fuel tank. All newly mined MXC are added to the tank to ensure it continues to mine at peek efficiency. When MXC is removed from the fuel tank, the miner will mine at a reduced efficiency. For example, if all MXC would be removed from the fuel tank, the miner would mine at 50% efficiency.
+
+### Fuel percentage increases over time
+As a miner mines, it continues to add MXC. If a miner's tank size is 99 MXC, and all the fuel is removed from the tank, then the fuel percentage would be zero. However, if the miner mines one MXC on the following day, the fuel balance increases by one MXC, as does the tank size, resulting in a 1% fuel capacity. Naturally this version of "refilling" the tank takes time, however it ensure that the M2 Pro retains its value after all fuel is removed.
+
+## Uptime
+Uptime is a reliability metric calculated using the average reliability of the miner over the past 7 days. Uptime as a whole, has a 20 percent influence on miner health.
+
+## GPS Signal
+GPS is another form of wireless signal. Therefore we can *assume* that if the miner has a strong GPS signal, it's positioned well enough to provide an excellent wireless network. *GPS has a 10 percent influence on miner health.*
+
+## Orientation
+An M2 Pro antenna provides a wireless signal to the sides of the miner. If the miner is mounted horizontally, the network that it provides will be extremely limited (i.e. airplanes and moles would benefit when they pass overhead or underneath the miner). Therefore, orientation ensures a miner is mounted vertically as designed, with the antenna facing upwards. *Orientation has an 8 percent influence on miner health.*
+
+## Proximity
+In order to achieve a broad wireless network, and in doing so get the most possible coverage, proximity rewards users for spreading out their miners. If a miner is in close proximity with another miner, then it will receive a proximity hit on miner health. *Proximity has a 7 percent influence on miner health.*
+
+## Altitude
+A miner placed in a higher position is more likely to provide a wireless network that transverses physical obstacles. Altitude is measured by using the pressure sensor in the miner itself, and combining it with a terrain elevation database to determine how high above ground level the miner is. This is then cross referenced with the elevation of nearby miners to determine whether the miner is ideally placed. *Altitude has a 5 percent influence on miner health.*
+
+### Proposed alternative to altitude
+As altitude is extremely difficult to measure, we are considering a method for users to manually measure the signal strength of a miner.
From f7c69bcd0e3aab93673546d4d16bdb8eadd02165 Mon Sep 17 00:00:00 2001
From: jeffstahlnecker <45363541+jeffstahlnecker@users.noreply.github.com>
Date: Mon, 5 Jul 2021 20:27:40 +0200
Subject: [PATCH 090/234] New translations payload.md (German)
---
.../current/tutorials/devices/payload.md | 194 ++++++++++++++++++
1 file changed, 194 insertions(+)
create mode 100644 i18n/de/docusaurus-plugin-content-docs/current/tutorials/devices/payload.md
diff --git a/i18n/de/docusaurus-plugin-content-docs/current/tutorials/devices/payload.md b/i18n/de/docusaurus-plugin-content-docs/current/tutorials/devices/payload.md
new file mode 100644
index 0000000..733d9ab
--- /dev/null
+++ b/i18n/de/docusaurus-plugin-content-docs/current/tutorials/devices/payload.md
@@ -0,0 +1,194 @@
+---
+title: Payload Format
+sidebar_label: Payload Format
+---
+
+## Uplink Payload Data Format
+
+The payload is consisting of several commands in a Type-Length-Value (TLV) format. The first byte is consisting of Type (bits [7:4]), defining the command, and Length (bits [3:0]), the length of the arguments in bytes. If the Length bits are 0xF (binary 1111), the command has its length specified in bits [5:0] of the second byte.
+
+| Number | Name | Length | Description |
+| ------ | --------------- | ------ | ------------------------------------------------------------------------------------------------- |
+| 0 | Param value | >=2 | Response to the "Get params" command. The first byte is the param number, the rest are the value. |
+| 1 | Sensor data | >=1 | Sensor data. |
+| 2 | Battery level | 1 | Battery level in 10mV steps from 2V (0 = 2V, 255 = 4.55V). |
+| 3 | Battery Percent | 1 | Battery level in percent (0 to 100). |
+| 4 | Event data | >=1 | Event data |
+
+
+
+### Sensor Data
+
+Sensor data consists of a byte signifying the sensor type, and zero or more bytes of sensor data. The defined types and corresponding data formats are:
+
+| Number | Name | Length | Description |
+| ---------- | ----------- | ----------- | ---------------------------------------------------------------------------------------- |
+| 0 (0x00) | unknown | 0 | No data. |
+| 1 (0x01) | gps | 1 or 11 | GPS coordinates. |
+| 2 (0x02) | temp | 1 or 2 or 4 | Temperature in degrees Celsius. |
+| 3 (0x03) | humi | 1 or 2 or 4 | Relative humidity in %RH. |
+| 4 (0x04) | pressure | 4 | Barometric pressure in hPa. |
+| 5 (0x05) | pm10 | 4 | PM10 Concentration in μg/m3. |
+| 6 (0x06) | pm2.5 | 4 | PM2.5 Concentration in μg/m3. |
+| 7 (0x07) | tvoc | 4 | VOC Concentration in ppb. |
+| 8 (0x08) | no2 | 4 | Nitrogen Dioxide Concentration in ppm. |
+| 9 (0x09) | co2 | 4 | Carbon Dioxide Concentration in ppm. |
+| 10 (0x0a) | airFlow | 4 | Air Flow Rate (Wind Speed) in m/s. |
+| 11 (0x0b) | voltage | 1 or 2 or 4 | Voltage in V. |
+| 12 (0x0c) | current | 1 or 2 or 4 | Electric Current in A. |
+| 13 (0x0d) | power | 1 or 2 or 4 | Electric Power in W. |
+| 14 (0x0e) | powerUsage | 4 | Electric energy usage in kWh. |
+| 15 (0x0f) | waterUsage | 4 | Water usage in Kilolitres. |
+| 16 (0x10) | speed | 4 | Movement Speed in m/s. |
+| 17 (0x11) | rotation | 4 | Rotational speed in RPM. |
+| 18 (0x12) | counter | 4 | A generic counter in a 32-bits unsigned value. |
+| 19 (0x13) | digital | 1 | A generic digital value.
+
+ | Message field
+ |
+ Description
+ |
+
+
+ | Type
+ |
+ Message type. 1 byte value.
+ |
+
+
+ | rDevEUI
+ |
+ A random device EUI for the current device. 8 bytes long.
+ |
+
+
+ | devPubKey
+ |
+ The ECDH public key generated by device. 64 bytes long.
+ |
+
+
+ | serverPubKey
+ |
+ The ECDH public key generated by the server. 64 bytes long.
+ |
+
+
+ | version
+ |
+ Protocol version. Value is 0x01. 1 byte value.
+ |
+
+
+ | provisionIdHash
+ |
+ Hashed Provision ID. 32 bytes long.
+ |
+
+
+ | serverNonce
+ |
+ Random value for verifyCode generation. 4 bytes long.
+ |
+
+
+ | devNonce
+ |
+ Random value for verifyCode generation. 4 bytes long.
+ |
+
+
+ | devEUI
+ |
+ The assigned Device EUI for the device. 8 bytes long.
+ |
+
+
+ | verifyCode
+ |
+ Verification code. 16 bytes long.
+ |
+
+
+
+### ECDH
+
+In our example device source code, we used the following C source at GitHub for the ECDH.
+
+https://github.com/kokke/tiny-ECDH-c
+
+The compiled size is as small as 1.4KiB for ARM Thumb Code. It minimized the extra cost for fitting into an MCU.
+
+The ECDH key exchange will use the NIST K-233 curve. Private key size is 32 bytes, public key size is 64 bytes.
+
+
+### Key generation
+
+The keys used for LoRaWAN are generated inside the device instead of sending via the air. After the ECDH key exchange (Hello message), both device and server will hold a sharedKey in the same value. Then it will use the following calculation to derive to several keys.
+
+When the authentication is done, the derived AppKey and NwkKey should be stored in FLASH for later LoRaWAN OTAA use.
+
+
+```
+ AppKey = aes128_encrypt (sharedKey[0..15], rDevEUI | pad 0x01)
+
+ NwkKey = aes128_encrypt (sharedKey[32..47], rDevEUI | pad 0x02)
+
+ ProvKey = aes128_encrypt (sharedKey[16..23] | sharedKey[48..55], rDevEUI | pad 0x03)
+```
+
+
+AppKey and NwkKey are the keys for OTAA on LoRa communication.
+
+For 1.0.x LoRa, NwkKey will be used as AppKey for OTAA.
+
+ProvKey is used as the key for payload encryption of Auth messages and responses.
+
+Example:
+
+
+```
+// Input
+ sharedkey = {0x57, 0x57, 0x3A, 0x81, 0xE2, 0x7E, 0x48, 0x26, 0xFA, 0x8E, 0x18, 0x70, 0xCD,
+ 0x6B, 0x66, 0x40, 0xF3, 0x90, 0x5D, 0x98, 0x40, 0xF4, 0x12, 0xFA, 0xAE, 0x74,
+ 0x0B, 0x12, 0xE0, 0x01, 0x00, 0x00, 0xC4, 0xD8, 0x27, 0xA9, 0x37, 0x49, 0xEE,
+ 0x44, 0xEA, 0x1B, 0xAC, 0x1C, 0x18, 0x8C, 0x03, 0xAA, 0x6B, 0x02, 0xDA, 0x1C,
+ 0x68, 0xE9, 0xE8, 0xE6, 0xCA, 0xB9, 0xD1, 0xED, 0x91, 0x01, 0x00, 0x00};
+
+// Output
+ appkey = {0xFC, 0x3B, 0xDD, 0x59, 0x22, 0x87, 0xD9, 0x73
+ 0x48, 0xC0, 0x0B, 0xAC, 0x46, 0xB3, 0x05, 0x79};
+ nwkkey = {0x5B, 0x87, 0x83, 0xAF, 0x06, 0xFF, 0xB3, 0x62,
+ 0x9D, 0x03, 0x77, 0x9B, 0xF3, 0x4E, 0x12, 0x89};
+ provkey = {0x29, 0x53, 0x01, 0x98, 0x2D, 0x35, 0xC7, 0x2F,
+ 0x71, 0x42, 0xB9, 0xDD, 0x07, 0xFE, 0x1D, 0xEF};
+```
+
+
+
+
+
+## Request for Provision ID (CSV file)
+
+This is the CSV file you need to send to us to request for the Provision ID.
+
+
+```
+ MatchX Device Provisioning,,,,,
+ manufacturerName,MatchX GmbH,,,,
+ provisionId,model,serialNumber,fixedDevEUI,devEUI,appEUI
+ ,M-1234,S000000,Y,000000fffe000000,0000000000000000
+ ,M-1234,S000001,Y,000000fffe000001,0000000000000000
+ ,M-1234,S000002,Y,000000fffe000002,0000000000000000
+ ,M-1234,S000003,Y,000000fffe000003,0000000000000000
+ ,M-1234,S000004,Y,000000fffe000004,0000000000000000
+ ,M-1234,S000005,Y,000000fffe000005,0000000000000000
+ ,M-1234,S000006,Y,000000fffe000006,0000000000000000
+ ,M-1234,S000007,Y,000000fffe000007,0000000000000000
+```
+
+
+The first line is the signature, please don’t modify it.
+
+The second line is the name of the device manufacturer. Modify it to your company name.
+
+The third line is the header, please don’t modify it.
+
+Starting from the fourth line, it is the list of device information you need for a Provision ID.
+
+“provisionId” is the Provision ID, we will generate one for you if it is blank.
+
+“model” is the model number of your device.
+
+“serialNumber” is the serial number of your device.
+
+When your device has its own MAC address and is willing to use it as the Device EUI on LoRa, you should set the “fixedDevEUI” to “Y” and fill the “fixedDevEUI”.
+
+“appEUI” is not used at the moment, please fill it with “0000000000000000”.
+
+Here is the view when you use a spreadsheet program to edit the file.
+
+
+
+
+
+
+
+
+48-bits MAC to 64-bits EUI
+
+To convert a 48-bits MAC address into a 64-bits EUI, you need to insert a “0xff 0xfe” in the middle of it.
+
+For example:
+
+
+```
+ MAC = 01 02 03 04 05 06
+ EUI = 01 02 03 ff fe 04 05 06
+```
+
+
+
+
+After the request is approved, we will send you back the report file in CSV format. Here is an example for the report that is viewed with a spreadsheet program.
+
+
+
+
+
+The important parts are the “provisionId” and “provisionIdHash”. You need to program this information to the device. For the device with MAC and using fixed Device EUI, you need to take care of the “devEUI” and make sure the Provision ID is programmed to the corresponding device.
+
+Here is an example CSV file for the device that will use a random Device EUI. The “fixedDevEUI” will set to “N” and “deviceEUI” is blank. A random device EUI will assign to the device after provisioning.
+
+
+```
+ MatchX Device Provisioning,,,,,
+ manufacturerName,MatchX GmbH,,,,
+ provisionId,model,serialNumber,fixedDevEUI,devEUI,appEUI
+ ,M-1234,S000000,N,,0000000000000000
+ ,M-1234,S000001,N,,0000000000000000
+ ,M-1234,S000002,N,,0000000000000000
+ ,M-1234,S000003,N,,0000000000000000
+ ,M-1234,S000004,N,,0000000000000000
+ ,M-1234,S000005,N,,0000000000000000
+ ,M-1234,S000006,N,,0000000000000000
+ ,M-1234,S000007,N,,0000000000000000
+```
+
+
+
+
+
+
+
+
From e0cb48cdd7849c68cff0b4a8d5cf97ad16e41956 Mon Sep 17 00:00:00 2001
From: jeffstahlnecker <45363541+jeffstahlnecker@users.noreply.github.com>
Date: Fri, 16 Jul 2021 14:46:50 +0200
Subject: [PATCH 145/234] New translations miner-health.mdx (French)
---
.../current/tutorials/m2-pro/miner-health.mdx | 48 +++++++++++++++++++
1 file changed, 48 insertions(+)
create mode 100644 i18n/fr/docusaurus-plugin-content-docs/current/tutorials/m2-pro/miner-health.mdx
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/m2-pro/miner-health.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/m2-pro/miner-health.mdx
new file mode 100644
index 0000000..8e488ac
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/m2-pro/miner-health.mdx
@@ -0,0 +1,48 @@
+---
+sidebar_position: 4
+---
+
+# Miner Health
+
+Miner Health rewards users for placing their miner in a fashion that will provide a strong LoRa signal. These are the six items that make up miner health:
+* Fuel (Live)
+* Uptime (Live)
+* GPS Signal
+* Orientation
+* Proximity
+* Altitude
+
+## Miner Health Grace Period
+Each M2 Pro Miner has a 90-day grace period that begins with the initial registration of the miner. During this period of time, health will not affect the mining potential of the M2 Pro. After the grace period is over, the current health of the miner will be applied.
+
+If the fuel tank is empty after the grace period, mining efficiency will be reduced by 50% (see Fuel).
+
+## Fuel (Live)
+Each miner has a fuel tank. This tank is equal to the size of all the MXC mined by this miner. So a miner mined 10 MXC, the tank size would then be 10 MXC.
+
+*Fuel has a 50 percent influence on your mining potential*
+
+### How does this work?
+
+As a miner mines, it maintains the fuel tank. All newly mined MXC are added to the tank to ensure it continues to mine at peek efficiency. When MXC is removed from the fuel tank, the miner will mine at a reduced efficiency. For example, if all MXC would be removed from the fuel tank, the miner would mine at 50% efficiency.
+
+### Fuel percentage increases over time
+As a miner mines, it continues to add MXC. If a miner's tank size is 99 MXC, and all the fuel is removed from the tank, then the fuel percentage would be zero. However, if the miner mines one MXC on the following day, the fuel balance increases by one MXC, as does the tank size, resulting in a 1% fuel capacity. Naturally this version of "refilling" the tank takes time, however it ensure that the M2 Pro retains its value after all fuel is removed.
+
+## Uptime
+Uptime is a reliability metric calculated using the average reliability of the miner over the past 7 days. Uptime as a whole, has a 20 percent influence on miner health.
+
+## GPS Signal
+GPS is another form of wireless signal. Therefore we can *assume* that if the miner has a strong GPS signal, it's positioned well enough to provide an excellent wireless network. *GPS has a 10 percent influence on miner health.*
+
+## Orientation
+An M2 Pro antenna provides a wireless signal to the sides of the miner. If the miner is mounted horizontally, the network that it provides will be extremely limited (i.e. airplanes and moles would benefit when they pass overhead or underneath the miner). Therefore, orientation ensures a miner is mounted vertically as designed, with the antenna facing upwards. *Orientation has an 8 percent influence on miner health.*
+
+## Proximity
+In order to achieve a broad wireless network, and in doing so get the most possible coverage, proximity rewards users for spreading out their miners. If a miner is in close proximity with another miner, then it will receive a proximity hit on miner health. *Proximity has a 7 percent influence on miner health.*
+
+## Altitude
+A miner placed in a higher position is more likely to provide a wireless network that transverses physical obstacles. Altitude is measured by using the pressure sensor in the miner itself, and combining it with a terrain elevation database to determine how high above ground level the miner is. This is then cross referenced with the elevation of nearby miners to determine whether the miner is ideally placed. *Altitude has a 5 percent influence on miner health.*
+
+### Proposed alternative to altitude
+As altitude is extremely difficult to measure, we are considering a method for users to manually measure the signal strength of a miner.
From a5859031e9641cd7293c443ec1ea85cf2e528a32 Mon Sep 17 00:00:00 2001
From: jeffstahlnecker <45363541+jeffstahlnecker@users.noreply.github.com>
Date: Fri, 16 Jul 2021 14:46:51 +0200
Subject: [PATCH 146/234] New translations payload.md (French)
---
.../current/tutorials/devices/payload.md | 194 ++++++++++++++++++
1 file changed, 194 insertions(+)
create mode 100644 i18n/fr/docusaurus-plugin-content-docs/current/tutorials/devices/payload.md
diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/devices/payload.md b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/devices/payload.md
new file mode 100644
index 0000000..733d9ab
--- /dev/null
+++ b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/devices/payload.md
@@ -0,0 +1,194 @@
+---
+title: Payload Format
+sidebar_label: Payload Format
+---
+
+## Uplink Payload Data Format
+
+The payload is consisting of several commands in a Type-Length-Value (TLV) format. The first byte is consisting of Type (bits [7:4]), defining the command, and Length (bits [3:0]), the length of the arguments in bytes. If the Length bits are 0xF (binary 1111), the command has its length specified in bits [5:0] of the second byte.
+
+| Number | Name | Length | Description |
+| ------ | --------------- | ------ | ------------------------------------------------------------------------------------------------- |
+| 0 | Param value | >=2 | Response to the "Get params" command. The first byte is the param number, the rest are the value. |
+| 1 | Sensor data | >=1 | Sensor data. |
+| 2 | Battery level | 1 | Battery level in 10mV steps from 2V (0 = 2V, 255 = 4.55V). |
+| 3 | Battery Percent | 1 | Battery level in percent (0 to 100). |
+| 4 | Event data | >=1 | Event data |
+
+
+
+### Sensor Data
+
+Sensor data consists of a byte signifying the sensor type, and zero or more bytes of sensor data. The defined types and corresponding data formats are:
+
+| Number | Name | Length | Description |
+| ---------- | ----------- | ----------- | ---------------------------------------------------------------------------------------- |
+| 0 (0x00) | unknown | 0 | No data. |
+| 1 (0x01) | gps | 1 or 11 | GPS coordinates. |
+| 2 (0x02) | temp | 1 or 2 or 4 | Temperature in degrees Celsius. |
+| 3 (0x03) | humi | 1 or 2 or 4 | Relative humidity in %RH. |
+| 4 (0x04) | pressure | 4 | Barometric pressure in hPa. |
+| 5 (0x05) | pm10 | 4 | PM10 Concentration in μg/m3. |
+| 6 (0x06) | pm2.5 | 4 | PM2.5 Concentration in μg/m3. |
+| 7 (0x07) | tvoc | 4 | VOC Concentration in ppb. |
+| 8 (0x08) | no2 | 4 | Nitrogen Dioxide Concentration in ppm. |
+| 9 (0x09) | co2 | 4 | Carbon Dioxide Concentration in ppm. |
+| 10 (0x0a) | airFlow | 4 | Air Flow Rate (Wind Speed) in m/s. |
+| 11 (0x0b) | voltage | 1 or 2 or 4 | Voltage in V. |
+| 12 (0x0c) | current | 1 or 2 or 4 | Electric Current in A. |
+| 13 (0x0d) | power | 1 or 2 or 4 | Electric Power in W. |
+| 14 (0x0e) | powerUsage | 4 | Electric energy usage in kWh. |
+| 15 (0x0f) | waterUsage | 4 | Water usage in Kilolitres. |
+| 16 (0x10) | speed | 4 | Movement Speed in m/s. |
+| 17 (0x11) | rotation | 4 | Rotational speed in RPM. |
+| 18 (0x12) | counter | 4 | A generic counter in a 32-bits unsigned value. |
+| 19 (0x13) | digital | 1 | A generic digital value.
+ 
+ 
+
+
+
+
+
+
+
+