diff --git a/i18n/de/docusaurus-plugin-content-blog/2019-05-30-welcome.md b/i18n/de/docusaurus-plugin-content-blog/2019-05-30-welcome.md index 7783719..592f3ed 100644 --- a/i18n/de/docusaurus-plugin-content-blog/2019-05-30-welcome.md +++ b/i18n/de/docusaurus-plugin-content-blog/2019-05-30-welcome.md @@ -2,10 +2,12 @@ slug: welcome title: Welcome author: Jeff Stahlnecker -author_title: Front End Engineer @ Facebook +author_title: Head of Development at MXC Foundation author_url: https://github.com/jeffstahlnecker author_image_url: https://avatars.githubusercontent.com/u/45363541?v=4 -tags: [welcome, intro] +tags: + - welcome + - intro --- It's the beginning. Since I returned to the community following the Miner Health release, I've been saying that we'll impove transparency in development at MXC. This site is the beginning of this transparency. More content will be added here. diff --git a/i18n/de/docusaurus-plugin-content-blog/2021-05-30-welcome.md b/i18n/de/docusaurus-plugin-content-blog/2021-05-30-welcome.md new file mode 100644 index 0000000..592f3ed --- /dev/null +++ b/i18n/de/docusaurus-plugin-content-blog/2021-05-30-welcome.md @@ -0,0 +1,13 @@ +--- +slug: welcome +title: Welcome +author: Jeff Stahlnecker +author_title: Head of Development at MXC Foundation +author_url: https://github.com/jeffstahlnecker +author_image_url: https://avatars.githubusercontent.com/u/45363541?v=4 +tags: + - welcome + - intro +--- + +It's the beginning. Since I returned to the community following the Miner Health release, I've been saying that we'll impove transparency in development at MXC. This site is the beginning of this transparency. More content will be added here. diff --git a/i18n/de/docusaurus-plugin-content-blog/2021-07-05-tech-update.md b/i18n/de/docusaurus-plugin-content-blog/2021-07-05-tech-update.md new file mode 100644 index 0000000..2dd0bc2 --- /dev/null +++ b/i18n/de/docusaurus-plugin-content-blog/2021-07-05-tech-update.md @@ -0,0 +1,36 @@ +--- +slug: 2021-07-05-tech-update +title: Tech Update - July 5, 2021 +author: Jeff Stahlnecker +author_title: Head of Development @ MXC Foundation +author_url: https://github.com/jeffstahlnecker +author_image_url: https://avatars.githubusercontent.com/u/45363541?v=4 +tags: + - tech update + - datadash + - supernode + - dhx +--- + +Welcome to the very first MXC tech update! + +This week the tech team has been extremely busy. Throughout the past sprint we've focused on closing any and all ongoing projects. That brought us back to a few "low hanging" items that will add some EPIC value to our users -- especially those interested in connecting LoRa devices. + +## Device Provisioning +Our very own backend engineer Lixuan took a deep dive to test the device provisioning system built by Ian to ensure that it was ready to be added with our live code. She solved a number of conflicts (device provisioning has been *ready* since January!), then ran it through a round of rigorous testing. This was done in collaboration with MatchX embedded software engineer Ian. They did some great work, and you'll see device provisioning going live early this week. In the meantime, you can check out the technical documentation here: [Device Provisioning FAQ](/docs/tutorials/devices/provisioning) + +As part of our focus on devices during the past two weeks, Lixuan also solved an issue which kept users from adding new devices on a supernode. We should be in ship-shape, and ready for some developer interaction. Feel free to send us your feedback! :) + +## Foundation for DHX Simulator Improvement +The DataDash DHX Simulator has been a long-standing issue. While it works, it's a little buggy, and once in a while spits out something unexpected. Our backend developer Pavel decided enough is enough, and jumped in to solve the challenge of the buggy simulator. To accomplish this he brought together the required information from a ton of different sources and built an API for the DataDash team to integrate. For those developers out there, I'll update this post with a link to the API as soon as it is live. + +## Improved Technical Support +We've been working hard to improve the technical support services provided by both MXC and MatchX. Our Tech Support Engineer Latifah has been hard at work building a ticketing system, integrating Discord, writing an internal support knowledgebase, while naturally also responding to your support requests. She's done an excellent job, and has set a strong foundation for reliable support moving forward. + +## Cleaning up the DataDash +Over the past two weeks our DataDash team has focused primarily on solving some pesky issues with the app. We also added support for DHX in the in-app address book. Just another feature to make life a little easier for you. + +## Contributing to DataHighway +Team members Luke, Ayush and Christian updated the DataHighway blockchain to add multisig functionality. They also made a number of improvements, and fixed issues with the Harbour testnet. You can review the full release notes [here](https://github.com/DataHighway-DHX/node/releases/tag/v3.0.5). + +That's the newest from Tech, and I'll be sure to update this post with that API link as soon as it goes live. \ No newline at end of file diff --git a/i18n/de/docusaurus-plugin-content-blog/2021-07-20-tech-update.md b/i18n/de/docusaurus-plugin-content-blog/2021-07-20-tech-update.md new file mode 100644 index 0000000..0a2127b --- /dev/null +++ b/i18n/de/docusaurus-plugin-content-blog/2021-07-20-tech-update.md @@ -0,0 +1,66 @@ +--- +slug: 2021-07-20-tech-update +title: Tech Update - July 20, 2021 +author: Jeff Stahlnecker +author_title: Head of Development @ MXC Foundation +author_url: https://github.com/jeffstahlnecker +author_image_url: https://avatars.githubusercontent.com/u/45363541?v=4 +tags: + - tech update + - datadash + - dhx + - mxc controller + - device provisioning +--- + +It's hard to believe it's been another two weeks --- and we've been EXTREMELY busy polishing up some pretty epic features. + +### All About Device Provisioning +It took us quite some time to get the [device provisioning](/docs/tutorials/devices/provisioning) developer preview ready. A bit longer than expected. Device provisioning interacts with a number of supernode systems on a regular basis, meaning that each of these interactions had to be thoroughly tested. During that process we found some items that could cause issues when the system scales, so we went ahead and took the time to resolve those before pushing out the feature. I'm excited to say that the device provisioning developer preview is now live and ready for action. If you want to get a manufacturer ID and begin testing the system, email support@mxc.org. + +In the meantime, Ian is actively working on providing a sample lora device source code to make it easier for manufacturers (and tinkerers) to get started. + +### DataDash Goes Dark (for beta testers) +That's right! We're working hard on getting dark mode out there for all of you night owls. If you want to get a sneak peek at dark mode and provide some epic feedback for us, you can join the live beta by using the command `!role ios` or `!role android` in our [Discord Community](https://mxc.news/discord). This will get you access to the dedicated beta channel for your phone, which provides you with the information you need to get signed up. + +:::caution + +Beta releases have bugs. By joining the beta, you will experience these bugs. If you find an issue, always report it directly to us in our [GitHub Repo](https://github.com/mxc-foundation/supernode-app/issues/new?assignees=&labels=bug%2Ctriage&template=bug_report.yml&title=%5BBug%5D%3A+). + +::: + +### Tech Support Continues to Amaze +Ok I just had to say this one. Yes it sounds markety, and I know not everyone is always amazed, but I'm very happy with it. Within a few weeks our new Tech Support Engineer Latifah has gone from "first day with LoRa" to actively troubleshooting miners, certifying issues, finding solutions for said issues, and of course ensuring that each member of our community receives top of the line technical support. + +Keep in mind, the only way to get "official" technical support is to email support@mxc.org or by using the `/support` command in our [Discord Server](https://mxc.news/discord). + +### MXC Controller - the news on the Web App +For those of you digging into the nitty-gritty of the LoRa/LPWAN infrastructure, I'm sure you've noticed a few issues with the current web app. We know about those, and we're working on rolling out a new web app to solve all of these issues. Because we've decided to move from React to a Flutter based web app, it will take us just a bit of time to get started. + +This week we started cross-training our React developer Nam to start working with Flutter. While he's been studying, he also worked with the Flutter team to outline the base architecture of the application so that we can finalize the overall design in our upcoming sprint. + +The MXC Controller will be available as beta during development. This will provide you with early access to key pages, while keeping you informed that it's beta, and will probably have a few bugs. + +:::caution + +Beta releases will have bugs. Just pointing that out again. + +::: + +Our first release will include: +* Base architecture +* Sign-in / Register +* Device Management/Configuration pages + +I'll keep you updated on the status of this as we move forward, and of course I'll share the GitHub repo when the development begins. + + +### Continuing our Contribution to DataHighway +We haven't forgotten DataHighway and we still strongly believe in the future of this project. Blockchain developers Luke and Ayush have been hard at work to both improve the DataHighway, and bring governance on chain. There's been some progress made in that direction, however we're being über careful. As we progress further with the development, we'll start contributing to the documentation as well to ensure it's easier for others to participate. + +### Community Contributions +This documentation is fluid, and anyone can work to help improve it. If you see something that you know about, and feel confident writing an article about, feel free to fork the repo, make the changes, and submit a pull request. + +Now I know that not everyone is familiar with GitHub. In that case, let me know on Discord and I'll open up a channel for us to chat. Either I'll teach you what you need to know to participate directly on GitHub, or you can just send me the article you believe should be in the documentation. + +That's been this week's news update --- uh yeah ok wrong channel. ;) \ No newline at end of file diff --git a/i18n/de/docusaurus-plugin-content-blog/2021-07-5-tech-update.md b/i18n/de/docusaurus-plugin-content-blog/2021-07-5-tech-update.md new file mode 100644 index 0000000..2dd0bc2 --- /dev/null +++ b/i18n/de/docusaurus-plugin-content-blog/2021-07-5-tech-update.md @@ -0,0 +1,36 @@ +--- +slug: 2021-07-05-tech-update +title: Tech Update - July 5, 2021 +author: Jeff Stahlnecker +author_title: Head of Development @ MXC Foundation +author_url: https://github.com/jeffstahlnecker +author_image_url: https://avatars.githubusercontent.com/u/45363541?v=4 +tags: + - tech update + - datadash + - supernode + - dhx +--- + +Welcome to the very first MXC tech update! + +This week the tech team has been extremely busy. Throughout the past sprint we've focused on closing any and all ongoing projects. That brought us back to a few "low hanging" items that will add some EPIC value to our users -- especially those interested in connecting LoRa devices. + +## Device Provisioning +Our very own backend engineer Lixuan took a deep dive to test the device provisioning system built by Ian to ensure that it was ready to be added with our live code. She solved a number of conflicts (device provisioning has been *ready* since January!), then ran it through a round of rigorous testing. This was done in collaboration with MatchX embedded software engineer Ian. They did some great work, and you'll see device provisioning going live early this week. In the meantime, you can check out the technical documentation here: [Device Provisioning FAQ](/docs/tutorials/devices/provisioning) + +As part of our focus on devices during the past two weeks, Lixuan also solved an issue which kept users from adding new devices on a supernode. We should be in ship-shape, and ready for some developer interaction. Feel free to send us your feedback! :) + +## Foundation for DHX Simulator Improvement +The DataDash DHX Simulator has been a long-standing issue. While it works, it's a little buggy, and once in a while spits out something unexpected. Our backend developer Pavel decided enough is enough, and jumped in to solve the challenge of the buggy simulator. To accomplish this he brought together the required information from a ton of different sources and built an API for the DataDash team to integrate. For those developers out there, I'll update this post with a link to the API as soon as it is live. + +## Improved Technical Support +We've been working hard to improve the technical support services provided by both MXC and MatchX. Our Tech Support Engineer Latifah has been hard at work building a ticketing system, integrating Discord, writing an internal support knowledgebase, while naturally also responding to your support requests. She's done an excellent job, and has set a strong foundation for reliable support moving forward. + +## Cleaning up the DataDash +Over the past two weeks our DataDash team has focused primarily on solving some pesky issues with the app. We also added support for DHX in the in-app address book. Just another feature to make life a little easier for you. + +## Contributing to DataHighway +Team members Luke, Ayush and Christian updated the DataHighway blockchain to add multisig functionality. They also made a number of improvements, and fixed issues with the Harbour testnet. You can review the full release notes [here](https://github.com/DataHighway-DHX/node/releases/tag/v3.0.5). + +That's the newest from Tech, and I'll be sure to update this post with that API link as soon as it goes live. \ No newline at end of file diff --git a/i18n/de/docusaurus-plugin-content-docs/current/tutorials/datadash/_category_.json b/i18n/de/docusaurus-plugin-content-docs/current/tutorials/datadash/_category_.json new file mode 100644 index 0000000..96eea63 --- /dev/null +++ b/i18n/de/docusaurus-plugin-content-docs/current/tutorials/datadash/_category_.json @@ -0,0 +1,4 @@ +{ + "label": "DataDash", + "position": 6 +} diff --git a/i18n/de/docusaurus-plugin-content-docs/current/tutorials/datadash/beta.md b/i18n/de/docusaurus-plugin-content-docs/current/tutorials/datadash/beta.md new file mode 100644 index 0000000..70fd43e --- /dev/null +++ b/i18n/de/docusaurus-plugin-content-docs/current/tutorials/datadash/beta.md @@ -0,0 +1,20 @@ +--- +sidebar_position: 2 +title: DataDash Beta Testing +--- + +# DataDash Ongoing Beta +At the moment we have an open beta DataDash group for both iOS and Android. We consider this a semi-closed beta because we require participants to join our beta discord channels. This is key for discussions among participants, and provides us with an easy way to interact with beta participants. + + +To participate as a beta tester follow the following steps: +1. Join our [Discord Community](https://mxc.news/discord) +1. Use the #bot-talk channel to send one of the following commands: + * `!role ios` + * `!role android` +1. You will then see a new channel in the `development` category. Follow the steps outlined at the top of the channel to join your selected test group. + +## DataDash Closed Beta +Before a major release, we will do a call for closed beta participants. This will have a limited number of available seats per operating system, and will only be available to current beta testers who actively submit feedback. + +Closed betas will provide users access to new and unreleased features that require a major backend change. Because of this, each participant will receive a test account on a "fake" supernode to work with. \ No newline at end of file diff --git a/i18n/de/docusaurus-plugin-content-docs/current/tutorials/datadash/bugs.md b/i18n/de/docusaurus-plugin-content-docs/current/tutorials/datadash/bugs.md new file mode 100644 index 0000000..01e11de --- /dev/null +++ b/i18n/de/docusaurus-plugin-content-docs/current/tutorials/datadash/bugs.md @@ -0,0 +1,19 @@ +--- +sidebar_position: 2 +title: Reporting Bugs +--- + +# How to report DataDash Bugs + +The DataDash app codebase is [Publicly available on GitHub](https://github.com/mxc-foundation/supernode-app). Therefore the best way to submit a DataDash bug, is directly as a [GitHub issue](https://github.com/mxc-foundation/supernode-app/issues). + +Please include the following information in your bug report: + +* What is the problem? +* What is the expected behavior? +* Mark the issue with the appropriate labels: + * `bug` + * `ios` or `android` +* Provide any additional information, screenshots, or videos you believe might be helpful. + +**GitHub Issues are public! Do not share any personal or identifiable information. If you believe the issue is specific to you, it should be submitted as a support ticket to [support@mxc.org](mailto:support.mxc.org).** diff --git a/i18n/de/docusaurus-plugin-content-docs/current/tutorials/datadash/intro.md b/i18n/de/docusaurus-plugin-content-docs/current/tutorials/datadash/intro.md new file mode 100644 index 0000000..5df58e1 --- /dev/null +++ b/i18n/de/docusaurus-plugin-content-docs/current/tutorials/datadash/intro.md @@ -0,0 +1,35 @@ +--- +sidebar_position: 1 +title: Intro +--- + +# Introducing the DataDash App + +Our DataDash app has the following core functionality: +* LPWAN Functionality + * M2 Pro Miner + * Register + * Manage Miner Health + * MXProtocol enabled devices (coming soon) + * Register + * View live data frames + * Generate MQTT credentials (for external data management tools) +* Token Management + * MXC M2M Wallet + * DHX Wallet + * BTC Wallet (Withdrawals Only) + + +## Downloading the DataDash App + +You can get the DataDash app at the following locations: + +**Android** +* [Google Play Store](https://play.google.com/store/apps/details?id=com.mxc.smartcity) +* [APK Download](https://datadash.oss-accelerate.aliyuncs.com/app-prod-release.apk) + +**iOS** +* [App Store](https://apps.apple.com/us/app/datadash-app/id1509218470) + +## Participating with DataDash Development +Our DataDash app is [open on GitHub](https://github.com/mxc-foundation/supernode-app) and anyone is welcome to participate in its improvement. To participate, clone the repo, and then tackle a [GitHub issue](https://github.com/mxc-foundation/supernode-app/issues). When you think you've solved it, submit a pull request for our team to review. Before getting started, take a look at the rules [here](https://github.com/mxc-foundation/supernode-app/blob/master/RETHINK.md). \ No newline at end of file diff --git a/i18n/de/docusaurus-plugin-content-docs/current/tutorials/devices/integrations.md b/i18n/de/docusaurus-plugin-content-docs/current/tutorials/devices/integrations.md index 9b2116c..cbeabdb 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/tutorials/devices/integrations.md +++ b/i18n/de/docusaurus-plugin-content-docs/current/tutorials/devices/integrations.md @@ -1,5 +1,5 @@ --- -sidebar_position: 3 +sidebar_position: 3 title: Integrations --- @@ -7,9 +7,7 @@ title: Integrations By default supernode provides MQTT broker service for users to subscribe or pushlish events on their devices. -Users can subscribe to MQTT broker under topics in the servers after authentication. Before that, you need to make sure -you have mosquitto package installed. Use the package manager apt to install these dependencies on the Ubuntu 18.04 LTS -server: +Users can subscribe to MQTT broker under topics in the servers after authentication. Before that, you need to make sure you have mosquitto package installed. Use the package manager apt to install these dependencies on the Ubuntu 18.04 LTS server: ``` sudo apt-add-repository ppa:mosquitto-dev/mosquitto-ppa @@ -161,7 +159,7 @@ Response Call ```shell -curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'Grpc-Metadata-Authorization: Bearer {{ .SUPERNODE_JWT }}' -d '{ "organizationId": "{{ .ORG_ID }}"}' 'https://{{ .SUPERNODE_URL }}/api/mosquitto-auth/login' +curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'Grpc-Metadata-Authorization: Bearer {{ .SUPERNODE_JWT }}' -d '{ "organizationId": "{{ .ORG_ID }}", "ttlInSeconds": "{{ .TIME_TO_LIVE_IN_SECONDS }}"}' 'https://{{ .SUPERNODE_URL }}/api/mosquitto-auth/login' ``` Response @@ -220,5 +218,4 @@ The message format should be as follow: - `confirmed`: whether the payload must be sent as confirmed data down or not - `fPort`: FPort to use (must be > 0) - `data`: base64 encoded data (plaintext, will be encrypted by Network Server) -- `object`: decoded object (when application codec has been configured), when providing the 'object', you can omit ' - data' +- `object`: decoded object (when application codec has been configured), when providing the 'object', you can omit ' data' 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.
0: Low or OFF, 1: High or ON, -1 Unknown or Invalid. | +| 20 (0x14) | percent | 1 | A generic value in percent. | +| 21 (0x15) | powerFactor | 2 or 4 | Power factor for AC power system.
Value range from 0 to 1. | +| 254 (0xfe) | uplinkPower | 1 | Exact value of TX Power in dBm. | + + + +#### GPS data format + +When data length is 1 + +| Offset | Length | Description | +| ------ | ------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 0 | 1 | Indicates whether the node has moved since last GPS fix. Possible values are:
    0: Node is stable since last GPS fix
    1: Node has moved, or has not received a GPS fix since boot; waiting for GPS fix | + +When data length is 11 + +| Offset | Length | Description | +| ------ | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 0 | 1 | $GPGGA Position Fix Indicator. Possible values are:
* 0 Fix not available or invalid
* 1 GPS SPS Mode, fix valid
* 2 Differential GPS, SPS Mode, fix valid
* 6 Dead Reckoning Mode, fix valid | +| 1 | 4 | Latitude in 1/1000 of minutes, as little-endian int32. Positive is north, negative is south. To get the value in degrees, divide by 600000. | +| 5 | 4 | Longitude in 1/1000 of minutes, as little-endian int32. Positive is east, negative is west. To get the value in degrees, divide by 600000. | +| 9 | 2 | Altitude above geoid mean sea level in decimeters (0.1m), as little-endian int16. | + + + +#### Data format for 1 byte value + +It is a signed 8-bits integer (int8_t), giving the range between -128 and +127. + +```javascript +// Decoding +if (offset_0 > 0x7f) { + value = ((offset_0 ^ 0xff) + 1) * -1; +} +else { + value = offset_0; +} +``` + + + +#### Data format for 2 bytes value + +It is a signed 16-bits fixed point number. Offset 0 is the sign bit and integer part. Offset 1 is the fractional part. + +```javascript +// Decoding in Javascript +let raw_value = (offset_0 << 8) | offset_1; +if (raw_value > 0x7fff) { + value = ((raw_value ^ 0xffff) + 1) * -1; +} +else { + value = raw_value; +} +value = value / 256; +``` + + + +#### Data format for 4 bytes value + +It is a 32-bits floating point number (IEEE 754). Offset 0 is the MSB. + +For example, a value of 54.12 will has a 32-bits value of 0x42587ae1. + +The payload will become <0x42><0x58><0x7a><0xe1>. + +```javascript +// Decoding in Javascript +let raw_value = (offset_0 << 24) | (offset_1 << 16) | (offset_2 << 8) | offset_3; +let v_temp = new DataView(new ArrayBuffer(4)) +v_temp.setUint32(0, raw_value) +value = v_temp.getFloat32(0) +``` + + + +The NAN (Not A Number) (0x7fc00000), means the sensor value is unknown or invalid. + + + +### Event Data + +Event data is information about change that occurs at a point in time. A event will contain the type value and additional event data. + +| Number | Name | Length | Description | +| --------- | ------------- | ------ | ------------------------------------------------------------------ | +| 0 (0x00) | unknown | 0 | No data. | +| 11 (0x0b) | opened | 1 | The unit is opened by a user. Data is the user ID. | +| 12 (0x0c) | specialOpened | 0 | The unit is opened in a special way. For example, a key or button. | +| 13 (0x0d) | forceOpened | 0 | The unit is opened in a abnormal way. | + + + +## Downlink Payload Data Format + +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 | Get params | 1 | Get parameter described by first byte. | +| 1 | Set params | >=2 | Set parameter described by first byte to the value specified in the rest of the message. | +| 2 | Reboot | 0 | Reboot the node immediately. | +| 3 | Reboot/upgrade | 1 | Reboot the node after the specified timeout; optionally turn BLE and SUOTA on for upgrades. The argument is as follows:bit [7]:0: just reboot1: BLE onbits [6:3]: Reservedbits [2:0]: Timeout0: TBD1: 5 minutes2: 15 minutes3: 30 minutes4: 1 hour5: 2 hours6: 4 hours7: TBD | +| 4 | Set Controls | \>=1 | Set a value to the control. For example, turn on/off a digital output. | + + + +### Parameters + +| Number | Name | Length | Description | +| ------ | ------- | ------ | ------------------------------------------------------------------------- | +| 0 | deveui | 6 | DevEUI-48 and BLE MAC address (MSBF)
Only for DevKit. Please don't use it at final product. | +| 1 | appeui | 8 | AppEUI-64 (MSBF)
Only for DevKit. Please don't use it at final product. | +| 2 | appkey | 16 | AppKey (write-only)
Only for DevKit. Please don't use it at final product. | +| 3 | period | 1 | Sensor period | +| 4 | sf | 1 | Minimal LoRa Spread Factor (valid values: 7-12) | +| 5 | version | 2 | Version number.
01 00 => V1.0 | + +Parameters 0, 1, 2 and 4 are actualized after reboot. + +Sensor period is as follows: + +| Number | Period | +| ------ | -------- | +| 0 | Default | +| 1 | 10 sec | +| 2 | 30 sec | +| 3 | 1 min | +| 4 | 2 min | +| 5 | 5 min | +| 6 | 10 min | +| 7 | 30 min | +| 8 | 1 hour | +| 9 | 2 hours | +| 10 | 5 hours | +| 11 | 12 hours | + + + +### Controls + +Controls are used for the user to change a value or state of the device. The control data consists of a byte signifying the data type, and zero or more bytes of the data. The defined types and corresponding data formats are: + +| Number | Name | Length | Description | +| --------- | ------- | ------ | ----------------------------------------------------------------- | +| 0 (0x00) | unknown | 0 | No data. | +| 19 (0x13) | digital | 1 | A generic digital value.
0: Low or OFF, 1: High or ON. | +| 20 (0x14) | percent | 1 | A generic value in percent. | diff --git a/i18n/de/docusaurus-plugin-content-docs/current/tutorials/devices/provisioning.mdx b/i18n/de/docusaurus-plugin-content-docs/current/tutorials/devices/provisioning.mdx new file mode 100644 index 0000000..b56498c --- /dev/null +++ b/i18n/de/docusaurus-plugin-content-docs/current/tutorials/devices/provisioning.mdx @@ -0,0 +1,514 @@ +--- +sidebar_position: 4 +sidebar_label: Device Provisioning +--- + +# Device Provisioning + +## What is Device Provisioning? + +Device Provisioning is a process of exchanging sensitive information between a device and a server. This process will store the encryption keys required for LoRaWAN communication on the device and the server. The whole process will be completed through LoRa communication. Therefore, no additional hardware is required on the device. + +In terms of security, Elliptic-curve Diffie-Hellman is used as the key exchange, which enables subsequent sensitive data to be exchanged between the device and the server in a secure manner. + + +## What is the advantage of it? + +With the provisioning is done and the key is ready on both server and device. The operation on the user side will become simple. The user needs only a few steps to register the device to the system. He/She just needs to use our DataDash mobile APP to scan the QR-code label on the device. Then enter a few more information about the device, such as name. After that the device will start to join the network. The user didn’t need to enter any keys that the traditional way needs. During production no keys need to be sent to the assembly house, further improving the security by preventing unwanted compromise of the keys by the 3rd party. + + +## What about the QR-code label? + +The QR-code label stored the identity of the device. There is no sensitive information on it, just an ID code (called Provision ID). A minimal label just needs the Provision ID. The mobile APP will use this Provision ID to register the device to the system. It is a secure way to do the task which no encryption keys content appears during the whole process. + +Here is an example of a minimal label. + + + + + + + +
+ alt_text + PID:PROVISIONIDOOOOOOOOO
+ +For a big device that has more space for the label, a long version label could be used to store more information. + + + + + + +
+ lora provisioning label +
+ +``` +{ + "PROVID": "PROVISIONIDOOOOOOOOO", + "BRAND": "MatchX", + "MODEL": "MX1234", + "SN": "S123456" +} + +``` + + +## What device developer needs to do? + +The firmware needs to implement the flow device provisioning. It is a two steps process and needs to be done for a new produced device. The details of this process is listed on the later part of this document. + +During the device provisioning, it required the Provision ID to identify the device. We suggest the device firmware add an interface to let the manufacturer set this information at the end of the quality assurance (QA) procedure. + +An example method is to use a UART interface to program the information. Our example device uses an “AT” command to achieve this. But any other serial protocol should be fine. + + +![alt_text](/img/provisioning/lora-provisioning-stack.png "image_tooltip") + + +## What device manufacturer needs to do? + +To successfully provision a device, it required the information of Provision ID. The manufacturer needs to request it from us, MatchX. We will prepare a spreadsheet that has the assigned Provision ID and related information for the manufacturer. The Manufacturer needs to make sure the information is set to the device with the correct matched QR-Code label. + +We suggest the manufacturer to add an extra step at their quality assurance (QA) procedure. The step included setting the Provision ID to the device with a matched QR-Code label. Then verify the device is being provisioned, that means it exchanged key information with the server. + + +![alt_text](/img/provisioning/lora-provisioning-steps.png "image_tooltip") + + + + + +## Device Provisioning Implementation Details + +Source code of our example device: TBD + + +### Provision ID + +The Provision ID is a unique string for each device. During the provisioning, it is used as an identity at the provisioning server to access the device information. The Provision ID is 20 characters long and uses the RFC4648 Base32 alphabet. + + +### Hash of Provision ID + +It is the result of the SHA256 hash on the Provision ID. The device provisioning process uses this value when doing authentication with the server. To minimize the complexity of the device implementation, we suggest the device also store this value to its FLASH, instead of calculating it by itself. + + +``` +provisionIdHash = SHA256(provisionId | '.MatchX') +``` + + +For example: + + +``` +PID = 'TESTPIDOOOOOOOOOOOOO' +HASH = 'c8c7564b46b91c91ef6c4f37bcca8cf7e81baac6eb869dcc62e5fafdd0242497' +``` + + + +### Message integrity code (MIC) + +The message integrity code (MIC) value at LoRa PHYPayload for HELLO and AUTH messages is calculated as below. + + +``` +FixedKey[] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, +0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f}; + +cmac = aes128_cmac(FixedKey, message) +MIC = cmac[0..3] +``` + + +### Verification Code + +The verification code is used when the device authenticates with the server. The calculation is shown below. + + +``` + FixedKey[] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, + 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f}; + + cal_buf = provisionId + nonce; + verifyCode = aes128_cmac(FixedKey, cal_buf) +``` + +Example: + + +``` +// Input + privisionid = "SERIALNUMBEROOOOOOOO"; + servernonce = {0x01, 0x02, 0x03, 0x04}; + +// Output + verifyCode = {0x2E, 0x69, 0xBB, 0x5E, 0xD7, 0x8B, 0x5E, 0xE8, + 0x0C, 0x6A, 0x8A, 0xDC, 0x81, 0x91, 0xDD, 0xF8}; +``` + + + +### AES + +The encryption scheme used in aes128_encrypt() and aes128_cmac() are the same as LoRaWAN specification. This approach will minimize the need for extra code on the device side. + + +### LoRa + +The device provisioning using the “Proprietary” LoRa frame for communication, it means the MType on MHDR is set to ‘111’. + +The receiving windows using RX1 and delay is 5s. + +Data Rate: + + + + + + + + + + + + + + + + + + + + + + + +
Region + Data Rate + Configuration +
EU868 + 3 + Up and Down: SF9 / 125 kHz +
US915 + 3 + Up: SF7 / 125 kHz +

+ Down: SF7 / 500 kHz +

+
CN470 + 3 + Up and Down: SF9 / 125 kHz +
+ +### Sequence Diagram + +The device provisioning has two steps. First, it is a ECDH key exchange process, called “Hello” by us. The device and the server will exchange their public key on this step. Then the next step is the authentication. The device will submit its hashed Provision ID to the server. If it is a valid ID on the server, the server will accept the request and send back the EUI information. + +The keys used for LoRaWAN OTAA are derived from the ECDH shared key. All this information will not appear on the communication message. + +![alt_text](/img/provisioning/lora-device-provisioning-sequence.png "image_tooltip") + + +### Message format + +The messages shown below are the content of the MACPayload of the Proprietary MAC message of LoRaWAN. + +LoRaWAN PHYPayload: + + + + + + + + +
MHDR + MACPayload +

+ (Hello / Auth) +

+ 		MIC +
+ +##### Hello message + + +``` + | Type | rDevEUI | devPubKey | version | + | 0x01 | 8 bytes | 64 bytes | 1 byte | +``` + + + +##### Hello response + + +``` + | Type | rDevEUI | serverPubKey | serverNonce | + | 0x81 | 8 bytes | 64 bytes | 4 bytes | +``` + + + +##### Auth request + + +``` + | Type | rDevEUI | Encrypted Payload | + | 0x11 | 8 bytes | 52 bytes | + + | provisionIdHash | verifyCode | devNonce | + | 32 bytes | 16 bytes | 4 bytes | +``` + + + +##### Auth accepted + + +``` + | Type | rDevEUI | Encrypted Payload | + | 0x91 | 8 bytes | 32 bytes | + ​ + | devEUI | appEUI | verifyCode | + | 8 bytes | 8 bytes | 16 bytes | +``` + + + +##### Auth rejected + + +``` + | Type | rDevEUI | + | 0x92 | 8 bytes | +``` + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
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. + + + + + +![alt_text](/img/provisioning/lora-provisioning-spreadsheet-view.png "image_tooltip") + + +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. + + +![alt_text](/img/provisioning/device-provisioning-report.png "image_tooltip") + + +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 +``` + + + + + + +![alt_text](/img/provisioning/lora-provisioning-spreadsheet-view-1.png "image_tooltip") + diff --git a/i18n/de/docusaurus-plugin-content-docs/current/tutorials/dhx/_category_.json b/i18n/de/docusaurus-plugin-content-docs/current/tutorials/dhx/_category_.json new file mode 100644 index 0000000..6f5f53d --- /dev/null +++ b/i18n/de/docusaurus-plugin-content-docs/current/tutorials/dhx/_category_.json @@ -0,0 +1,4 @@ +{ + "label": "Mining DHX", + "position": 4 +} diff --git a/i18n/de/docusaurus-plugin-content-docs/current/tutorials/dhx/intro.md b/i18n/de/docusaurus-plugin-content-docs/current/tutorials/dhx/intro.md new file mode 100644 index 0000000..18d2c90 --- /dev/null +++ b/i18n/de/docusaurus-plugin-content-docs/current/tutorials/dhx/intro.md @@ -0,0 +1 @@ +# What is DHX \ No newline at end of file diff --git a/i18n/de/docusaurus-plugin-content-docs/current/tutorials/intro.md b/i18n/de/docusaurus-plugin-content-docs/current/tutorials/intro.md index b92ff53..5e1be6f 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/tutorials/intro.md +++ b/i18n/de/docusaurus-plugin-content-docs/current/tutorials/intro.md @@ -8,16 +8,32 @@ sidebar_position: 1 There are a number of ways for developers to interact with the MXC ecosystem. These forms of participation are integral to the further development and deployment of the MXProtocol. ## Direct Participation + +### Beta Testing +Beta testing new features before they are released is a great way to help us improve the overall user experience with our products. Here are beta opportunities currently available: + +| Product | Beta Type | How to Participate | +| --------------- | --------- | ------------------------------------------ | +| DataDash | Closed | [Instructions](tutorials/datadash/beta.md) | +| MXC Controller | Closed | *Coming Soon* | +| M2 Pro (MatchX) | Open | *Coming Soon* | + +*A beta version is pre-release and considered unstable. This means that you may experience some issues. Normally these will be minimal, however participating in an M2 Pro beta could potentially affect your mining. MXC Controller and DataDash betas will not have any influence on your overall mining potential.* + + +### Coding and Translating We have a number of public repos with active issues that could use assistance. Our team is still growing, and community support is always appreciated, encouraged and in some cases rewarded. -Here is an updated list of repos that could use assistance. +Here is an updated list of repos that could use assistance. * [DataDash App](https://github.com/mxc-foundation/supernode-app) [Flutter / Dart] + * [Translate the DataDash](https://crowdin.com/project/mxc-mobile-app) * [Developer Documentation](https://github.com/mxc-foundation/developer-documentation) [Markdown, Javascript] + * [Translate the Docs Today](https://crowdin.com/project/mxc-documentation) -We will continue to add repositories to this list as we work to increase transparency with our code and development process. +We will continue to add repositories to this list as we work to increase transparency with our code and development process. ## Manufacturing / Configuring Devices -Without devices the network has no purpose. Therefore, we've created an easy way for manufacturers to get involved with the network, making it possible for their devices to be deployed as a turnkey solution in the MXC ecosystem. +Without devices the network has no purpose. Therefore, we've created an easy way for manufacturers to get involved with the network, making it possible for their devices to be deployed as a turnkey solution in the MXC ecosystem. In order to increase security of the entire network, we've worked with MatchX to develop a novel provisioning concept for LoRa devices. This provisioning process is a requirement for any devices intending to be MXProtocol compatible. We have made this decision as: 1. Device provisioning increases the security of the device data @@ -27,7 +43,7 @@ In order to increase security of the entire network, we've worked with MatchX to You can discover more about device provisioning for the MXProtocol in Devices. ## Reporting Issues -Even though we attempt to do rigorous QA before every release, some pesky bugs still slip through. Actively reporting bugs is an extremely important form of participation, and helps us to improve the stability of the entire network. +Even though we attempt to do rigorous QA before every release, some pesky bugs still slip through. Actively reporting bugs is an extremely important form of participation, and helps us to improve the stability of the entire network. You can report bugs in the #bugs channel in our [Discord Server](https://mxc.news/discord) diff --git a/i18n/de/docusaurus-plugin-content-docs/current/tutorials/m2-pro/intro.md b/i18n/de/docusaurus-plugin-content-docs/current/tutorials/m2-pro/intro.md index 743d33c..aa259e4 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/tutorials/m2-pro/intro.md +++ b/i18n/de/docusaurus-plugin-content-docs/current/tutorials/m2-pro/intro.md @@ -2,4 +2,5 @@ title: Introduction sidebar_position: 1 --- + # The M2 Pro Miner \ No newline at end of file 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. diff --git a/i18n/de/docusaurus-plugin-content-docs/current/tutorials/m2-pro/troubleshooting.md b/i18n/de/docusaurus-plugin-content-docs/current/tutorials/m2-pro/troubleshooting.md index 569c821..a397b99 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/tutorials/m2-pro/troubleshooting.md +++ b/i18n/de/docusaurus-plugin-content-docs/current/tutorials/m2-pro/troubleshooting.md @@ -2,4 +2,66 @@ sidebar_position: 5 --- -# Troubleshooting \ No newline at end of file +# Troubleshooting +Experiencing a problem with your M2 Pro? This tutorial will help you find it. Naturally you can also ask for help in one of our communities, or reach out for manufacturer support by writing [support@matchx.io](mailto:support@matchx.io). + +## Connectivity (uptime) +If your uptime is taking a hit, there's an easy way to find out if the miner is at fault, or your local network connection. To do that follow the following steps: +### 1. Access the M2 Pro Miner web interface +You can find the interface here: `http://yourSerialNumber.local` + * Your computer or phone must be on the same network as the M2 Pro Miner + * This URL works only on iOS, Win10 and Linux. It doesn't work on Android. +``` +Username: admin +Password: your serial number using all caps +``` + + + +### 2. View the miner logs: +1. After logging in, you can view or download your logs by clicking on `SysLog` in the menu ![log file structure](/img/troubleshooting/sysLog.png) + * If you're having an ongoing issue, you may want to download your logs regularly. The miner can only store logs for the past 48 hours, so if additional troubleshooting is needed, you should download your logs once every two days. +### 3. Reading the logs + +First step is to check if offline is happening due to failed heartbeat. Use the search/find function (ctl+f, cmd+f) and type in the word failure to see any failed heartbeat. + +This is the example of a successful heartbeat session. + ``` + Jun 29 04:58:09 M2XLCTRM3ZW daemon.info gwconfd[619]: Received hb response: fw conf + ``` +Here is an example of a failed heartbeat session. + +``` +Jun 29 04:56:07 M2XLCTRM3ZW daemon.err gwconfd[619]: Heartbeat api failure:4: Deadline Exceeded +``` +A failed heartbeat can happen due to many reason but the most common reason is an unstable network connection. To rule this out, you need to check if the internet connection is good. + +These are the list of common errors which indicates unstable, loss or bad internet connection. +1. Connectivity error from network issue +``` +Jun 24 06:49:53 M2XLCTRM3ZW daemon.err tlsDaemon[606]: Setup TLS error: TCP Connection error. +``` + +2. Unstable/dropping WiFi connection +``` +Jun 17 07:25:29 M2XLCTRM3ZW user.info kernel: CFG80211-ERROR) wl_is_linkdown : Link down Reason : WLC_E_LINK +``` +3. Internet connection loss +``` +Jun 13 15:05:50 M2XLCTRM3ZW daemon.info netMgmtDaemon[614]: Internet connection loss +``` + +In most cases, the issue is related to unstable internet connection at user's end and the miner is working fine (not a hardware issue). + +To isolate this further, you can try the following: +* If the miner is connected using wireless connection – try using wired connection. +* If wired connection is not possible – move the miner closer to the router as see if the uptime improves +* If both still not solving the issue - try putting the miner on a different network (such as, at friend's home). If the miner is working fine on another network, the issue is related to your home network connection. + +### 4. Checking LoRa Connectivity [in the LoRa Log menu option] +For LoRa, when you see that a miner is offline you can check on the Last Seen. This is pretty straight forward as you just need to search these two lines. If you get PUSH_ACK, that means it is fine. +``` +[2021-06-17 08:58:48.437] [loraMgmtDaemon] [info] INFO: [up] PUSH_ACK received in 43 ms +``` +This message is sent every 30 seconds. + diff --git a/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/images/fig1_lpwan_comparison.png b/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/images/fig1_lpwan_comparison.png new file mode 100644 index 0000000..b481449 Binary files /dev/null and b/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/images/fig1_lpwan_comparison.png differ diff --git a/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/images/fig2_dataflow.png b/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/images/fig2_dataflow.png new file mode 100644 index 0000000..e223f70 Binary files /dev/null and b/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/images/fig2_dataflow.png differ diff --git a/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/images/fig3_MXProtocol_stack.png b/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/images/fig3_MXProtocol_stack.png new file mode 100644 index 0000000..e0e3584 Binary files /dev/null and b/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/images/fig3_MXProtocol_stack.png differ diff --git a/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/images/fig4_mxp_smart_bidding.png b/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/images/fig4_mxp_smart_bidding.png new file mode 100644 index 0000000..067516d Binary files /dev/null and b/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/images/fig4_mxp_smart_bidding.png differ diff --git a/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/images/fig5_anti_collision_coordinator.png b/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/images/fig5_anti_collision_coordinator.png new file mode 100644 index 0000000..2249468 Binary files /dev/null and b/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/images/fig5_anti_collision_coordinator.png differ diff --git a/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/images/fig6_anti_collision_integration.png b/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/images/fig6_anti_collision_integration.png new file mode 100644 index 0000000..0523fca Binary files /dev/null and b/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/images/fig6_anti_collision_integration.png differ diff --git a/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/images/fig7_inter_chain_market.png b/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/images/fig7_inter_chain_market.png new file mode 100644 index 0000000..a062843 Binary files /dev/null and b/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/images/fig7_inter_chain_market.png differ diff --git a/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/images/fig8_LPWAN.png b/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/images/fig8_LPWAN.png new file mode 100644 index 0000000..48e0618 Binary files /dev/null and b/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/images/fig8_LPWAN.png differ diff --git a/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/intro.md b/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/intro.md index 61c574b..adeb6a8 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/intro.md +++ b/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/intro.md @@ -2,6 +2,7 @@ title: Introduction sidebar_position: 1 --- + # MXC Whitepapers Overview of the WhitePapers \ No newline at end of file diff --git a/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/mxprotocol.md b/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/mxprotocol.md index 6768da7..b9c416b 100644 --- a/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/mxprotocol.md +++ b/i18n/de/docusaurus-plugin-content-docs/current/whitepapers/mxprotocol.md @@ -3,4 +3,511 @@ title: MXProtocol sidebar_position: 2 --- -# MXProtocol \ No newline at end of file +# MXProtocol (Machine eXchange Protocol): Premium Network Infrastructure, Infinite Data Stream + +## Table of Contents + +- [Machine eXchange Protocol: Premium Network Infrastructure, Infinite Data Stream](#machine-exchange-protocol-premium-network-infrastructure-infinite-data-stream) + - [1. MXC Vision](#1-mxc-vision) + - [2. Background](#2-background) + - [2.1 LPWAN vs other technologies](#21-lpwan-vs-other-technologies) + - [2.1.1 LoRaWAN](#211-lorawan) + - [2.1.2 NB-IoT](#212-nb-iot) + - [2.1.3 Deployment considerations](#213-deployment-considerations) + - [MXC economy](#mxc-economy) + - [3.1 Commerce network effect](#31-commerce-network-effect) + - [3.2 Asset-Backed Securitization](#32-asset-backed-securitization) + - [3.3 Data bloom](#33-data-bloom) + - [3.3.1 MXC-assisted garbage collection](#331-mxc-assisted-garbage-collection) + - [3.3.2 MXC-assisted car sharing](#332-mxc-assisted-car-sharing) + - [4. MXProtocol stack](#4-mxprotocol-stack) + - [4.1 Permissionless Blockchain](#41-permissionless-blockchain) + - [4.1.1 Features](#411-features) + - [4.1.2 Security and efficiency](#412-security-and-efficiency) + - [4.1.3 Long-term adoptions](#413-long-term-adoptions) + - [5. Smart Bidding](#5-smart-bidding) + - [5.1 Goals of design](#51-goals-of-design) + - [5.2 Design and implementation](#52-design-and-implementation) + - [5.3 Gateway status](#53-gateway-status) + - [5.4 Smart Bidding strategy](#54-smart-bidding-strategy) + - [5.5 Sensor Smart Bidding code](#55-sensor-smart-bidding-code) + - [6. Anti-Collision Coordinator](#6-anti-collision-coordinator) + - [6.1 Goals of the design](#61-goals-of-the-design) + - [6.2 Design and implementation](#62-design-and-implementation) + - [6.3 Third party integration](#63-third-party-integration) + - [7. Inter-Chain Data Market](#7-inter-chain-data-market) + - [7.1 Goals of the design](#71-goals-of-the-design) + - [7.2 Design and implementation](#72-design-and-implementation) + - [7.3 Polkadot and Aeternity](#73-polkadot-and-aeternity) + - [8. Smart Bidding use cases](#8-smart-bidding-use-cases) + - [8.1 Downlink resource auction](#81-downlink-resource-auction) + - [8.2 Network coverage market](#82-network-coverage-market) + - [8.3 Service market](#83-service-market) + - [9. Development progress](#9-development-progress) + - [10. References](#10-references) + +## 1. MXC Vision + +> The MXC vision is to introduce a systematic process to both simplify and increase IoT data transactions. + +The decentralized infrastructure upon which MXC’s system is based is the future of Low Power Wide Access Network (LPWAN) and the Machine eXchange Protocol (MXProtocol). Utilizing this solid device network foundation, MXC is introducing an extraordinarily unique coin offering, Machine eXchange Coin (MXC), which allows for increased data transactions and an idiosyncratic data flow monetization within the mammoth data market. + +MXProtocol places a keen focus on reducing collision between networks, constructing an inter-chain data market, developing a market for network coverage and introducing an independent Quality of Services (QoS) framework for both data providers and receivers. For the first time ever, individual network users, corporations and enterprises can all participate in the construction of decentralized, ubiquitous and secure LPWAN. Simply by connecting “anything” to the network, adopters will be able to profit and trade MXC. + +The trading network is built on the premise of the “sharing economy.” Therefore, it is uniquely and exclusively owned by users — both individuals and enterprises — who take advantage of the monetization of the network in two ways: + +1. By increasing uplink and downlink coverage via a Gateway, e.g. a MatchBox LPWAN Gateway, Cisco LPWAN Gateway +2. By unleashing access to a massive network of published and traded data to the marketplace which is securely traded using blockchain technology + +Both sensors and connected devices bid (via the integrated QoS) for the downlink network resource to, for example, unlock a door or, alternatively, shut down a faulty radiator, subsequently offering a market-devised price for the uncovered regions. This ultimately increases data network coverage. “Things” can autonomously pay each other with MXC tokens and get accredited by sharing the data with different users/marketplaces. + +There has been a phenomenal increase in the sourcing, collection and transmission of big data within the past five years. Additionally, the increasing use of artificial intelligence feeding off this data has assisted people to simplify tedious tasks and to make better informed decisions on everything from projecting a weather forecast, to saving household energy, to even choosing the right music to play at home. The tone has now been set for decades to come. Machines interacting with one another has seen a significant increase over such a short period. This will only increase as our interdependency on machines and machine learning grows and becomes ever more significant in day to day life. + +Whether for individuals or big companies, the need for a specified network concentrating on machines and machine data is here to stay. It will play a bigger part in supporting both individuals and businesses than ever before. MXProtocol introduces the next generation of LPWAN with a superior IoT data platform and a premium network experience, allowing for a simplified and expedited way to create a secure and efficient solution for IoT. + +The following sections elaborate on the unique advantages of MXProtocol, including its components — permissionless blockchain, Smart Bidding, Anti-Collision Coordinator and Inter-Chain Data Market — that make it a truly innovative technology. + +## 2. Background + +MXC is a German non-profit organization based in the country’s start-up and blockchain capital, Berlin. MXC is partnering with various LPWAN companies. MXProtocol is a revolutionary design that solves the problem of LPWAN and bridges the data gap between different infrastructures. + +IoT is a hot topic that has been intently discussed for over a decade. The one focus and premise of the IoT network is connecting “things” to the Internet and collecting/using this data from the objects that can’t speak for themselves. The application of this new founded, increased data is highly limited due to the current methods offering low range and high power consumption. For example, standard WiFi can generally reach an absolute maximum of around 100 meters, and using 3G/4G consumes a significant amount of power, thus reducing effective battery life and increasing maintenance costs significantly. The fact is, current implementations for data networks are extremely expensive and offer very low usability. The need for a new technology is here and the need for LPWAN will only increase as it solves the current problems of low range/high cost data transmissions. + +The fact is, current implementations for data networks are extremely expensive and offer very low usability. The need for a new technology is here and the need for LPWAN will only increase as it solves the current problems of low range/high cost data transmissions. + + + +
+ LPWAN +
+ +### 2.1 LPWAN vs other technologies + +LPWAN technology emerged to the forefront in recent years with the goal of finding a better data transmission solution to the shortfalls of WiFi, Bluetooth and 3G & 4G networks. These earlier established networks were originally targeted at connecting people, not at connecting the data generated by “things.” The amount of machine-generated data has multiplied significantly in recent times. The new LPWAN technology offers aspects where others simply can’t compete: + +- 10 year sensor battery life +- 20 km data reach with just a single Gateway +- Offers an extreme amount of connection points (over 60,000 for a single network cell) supported by LPWAN Gateways at an extremely low cost + +Now, when compared to the current wireless network, it’s easy to see the superior advancements that the MXC solutions offer. As illustrated in Figure 1, LoRa and NB-IoT are simply the most potent solutions on the LPWAN market. + +#### 2.1.1 LoRaWAN + +LoRaWAN is an open-source protocol defined by the LoRa Alliance, which is already supported by industrial giants such as Cisco, Alibaba, Comcast, IBM and SK Telecom and many more. Advantages of LoRaWAN are 20 km open space coverage, low data rates (low-level kbps) and ultra-low power, allowing for 10 years continued operation on a single battery. + +Both the Gateways and end sensor devices use the LoRaWAN protocol. In fact, devices of any brand are supported and can be connected to the network as long as they are LoRa/LPWAN compatible. + +#### 2.1.2 NB-IoT + +NB-IoT is a narrowband radio technology specified by 3GPP as a licensed telecommuni- cation protocol. NB-IoT focuses specifically on indoor coverage, low throughput and long battery life, enabling a large number of connected devices. + +The advantage for an MXC IoT user is that it gives an individual the power to host their own network wherever and whenever they like. Compare that with the NB-IoT base stations (which are owned by telecommunications conglomerates) which charge users expensive SIM card fees to send data messages over the Internet through NB-IoT protocol. MXProtocol supports all LPWAN technologies, developed LoRaWAN Gateways, NB-IoT and LoRaWAN sensors. That’s decentralization. That’s yet another MXC advantage. + +#### 2.1.3 Deployment considerations + +When deploying LPWAN, the first consideration is understanding how to avoid a col- lision between different competing networks residing in the same region. Generally, the issue comes from the fact that both may use the same channel to send out the message at the same time and leave the other available channel empty due to the chosen preferences. As a result, it’s generally hard to reach a consensus between these networks and thus the deployment suffers as network usage increases. The decentralization and distributed mech- anism of MXProtocol solves this issue by coordinating the networks. The network evolves by having users pay micro-payments for the resources that another one offers. + +The second concern is due to the shortage of downlink resources for the dense sensor/ end device deployment. Usually there are some sensors/end devices which require no downlink or can bear with the loss of downlinks. This is usually associated with low-activity sensors, such as garbage bins or electricity meters. However, end devices like bike locks or location tracker devices need to receive regular and reliable confirmations from the cloud for every uplink. Hence, they are willing to pay a premium for this reliability and a QoS provided by the networks. MXProtocol provides this bidding resource, ensuring that, for example, a garbage bin sensor won’t take first preference over the vital downlink resource of something like a bike lock. + +Another consideration pertains to the requirements for multi-national cooperations (MNC) and small to medium enterprises (SME) trading their data assets publicly generated using LPWAN technology. Within LPWAN, both the data stream and asset trading features are simplified, easy to read and can be digitally transmitted from many kilometers away. This makes the data exchange a clear necessity for the needs of the LPWAN market of tomorrow. + +With respect to the needs of MNCs or SMEs, it’s likely that such enterprises will wish to deploy their own LPWAN to cover an entire city or a region for its own specific applica- tions such as asset tracking (e.g. automobile) or sensor data management. This is a perfect solution for “Big Business.” LPWAN technology delivers via its long reach ensuring that sensor/end device uplink packets are securely received as per the protocol design. + +This leads to one of the key aspects of the MXProtocol: bringing the monetization of data services to the forefront. Using the MXProtocol, micro-payments within the LPWAN infrastructure will be traded from third party sensors/end devices, ensuring data is conveniently, correctly and concisely transmitted in a secure manner, whilst being maintained by the support of system administrators. The industry has been waiting for a decentralized and consensus-based mechanism to improve the usability of LPWAN, and MXC is delivering. + +MXC has designed this next generation LPWAN infrastructure using MXProtocol in order to significantly boost the applications of blockchain and IoT within the real-world context. + +## MXC economy + +Machine eXchange Coin (MXC) offers a unique and specifically designed decentralized technological “Data Trade Network” to the global Token economy. Data can be shared on a mass scale whilst ensuring complete end to end privacy. The MXC intends to be distributed amongst data owners, data receivers and data network hosts, allowing for a facilitated cross-over from a “commodity” based Coin into an everyday trading Coin currency. + +### 3.1 Commerce network effect + +Machine eXchange Coin is the first Token designed to bridge current commodity-based trading of cryptocurrency tokens and the cash-based global economy. Utilizing the “sharing economy,” MXC uses this as an axis, allowing large businesses, SMEs and individuals to borrow or rent assets owned by someone else. + +Individuals place LoRa-based protocol hardware in opportune positions in order to benefit and profit from their locations and their decentralized LoRaWAN network. Businesses benefit by using these user-based networks to send sensor/device data, building a new “sharing economy.” Wallets are stored in the cloud allowing individuals to profit from businesses sending sensor data via their LoRaWAN LPWAN. The coins are then sent and traded from the sensor holders that MXProtocol addresses to the Gateway distributor. + +MXProtocol gives network participants incentives to use, deploy and trade their network elements. In addition to that, it is a people-owned secure and private network that won’t suffer from public congestion like what Ethereum encountered with cryptokitties. + +### 3.2 Asset-Backed Securitization + +MXC has been highly successful with regards to the design and production of high-end LPWAN hardware. Using the coins and sharing economy will allow for a massive influx of shared sensor data amongst individuals and companies, giving better insights into consumer behavior, environmental impacts and machine-based optimizations. + +With MXC, Asset-Backed Securitization (ABS) adds a completely new way for individuals and companies to both trade and manage their data and physical assets. Current methods see sensitive data easily being passed and reproduced to a number of parties without any of them knowing that the data has potentially already been corrupted, seen and/or shared amongst potential competitors/untrusted parties. MXC makes it possible for corporations and individuals to track both physical goods and intangible data, ensuring that buyers/ receivers of the goods are the only party who have received the data/physical good, and for this information to come from a qualified and reliable source. + +By applying ABS, the individual data is allocated to one dedicated source. In contrast, a buyer of a tangible paper certificate, for example, has no way of knowing that the same certificate hasn’t been sold/reproduced and assigned to potentially multiple parties. + +### 3.3 Data bloom + +MXC is a blockchain-based decentralized platform designed to revolutionize three core functions based around the basic financial theory: Lend, Send and Spend. + +#### 3.3.1 MXC-assisted garbage collection + +The future is here. The one constant in everyone’s life from now on will be the data surrounding all of us. In the past such a statement referred to “people-generated data.” However, times have changed. “Machine-generated data” is taking over at a phenomenal rate. + +The beauty of machine-based data, when compared with human-based data, is it doesn’t sleep. Machine-based data is constant and it’s reliability is unmatched when compared with any people-generated data. So why is this important? + +Take, for example, a local city council. Their task is to ensure safety, security and general well-being of the local city. One of these responsibilities includes simple tasks such as garbage collection. The simple act of emptying city trash may seem like a monotonous task, but it in fact requires planning and chain management: When do collections occur? How often should trash collections occur? How many employees are required to empty garbage cans across the city? MXC simplifies such tasks using MXProtocol. + +Using sensor/end devices situated in garbage cans and allowing them to transmit device data via a Gateway allows the city council to detect the levels of garbage built up within the can. What does this mean for the council? + +- Saving fuel: The council only needs to send out garbage trucks when necessary, as opposed to sending out trucks to check cans, irrespective of whether they are full or even completely empty. +- Saving wages: By only sending out employees at the moment a garbage can needs to be emptied, the council can then reallocate human resources, thus saving employee wages. +- Reducing traffic congestion: Garbage trucks are often frustrating for commuters. When parked on the side of the road, they can increase general traffic significantly. Being aware of the need for garbage removal in certain areas can reduce the need for trucks and allow for smoother traffic flows. + +Many of these highlighted aspects make up the chain of events associated with what are deemed to be “menial tasks” but, as shown, the flow on effect is quite significant. MXC IoT is ready to solve such issues, allowing for simple tasks to be categorized and ensuring exact resources are allocated only when needed. + +#### 3.3.1 MXC-assisted car sharing + +Using LoRaWAN sensor/end devices and Gateways can also reduce the cost of car sharing partners. + +Covering an entire city center in LPWAN allows individuals to simply build their own completely independent network, free from telecommunications companies and net- works charging exorbitant costs. + +The benefits of doing this for a company such as a “car sharing” company allows them to track their vehicles without the need to depend on Telecommunication coverage. Using LPWAN significantly reduces the costs, especially when compared with the costs of tracking using a SIM card. + +In addition to GPS tracking, car doors can be locked and unlocked using LPWAN, increasing security for users, all at a very low cost compared to current methods. + +By bringing such key services, MXC provides transparency and greatly enhances customer experience. MXC’s mission is to intensify data sharing whilst forging a unity between those with finance and data service needs and those without finance but who have private access to network integration and distribution, thus eliminating borders, intermediaries and prejudices. + +MXProtocol focuses on three foundational pillars: + +- Extend and support the massive device data economy +- Utilize the decentralized “sharing economy” +- Trade of assets within the current coin economy + +MXProtocol connects “things” utilizing a market-based economy, which adds a plethora of new transmission points allowing more data to be shared, traded, sold and analyzed for data mining. + +Within the new decentralized MXC economy, everyone can profit from the sharing of data; end to end encryption grants authorized usage of the data; and entire communities can benefit from using their locations to act as a network facility to transport this data — trading assets, profiting from the coin economy. + +## 4. MXProtocol stack + +MXProtocol infrastructure consists of both sensor and end devices, Gateway and cloud. Sensors and end devices collect data from “things,” and send to the cloud via the Gateway. This is uniquely designed to specifically be a decentralized solution allowing for everyone to suit their/the market’s needs. The usability of the hardware has been specifically designed as a “plug and play” solution, making installation simple without the need for a professional configuration. It is designed to be easy to set up and easy to share data. + +As the flow in [Figure 2](#fig2) demonstrates, LPWAN Gateways connect to each other to form either a mesh network as a collective cloud or the Internet. The sensors or end devices communicate with Gateways using LPWAN technology for bi-directional communication. Notably, the sensors and end devices are not purely limited to a single LPWAN product. In fact, any LoRaWAN compatible sensors are able to connect to the LPWAN network and can start sending and receiving messages. + + +
+ dataflow +
+ +MXProtocol facilitates the data and value flow of the LPWAN. Inside this ecosystem, each sensor or end device has a MXC wallet address assigned to an individual user. This is required in order to both pay for the network usage and to receive money from selling the data and services. The sensor wallet is stored in the cloud in order to maintain the LPWAN low-power requirements. This is also due to the fact that the CPU is usually resource-constrained. The same wallet is used as the Gateway wallet (also found in a user account and stored in the cloud). This wallet will receive coins from uploading/downloading the data from the cloud to the sensor and assists in paying for the other LPWAN’s resource or data. + +Coinciding with the current LPWAN infrastructure protocol, the data link between the Gateway and sensor end devices is unregulated. As a result, there would be no possibility to be rewarded for forwarding data from the sensor to cloud via the Gateway, and ultimately the downlink resource would be limited, only being allocated on a “first come, first served” basis. This system as is would negatively impact low-level data procurement services offered by things such as a door lock or car charging station system and would result in the data link not being appropriately monetized. MXC LPWAN infrastructure solves such issues, delivering the ultimate user experience to SMEs and MNCs. + + +
+ dataflow-mxprotocol +
+ +[Figure 3](#fig3) shows the detailed technical stack of the MXProtocol infrastructure. The decentralized and autonomous LPWAN can be built on any permissionless blockchain, such as IOTA, Stellar, Skywire and NEO. + +Based on this, the Anti-Collision Coordinator between LPWANs, Smart Bidding and Inter-chain data market are introduced to answer the LPWAN deployment considerations mentioned in the previous chapter [see 2.1.3](#213-deployment-considerations). + +### 4.1 Permissionless Blockchain + +There are various kinds of blockchain. Anyone can use cryptographic keys, anyone can be a node and join the network, and anyone can become a participant to service the network and seek a reward. Participants can walk away from being a node, return if and when they feel like it and get a full account of all network activity since they left. + +In a permissionless blockchain, anyone can read the chain, anyone can make legitimate changes and anyone can write a new block into the chain as long as they follow the rules. Decisions on a permissionless blockchain are made by the network participants. The protocol is based on a consensus protocol. The permissionless blockchain provides a way to reach consensus without relying on a closed system to accurately record financial transactions. + +#### 4.1.1 Features + +MXC built MXProtocol as an inclusive platform where all participants are encouraged to contribute. MXProtocol is a distributed network protocol backed by monetization of the resources and incentives from enterprises and individuals based on permissionless blockchain. The permissionless blockchain design makes MXProtocol efficient and independent: the more people use it, the more robust the network will be. + +The blockchain should have four key properties: decentralized control, low latency, flexible trust, and asymptotic security. In other words, MXProtocol should run on a permissionless blockchain that has: + +- A true decentralized network. +- It has eliminated mining rewards. +- All transactions get confirmed quickly. +- There is an anti-spam role. There should be a preventive measure against nefarious users flooding the network (a DoS attack). + +#### 4.1.2 Security and efficiency + +Often, the speed and privacy of a network is the concern for SMEs and MNCs. Public blockchains, such as Ethereum and Bitcoin, often suffer from big computing slow downs, practically grinding the systems to a halt, leading to a situation where the whole network and the 51 percent resources can attack the blocks. There should be a blockchain providing more privacy and efficiency for businesses and individuals collectively. MXProtocol needs to be run on a secure and efficient blockchain that can provide the devices with good connectivity. + +The MXC-introduced LPWAN application requires further fragmented and discrete transactions for sensitive data and services in an IoT realm. That is why MXC continues to develop upon the permissionless blockchain, making MXProtocol more efficient and more suitable for the needs of LPWAN and IoT applications. + +#### 4.1.3 Long-term adoptions + +As previously stated, MXProtocol is a LPWAN platform protocol that brings efficiency and robustness to the users. There are, however, still several components inside permissionless blockchain itself that MXC feels necessary to emphasize. For example, to ensure the long term stability of the LPWAN IoT projects, continued research is still required with regards to the current data interface. Real field deployment will need to be conducted in order to properly satisfy the plethora of data streams connecting from the LPWAN sensors/end devices and ensure they are routed to the network seamlessly. + +## 5. Smart Bidding + +Due to governmental regulations of the LPWAN spectrum, the downlink is a precious resource that is closely guarded by sensors and end devices. The majority of the world uses eight downlink channels for acknowledgement or confirmation of the sensor data, and each channel usually has to wait anywhere from a few milliseconds up to a few minutes in order to send another packet. + +The downlink channels are fixed in the protocol and code, and the waiting time for each downlink is dependent on the data rate of the sensor/end device. A key side note to this point is that LPWAN Gateways use the latest in “Listen Before Talk” technology allowing them to send data more regularly. This means that data may be sent when the channel is free, and therefore doesn’t have to wait for a specific time period to elapse. + +### 5.1 Goals of design + +To further overcome such industry-wide issues, MXProtocol implements a bidding mechanism, designed to bring the needed resources to those devices that are willing to bid the most. Generally public LPWAN deployment is pushed by both individuals and corporations who do so in order to extend their own individual network reach. Introducing a bidding mechanism will cause network reaches to multiply due to the fact that users can both earn and learn from the data that are sent by the sensors. The purpose of this section is to examine the Smart Bidding design that would support a well-functioning LPWAN ecosystem. The goals of the design are to: + +- Allocate downlink resources adequately +- Allow all sensors/end devices to compete on a market platform for network resources +- Offer network deployments incentives, assisting them to monetize +- Ensure LPWAN services are monetized +- Power the decentralized ledger with MXProtocol to simplify and resolve any issues + +### 5.2 Design and implementation + +There are different bidding models, ranges and methods to be set in Smart Bidding. The goal is to assign the network resource to the highest bidder. The design and functionality of the Smart Bidding process is proposed in [Figure 4](#fig4). Sensors/end devices bid on one single downlink channel out of the eight available on the LPWAN Gateway. The Smart Bidding code sensors/end devices are hosted on the cloud code, enabling them to place a bid. The LPWAN Gateway then provides the status of the network and provides resources to the sensors/end devices. + +In the example illustrated in in Figure 4, there are three sensors/end devices are bidding on one single channel for the downlink resource. The sensor on the right doesn’t participate in the auction due to the specification of its code. Let’s say this is due to the sensor that is used for a minor purpose, e.g. to monitor a garbage can or electricity meter, so the downlink confirmation can acceptably be lost. This leaves the other two devices to bid for the downlink. In this case, the door lock wins the auction. Should the downlink arrive, the payment is then automatically sent from the sensor wallet to the Gateway wallet which provided the resource. + +Usually one Gateway offers eight channels for the sensors/end devices to bid and the prices change dynamically due to the status of the Gateway, or alternatively, the willingness of the sensors. + + + +
+ MXP-smart-bidding +
+ +### 5.3 Gateway status + +Sensors and end devices will already be aware of the status of the Gateway in advance in order to make an appropriate bid for the resources and the services that provided by the network. To motivate the network administrator to maintain a robust LPWAN, we define the following metrics of the Gateway to let sensors/end devices to bid for the dynamic prices: + +- Mean time between failures (MTBF) +- Number of downlink packets sent +- Gateway density +- List of services available + +The first key parameter used to measure the stability of a Gateway on the network is determined by measuring the down time. It is recommended that a smaller MTBF be used than a larger one, because of the QoS that is required for the sensors. Thus, the high QoS sensors/end devices are willing to pay for the more stable LPWAN Gateways. + +The number of downlink packets sent by the Gateway represents the popularity of the device. This usually means the end devices/sensors around the Gateway are dense. If a sensor requires a downlink from the Gateway, which has a high number of downlink packets, it will need to place a higher bid or increase the overall bidding range accordingly. + +Gateway density is a parameter which is expected to motivate network administrators to deploy more Gateways in the areas that have little to no coverage. As demonstrated, it’s already clear that sensors will be willing to pay for low Gateway density with higher prices. Low density means the downlink channels and the services are limited and that the prices will be high when sensors are competing with each other. Overall, it’s expected that this metric will push people to expand the network in order to provide better network access to the LPWAN devices. + +From time to time, LPWAN will provide a list of services, e.g. firmware upgrades, GPS-free localization, network configuration optimization. This allows all hardware to be regularly kept up to date. Sensors and end devices would then choose from the Gateway bids for services, combined with the MTBF and the number of downlinks sent for the auction. + +### 5.4 Smart Bidding strategy + +The following are the standard auction methods found in the system: + +- Auction + - Increase: When the initial bid fails, an increased bid is made in order to secure the auction. + - Decrease: Similar to the Google Keyword style bidding auctions, the user states their bidding range. The system then states (considering all factors) the nec- essary bidding rate. In many instances, this will save customer coins. +- Fixed price + - The network resource or service are offered at a fixed price, with limited or unlimited quantity. Sensors/end devices just pay per use. +- Quantitative purchase + - The network resource or service are bid by quantitative metrics, like a period of time for downlink resource, the region of a whole city’s downlink and the amount of resources that are needed. + +### 5.5 Sensor Smart Bidding code + +Sensors and end devices are programmed with a snippet of code to enable them to bid for network resources and services that are provided by Gateways. This is implemented on the cloud so third party sensors can still use the logic easily by porting the code. There are several parameters to receive from a Gateway in advance, such as the density of the deployment and the list of services that are available to the sensors, just to name a few. + +After the information has been obtained by the Gateway, sensors would bid for resources of the service according to the type of the auction. For example, a bike lock would bid for a downlink resource using the increase method. This specifies the range of the coins that the bike lock is willing to pay for each transaction and the market dictates the end price. + +A dedicated technical white paper about the logic, design and implementation of the Smart Bidding will be released and the APIs with documentation will be available on the MXC website. + +```cpp +bid bike lock { + + /* Define the willingness to pay for the services or resources */ + type bidder + + /* Define the gateway status it will use for the auction */ + struct gw { + uint mtbf; + uint numdl; + uint density; + address service; + } + + address lock1; + gw[] gwstats; + + /* Parse the status that received from the gateway */ + function Parse(gwstats) public { + gwstats [ lock1 ] = msg. sender + lock1 = gwstats [ lock1 ]. service + } + + fuction bid(coin) constant returns (bytes32) { + coin.maximum = 10 + coin.minimum = 6 + auction.type = liner + auction.block = once + + return coin + } +} +``` + +## 6. Anti-Collision Coordinator + +With the increasing amount of LPWAN field deployments, the problem of network congestion is anticipated to rapidly increase. This is especially so when the network coverage targets ultra-long ranges of 20 km or more. + +In 2020, there are expected to be more than 75 billion devices connected to the Internet. If the majority of these are to use LPWAN, it can be assumed that it would put quite a strain on the network resources. As a result, MXProtocol infrastructure has bridged the gap between different networks using the innovative protocol. + +### 6.1 Goals of the design + +> The MXProtocol also offers a general overwhelming consensus for all public LPWAN by adding a community-based consensus, permissions and deployment permission etiquette. + +Here we define the goals of the design for the LPWAN ecosystem: + +- Minimize packet collision for uplinks in the same region deployed with multiple networks. +- Allocate new resources to the sensors/end devices that need downlink for the networks. +- Enable individual networks to pay for other networks resources and services, i.e. network roaming. +- Settle all monetary transactions in MXC. + +### 6.2 Design and implementation + +The design of the Anti-Collision Coordinator is illustrated in [Figure 5](#fig5). The coordinator has two responsibilities. The first is to make payments between networks using MXC. The second is to coordinate between networks about the downlink and uplink status. In the example illustrated in [Figure 5](#fig5), we see the door lock has successfully bid the downlink from the MXProtocol at downlink channel 1. However, the network that deployed over 1 km is also using the downlink channel 1 for the garbage sensor, and the pending collision is obvious. The solution would be that the Anti-Collision. + + +
+ anti-collision-coordinator +
+ +Coordinator would pay for Cisco’s network resource, allowing the Gateway to pause downlink channel 1 for this time’s message, thus allowing the door lock to receive the “unlock door” confirmation from the cloud. + +On the other side, the two networks report each other’s uplink lost message, since the LoRaWAN protocol has the counter for the uplink. Later, the coordinator finds out that the majority of the packets that are lost come from both street lighting and the parking meter due to the fact that their sending intervals are overlapped and they are quite close to each other. + +The coordinator then delays the street light’s sending interval or, alternatively, it changes the data rate to make sure that they won’t collide with each other, and the fees for a delay should be paid by the parking meter. Such network coordination is expected to occur quite often when future deployment of LPWAN sensors becomes more dense. Thus, the Anti-Collision Coordinator solves the problem of the network resource allocation in free-licensed bands completely. + +### 6.3 Third party integration + +The Anti-Collision Coordinator is indeed a protocol plug-in for the LoRaWAN server to control the Media Access Control (MAC) layer of LoRaWAN uplinks and downlinks. + +There are two ways to integrate the Anti-Collision Coordinator into the LPWAN server. First is to run the full node which integrates the anti-collision mechanism into the protocol layer like illustrated in [Figure 3](#fig3). Another solution is to run a light node with the anti-collision module that could be compatible with all the LoRaWAN servers. + +As [Figure 6](#fig6) shows, the Anti-Collision Coordinator is essentially a plug-in for the other LoRaWAN servers that is compatible with LoRaWAN protocol. The plug-in is a protocol enhancement that controls the uplink and downlink based on the payment logic and resource requirement between two or more networks. + +A light node connects to the full node to assign the LPWAN a wallet for sending and receiving MXCs. The Anti-Collision Coordinator controls the MAC layer for all the LoRaWAN devices. A separate white paper will be released about the protocol design of the Anti-Collision Coordinator and its APIs for LoRaWAN servers. + +
+ anti-collision-third-party-integration +
+ +## 7. Inter-Chain Data Market + +Currently, there are several traditional data markets that originate from cryptocurrencies, e.g. Streamr, IOTA and Mobius. All provide a secure mechanism to make sure that the data stream can be copied and transmitted from the owner to the consumer in a sequential manner. + +Most cryptocurrencies are in need of data. This data is fed into the system to provide checks and balances, ensuring all players along the chain have performed their role correctly. For example, a smart contract specifies which goods need to be delivered from city A to city B and this requires the buyer to pay the seller, e.g. 10 ETH. So, how can one determine whether the goods have been successfully delivered? The smart contract must rely on external Oracles from either the GPS data from the package or the LPWAN tag reading from the warehouse. + +> The entire industry continually requires chains such as Mobius or MXC to feed other chains smart contracts and the interdependent information to the applications. + +Oracles are third party services which are not part of the blockchain consensus mechanism. The main challenge with Oracles is that people need to trust these sources of information. Whether a website or a sensor, the source of information needs to be consistently trustworthy. In order to solve these issues, Oracles have different trusted computing techniques. + +### 7.1 Goals of the design + +Blockchains support Oracles in order to assist with fetching external data. The reason for this comes from the fact that blockchain applications, such as Bitcoin scripts and smart contracts cannot access and fetch data directly. As a result, they require pricing feeds for assets and financial applications and weather-related information for peer-to-peer insurance, all written with smart contracts. Here we define the goals of the MXProtocol data market with respect to designing for Oracles: + +- Facilitate data usage between different blockchains +- Establish a trusted resource for the external Oracles +- Stack up the data for later purchase +- Enable purchase of a live data stream +- Provide APIs for non-blockchain applications to access the data +- Settle all monetary transfers within MXC + +### 7.2 Design and implementation + +The MXProtocol Inter-Chain Data Market provides an effective method to feed the other smart contracts with LPWAN data captured by sensors or end devices. + + +
+ inter-chain-data-market +
+ +[Figure 7](#fig7) shows the example of the transaction between MXProtocol data and blockchains like Ethereum. + +MXProtocol feeds data to Ethereum smart contracts, and gets Ethereum payments as rewards. It only requires a simple protocol to trust that the data fetched from the MXProtocol data source is genuine and untampered. In addition to that, the rich data stream can also be used by external non-blockchain applications via Web APIs. + +Major block chains like Ethereum are short in data for smart contracts, and the data that is provided by external Oracles essentially may not be trustworthy. With the MXProtocol Inter-chain data market, the generation and flow of the data can be tracked and verified publicly on the chain. Hence, the security issue is solved internally with MXProtocol. + +### 7.3 Polkadot and Aeternity + +Polkadot is essentially a protocol that communicates between different networks. It solves consensus and transaction delivery between different chains. + +Aeternity is created to be the interface between real world data and smart contracts. Instead of using Oracles that can cause a single point of failure, Aeternity’s design provides decen- tralized infrastructure for holding and transferring the data to smart contracts. + +The MXProtocol Inter-chain data market uses the idea and mechanism developed by both Polkadot and Aeternity to deal with consensus, privacy, transaction delivery and security. A separate white paper will be released about this design. + +## 8. Smart Bidding use cases + +### 8.1 Downlink resource auction + +Downlink resource auctions occur when it is the only option for the Gateways to decide which sensor/end devices to communicate with. The Gateway usually has eight downlink channels, supporting more than 60,000 sensors that need to be acknowledged in sequence. Uplinks are free for the sensors since all the Gateways will pick up the packets and forward them within the same network, and the Anti-Collision Coordinator needs to pay the other network when collisions need to be avoided. The downlink resources need to be allocated to some sensors that need downlinks to execute the commands ([See Figure 8](#fig8)). Smart Bidding codes decide the willingness for the sensor/end devices to pay for the resources, and all the transactions are settled in MXC. + +Both the European and U.S. radio committees impose regulations on the spectrum access for LPWAN radios using 868/915Mhz bands. These regulations cover issues from maximum time on air to maximum duty cycle, which, in turn, introduces waiting times between two packets. For Gateways without Listen-Before-Talk Technology, this waiting time can range anywhere from a few milliseconds to minutes depending on the data rate and number of bytes being sent. + + +
+ LPWAN +
+ +Currently, the downlink resource is distributed on a “first come first served” basis, which can lead to many potential problems for various devices. For example, if an electricity monitoring meter were to get downlink priority over a door lock, the door lock in turn doesn’t receive the confirmation to unlock the door. The MXProtocol Smart Bidding solves this problem as covered in the following two aspects: + +- Allocate the downlink resource within the same LPWAN using the Smart Bidding code snippet for the auction. +- Enable different networks to trade for the downlink resources for the sensors/ end devices that are willing to pay. + +The snippet of code inside the sensors/end devices decides the market prices of the LPWAN. For a dense Gateway deployment like a city center, the prices can be lower due to the abundant resources of the downlink channels available. While in the mountains or suburban areas, few sensors would compete for the downlink resources and thus the prices will rise. The sensors will bid according to the MTBF, downlink numbers and the density of the network. + +The auction method and logic behind the bidding can be programmed by the owner of the sensor. It is expected that AI-driven algorithms will later be introduced to offer smarter bidding strategy for the sensors and end devices. + +### 8.2 Network coverage market + +It is expected that the supply of downlink resources will gradually increase with the demand of the sensors/end devices. The bidders will pay for the high prices for the lower Gateway density, which gives SMEs and MNCs incentives to expand the network coverage to get more MXC coin rewards. + +Figure 6 illustrates the market placed by Smart Bidding codes. The prices are lower at the dense deployment where the two LPWAN coverages overlap, and higher where there is only one LPWAN coverage. + +Some sensors travel around the city. Their code specifies the maximum amount of coins that it would like to pay for a single downlink. However, they have been to the places where no LPWAN coverage is available. Once they are back to the network, they put the last off-chain bid to the chain, and notify the whole network that they are willing to pay a pre-determined price from the Smart Bidding code. + +The prices and the amount of off-chain bids will surely motivate companies and individuals to deploy the LPWAN Gateway to the field, thus expanding the network coverage for the chain. MXProtocol shifts control from telecommunication conglomerates to companies and individuals by allowing them to deploy their own LPWAN. + +### 8.3 Service market + +There are lists of services that LPWAN can provide to the sensors/end devices. For example, an Over-the-air firmware update should be multi-casted to the sensors with downlink and it requires the sensors to bid for the resource. + +The most attractive aspect of the LPWAN is to implement GPS-free localization, which also works indoors and underground. In contrast to GPS or SIM card’s high power consumption and limited reach, LPWAN localization uses the packets sent by the sensors to calculate the position, which requires no computation from the resource-limited sensors. + +Such a service requires the resources of both a Gateway and the cloud. Hence, the Smart Bidding code will specify whether it is willing to pay for the service and its accuracy. The more Gateways that receive the packets, the more accurate the position will be. + +LPWAN sometimes needs to change the channel configurations like the arrangement or the allowed data rate. This kind of coordination will need to be applied globally and the network will have to try to synchronize such a configuration as much as possible. Smart Bidding can also accept “free auctions” where they require no one to pay. + +Through the MXProtocol Smart Bidding design, it is possible that sensors/end devices pay for the services that the network offers to them. The outcome of the design will be: + +- Some sensors/end devices get the services and the resources that they demand through auction +- Network deployment receives reward by offering services and resources to the LPWAN sensors/end devices +- All the monetary transactions are done automatically in MXC without human intervention + +## 9. Development progress + +MXC Foundation’s partner MatchX has released the MatchBox LPWAN Gateway, and the LPWAN module with development kits. It has reached more than 40 countries with distributors in Australia, North America, Asia and Europe. + +The first Proof-of-Concept has been performed in conjunction with the Stellar Development Foundation, utilizing the LPWAN coverage and enabling sensors to pay with each other. + +## 10. References + +- _What is LPWAN (low-power wide area network)?_ - Definition from WhatIs.com. (2018). IoT Agenda. Retrieved 8 January 2018, from +- _LoRa Alliance._ (2018). LoRa Alliance. Retrieved 8 January 2018, from +- _Skywire and Viscript | Skycoin Blog._ (2018). Blog.skycoin.net. Retrieved 8 January 2018, from +- _Skywire - Skycoin Meshnet Project | Skycoin Blog._ (2018). Blog.skycoin.net. Retrieved 8 January 2018, from +- _contributors, S._ (2018). Create an Account | Stellar Developers. Stellar.org. Retrieved 5 February 2018, from +- Kusmierz, B. (2017). _The first glance at the simulation of the Tangle: discrete model._ +- Popov, S. (2016). _The tangle._ IOTA. +- Kim, J. (2014). _Introducing Stellar - Stellar CN._ Stellar CN. Retrieved 5 February 2018, from +- _Ethereum Project._ (2018). Ethereum.org. Retrieved 8 January 2018, from +- _RSK._ (2018). RSK. Retrieved 8 January 2018, from +- Dudley, J., Hochstetler, G., Dudley, J., Hearn, M., Hearn, M., \& Hearn, M. (2018). _Corda: Frictionless Commerce._ corda.net. Retrieved 8 January 2018, from +- _LoRaWAN in Europe._ (2017). Matchx.io. Retrieved 8 January 2018, from +- _LoRaWAN regulations in Korea, Australia, India Japan and South East Asia._ (2017). Matchx.io. Retrieved 8 January 2018, from diff --git a/i18n/fr/code.json b/i18n/fr/code.json new file mode 100644 index 0000000..b4bed9b --- /dev/null +++ b/i18n/fr/code.json @@ -0,0 +1,175 @@ +{ + "Leverage the MXProtocol on LPWAN Miners to build the free Global IoT Network.": { + "message": "Leverage the MXProtocol on LPWAN Miners to build the free Global IoT Network." + }, + "Configure your LPWAN devices and sensors to use the MXProtocol's unique provisioning method providing your users with a turnkey experience.": { + "message": "Configure your LPWAN devices and sensors to use the MXProtocol's unique provisioning method providing your users with a turnkey experience." + }, + "Connect to your LPWAN devices with data analysis tools.": { + "message": "Connect to your LPWAN devices with data analysis tools." + }, + "theme.NotFound.title": { + "message": "Page Not Found", + "description": "The title of the 404 page" + }, + "theme.NotFound.p1": { + "message": "We could not find what you were looking for.", + "description": "The first paragraph of the 404 page" + }, + "theme.NotFound.p2": { + "message": "Please contact the owner of the site that linked you to the original URL and let them know their link is broken.", + "description": "The 2nd paragraph of the 404 page" + }, + "theme.blog.paginator.navAriaLabel": { + "message": "Blog list page navigation", + "description": "The ARIA label for the blog pagination" + }, + "theme.blog.paginator.newerEntries": { + "message": "Newer Entries", + "description": "The label used to navigate to the newer blog posts page (previous page)" + }, + "theme.blog.paginator.olderEntries": { + "message": "Older Entries", + "description": "The label used to navigate to the older blog posts page (next page)" + }, + "theme.blog.post.readingTime.plurals": { + "message": "One min read|{readingTime} min read", + "description": "Pluralized label for \"{readingTime} min read\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" + }, + "theme.tags.tagsListLabel": { + "message": "Tags:", + "description": "The label alongside a tag list" + }, + "theme.blog.post.readMore": { + "message": "Read More", + "description": "The label used in blog post item excerpts to link to full blog posts" + }, + "theme.blog.post.paginator.navAriaLabel": { + "message": "Blog post page navigation", + "description": "The ARIA label for the blog posts pagination" + }, + "theme.blog.post.paginator.newerPost": { + "message": "Newer Post", + "description": "The blog post button label to navigate to the newer/previous post" + }, + "theme.blog.post.paginator.olderPost": { + "message": "Older Post", + "description": "The blog post button label to navigate to the older/next post" + }, + "theme.blog.sidebar.navAriaLabel": { + "message": "Blog recent posts navigation", + "description": "The ARIA label for recent posts in the blog sidebar" + }, + "theme.AnnouncementBar.closeButtonAriaLabel": { + "message": "Close", + "description": "The ARIA label for close button of announcement bar" + }, + "theme.tags.tagsPageTitle": { + "message": "Tags", + "description": "The title of the tag list page" + }, + "theme.blog.post.plurals": { + "message": "One post|{count} posts", + "description": "Pluralized label for \"{count} posts\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" + }, + "theme.blog.tagTitle": { + "message": "{nPosts} tagged with \"{tagName}\"", + "description": "The title of the page for a blog tag" + }, + "theme.tags.tagsPageLink": { + "message": "View All Tags", + "description": "The label of the link targeting the tag list page" + }, + "theme.CodeBlock.copyButtonAriaLabel": { + "message": "Copy code to clipboard", + "description": "The ARIA label for copy code blocks button" + }, + "theme.CodeBlock.copied": { + "message": "Copied", + "description": "The copied button label on code blocks" + }, + "theme.CodeBlock.copy": { + "message": "Copy", + "description": "The copy button label on code blocks" + }, + "theme.docs.sidebar.expandButtonTitle": { + "message": "Expand sidebar", + "description": "The ARIA label and title attribute for expand button of doc sidebar" + }, + "theme.docs.sidebar.expandButtonAriaLabel": { + "message": "Expand sidebar", + "description": "The ARIA label and title attribute for expand button of doc sidebar" + }, + "theme.docs.paginator.navAriaLabel": { + "message": "Docs pages navigation", + "description": "The ARIA label for the docs pagination" + }, + "theme.docs.paginator.previous": { + "message": "Previous", + "description": "The label used to navigate to the previous doc" + }, + "theme.docs.paginator.next": { + "message": "Next", + "description": "The label used to navigate to the next doc" + }, + "theme.docs.sidebar.collapseButtonTitle": { + "message": "Collapse sidebar", + "description": "The title attribute for collapse button of doc sidebar" + }, + "theme.docs.sidebar.collapseButtonAriaLabel": { + "message": "Collapse sidebar", + "description": "The title attribute for collapse button of doc sidebar" + }, + "theme.docs.sidebar.responsiveCloseButtonLabel": { + "message": "Close menu", + "description": "The ARIA label for close button of mobile doc sidebar" + }, + "theme.docs.sidebar.responsiveOpenButtonLabel": { + "message": "Open menu", + "description": "The ARIA label for open button of mobile doc sidebar" + }, + "theme.docs.sidebar.navAriaLabel": { + "message": "Sidebar navigation", + "description": "The ARIA label for documentation menu" + }, + "theme.docs.versions.unreleasedVersionLabel": { + "message": "This is unreleased documentation for {siteTitle} {versionLabel} version.", + "description": "The label used to tell the user that he's browsing an unreleased doc version" + }, + "theme.docs.versions.unmaintainedVersionLabel": { + "message": "This is documentation for {siteTitle} {versionLabel}, which is no longer actively maintained.", + "description": "The label used to tell the user that he's browsing an unmaintained doc version" + }, + "theme.docs.versions.latestVersionSuggestionLabel": { + "message": "For up-to-date documentation, see the {latestVersionLink} ({versionLabel}).", + "description": "The label userd to tell the user that he's browsing an unmaintained doc version" + }, + "theme.docs.versions.latestVersionLinkLabel": { + "message": "latest version", + "description": "The label used for the latest version suggestion link label" + }, + "theme.common.editThisPage": { + "message": "Edit this page", + "description": "The link label to edit the current page" + }, + "theme.common.headingLinkTitle": { + "message": "Direct link to heading", + "description": "Title for link to heading" + }, + "theme.lastUpdated.atDate": { + "message": " on {date}", + "description": "The words used to describe on which date a page has been last updated" + }, + "theme.lastUpdated.byUser": { + "message": " by {user}", + "description": "The words used to describe by who the page has been last updated" + }, + "theme.lastUpdated.lastUpdatedAtBy": { + "message": "Last updated{atDate}{byUser}", + "description": "The sentence used to display when a page has been last updated, and by who" + }, + "theme.common.skipToMainContent": { + "message": "Skip to main content", + "description": "The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation" + } +} \ No newline at end of file diff --git a/i18n/fr/docusaurus-plugin-content-blog/2021-05-30-welcome.md b/i18n/fr/docusaurus-plugin-content-blog/2021-05-30-welcome.md new file mode 100644 index 0000000..4964f2c --- /dev/null +++ b/i18n/fr/docusaurus-plugin-content-blog/2021-05-30-welcome.md @@ -0,0 +1,13 @@ +--- +slug: bienvenue +title: Bienvenue +author: Jeff Stahlnecker +author_title: Responsable du développement à la Fondation MXC +author_url: https://github.com/jeffstahlnecker +author_image_url: https://avatars.githubusercontent.com/u/16069751 +tags: + - bienvenue + - introduction +--- + +C'est le début. Depuis que je suis retourné dans la communauté à la suite de la sortie de Miner Health, j'ai stipulé que nous améliorerons la transparence dans le développement de MXC. Ce site est le début de cette transparence. Plus de contenu sera ajouté ici. diff --git a/i18n/fr/docusaurus-plugin-content-blog/2021-07-05-tech-update.md b/i18n/fr/docusaurus-plugin-content-blog/2021-07-05-tech-update.md new file mode 100644 index 0000000..d5fcb95 --- /dev/null +++ b/i18n/fr/docusaurus-plugin-content-blog/2021-07-05-tech-update.md @@ -0,0 +1,36 @@ +--- +slug: 07-07-2021-05-Mise à jour technique +title: Mise à jour Tech - 5 Juillet 2021 +author: Jeff Stahlnecker +author_title: Responsable du développement à la Fondation MXC +author_url: https://github.com/jeffstahlnecker +author_image_url: https://avatars.githubusercontent.com/u/16069751 +tags: + - mise à jour technique + - datadash + - supernode + - dhx +--- + +Bienvenue à la toute première mise à jour MXC tech ! + +Cette semaine, l'équipe technique a été extrêmement occupée. Tout au long du sprint passé, nous nous sommes concentrés sur la réussite de tous les projets en cours. Cela nous a ramenés à quelques éléments « à faible accroche » qui ajouteront une valeur EPIC à nos utilisateurs — en particulier ceux qui sont intéressés par la connexion de périphériques LoRa. + +## Approvisionnement de l'appareil +Notre ingénieur de backend Lixuan a testé dans les moindres recoins le système d'approvisionnement de l'appareil construit par Ian pour s'assurer qu'il était prêt à être ajouté à notre code live. Elle a résolu un certain nombre de conflits (le provisionnement de l'appareil est *prêt* depuis janvier!), puis a effectué une série de tests rigoureux. Cela a été fait en collaboration avec l'ingénieur logiciel de MatchX, Ian. Ils ont fait du très bon travail, et vous verrez que l'approvisionnement de l'appareil sera disponible dès le début de la semaine. En attendant, vous pouvez consulter la documentation technique ici : [FAQ approvisionnement de périphériques](/docs/tutorials/devices/provisioning) + +Dans le cadre de notre focalisation sur les appareils au cours des deux dernières semaines, Lixuan a également résolu un problème qui a empêché les utilisateurs d'ajouter de nouveaux périphériques sur une supernode. We should be in ship-shape, and ready for some developer interaction. Feel free to send us your feedback! :) + +## Foundation for DHX Simulator Improvement +The DataDash DHX Simulator has been a long-standing issue. While it works, it's a little buggy, and once in a while spits out something unexpected. Our backend developer Pavel decided enough is enough, and jumped in to solve the challenge of the buggy simulator. To accomplish this he brought together the required information from a ton of different sources and built an API for the DataDash team to integrate. For those developers out there, I'll update this post with a link to the API as soon as it is live. + +## Improved Technical Support +We've been working hard to improve the technical support services provided by both MXC and MatchX. Our Tech Support Engineer Latifah has been hard at work building a ticketing system, integrating Discord, writing an internal support knowledgebase, while naturally also responding to your support requests. She's done an excellent job, and has set a strong foundation for reliable support moving forward. + +## Cleaning up the DataDash +Over the past two weeks our DataDash team has focused primarily on solving some pesky issues with the app. We also added support for DHX in the in-app address book. Just another feature to make life a little easier for you. + +## Contributing to DataHighway +Team members Luke, Ayush and Christian updated the DataHighway blockchain to add multisig functionality. They also made a number of improvements, and fixed issues with the Harbour testnet. You can review the full release notes [here](https://github.com/DataHighway-DHX/node/releases/tag/v3.0.5). + +That's the newest from Tech, and I'll be sure to update this post with that API link as soon as it goes live. \ No newline at end of file diff --git a/i18n/fr/docusaurus-plugin-content-blog/2021-07-20-tech-update.md b/i18n/fr/docusaurus-plugin-content-blog/2021-07-20-tech-update.md new file mode 100644 index 0000000..0a2127b --- /dev/null +++ b/i18n/fr/docusaurus-plugin-content-blog/2021-07-20-tech-update.md @@ -0,0 +1,66 @@ +--- +slug: 2021-07-20-tech-update +title: Tech Update - July 20, 2021 +author: Jeff Stahlnecker +author_title: Head of Development @ MXC Foundation +author_url: https://github.com/jeffstahlnecker +author_image_url: https://avatars.githubusercontent.com/u/45363541?v=4 +tags: + - tech update + - datadash + - dhx + - mxc controller + - device provisioning +--- + +It's hard to believe it's been another two weeks --- and we've been EXTREMELY busy polishing up some pretty epic features. + +### All About Device Provisioning +It took us quite some time to get the [device provisioning](/docs/tutorials/devices/provisioning) developer preview ready. A bit longer than expected. Device provisioning interacts with a number of supernode systems on a regular basis, meaning that each of these interactions had to be thoroughly tested. During that process we found some items that could cause issues when the system scales, so we went ahead and took the time to resolve those before pushing out the feature. I'm excited to say that the device provisioning developer preview is now live and ready for action. If you want to get a manufacturer ID and begin testing the system, email support@mxc.org. + +In the meantime, Ian is actively working on providing a sample lora device source code to make it easier for manufacturers (and tinkerers) to get started. + +### DataDash Goes Dark (for beta testers) +That's right! We're working hard on getting dark mode out there for all of you night owls. If you want to get a sneak peek at dark mode and provide some epic feedback for us, you can join the live beta by using the command `!role ios` or `!role android` in our [Discord Community](https://mxc.news/discord). This will get you access to the dedicated beta channel for your phone, which provides you with the information you need to get signed up. + +:::caution + +Beta releases have bugs. By joining the beta, you will experience these bugs. If you find an issue, always report it directly to us in our [GitHub Repo](https://github.com/mxc-foundation/supernode-app/issues/new?assignees=&labels=bug%2Ctriage&template=bug_report.yml&title=%5BBug%5D%3A+). + +::: + +### Tech Support Continues to Amaze +Ok I just had to say this one. Yes it sounds markety, and I know not everyone is always amazed, but I'm very happy with it. Within a few weeks our new Tech Support Engineer Latifah has gone from "first day with LoRa" to actively troubleshooting miners, certifying issues, finding solutions for said issues, and of course ensuring that each member of our community receives top of the line technical support. + +Keep in mind, the only way to get "official" technical support is to email support@mxc.org or by using the `/support` command in our [Discord Server](https://mxc.news/discord). + +### MXC Controller - the news on the Web App +For those of you digging into the nitty-gritty of the LoRa/LPWAN infrastructure, I'm sure you've noticed a few issues with the current web app. We know about those, and we're working on rolling out a new web app to solve all of these issues. Because we've decided to move from React to a Flutter based web app, it will take us just a bit of time to get started. + +This week we started cross-training our React developer Nam to start working with Flutter. While he's been studying, he also worked with the Flutter team to outline the base architecture of the application so that we can finalize the overall design in our upcoming sprint. + +The MXC Controller will be available as beta during development. This will provide you with early access to key pages, while keeping you informed that it's beta, and will probably have a few bugs. + +:::caution + +Beta releases will have bugs. Just pointing that out again. + +::: + +Our first release will include: +* Base architecture +* Sign-in / Register +* Device Management/Configuration pages + +I'll keep you updated on the status of this as we move forward, and of course I'll share the GitHub repo when the development begins. + + +### Continuing our Contribution to DataHighway +We haven't forgotten DataHighway and we still strongly believe in the future of this project. Blockchain developers Luke and Ayush have been hard at work to both improve the DataHighway, and bring governance on chain. There's been some progress made in that direction, however we're being über careful. As we progress further with the development, we'll start contributing to the documentation as well to ensure it's easier for others to participate. + +### Community Contributions +This documentation is fluid, and anyone can work to help improve it. If you see something that you know about, and feel confident writing an article about, feel free to fork the repo, make the changes, and submit a pull request. + +Now I know that not everyone is familiar with GitHub. In that case, let me know on Discord and I'll open up a channel for us to chat. Either I'll teach you what you need to know to participate directly on GitHub, or you can just send me the article you believe should be in the documentation. + +That's been this week's news update --- uh yeah ok wrong channel. ;) \ No newline at end of file diff --git a/i18n/fr/docusaurus-plugin-content-docs/current.json b/i18n/fr/docusaurus-plugin-content-docs/current.json new file mode 100644 index 0000000..893a6c4 --- /dev/null +++ b/i18n/fr/docusaurus-plugin-content-docs/current.json @@ -0,0 +1,18 @@ +{ + "version.label": { + "message": "Next", + "description": "The label for version current" + }, + "sidebar.tutorialSidebar.category.M2 Pro Miner": { + "message": "M2 Pro Miner", + "description": "The label for category M2 Pro Miner in sidebar tutorialSidebar" + }, + "sidebar.tutorialSidebar.category.Devices": { + "message": "Devices", + "description": "The label for category Devices in sidebar tutorialSidebar" + }, + "sidebar.tutorialSidebar.category.Supernode": { + "message": "Supernode", + "description": "The label for category Supernode in sidebar tutorialSidebar" + } +} \ No newline at end of file diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/api/intro.md b/i18n/fr/docusaurus-plugin-content-docs/current/api/intro.md new file mode 100644 index 0000000..ab0d5c0 --- /dev/null +++ b/i18n/fr/docusaurus-plugin-content-docs/current/api/intro.md @@ -0,0 +1,7 @@ +--- +title: Introduction +sidebar_position: 1 +--- + +# MXC API +Public Access API \ No newline at end of file diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/datadash/_category_.json b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/datadash/_category_.json new file mode 100644 index 0000000..96eea63 --- /dev/null +++ b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/datadash/_category_.json @@ -0,0 +1,4 @@ +{ + "label": "DataDash", + "position": 6 +} diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/datadash/beta.md b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/datadash/beta.md new file mode 100644 index 0000000..70fd43e --- /dev/null +++ b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/datadash/beta.md @@ -0,0 +1,20 @@ +--- +sidebar_position: 2 +title: DataDash Beta Testing +--- + +# DataDash Ongoing Beta +At the moment we have an open beta DataDash group for both iOS and Android. We consider this a semi-closed beta because we require participants to join our beta discord channels. This is key for discussions among participants, and provides us with an easy way to interact with beta participants. + + +To participate as a beta tester follow the following steps: +1. Join our [Discord Community](https://mxc.news/discord) +1. Use the #bot-talk channel to send one of the following commands: + * `!role ios` + * `!role android` +1. You will then see a new channel in the `development` category. Follow the steps outlined at the top of the channel to join your selected test group. + +## DataDash Closed Beta +Before a major release, we will do a call for closed beta participants. This will have a limited number of available seats per operating system, and will only be available to current beta testers who actively submit feedback. + +Closed betas will provide users access to new and unreleased features that require a major backend change. Because of this, each participant will receive a test account on a "fake" supernode to work with. \ No newline at end of file diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/datadash/bugs.md b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/datadash/bugs.md new file mode 100644 index 0000000..01e11de --- /dev/null +++ b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/datadash/bugs.md @@ -0,0 +1,19 @@ +--- +sidebar_position: 2 +title: Reporting Bugs +--- + +# How to report DataDash Bugs + +The DataDash app codebase is [Publicly available on GitHub](https://github.com/mxc-foundation/supernode-app). Therefore the best way to submit a DataDash bug, is directly as a [GitHub issue](https://github.com/mxc-foundation/supernode-app/issues). + +Please include the following information in your bug report: + +* What is the problem? +* What is the expected behavior? +* Mark the issue with the appropriate labels: + * `bug` + * `ios` or `android` +* Provide any additional information, screenshots, or videos you believe might be helpful. + +**GitHub Issues are public! Do not share any personal or identifiable information. If you believe the issue is specific to you, it should be submitted as a support ticket to [support@mxc.org](mailto:support.mxc.org).** diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/datadash/intro.md b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/datadash/intro.md new file mode 100644 index 0000000..5df58e1 --- /dev/null +++ b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/datadash/intro.md @@ -0,0 +1,35 @@ +--- +sidebar_position: 1 +title: Intro +--- + +# Introducing the DataDash App + +Our DataDash app has the following core functionality: +* LPWAN Functionality + * M2 Pro Miner + * Register + * Manage Miner Health + * MXProtocol enabled devices (coming soon) + * Register + * View live data frames + * Generate MQTT credentials (for external data management tools) +* Token Management + * MXC M2M Wallet + * DHX Wallet + * BTC Wallet (Withdrawals Only) + + +## Downloading the DataDash App + +You can get the DataDash app at the following locations: + +**Android** +* [Google Play Store](https://play.google.com/store/apps/details?id=com.mxc.smartcity) +* [APK Download](https://datadash.oss-accelerate.aliyuncs.com/app-prod-release.apk) + +**iOS** +* [App Store](https://apps.apple.com/us/app/datadash-app/id1509218470) + +## Participating with DataDash Development +Our DataDash app is [open on GitHub](https://github.com/mxc-foundation/supernode-app) and anyone is welcome to participate in its improvement. To participate, clone the repo, and then tackle a [GitHub issue](https://github.com/mxc-foundation/supernode-app/issues). When you think you've solved it, submit a pull request for our team to review. Before getting started, take a look at the rules [here](https://github.com/mxc-foundation/supernode-app/blob/master/RETHINK.md). \ No newline at end of file diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/devices/_category_.json b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/devices/_category_.json new file mode 100644 index 0000000..e6288dd --- /dev/null +++ b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/devices/_category_.json @@ -0,0 +1,4 @@ +{ + "label": "Devices", + "position": 3 +} diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/devices/integrations.md b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/devices/integrations.md new file mode 100644 index 0000000..cbeabdb --- /dev/null +++ b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/devices/integrations.md @@ -0,0 +1,221 @@ +--- +sidebar_position: 3 +title: Integrations +--- + +# Device Integrations + +By default supernode provides MQTT broker service for users to subscribe or pushlish events on their devices. + +Users can subscribe to MQTT broker under topics in the servers after authentication. Before that, you need to make sure you have mosquitto package installed. Use the package manager apt to install these dependencies on the Ubuntu 18.04 LTS server: + +``` +sudo apt-add-repository ppa:mosquitto-dev/mosquitto-ppa +sudo apt-get update +sudo apt install mosquitto mosquitto-clients +``` + +## Subscription + +You can either subscribe to the broker in your console or you can use package for Subscription inside your program. + +A template of subscribing to the topic: + +```shell +mosquitto_sub -h {{ .SUPERNODE_URL }} -p 8883 -t '{{ .EVENT_TOPIC_STRING }}' -v -u '{{ .USER_MQTT_AUTH_JWT }}' -P 'default' -i '`hostname`-$$' --capath /etc/ssl/certs +``` + +### How to get `{{ .SUPERNODE_URL }}` + +`{{ .SUPERNODE_URL }}` is the URL of supernode where you registered your devices: + +- matchx EU `lora.supernode.matchx.io` +- matchx US `ussn.matchx.io` +- hHuaweikeji `lora.hunanhuaweikeji.com` +- mxcxy `mxcxy.com` +- k-supernode `k-supernode.com` +- enlink `lora.rosanetworks.com` +- du-capital `supernode.iot-ducapital.net` + +### How to get `{{ .EVENT_TOPIC_STRING }}` + +1. Get JWT for supernode user account, in the following content, we call it `{{ .SUPERNODE_JWT }}` + +`{{ .SUPERNODE_JWT }}` will be used for authenticate your further requests. + +Call + +```shell +curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' -d '{ "password": "{{ .SUPERNODE_PASSWORD }}", "username": "{{ .SUPERNODE_USERNAME }}"}' 'https://{{ .SUPERNODE_URL }}/api/internal/login' +``` + +Response + +```json +{ + "jwt": "{{ .SUPERNODE_JWT }}", + "is2faRequired": false +} +``` + +2. Get organization list + +`{{ .ORG_ID }}` is important parameter for your further requests. + +Call + +```shell +curl -X GET --header 'Accept: application/json' --header 'Grpc-Metadata-Authorization: Bearer {{ .SUPERNODE_JWT }}' 'https://{{ .SUPERNODE_URL }}/api/organizations?limit=999&offset=0' +``` + +Response + +```json +{ + "totalCount": "1", + "result": [ + { + "id": "{{ .ORG_ID }}", + "name": "Your Organization Name", + "displayName": "Your Organization Display Name", + "canHaveGateways": true, + "createdAt": "2020-04-22T09:53:38.928940Z", + "updatedAt": "2021-05-12T12:50:02.391191Z" + } + ] +} +``` + +3. Get application list with given `{{ .ORG_ID }}` + +Call + +```shell +curl -X GET --header 'Accept: application/json' --header 'Grpc-Metadata-Authorization: Bearer {{ .SUPERNODE_JWT }}' 'https://{{ .SUPERNODE_URL }}/api/applications?limit=999&offset=0&organizationID={{ .ORG_ID }}' +``` + +Response + +```json +{ + "totalCount": "1", + "result": [ + { + "id": "{{ .APPLICATION_ID }}", + "name": "Your application name", + "description": "description", + "organizationID": "{{ .ORG_ID }}", + "serviceProfileID": "service profile id", + "serviceProfileName": "service proile name" + } + ] +} +``` + +4. Get `{{ .EVENT_TOPIC_STRING }}` for subscribing to all devices' events under same application + +Call + +```shell +curl -X GET --header 'Accept: application/json' --header 'Grpc-Metadata-Authorization: Bearer {{ .SUPERNODE_JWT }}' 'https://{{ .SUPERNODE_URL }}/api/mosquitto-auth/subscribe-application-events?applicationId={{ .APPLICATION_ID }}&organizationId={{ .ORG_ID }}' +``` + +Response + +```json +{ + "topic": "Topic for subscribing to application {{ .APPLICATION_ID }}: 'application/{{ .APPLICATION_ID }}/device/+/event/+'" +} +``` + +5. Get `{{ .EVENT_TOPIC_STRING }}` for subscribing to events with given {{ .DEV_EUI }} and {{ .ORG_ID }} + +Call + +```shell +curl -X GET --header 'Accept: application/json' --header 'Grpc-Metadata-Authorization: Bearer {{ .SUPERNODE_JWT }}' 'https://{{ .SUPERNODE_URL }}/api/mosquitto-auth/subscribe-device-events?devEui={{ .DEV_EUI }}&organizationId={{ .ORG_ID }}' + +``` + +Response + +```json +{ + "topic": [ + "Topic for subscribing to device {{ .DEV_EUI }} on event up: 'application/{{ .APPLICATION_ID }}/device/{{ .DEV_EUI }}/event/up'", + "Topic for subscribing to device {{ .DEV_EUI }} on event join: 'application/{{ .APPLICATION_ID }}/device/{{ .DEV_EUI }}/event/join'", + "Topic for subscribing to device {{ .DEV_EUI }} on event ack: 'application/{{ .APPLICATION_ID }}/device/{{ .DEV_EUI }}/event/ack'", + "Topic for subscribing to device {{ .DEV_EUI }} on event error: 'application/{{ .APPLICATION_ID }}/device/{{ .DEV_EUI }}/event/error'", + "Topic for subscribing to device {{ .DEV_EUI }} on event status: 'application/{{ .APPLICATION_ID }}/device/{{ .DEV_EUI }}/event/status'", + "Topic for subscribing to device {{ .DEV_EUI }} on event location: 'application/{{ .APPLICATION_ID }}/device/{{ .DEV_EUI }}/event/location'", + "Topic for subscribing to device {{ .DEV_EUI }} on event txack: 'application/{{ .APPLICATION_ID }}/device/{{ .DEV_EUI }}/event/txack'", + "Topic for subscribing to device {{ .DEV_EUI }} on all events: 'application/{{ .APPLICATION_ID }}/device/{{ .DEV_EUI }}/event/+'" + ] +} +``` + +### How to get `{{ .USER_MQTT_AUTH_JWT }}` + +Call + +```shell +curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'Grpc-Metadata-Authorization: Bearer {{ .SUPERNODE_JWT }}' -d '{ "organizationId": "{{ .ORG_ID }}", "ttlInSeconds": "{{ .TIME_TO_LIVE_IN_SECONDS }}"}' 'https://{{ .SUPERNODE_URL }}/api/mosquitto-auth/login' +``` + +Response + +```json +{ + "jwtMqttAuth": "{{ .USER_MQTT_AUTH_JWT }}" +} +``` + +## Publishing + +A template of publishing with mosquitto_pub looks as this: + +```shell +mosquitto_pub -h {{ .SUPERNODE_URL }} -p 8883 -u '{{ .USER_MQTT_AUTH_JWT }}' -P 'default' -i '`hostname`-$$' -t '{{ .COMMAND_TOPIC_STRING }}' -m '{{ .MESSAGE }}' --capath /etc/ssl/certs + +``` + +### How to get `{{ .COMMAND_TOPIC_STRING }}` + +Call + +```shell +curl -X GET --header 'Accept: application/json' --header 'Grpc-Metadata-Authorization: Bearer {{ .SUPERNODE_JWT }}' 'https://{{ .SUPERNODE_URL }}/api/mosquitto-auth/send-command?devEui={{ .DEV_EUI }}&organizationId={{ .ORG_ID }}' +``` + +Response + +```json +{ + "topic": "Topic for publishing to device {{ .DEV_EUI }}: 'application/{{ .APPLICATION_ID }}/device/{{ .DEV_EUI }}/command/down'" +} +``` + +### How to get `{{ .MESSAGE }}` + +The message format should be as follow: + +```json +{ + "confirmed": true, + "fPort": 10, + "data": "....", + "object": { + "temperatureSensor": { + "1": 25 + }, + "humiditySensor": { + "1": 32 + } + } +} +``` + +- `confirmed`: whether the payload must be sent as confirmed data down or not +- `fPort`: FPort to use (must be > 0) +- `data`: base64 encoded data (plaintext, will be encrypted by Network Server) +- `object`: decoded object (when application codec has been configured), when providing the 'object', you can omit ' data' diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/devices/intro.md b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/devices/intro.md new file mode 100644 index 0000000..b0dafc2 --- /dev/null +++ b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/devices/intro.md @@ -0,0 +1,6 @@ +--- +sidebar_position: 1 +title: Introduction +--- + +# MXProtocol Enabled Devices \ No newline at end of file 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.
0: Low or OFF, 1: High or ON, -1 Unknown or Invalid. | +| 20 (0x14) | percent | 1 | A generic value in percent. | +| 21 (0x15) | powerFactor | 2 or 4 | Power factor for AC power system.
Value range from 0 to 1. | +| 254 (0xfe) | uplinkPower | 1 | Exact value of TX Power in dBm. | + + + +#### GPS data format + +When data length is 1 + +| Offset | Length | Description | +| ------ | ------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 0 | 1 | Indicates whether the node has moved since last GPS fix. Possible values are:
    0: Node is stable since last GPS fix
    1: Node has moved, or has not received a GPS fix since boot; waiting for GPS fix | + +When data length is 11 + +| Offset | Length | Description | +| ------ | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 0 | 1 | $GPGGA Position Fix Indicator. Possible values are:
* 0 Fix not available or invalid
* 1 GPS SPS Mode, fix valid
* 2 Differential GPS, SPS Mode, fix valid
* 6 Dead Reckoning Mode, fix valid | +| 1 | 4 | Latitude in 1/1000 of minutes, as little-endian int32. Positive is north, negative is south. To get the value in degrees, divide by 600000. | +| 5 | 4 | Longitude in 1/1000 of minutes, as little-endian int32. Positive is east, negative is west. To get the value in degrees, divide by 600000. | +| 9 | 2 | Altitude above geoid mean sea level in decimeters (0.1m), as little-endian int16. | + + + +#### Data format for 1 byte value + +It is a signed 8-bits integer (int8_t), giving the range between -128 and +127. + +```javascript +// Decoding +if (offset_0 > 0x7f) { + value = ((offset_0 ^ 0xff) + 1) * -1; +} +else { + value = offset_0; +} +``` + + + +#### Data format for 2 bytes value + +It is a signed 16-bits fixed point number. Offset 0 is the sign bit and integer part. Offset 1 is the fractional part. + +```javascript +// Decoding in Javascript +let raw_value = (offset_0 << 8) | offset_1; +if (raw_value > 0x7fff) { + value = ((raw_value ^ 0xffff) + 1) * -1; +} +else { + value = raw_value; +} +value = value / 256; +``` + + + +#### Data format for 4 bytes value + +It is a 32-bits floating point number (IEEE 754). Offset 0 is the MSB. + +For example, a value of 54.12 will has a 32-bits value of 0x42587ae1. + +The payload will become <0x42><0x58><0x7a><0xe1>. + +```javascript +// Decoding in Javascript +let raw_value = (offset_0 << 24) | (offset_1 << 16) | (offset_2 << 8) | offset_3; +let v_temp = new DataView(new ArrayBuffer(4)) +v_temp.setUint32(0, raw_value) +value = v_temp.getFloat32(0) +``` + + + +The NAN (Not A Number) (0x7fc00000), means the sensor value is unknown or invalid. + + + +### Event Data + +Event data is information about change that occurs at a point in time. A event will contain the type value and additional event data. + +| Number | Name | Length | Description | +| --------- | ------------- | ------ | ------------------------------------------------------------------ | +| 0 (0x00) | unknown | 0 | No data. | +| 11 (0x0b) | opened | 1 | The unit is opened by a user. Data is the user ID. | +| 12 (0x0c) | specialOpened | 0 | The unit is opened in a special way. For example, a key or button. | +| 13 (0x0d) | forceOpened | 0 | The unit is opened in a abnormal way. | + + + +## Downlink Payload Data Format + +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 | Get params | 1 | Get parameter described by first byte. | +| 1 | Set params | >=2 | Set parameter described by first byte to the value specified in the rest of the message. | +| 2 | Reboot | 0 | Reboot the node immediately. | +| 3 | Reboot/upgrade | 1 | Reboot the node after the specified timeout; optionally turn BLE and SUOTA on for upgrades. The argument is as follows:bit [7]:0: just reboot1: BLE onbits [6:3]: Reservedbits [2:0]: Timeout0: TBD1: 5 minutes2: 15 minutes3: 30 minutes4: 1 hour5: 2 hours6: 4 hours7: TBD | +| 4 | Set Controls | \>=1 | Set a value to the control. For example, turn on/off a digital output. | + + + +### Parameters + +| Number | Name | Length | Description | +| ------ | ------- | ------ | ------------------------------------------------------------------------- | +| 0 | deveui | 6 | DevEUI-48 and BLE MAC address (MSBF)
Only for DevKit. Please don't use it at final product. | +| 1 | appeui | 8 | AppEUI-64 (MSBF)
Only for DevKit. Please don't use it at final product. | +| 2 | appkey | 16 | AppKey (write-only)
Only for DevKit. Please don't use it at final product. | +| 3 | period | 1 | Sensor period | +| 4 | sf | 1 | Minimal LoRa Spread Factor (valid values: 7-12) | +| 5 | version | 2 | Version number.
01 00 => V1.0 | + +Parameters 0, 1, 2 and 4 are actualized after reboot. + +Sensor period is as follows: + +| Number | Period | +| ------ | -------- | +| 0 | Default | +| 1 | 10 sec | +| 2 | 30 sec | +| 3 | 1 min | +| 4 | 2 min | +| 5 | 5 min | +| 6 | 10 min | +| 7 | 30 min | +| 8 | 1 hour | +| 9 | 2 hours | +| 10 | 5 hours | +| 11 | 12 hours | + + + +### Controls + +Controls are used for the user to change a value or state of the device. The control data consists of a byte signifying the data type, and zero or more bytes of the data. The defined types and corresponding data formats are: + +| Number | Name | Length | Description | +| --------- | ------- | ------ | ----------------------------------------------------------------- | +| 0 (0x00) | unknown | 0 | No data. | +| 19 (0x13) | digital | 1 | A generic digital value.
0: Low or OFF, 1: High or ON. | +| 20 (0x14) | percent | 1 | A generic value in percent. | diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/devices/provisioning.mdx b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/devices/provisioning.mdx new file mode 100644 index 0000000..b56498c --- /dev/null +++ b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/devices/provisioning.mdx @@ -0,0 +1,514 @@ +--- +sidebar_position: 4 +sidebar_label: Device Provisioning +--- + +# Device Provisioning + +## What is Device Provisioning? + +Device Provisioning is a process of exchanging sensitive information between a device and a server. This process will store the encryption keys required for LoRaWAN communication on the device and the server. The whole process will be completed through LoRa communication. Therefore, no additional hardware is required on the device. + +In terms of security, Elliptic-curve Diffie-Hellman is used as the key exchange, which enables subsequent sensitive data to be exchanged between the device and the server in a secure manner. + + +## What is the advantage of it? + +With the provisioning is done and the key is ready on both server and device. The operation on the user side will become simple. The user needs only a few steps to register the device to the system. He/She just needs to use our DataDash mobile APP to scan the QR-code label on the device. Then enter a few more information about the device, such as name. After that the device will start to join the network. The user didn’t need to enter any keys that the traditional way needs. During production no keys need to be sent to the assembly house, further improving the security by preventing unwanted compromise of the keys by the 3rd party. + + +## What about the QR-code label? + +The QR-code label stored the identity of the device. There is no sensitive information on it, just an ID code (called Provision ID). A minimal label just needs the Provision ID. The mobile APP will use this Provision ID to register the device to the system. It is a secure way to do the task which no encryption keys content appears during the whole process. + +Here is an example of a minimal label. + + + + + + + +
+ alt_text + PID:PROVISIONIDOOOOOOOOO
+ +For a big device that has more space for the label, a long version label could be used to store more information. + + + + + + +
+ lora provisioning label +
+ +``` +{ + "PROVID": "PROVISIONIDOOOOOOOOO", + "BRAND": "MatchX", + "MODEL": "MX1234", + "SN": "S123456" +} + +``` + + +## What device developer needs to do? + +The firmware needs to implement the flow device provisioning. It is a two steps process and needs to be done for a new produced device. The details of this process is listed on the later part of this document. + +During the device provisioning, it required the Provision ID to identify the device. We suggest the device firmware add an interface to let the manufacturer set this information at the end of the quality assurance (QA) procedure. + +An example method is to use a UART interface to program the information. Our example device uses an “AT” command to achieve this. But any other serial protocol should be fine. + + +![alt_text](/img/provisioning/lora-provisioning-stack.png "image_tooltip") + + +## What device manufacturer needs to do? + +To successfully provision a device, it required the information of Provision ID. The manufacturer needs to request it from us, MatchX. We will prepare a spreadsheet that has the assigned Provision ID and related information for the manufacturer. The Manufacturer needs to make sure the information is set to the device with the correct matched QR-Code label. + +We suggest the manufacturer to add an extra step at their quality assurance (QA) procedure. The step included setting the Provision ID to the device with a matched QR-Code label. Then verify the device is being provisioned, that means it exchanged key information with the server. + + +![alt_text](/img/provisioning/lora-provisioning-steps.png "image_tooltip") + + + + + +## Device Provisioning Implementation Details + +Source code of our example device: TBD + + +### Provision ID + +The Provision ID is a unique string for each device. During the provisioning, it is used as an identity at the provisioning server to access the device information. The Provision ID is 20 characters long and uses the RFC4648 Base32 alphabet. + + +### Hash of Provision ID + +It is the result of the SHA256 hash on the Provision ID. The device provisioning process uses this value when doing authentication with the server. To minimize the complexity of the device implementation, we suggest the device also store this value to its FLASH, instead of calculating it by itself. + + +``` +provisionIdHash = SHA256(provisionId | '.MatchX') +``` + + +For example: + + +``` +PID = 'TESTPIDOOOOOOOOOOOOO' +HASH = 'c8c7564b46b91c91ef6c4f37bcca8cf7e81baac6eb869dcc62e5fafdd0242497' +``` + + + +### Message integrity code (MIC) + +The message integrity code (MIC) value at LoRa PHYPayload for HELLO and AUTH messages is calculated as below. + + +``` +FixedKey[] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, +0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f}; + +cmac = aes128_cmac(FixedKey, message) +MIC = cmac[0..3] +``` + + +### Verification Code + +The verification code is used when the device authenticates with the server. The calculation is shown below. + + +``` + FixedKey[] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, + 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f}; + + cal_buf = provisionId + nonce; + verifyCode = aes128_cmac(FixedKey, cal_buf) +``` + +Example: + + +``` +// Input + privisionid = "SERIALNUMBEROOOOOOOO"; + servernonce = {0x01, 0x02, 0x03, 0x04}; + +// Output + verifyCode = {0x2E, 0x69, 0xBB, 0x5E, 0xD7, 0x8B, 0x5E, 0xE8, + 0x0C, 0x6A, 0x8A, 0xDC, 0x81, 0x91, 0xDD, 0xF8}; +``` + + + +### AES + +The encryption scheme used in aes128_encrypt() and aes128_cmac() are the same as LoRaWAN specification. This approach will minimize the need for extra code on the device side. + + +### LoRa + +The device provisioning using the “Proprietary” LoRa frame for communication, it means the MType on MHDR is set to ‘111’. + +The receiving windows using RX1 and delay is 5s. + +Data Rate: + + + + + + + + + + + + + + + + + + + + + + + +
Region + Data Rate + Configuration +
EU868 + 3 + Up and Down: SF9 / 125 kHz +
US915 + 3 + Up: SF7 / 125 kHz +

+ Down: SF7 / 500 kHz +

+
CN470 + 3 + Up and Down: SF9 / 125 kHz +
+ +### Sequence Diagram + +The device provisioning has two steps. First, it is a ECDH key exchange process, called “Hello” by us. The device and the server will exchange their public key on this step. Then the next step is the authentication. The device will submit its hashed Provision ID to the server. If it is a valid ID on the server, the server will accept the request and send back the EUI information. + +The keys used for LoRaWAN OTAA are derived from the ECDH shared key. All this information will not appear on the communication message. + +![alt_text](/img/provisioning/lora-device-provisioning-sequence.png "image_tooltip") + + +### Message format + +The messages shown below are the content of the MACPayload of the Proprietary MAC message of LoRaWAN. + +LoRaWAN PHYPayload: + + + + + + + + +
MHDR + MACPayload +

+ (Hello / Auth) +

+ 		MIC +
+ +##### Hello message + + +``` + | Type | rDevEUI | devPubKey | version | + | 0x01 | 8 bytes | 64 bytes | 1 byte | +``` + + + +##### Hello response + + +``` + | Type | rDevEUI | serverPubKey | serverNonce | + | 0x81 | 8 bytes | 64 bytes | 4 bytes | +``` + + + +##### Auth request + + +``` + | Type | rDevEUI | Encrypted Payload | + | 0x11 | 8 bytes | 52 bytes | + + | provisionIdHash | verifyCode | devNonce | + | 32 bytes | 16 bytes | 4 bytes | +``` + + + +##### Auth accepted + + +``` + | Type | rDevEUI | Encrypted Payload | + | 0x91 | 8 bytes | 32 bytes | + ​ + | devEUI | appEUI | verifyCode | + | 8 bytes | 8 bytes | 16 bytes | +``` + + + +##### Auth rejected + + +``` + | Type | rDevEUI | + | 0x92 | 8 bytes | +``` + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
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. + + + + + +![alt_text](/img/provisioning/lora-provisioning-spreadsheet-view.png "image_tooltip") + + +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. + + +![alt_text](/img/provisioning/device-provisioning-report.png "image_tooltip") + + +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 +``` + + + + + + +![alt_text](/img/provisioning/lora-provisioning-spreadsheet-view-1.png "image_tooltip") + diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/dhx/_category_.json b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/dhx/_category_.json new file mode 100644 index 0000000..6f5f53d --- /dev/null +++ b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/dhx/_category_.json @@ -0,0 +1,4 @@ +{ + "label": "Mining DHX", + "position": 4 +} diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/dhx/intro.md b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/dhx/intro.md new file mode 100644 index 0000000..18d2c90 --- /dev/null +++ b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/dhx/intro.md @@ -0,0 +1 @@ +# What is DHX \ No newline at end of file diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/intro.md b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/intro.md new file mode 100644 index 0000000..5e1be6f --- /dev/null +++ b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/intro.md @@ -0,0 +1,51 @@ +--- +title: Introduction +sidebar_position: 1 +--- + +# Introduction + +There are a number of ways for developers to interact with the MXC ecosystem. These forms of participation are integral to the further development and deployment of the MXProtocol. + +## Direct Participation + +### Beta Testing +Beta testing new features before they are released is a great way to help us improve the overall user experience with our products. Here are beta opportunities currently available: + +| Product | Beta Type | How to Participate | +| --------------- | --------- | ------------------------------------------ | +| DataDash | Closed | [Instructions](tutorials/datadash/beta.md) | +| MXC Controller | Closed | *Coming Soon* | +| M2 Pro (MatchX) | Open | *Coming Soon* | + +*A beta version is pre-release and considered unstable. This means that you may experience some issues. Normally these will be minimal, however participating in an M2 Pro beta could potentially affect your mining. MXC Controller and DataDash betas will not have any influence on your overall mining potential.* + + +### Coding and Translating +We have a number of public repos with active issues that could use assistance. Our team is still growing, and community support is always appreciated, encouraged and in some cases rewarded. + +Here is an updated list of repos that could use assistance. +* [DataDash App](https://github.com/mxc-foundation/supernode-app) [Flutter / Dart] + * [Translate the DataDash](https://crowdin.com/project/mxc-mobile-app) +* [Developer Documentation](https://github.com/mxc-foundation/developer-documentation) [Markdown, Javascript] + * [Translate the Docs Today](https://crowdin.com/project/mxc-documentation) + +We will continue to add repositories to this list as we work to increase transparency with our code and development process. + +## Manufacturing / Configuring Devices +Without devices the network has no purpose. Therefore, we've created an easy way for manufacturers to get involved with the network, making it possible for their devices to be deployed as a turnkey solution in the MXC ecosystem. + +In order to increase security of the entire network, we've worked with MatchX to develop a novel provisioning concept for LoRa devices. This provisioning process is a requirement for any devices intending to be MXProtocol compatible. We have made this decision as: +1. Device provisioning increases the security of the device data +1. Users will be able to deploy devices without any additional hassle +1. Improve device data integration and compatibility + +You can discover more about device provisioning for the MXProtocol in Devices. + +## Reporting Issues +Even though we attempt to do rigorous QA before every release, some pesky bugs still slip through. Actively reporting bugs is an extremely important form of participation, and helps us to improve the stability of the entire network. + +You can report bugs in the #bugs channel in our [Discord Server](https://mxc.news/discord) + +Bugs can also be reported directly as issues in the relevant GitHub Repo: +* [DataDash App Bugs](https://github.com/mxc-foundation/supernode-app/issues) \ No newline at end of file diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/m2-pro/_category_.json b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/m2-pro/_category_.json new file mode 100644 index 0000000..c3a9dcb --- /dev/null +++ b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/m2-pro/_category_.json @@ -0,0 +1,4 @@ +{ + "label": "M2 Pro Miner", + "position": 2 +} diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/m2-pro/gui.md b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/m2-pro/gui.md new file mode 100644 index 0000000..ab0362b --- /dev/null +++ b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/m2-pro/gui.md @@ -0,0 +1,5 @@ +--- +sidebar_position: 3 +--- + +# Web GUI \ No newline at end of file diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/m2-pro/intro.md b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/m2-pro/intro.md new file mode 100644 index 0000000..aa259e4 --- /dev/null +++ b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/m2-pro/intro.md @@ -0,0 +1,6 @@ +--- +title: Introduction +sidebar_position: 1 +--- + +# The M2 Pro Miner \ No newline at end of file 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. diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/m2-pro/setup.md b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/m2-pro/setup.md new file mode 100644 index 0000000..e65e163 --- /dev/null +++ b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/m2-pro/setup.md @@ -0,0 +1,5 @@ +--- +sidebar_position: 2 +--- + +# Setup \ No newline at end of file diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/m2-pro/troubleshooting.md b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/m2-pro/troubleshooting.md new file mode 100644 index 0000000..a397b99 --- /dev/null +++ b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/m2-pro/troubleshooting.md @@ -0,0 +1,67 @@ +--- +sidebar_position: 5 +--- + +# Troubleshooting +Experiencing a problem with your M2 Pro? This tutorial will help you find it. Naturally you can also ask for help in one of our communities, or reach out for manufacturer support by writing [support@matchx.io](mailto:support@matchx.io). + +## Connectivity (uptime) +If your uptime is taking a hit, there's an easy way to find out if the miner is at fault, or your local network connection. To do that follow the following steps: +### 1. Access the M2 Pro Miner web interface +You can find the interface here: `http://yourSerialNumber.local` + * Your computer or phone must be on the same network as the M2 Pro Miner + * This URL works only on iOS, Win10 and Linux. It doesn't work on Android. +``` +Username: admin +Password: your serial number using all caps +``` + + + +### 2. View the miner logs: +1. After logging in, you can view or download your logs by clicking on `SysLog` in the menu ![log file structure](/img/troubleshooting/sysLog.png) + * If you're having an ongoing issue, you may want to download your logs regularly. The miner can only store logs for the past 48 hours, so if additional troubleshooting is needed, you should download your logs once every two days. +### 3. Reading the logs + +First step is to check if offline is happening due to failed heartbeat. Use the search/find function (ctl+f, cmd+f) and type in the word failure to see any failed heartbeat. + +This is the example of a successful heartbeat session. + ``` + Jun 29 04:58:09 M2XLCTRM3ZW daemon.info gwconfd[619]: Received hb response: fw conf + ``` +Here is an example of a failed heartbeat session. + +``` +Jun 29 04:56:07 M2XLCTRM3ZW daemon.err gwconfd[619]: Heartbeat api failure:4: Deadline Exceeded +``` +A failed heartbeat can happen due to many reason but the most common reason is an unstable network connection. To rule this out, you need to check if the internet connection is good. + +These are the list of common errors which indicates unstable, loss or bad internet connection. +1. Connectivity error from network issue +``` +Jun 24 06:49:53 M2XLCTRM3ZW daemon.err tlsDaemon[606]: Setup TLS error: TCP Connection error. +``` + +2. Unstable/dropping WiFi connection +``` +Jun 17 07:25:29 M2XLCTRM3ZW user.info kernel: CFG80211-ERROR) wl_is_linkdown : Link down Reason : WLC_E_LINK +``` +3. Internet connection loss +``` +Jun 13 15:05:50 M2XLCTRM3ZW daemon.info netMgmtDaemon[614]: Internet connection loss +``` + +In most cases, the issue is related to unstable internet connection at user's end and the miner is working fine (not a hardware issue). + +To isolate this further, you can try the following: +* If the miner is connected using wireless connection – try using wired connection. +* If wired connection is not possible – move the miner closer to the router as see if the uptime improves +* If both still not solving the issue - try putting the miner on a different network (such as, at friend's home). If the miner is working fine on another network, the issue is related to your home network connection. + +### 4. Checking LoRa Connectivity [in the LoRa Log menu option] +For LoRa, when you see that a miner is offline you can check on the Last Seen. This is pretty straight forward as you just need to search these two lines. If you get PUSH_ACK, that means it is fine. +``` +[2021-06-17 08:58:48.437] [loraMgmtDaemon] [info] INFO: [up] PUSH_ACK received in 43 ms +``` +This message is sent every 30 seconds. + diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/supernode/_category_.json b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/supernode/_category_.json new file mode 100644 index 0000000..9cffdf1 --- /dev/null +++ b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/supernode/_category_.json @@ -0,0 +1,4 @@ +{ + "label": "Supernode", + "position": 4 +} diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/supernode/intro.md b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/supernode/intro.md new file mode 100644 index 0000000..3414fdc --- /dev/null +++ b/i18n/fr/docusaurus-plugin-content-docs/current/tutorials/supernode/intro.md @@ -0,0 +1,6 @@ +--- +sidebar_position: 1 +title: Introduction +--- + +# Introducing Supernodes \ No newline at end of file diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/images/fig1_lpwan_comparison.png b/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/images/fig1_lpwan_comparison.png new file mode 100644 index 0000000..b481449 Binary files /dev/null and b/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/images/fig1_lpwan_comparison.png differ diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/images/fig2_dataflow.png b/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/images/fig2_dataflow.png new file mode 100644 index 0000000..e223f70 Binary files /dev/null and b/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/images/fig2_dataflow.png differ diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/images/fig3_MXProtocol_stack.png b/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/images/fig3_MXProtocol_stack.png new file mode 100644 index 0000000..e0e3584 Binary files /dev/null and b/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/images/fig3_MXProtocol_stack.png differ diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/images/fig4_mxp_smart_bidding.png b/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/images/fig4_mxp_smart_bidding.png new file mode 100644 index 0000000..067516d Binary files /dev/null and b/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/images/fig4_mxp_smart_bidding.png differ diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/images/fig5_anti_collision_coordinator.png b/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/images/fig5_anti_collision_coordinator.png new file mode 100644 index 0000000..2249468 Binary files /dev/null and b/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/images/fig5_anti_collision_coordinator.png differ diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/images/fig6_anti_collision_integration.png b/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/images/fig6_anti_collision_integration.png new file mode 100644 index 0000000..0523fca Binary files /dev/null and b/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/images/fig6_anti_collision_integration.png differ diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/images/fig7_inter_chain_market.png b/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/images/fig7_inter_chain_market.png new file mode 100644 index 0000000..a062843 Binary files /dev/null and b/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/images/fig7_inter_chain_market.png differ diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/images/fig8_LPWAN.png b/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/images/fig8_LPWAN.png new file mode 100644 index 0000000..48e0618 Binary files /dev/null and b/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/images/fig8_LPWAN.png differ diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/intro.md b/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/intro.md new file mode 100644 index 0000000..adeb6a8 --- /dev/null +++ b/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/intro.md @@ -0,0 +1,8 @@ +--- +title: Introduction +sidebar_position: 1 +--- + +# MXC Whitepapers + +Overview of the WhitePapers \ No newline at end of file diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/mxc-data-economy.md b/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/mxc-data-economy.md new file mode 100644 index 0000000..7bcfc32 --- /dev/null +++ b/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/mxc-data-economy.md @@ -0,0 +1,6 @@ +--- +title: MXC Data Economy +sidebar_position: 3 +--- + +# MXC Data Economy \ No newline at end of file diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/mxprotocol.md b/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/mxprotocol.md new file mode 100644 index 0000000..b9c416b --- /dev/null +++ b/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/mxprotocol.md @@ -0,0 +1,513 @@ +--- +title: MXProtocol +sidebar_position: 2 +--- + +# MXProtocol (Machine eXchange Protocol): Premium Network Infrastructure, Infinite Data Stream + +## Table of Contents + +- [Machine eXchange Protocol: Premium Network Infrastructure, Infinite Data Stream](#machine-exchange-protocol-premium-network-infrastructure-infinite-data-stream) + - [1. MXC Vision](#1-mxc-vision) + - [2. Background](#2-background) + - [2.1 LPWAN vs other technologies](#21-lpwan-vs-other-technologies) + - [2.1.1 LoRaWAN](#211-lorawan) + - [2.1.2 NB-IoT](#212-nb-iot) + - [2.1.3 Deployment considerations](#213-deployment-considerations) + - [MXC economy](#mxc-economy) + - [3.1 Commerce network effect](#31-commerce-network-effect) + - [3.2 Asset-Backed Securitization](#32-asset-backed-securitization) + - [3.3 Data bloom](#33-data-bloom) + - [3.3.1 MXC-assisted garbage collection](#331-mxc-assisted-garbage-collection) + - [3.3.2 MXC-assisted car sharing](#332-mxc-assisted-car-sharing) + - [4. MXProtocol stack](#4-mxprotocol-stack) + - [4.1 Permissionless Blockchain](#41-permissionless-blockchain) + - [4.1.1 Features](#411-features) + - [4.1.2 Security and efficiency](#412-security-and-efficiency) + - [4.1.3 Long-term adoptions](#413-long-term-adoptions) + - [5. Smart Bidding](#5-smart-bidding) + - [5.1 Goals of design](#51-goals-of-design) + - [5.2 Design and implementation](#52-design-and-implementation) + - [5.3 Gateway status](#53-gateway-status) + - [5.4 Smart Bidding strategy](#54-smart-bidding-strategy) + - [5.5 Sensor Smart Bidding code](#55-sensor-smart-bidding-code) + - [6. Anti-Collision Coordinator](#6-anti-collision-coordinator) + - [6.1 Goals of the design](#61-goals-of-the-design) + - [6.2 Design and implementation](#62-design-and-implementation) + - [6.3 Third party integration](#63-third-party-integration) + - [7. Inter-Chain Data Market](#7-inter-chain-data-market) + - [7.1 Goals of the design](#71-goals-of-the-design) + - [7.2 Design and implementation](#72-design-and-implementation) + - [7.3 Polkadot and Aeternity](#73-polkadot-and-aeternity) + - [8. Smart Bidding use cases](#8-smart-bidding-use-cases) + - [8.1 Downlink resource auction](#81-downlink-resource-auction) + - [8.2 Network coverage market](#82-network-coverage-market) + - [8.3 Service market](#83-service-market) + - [9. Development progress](#9-development-progress) + - [10. References](#10-references) + +## 1. MXC Vision + +> The MXC vision is to introduce a systematic process to both simplify and increase IoT data transactions. + +The decentralized infrastructure upon which MXC’s system is based is the future of Low Power Wide Access Network (LPWAN) and the Machine eXchange Protocol (MXProtocol). Utilizing this solid device network foundation, MXC is introducing an extraordinarily unique coin offering, Machine eXchange Coin (MXC), which allows for increased data transactions and an idiosyncratic data flow monetization within the mammoth data market. + +MXProtocol places a keen focus on reducing collision between networks, constructing an inter-chain data market, developing a market for network coverage and introducing an independent Quality of Services (QoS) framework for both data providers and receivers. For the first time ever, individual network users, corporations and enterprises can all participate in the construction of decentralized, ubiquitous and secure LPWAN. Simply by connecting “anything” to the network, adopters will be able to profit and trade MXC. + +The trading network is built on the premise of the “sharing economy.” Therefore, it is uniquely and exclusively owned by users — both individuals and enterprises — who take advantage of the monetization of the network in two ways: + +1. By increasing uplink and downlink coverage via a Gateway, e.g. a MatchBox LPWAN Gateway, Cisco LPWAN Gateway +2. By unleashing access to a massive network of published and traded data to the marketplace which is securely traded using blockchain technology + +Both sensors and connected devices bid (via the integrated QoS) for the downlink network resource to, for example, unlock a door or, alternatively, shut down a faulty radiator, subsequently offering a market-devised price for the uncovered regions. This ultimately increases data network coverage. “Things” can autonomously pay each other with MXC tokens and get accredited by sharing the data with different users/marketplaces. + +There has been a phenomenal increase in the sourcing, collection and transmission of big data within the past five years. Additionally, the increasing use of artificial intelligence feeding off this data has assisted people to simplify tedious tasks and to make better informed decisions on everything from projecting a weather forecast, to saving household energy, to even choosing the right music to play at home. The tone has now been set for decades to come. Machines interacting with one another has seen a significant increase over such a short period. This will only increase as our interdependency on machines and machine learning grows and becomes ever more significant in day to day life. + +Whether for individuals or big companies, the need for a specified network concentrating on machines and machine data is here to stay. It will play a bigger part in supporting both individuals and businesses than ever before. MXProtocol introduces the next generation of LPWAN with a superior IoT data platform and a premium network experience, allowing for a simplified and expedited way to create a secure and efficient solution for IoT. + +The following sections elaborate on the unique advantages of MXProtocol, including its components — permissionless blockchain, Smart Bidding, Anti-Collision Coordinator and Inter-Chain Data Market — that make it a truly innovative technology. + +## 2. Background + +MXC is a German non-profit organization based in the country’s start-up and blockchain capital, Berlin. MXC is partnering with various LPWAN companies. MXProtocol is a revolutionary design that solves the problem of LPWAN and bridges the data gap between different infrastructures. + +IoT is a hot topic that has been intently discussed for over a decade. The one focus and premise of the IoT network is connecting “things” to the Internet and collecting/using this data from the objects that can’t speak for themselves. The application of this new founded, increased data is highly limited due to the current methods offering low range and high power consumption. For example, standard WiFi can generally reach an absolute maximum of around 100 meters, and using 3G/4G consumes a significant amount of power, thus reducing effective battery life and increasing maintenance costs significantly. The fact is, current implementations for data networks are extremely expensive and offer very low usability. The need for a new technology is here and the need for LPWAN will only increase as it solves the current problems of low range/high cost data transmissions. + +The fact is, current implementations for data networks are extremely expensive and offer very low usability. The need for a new technology is here and the need for LPWAN will only increase as it solves the current problems of low range/high cost data transmissions. + + + +
+ LPWAN +
+ +### 2.1 LPWAN vs other technologies + +LPWAN technology emerged to the forefront in recent years with the goal of finding a better data transmission solution to the shortfalls of WiFi, Bluetooth and 3G & 4G networks. These earlier established networks were originally targeted at connecting people, not at connecting the data generated by “things.” The amount of machine-generated data has multiplied significantly in recent times. The new LPWAN technology offers aspects where others simply can’t compete: + +- 10 year sensor battery life +- 20 km data reach with just a single Gateway +- Offers an extreme amount of connection points (over 60,000 for a single network cell) supported by LPWAN Gateways at an extremely low cost + +Now, when compared to the current wireless network, it’s easy to see the superior advancements that the MXC solutions offer. As illustrated in Figure 1, LoRa and NB-IoT are simply the most potent solutions on the LPWAN market. + +#### 2.1.1 LoRaWAN + +LoRaWAN is an open-source protocol defined by the LoRa Alliance, which is already supported by industrial giants such as Cisco, Alibaba, Comcast, IBM and SK Telecom and many more. Advantages of LoRaWAN are 20 km open space coverage, low data rates (low-level kbps) and ultra-low power, allowing for 10 years continued operation on a single battery. + +Both the Gateways and end sensor devices use the LoRaWAN protocol. In fact, devices of any brand are supported and can be connected to the network as long as they are LoRa/LPWAN compatible. + +#### 2.1.2 NB-IoT + +NB-IoT is a narrowband radio technology specified by 3GPP as a licensed telecommuni- cation protocol. NB-IoT focuses specifically on indoor coverage, low throughput and long battery life, enabling a large number of connected devices. + +The advantage for an MXC IoT user is that it gives an individual the power to host their own network wherever and whenever they like. Compare that with the NB-IoT base stations (which are owned by telecommunications conglomerates) which charge users expensive SIM card fees to send data messages over the Internet through NB-IoT protocol. MXProtocol supports all LPWAN technologies, developed LoRaWAN Gateways, NB-IoT and LoRaWAN sensors. That’s decentralization. That’s yet another MXC advantage. + +#### 2.1.3 Deployment considerations + +When deploying LPWAN, the first consideration is understanding how to avoid a col- lision between different competing networks residing in the same region. Generally, the issue comes from the fact that both may use the same channel to send out the message at the same time and leave the other available channel empty due to the chosen preferences. As a result, it’s generally hard to reach a consensus between these networks and thus the deployment suffers as network usage increases. The decentralization and distributed mech- anism of MXProtocol solves this issue by coordinating the networks. The network evolves by having users pay micro-payments for the resources that another one offers. + +The second concern is due to the shortage of downlink resources for the dense sensor/ end device deployment. Usually there are some sensors/end devices which require no downlink or can bear with the loss of downlinks. This is usually associated with low-activity sensors, such as garbage bins or electricity meters. However, end devices like bike locks or location tracker devices need to receive regular and reliable confirmations from the cloud for every uplink. Hence, they are willing to pay a premium for this reliability and a QoS provided by the networks. MXProtocol provides this bidding resource, ensuring that, for example, a garbage bin sensor won’t take first preference over the vital downlink resource of something like a bike lock. + +Another consideration pertains to the requirements for multi-national cooperations (MNC) and small to medium enterprises (SME) trading their data assets publicly generated using LPWAN technology. Within LPWAN, both the data stream and asset trading features are simplified, easy to read and can be digitally transmitted from many kilometers away. This makes the data exchange a clear necessity for the needs of the LPWAN market of tomorrow. + +With respect to the needs of MNCs or SMEs, it’s likely that such enterprises will wish to deploy their own LPWAN to cover an entire city or a region for its own specific applica- tions such as asset tracking (e.g. automobile) or sensor data management. This is a perfect solution for “Big Business.” LPWAN technology delivers via its long reach ensuring that sensor/end device uplink packets are securely received as per the protocol design. + +This leads to one of the key aspects of the MXProtocol: bringing the monetization of data services to the forefront. Using the MXProtocol, micro-payments within the LPWAN infrastructure will be traded from third party sensors/end devices, ensuring data is conveniently, correctly and concisely transmitted in a secure manner, whilst being maintained by the support of system administrators. The industry has been waiting for a decentralized and consensus-based mechanism to improve the usability of LPWAN, and MXC is delivering. + +MXC has designed this next generation LPWAN infrastructure using MXProtocol in order to significantly boost the applications of blockchain and IoT within the real-world context. + +## MXC economy + +Machine eXchange Coin (MXC) offers a unique and specifically designed decentralized technological “Data Trade Network” to the global Token economy. Data can be shared on a mass scale whilst ensuring complete end to end privacy. The MXC intends to be distributed amongst data owners, data receivers and data network hosts, allowing for a facilitated cross-over from a “commodity” based Coin into an everyday trading Coin currency. + +### 3.1 Commerce network effect + +Machine eXchange Coin is the first Token designed to bridge current commodity-based trading of cryptocurrency tokens and the cash-based global economy. Utilizing the “sharing economy,” MXC uses this as an axis, allowing large businesses, SMEs and individuals to borrow or rent assets owned by someone else. + +Individuals place LoRa-based protocol hardware in opportune positions in order to benefit and profit from their locations and their decentralized LoRaWAN network. Businesses benefit by using these user-based networks to send sensor/device data, building a new “sharing economy.” Wallets are stored in the cloud allowing individuals to profit from businesses sending sensor data via their LoRaWAN LPWAN. The coins are then sent and traded from the sensor holders that MXProtocol addresses to the Gateway distributor. + +MXProtocol gives network participants incentives to use, deploy and trade their network elements. In addition to that, it is a people-owned secure and private network that won’t suffer from public congestion like what Ethereum encountered with cryptokitties. + +### 3.2 Asset-Backed Securitization + +MXC has been highly successful with regards to the design and production of high-end LPWAN hardware. Using the coins and sharing economy will allow for a massive influx of shared sensor data amongst individuals and companies, giving better insights into consumer behavior, environmental impacts and machine-based optimizations. + +With MXC, Asset-Backed Securitization (ABS) adds a completely new way for individuals and companies to both trade and manage their data and physical assets. Current methods see sensitive data easily being passed and reproduced to a number of parties without any of them knowing that the data has potentially already been corrupted, seen and/or shared amongst potential competitors/untrusted parties. MXC makes it possible for corporations and individuals to track both physical goods and intangible data, ensuring that buyers/ receivers of the goods are the only party who have received the data/physical good, and for this information to come from a qualified and reliable source. + +By applying ABS, the individual data is allocated to one dedicated source. In contrast, a buyer of a tangible paper certificate, for example, has no way of knowing that the same certificate hasn’t been sold/reproduced and assigned to potentially multiple parties. + +### 3.3 Data bloom + +MXC is a blockchain-based decentralized platform designed to revolutionize three core functions based around the basic financial theory: Lend, Send and Spend. + +#### 3.3.1 MXC-assisted garbage collection + +The future is here. The one constant in everyone’s life from now on will be the data surrounding all of us. In the past such a statement referred to “people-generated data.” However, times have changed. “Machine-generated data” is taking over at a phenomenal rate. + +The beauty of machine-based data, when compared with human-based data, is it doesn’t sleep. Machine-based data is constant and it’s reliability is unmatched when compared with any people-generated data. So why is this important? + +Take, for example, a local city council. Their task is to ensure safety, security and general well-being of the local city. One of these responsibilities includes simple tasks such as garbage collection. The simple act of emptying city trash may seem like a monotonous task, but it in fact requires planning and chain management: When do collections occur? How often should trash collections occur? How many employees are required to empty garbage cans across the city? MXC simplifies such tasks using MXProtocol. + +Using sensor/end devices situated in garbage cans and allowing them to transmit device data via a Gateway allows the city council to detect the levels of garbage built up within the can. What does this mean for the council? + +- Saving fuel: The council only needs to send out garbage trucks when necessary, as opposed to sending out trucks to check cans, irrespective of whether they are full or even completely empty. +- Saving wages: By only sending out employees at the moment a garbage can needs to be emptied, the council can then reallocate human resources, thus saving employee wages. +- Reducing traffic congestion: Garbage trucks are often frustrating for commuters. When parked on the side of the road, they can increase general traffic significantly. Being aware of the need for garbage removal in certain areas can reduce the need for trucks and allow for smoother traffic flows. + +Many of these highlighted aspects make up the chain of events associated with what are deemed to be “menial tasks” but, as shown, the flow on effect is quite significant. MXC IoT is ready to solve such issues, allowing for simple tasks to be categorized and ensuring exact resources are allocated only when needed. + +#### 3.3.1 MXC-assisted car sharing + +Using LoRaWAN sensor/end devices and Gateways can also reduce the cost of car sharing partners. + +Covering an entire city center in LPWAN allows individuals to simply build their own completely independent network, free from telecommunications companies and net- works charging exorbitant costs. + +The benefits of doing this for a company such as a “car sharing” company allows them to track their vehicles without the need to depend on Telecommunication coverage. Using LPWAN significantly reduces the costs, especially when compared with the costs of tracking using a SIM card. + +In addition to GPS tracking, car doors can be locked and unlocked using LPWAN, increasing security for users, all at a very low cost compared to current methods. + +By bringing such key services, MXC provides transparency and greatly enhances customer experience. MXC’s mission is to intensify data sharing whilst forging a unity between those with finance and data service needs and those without finance but who have private access to network integration and distribution, thus eliminating borders, intermediaries and prejudices. + +MXProtocol focuses on three foundational pillars: + +- Extend and support the massive device data economy +- Utilize the decentralized “sharing economy” +- Trade of assets within the current coin economy + +MXProtocol connects “things” utilizing a market-based economy, which adds a plethora of new transmission points allowing more data to be shared, traded, sold and analyzed for data mining. + +Within the new decentralized MXC economy, everyone can profit from the sharing of data; end to end encryption grants authorized usage of the data; and entire communities can benefit from using their locations to act as a network facility to transport this data — trading assets, profiting from the coin economy. + +## 4. MXProtocol stack + +MXProtocol infrastructure consists of both sensor and end devices, Gateway and cloud. Sensors and end devices collect data from “things,” and send to the cloud via the Gateway. This is uniquely designed to specifically be a decentralized solution allowing for everyone to suit their/the market’s needs. The usability of the hardware has been specifically designed as a “plug and play” solution, making installation simple without the need for a professional configuration. It is designed to be easy to set up and easy to share data. + +As the flow in [Figure 2](#fig2) demonstrates, LPWAN Gateways connect to each other to form either a mesh network as a collective cloud or the Internet. The sensors or end devices communicate with Gateways using LPWAN technology for bi-directional communication. Notably, the sensors and end devices are not purely limited to a single LPWAN product. In fact, any LoRaWAN compatible sensors are able to connect to the LPWAN network and can start sending and receiving messages. + + +
+ dataflow +
+ +MXProtocol facilitates the data and value flow of the LPWAN. Inside this ecosystem, each sensor or end device has a MXC wallet address assigned to an individual user. This is required in order to both pay for the network usage and to receive money from selling the data and services. The sensor wallet is stored in the cloud in order to maintain the LPWAN low-power requirements. This is also due to the fact that the CPU is usually resource-constrained. The same wallet is used as the Gateway wallet (also found in a user account and stored in the cloud). This wallet will receive coins from uploading/downloading the data from the cloud to the sensor and assists in paying for the other LPWAN’s resource or data. + +Coinciding with the current LPWAN infrastructure protocol, the data link between the Gateway and sensor end devices is unregulated. As a result, there would be no possibility to be rewarded for forwarding data from the sensor to cloud via the Gateway, and ultimately the downlink resource would be limited, only being allocated on a “first come, first served” basis. This system as is would negatively impact low-level data procurement services offered by things such as a door lock or car charging station system and would result in the data link not being appropriately monetized. MXC LPWAN infrastructure solves such issues, delivering the ultimate user experience to SMEs and MNCs. + + +
+ dataflow-mxprotocol +
+ +[Figure 3](#fig3) shows the detailed technical stack of the MXProtocol infrastructure. The decentralized and autonomous LPWAN can be built on any permissionless blockchain, such as IOTA, Stellar, Skywire and NEO. + +Based on this, the Anti-Collision Coordinator between LPWANs, Smart Bidding and Inter-chain data market are introduced to answer the LPWAN deployment considerations mentioned in the previous chapter [see 2.1.3](#213-deployment-considerations). + +### 4.1 Permissionless Blockchain + +There are various kinds of blockchain. Anyone can use cryptographic keys, anyone can be a node and join the network, and anyone can become a participant to service the network and seek a reward. Participants can walk away from being a node, return if and when they feel like it and get a full account of all network activity since they left. + +In a permissionless blockchain, anyone can read the chain, anyone can make legitimate changes and anyone can write a new block into the chain as long as they follow the rules. Decisions on a permissionless blockchain are made by the network participants. The protocol is based on a consensus protocol. The permissionless blockchain provides a way to reach consensus without relying on a closed system to accurately record financial transactions. + +#### 4.1.1 Features + +MXC built MXProtocol as an inclusive platform where all participants are encouraged to contribute. MXProtocol is a distributed network protocol backed by monetization of the resources and incentives from enterprises and individuals based on permissionless blockchain. The permissionless blockchain design makes MXProtocol efficient and independent: the more people use it, the more robust the network will be. + +The blockchain should have four key properties: decentralized control, low latency, flexible trust, and asymptotic security. In other words, MXProtocol should run on a permissionless blockchain that has: + +- A true decentralized network. +- It has eliminated mining rewards. +- All transactions get confirmed quickly. +- There is an anti-spam role. There should be a preventive measure against nefarious users flooding the network (a DoS attack). + +#### 4.1.2 Security and efficiency + +Often, the speed and privacy of a network is the concern for SMEs and MNCs. Public blockchains, such as Ethereum and Bitcoin, often suffer from big computing slow downs, practically grinding the systems to a halt, leading to a situation where the whole network and the 51 percent resources can attack the blocks. There should be a blockchain providing more privacy and efficiency for businesses and individuals collectively. MXProtocol needs to be run on a secure and efficient blockchain that can provide the devices with good connectivity. + +The MXC-introduced LPWAN application requires further fragmented and discrete transactions for sensitive data and services in an IoT realm. That is why MXC continues to develop upon the permissionless blockchain, making MXProtocol more efficient and more suitable for the needs of LPWAN and IoT applications. + +#### 4.1.3 Long-term adoptions + +As previously stated, MXProtocol is a LPWAN platform protocol that brings efficiency and robustness to the users. There are, however, still several components inside permissionless blockchain itself that MXC feels necessary to emphasize. For example, to ensure the long term stability of the LPWAN IoT projects, continued research is still required with regards to the current data interface. Real field deployment will need to be conducted in order to properly satisfy the plethora of data streams connecting from the LPWAN sensors/end devices and ensure they are routed to the network seamlessly. + +## 5. Smart Bidding + +Due to governmental regulations of the LPWAN spectrum, the downlink is a precious resource that is closely guarded by sensors and end devices. The majority of the world uses eight downlink channels for acknowledgement or confirmation of the sensor data, and each channel usually has to wait anywhere from a few milliseconds up to a few minutes in order to send another packet. + +The downlink channels are fixed in the protocol and code, and the waiting time for each downlink is dependent on the data rate of the sensor/end device. A key side note to this point is that LPWAN Gateways use the latest in “Listen Before Talk” technology allowing them to send data more regularly. This means that data may be sent when the channel is free, and therefore doesn’t have to wait for a specific time period to elapse. + +### 5.1 Goals of design + +To further overcome such industry-wide issues, MXProtocol implements a bidding mechanism, designed to bring the needed resources to those devices that are willing to bid the most. Generally public LPWAN deployment is pushed by both individuals and corporations who do so in order to extend their own individual network reach. Introducing a bidding mechanism will cause network reaches to multiply due to the fact that users can both earn and learn from the data that are sent by the sensors. The purpose of this section is to examine the Smart Bidding design that would support a well-functioning LPWAN ecosystem. The goals of the design are to: + +- Allocate downlink resources adequately +- Allow all sensors/end devices to compete on a market platform for network resources +- Offer network deployments incentives, assisting them to monetize +- Ensure LPWAN services are monetized +- Power the decentralized ledger with MXProtocol to simplify and resolve any issues + +### 5.2 Design and implementation + +There are different bidding models, ranges and methods to be set in Smart Bidding. The goal is to assign the network resource to the highest bidder. The design and functionality of the Smart Bidding process is proposed in [Figure 4](#fig4). Sensors/end devices bid on one single downlink channel out of the eight available on the LPWAN Gateway. The Smart Bidding code sensors/end devices are hosted on the cloud code, enabling them to place a bid. The LPWAN Gateway then provides the status of the network and provides resources to the sensors/end devices. + +In the example illustrated in in Figure 4, there are three sensors/end devices are bidding on one single channel for the downlink resource. The sensor on the right doesn’t participate in the auction due to the specification of its code. Let’s say this is due to the sensor that is used for a minor purpose, e.g. to monitor a garbage can or electricity meter, so the downlink confirmation can acceptably be lost. This leaves the other two devices to bid for the downlink. In this case, the door lock wins the auction. Should the downlink arrive, the payment is then automatically sent from the sensor wallet to the Gateway wallet which provided the resource. + +Usually one Gateway offers eight channels for the sensors/end devices to bid and the prices change dynamically due to the status of the Gateway, or alternatively, the willingness of the sensors. + + + +
+ MXP-smart-bidding +
+ +### 5.3 Gateway status + +Sensors and end devices will already be aware of the status of the Gateway in advance in order to make an appropriate bid for the resources and the services that provided by the network. To motivate the network administrator to maintain a robust LPWAN, we define the following metrics of the Gateway to let sensors/end devices to bid for the dynamic prices: + +- Mean time between failures (MTBF) +- Number of downlink packets sent +- Gateway density +- List of services available + +The first key parameter used to measure the stability of a Gateway on the network is determined by measuring the down time. It is recommended that a smaller MTBF be used than a larger one, because of the QoS that is required for the sensors. Thus, the high QoS sensors/end devices are willing to pay for the more stable LPWAN Gateways. + +The number of downlink packets sent by the Gateway represents the popularity of the device. This usually means the end devices/sensors around the Gateway are dense. If a sensor requires a downlink from the Gateway, which has a high number of downlink packets, it will need to place a higher bid or increase the overall bidding range accordingly. + +Gateway density is a parameter which is expected to motivate network administrators to deploy more Gateways in the areas that have little to no coverage. As demonstrated, it’s already clear that sensors will be willing to pay for low Gateway density with higher prices. Low density means the downlink channels and the services are limited and that the prices will be high when sensors are competing with each other. Overall, it’s expected that this metric will push people to expand the network in order to provide better network access to the LPWAN devices. + +From time to time, LPWAN will provide a list of services, e.g. firmware upgrades, GPS-free localization, network configuration optimization. This allows all hardware to be regularly kept up to date. Sensors and end devices would then choose from the Gateway bids for services, combined with the MTBF and the number of downlinks sent for the auction. + +### 5.4 Smart Bidding strategy + +The following are the standard auction methods found in the system: + +- Auction + - Increase: When the initial bid fails, an increased bid is made in order to secure the auction. + - Decrease: Similar to the Google Keyword style bidding auctions, the user states their bidding range. The system then states (considering all factors) the nec- essary bidding rate. In many instances, this will save customer coins. +- Fixed price + - The network resource or service are offered at a fixed price, with limited or unlimited quantity. Sensors/end devices just pay per use. +- Quantitative purchase + - The network resource or service are bid by quantitative metrics, like a period of time for downlink resource, the region of a whole city’s downlink and the amount of resources that are needed. + +### 5.5 Sensor Smart Bidding code + +Sensors and end devices are programmed with a snippet of code to enable them to bid for network resources and services that are provided by Gateways. This is implemented on the cloud so third party sensors can still use the logic easily by porting the code. There are several parameters to receive from a Gateway in advance, such as the density of the deployment and the list of services that are available to the sensors, just to name a few. + +After the information has been obtained by the Gateway, sensors would bid for resources of the service according to the type of the auction. For example, a bike lock would bid for a downlink resource using the increase method. This specifies the range of the coins that the bike lock is willing to pay for each transaction and the market dictates the end price. + +A dedicated technical white paper about the logic, design and implementation of the Smart Bidding will be released and the APIs with documentation will be available on the MXC website. + +```cpp +bid bike lock { + + /* Define the willingness to pay for the services or resources */ + type bidder + + /* Define the gateway status it will use for the auction */ + struct gw { + uint mtbf; + uint numdl; + uint density; + address service; + } + + address lock1; + gw[] gwstats; + + /* Parse the status that received from the gateway */ + function Parse(gwstats) public { + gwstats [ lock1 ] = msg. sender + lock1 = gwstats [ lock1 ]. service + } + + fuction bid(coin) constant returns (bytes32) { + coin.maximum = 10 + coin.minimum = 6 + auction.type = liner + auction.block = once + + return coin + } +} +``` + +## 6. Anti-Collision Coordinator + +With the increasing amount of LPWAN field deployments, the problem of network congestion is anticipated to rapidly increase. This is especially so when the network coverage targets ultra-long ranges of 20 km or more. + +In 2020, there are expected to be more than 75 billion devices connected to the Internet. If the majority of these are to use LPWAN, it can be assumed that it would put quite a strain on the network resources. As a result, MXProtocol infrastructure has bridged the gap between different networks using the innovative protocol. + +### 6.1 Goals of the design + +> The MXProtocol also offers a general overwhelming consensus for all public LPWAN by adding a community-based consensus, permissions and deployment permission etiquette. + +Here we define the goals of the design for the LPWAN ecosystem: + +- Minimize packet collision for uplinks in the same region deployed with multiple networks. +- Allocate new resources to the sensors/end devices that need downlink for the networks. +- Enable individual networks to pay for other networks resources and services, i.e. network roaming. +- Settle all monetary transactions in MXC. + +### 6.2 Design and implementation + +The design of the Anti-Collision Coordinator is illustrated in [Figure 5](#fig5). The coordinator has two responsibilities. The first is to make payments between networks using MXC. The second is to coordinate between networks about the downlink and uplink status. In the example illustrated in [Figure 5](#fig5), we see the door lock has successfully bid the downlink from the MXProtocol at downlink channel 1. However, the network that deployed over 1 km is also using the downlink channel 1 for the garbage sensor, and the pending collision is obvious. The solution would be that the Anti-Collision. + + +
+ anti-collision-coordinator +
+ +Coordinator would pay for Cisco’s network resource, allowing the Gateway to pause downlink channel 1 for this time’s message, thus allowing the door lock to receive the “unlock door” confirmation from the cloud. + +On the other side, the two networks report each other’s uplink lost message, since the LoRaWAN protocol has the counter for the uplink. Later, the coordinator finds out that the majority of the packets that are lost come from both street lighting and the parking meter due to the fact that their sending intervals are overlapped and they are quite close to each other. + +The coordinator then delays the street light’s sending interval or, alternatively, it changes the data rate to make sure that they won’t collide with each other, and the fees for a delay should be paid by the parking meter. Such network coordination is expected to occur quite often when future deployment of LPWAN sensors becomes more dense. Thus, the Anti-Collision Coordinator solves the problem of the network resource allocation in free-licensed bands completely. + +### 6.3 Third party integration + +The Anti-Collision Coordinator is indeed a protocol plug-in for the LoRaWAN server to control the Media Access Control (MAC) layer of LoRaWAN uplinks and downlinks. + +There are two ways to integrate the Anti-Collision Coordinator into the LPWAN server. First is to run the full node which integrates the anti-collision mechanism into the protocol layer like illustrated in [Figure 3](#fig3). Another solution is to run a light node with the anti-collision module that could be compatible with all the LoRaWAN servers. + +As [Figure 6](#fig6) shows, the Anti-Collision Coordinator is essentially a plug-in for the other LoRaWAN servers that is compatible with LoRaWAN protocol. The plug-in is a protocol enhancement that controls the uplink and downlink based on the payment logic and resource requirement between two or more networks. + +A light node connects to the full node to assign the LPWAN a wallet for sending and receiving MXCs. The Anti-Collision Coordinator controls the MAC layer for all the LoRaWAN devices. A separate white paper will be released about the protocol design of the Anti-Collision Coordinator and its APIs for LoRaWAN servers. + +
+ anti-collision-third-party-integration +
+ +## 7. Inter-Chain Data Market + +Currently, there are several traditional data markets that originate from cryptocurrencies, e.g. Streamr, IOTA and Mobius. All provide a secure mechanism to make sure that the data stream can be copied and transmitted from the owner to the consumer in a sequential manner. + +Most cryptocurrencies are in need of data. This data is fed into the system to provide checks and balances, ensuring all players along the chain have performed their role correctly. For example, a smart contract specifies which goods need to be delivered from city A to city B and this requires the buyer to pay the seller, e.g. 10 ETH. So, how can one determine whether the goods have been successfully delivered? The smart contract must rely on external Oracles from either the GPS data from the package or the LPWAN tag reading from the warehouse. + +> The entire industry continually requires chains such as Mobius or MXC to feed other chains smart contracts and the interdependent information to the applications. + +Oracles are third party services which are not part of the blockchain consensus mechanism. The main challenge with Oracles is that people need to trust these sources of information. Whether a website or a sensor, the source of information needs to be consistently trustworthy. In order to solve these issues, Oracles have different trusted computing techniques. + +### 7.1 Goals of the design + +Blockchains support Oracles in order to assist with fetching external data. The reason for this comes from the fact that blockchain applications, such as Bitcoin scripts and smart contracts cannot access and fetch data directly. As a result, they require pricing feeds for assets and financial applications and weather-related information for peer-to-peer insurance, all written with smart contracts. Here we define the goals of the MXProtocol data market with respect to designing for Oracles: + +- Facilitate data usage between different blockchains +- Establish a trusted resource for the external Oracles +- Stack up the data for later purchase +- Enable purchase of a live data stream +- Provide APIs for non-blockchain applications to access the data +- Settle all monetary transfers within MXC + +### 7.2 Design and implementation + +The MXProtocol Inter-Chain Data Market provides an effective method to feed the other smart contracts with LPWAN data captured by sensors or end devices. + + +
+ inter-chain-data-market +
+ +[Figure 7](#fig7) shows the example of the transaction between MXProtocol data and blockchains like Ethereum. + +MXProtocol feeds data to Ethereum smart contracts, and gets Ethereum payments as rewards. It only requires a simple protocol to trust that the data fetched from the MXProtocol data source is genuine and untampered. In addition to that, the rich data stream can also be used by external non-blockchain applications via Web APIs. + +Major block chains like Ethereum are short in data for smart contracts, and the data that is provided by external Oracles essentially may not be trustworthy. With the MXProtocol Inter-chain data market, the generation and flow of the data can be tracked and verified publicly on the chain. Hence, the security issue is solved internally with MXProtocol. + +### 7.3 Polkadot and Aeternity + +Polkadot is essentially a protocol that communicates between different networks. It solves consensus and transaction delivery between different chains. + +Aeternity is created to be the interface between real world data and smart contracts. Instead of using Oracles that can cause a single point of failure, Aeternity’s design provides decen- tralized infrastructure for holding and transferring the data to smart contracts. + +The MXProtocol Inter-chain data market uses the idea and mechanism developed by both Polkadot and Aeternity to deal with consensus, privacy, transaction delivery and security. A separate white paper will be released about this design. + +## 8. Smart Bidding use cases + +### 8.1 Downlink resource auction + +Downlink resource auctions occur when it is the only option for the Gateways to decide which sensor/end devices to communicate with. The Gateway usually has eight downlink channels, supporting more than 60,000 sensors that need to be acknowledged in sequence. Uplinks are free for the sensors since all the Gateways will pick up the packets and forward them within the same network, and the Anti-Collision Coordinator needs to pay the other network when collisions need to be avoided. The downlink resources need to be allocated to some sensors that need downlinks to execute the commands ([See Figure 8](#fig8)). Smart Bidding codes decide the willingness for the sensor/end devices to pay for the resources, and all the transactions are settled in MXC. + +Both the European and U.S. radio committees impose regulations on the spectrum access for LPWAN radios using 868/915Mhz bands. These regulations cover issues from maximum time on air to maximum duty cycle, which, in turn, introduces waiting times between two packets. For Gateways without Listen-Before-Talk Technology, this waiting time can range anywhere from a few milliseconds to minutes depending on the data rate and number of bytes being sent. + + +
+ LPWAN +
+ +Currently, the downlink resource is distributed on a “first come first served” basis, which can lead to many potential problems for various devices. For example, if an electricity monitoring meter were to get downlink priority over a door lock, the door lock in turn doesn’t receive the confirmation to unlock the door. The MXProtocol Smart Bidding solves this problem as covered in the following two aspects: + +- Allocate the downlink resource within the same LPWAN using the Smart Bidding code snippet for the auction. +- Enable different networks to trade for the downlink resources for the sensors/ end devices that are willing to pay. + +The snippet of code inside the sensors/end devices decides the market prices of the LPWAN. For a dense Gateway deployment like a city center, the prices can be lower due to the abundant resources of the downlink channels available. While in the mountains or suburban areas, few sensors would compete for the downlink resources and thus the prices will rise. The sensors will bid according to the MTBF, downlink numbers and the density of the network. + +The auction method and logic behind the bidding can be programmed by the owner of the sensor. It is expected that AI-driven algorithms will later be introduced to offer smarter bidding strategy for the sensors and end devices. + +### 8.2 Network coverage market + +It is expected that the supply of downlink resources will gradually increase with the demand of the sensors/end devices. The bidders will pay for the high prices for the lower Gateway density, which gives SMEs and MNCs incentives to expand the network coverage to get more MXC coin rewards. + +Figure 6 illustrates the market placed by Smart Bidding codes. The prices are lower at the dense deployment where the two LPWAN coverages overlap, and higher where there is only one LPWAN coverage. + +Some sensors travel around the city. Their code specifies the maximum amount of coins that it would like to pay for a single downlink. However, they have been to the places where no LPWAN coverage is available. Once they are back to the network, they put the last off-chain bid to the chain, and notify the whole network that they are willing to pay a pre-determined price from the Smart Bidding code. + +The prices and the amount of off-chain bids will surely motivate companies and individuals to deploy the LPWAN Gateway to the field, thus expanding the network coverage for the chain. MXProtocol shifts control from telecommunication conglomerates to companies and individuals by allowing them to deploy their own LPWAN. + +### 8.3 Service market + +There are lists of services that LPWAN can provide to the sensors/end devices. For example, an Over-the-air firmware update should be multi-casted to the sensors with downlink and it requires the sensors to bid for the resource. + +The most attractive aspect of the LPWAN is to implement GPS-free localization, which also works indoors and underground. In contrast to GPS or SIM card’s high power consumption and limited reach, LPWAN localization uses the packets sent by the sensors to calculate the position, which requires no computation from the resource-limited sensors. + +Such a service requires the resources of both a Gateway and the cloud. Hence, the Smart Bidding code will specify whether it is willing to pay for the service and its accuracy. The more Gateways that receive the packets, the more accurate the position will be. + +LPWAN sometimes needs to change the channel configurations like the arrangement or the allowed data rate. This kind of coordination will need to be applied globally and the network will have to try to synchronize such a configuration as much as possible. Smart Bidding can also accept “free auctions” where they require no one to pay. + +Through the MXProtocol Smart Bidding design, it is possible that sensors/end devices pay for the services that the network offers to them. The outcome of the design will be: + +- Some sensors/end devices get the services and the resources that they demand through auction +- Network deployment receives reward by offering services and resources to the LPWAN sensors/end devices +- All the monetary transactions are done automatically in MXC without human intervention + +## 9. Development progress + +MXC Foundation’s partner MatchX has released the MatchBox LPWAN Gateway, and the LPWAN module with development kits. It has reached more than 40 countries with distributors in Australia, North America, Asia and Europe. + +The first Proof-of-Concept has been performed in conjunction with the Stellar Development Foundation, utilizing the LPWAN coverage and enabling sensors to pay with each other. + +## 10. References + +- _What is LPWAN (low-power wide area network)?_ - Definition from WhatIs.com. (2018). IoT Agenda. Retrieved 8 January 2018, from +- _LoRa Alliance._ (2018). LoRa Alliance. Retrieved 8 January 2018, from +- _Skywire and Viscript | Skycoin Blog._ (2018). Blog.skycoin.net. Retrieved 8 January 2018, from +- _Skywire - Skycoin Meshnet Project | Skycoin Blog._ (2018). Blog.skycoin.net. Retrieved 8 January 2018, from +- _contributors, S._ (2018). Create an Account | Stellar Developers. Stellar.org. Retrieved 5 February 2018, from +- Kusmierz, B. (2017). _The first glance at the simulation of the Tangle: discrete model._ +- Popov, S. (2016). _The tangle._ IOTA. +- Kim, J. (2014). _Introducing Stellar - Stellar CN._ Stellar CN. Retrieved 5 February 2018, from +- _Ethereum Project._ (2018). Ethereum.org. Retrieved 8 January 2018, from +- _RSK._ (2018). RSK. Retrieved 8 January 2018, from +- Dudley, J., Hochstetler, G., Dudley, J., Hearn, M., Hearn, M., \& Hearn, M. (2018). _Corda: Frictionless Commerce._ corda.net. Retrieved 8 January 2018, from +- _LoRaWAN in Europe._ (2017). Matchx.io. Retrieved 8 January 2018, from +- _LoRaWAN regulations in Korea, Australia, India Japan and South East Asia._ (2017). Matchx.io. Retrieved 8 January 2018, from diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/smart-machine-bidding.md b/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/smart-machine-bidding.md new file mode 100644 index 0000000..72dd182 --- /dev/null +++ b/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/smart-machine-bidding.md @@ -0,0 +1,6 @@ +--- +title: Smart Machine Bidding +sidebar_position: 3 +--- + +# Smart Machine Bidding \ No newline at end of file diff --git a/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/tokenomics.md b/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/tokenomics.md new file mode 100644 index 0000000..e7fca3d --- /dev/null +++ b/i18n/fr/docusaurus-plugin-content-docs/current/whitepapers/tokenomics.md @@ -0,0 +1,6 @@ +--- +title: Tokenomics +sidebar_position: 4 +--- + +# Tokenomics \ No newline at end of file diff --git a/i18n/fr/docusaurus-theme-classic/footer.json b/i18n/fr/docusaurus-theme-classic/footer.json new file mode 100644 index 0000000..0cb80f5 --- /dev/null +++ b/i18n/fr/docusaurus-theme-classic/footer.json @@ -0,0 +1,66 @@ +{ + "link.title.Docs": { + "message": "Docs", + "description": "The title of the footer links column with title=Docs in the footer" + }, + "link.title.Community": { + "message": "Community", + "description": "The title of the footer links column with title=Community in the footer" + }, + "link.title.More": { + "message": "More", + "description": "The title of the footer links column with title=More in the footer" + }, + "link.item.label.Tutorials": { + "message": "Tutorials", + "description": "The label of footer link with label=Tutorials linking to /docs/tutorials/intro" + }, + "link.item.label.API": { + "message": "API", + "description": "The label of footer link with label=API linking to /docs/api/intro" + }, + "link.item.label.Whitepapers": { + "message": "Whitepapers", + "description": "The label of footer link with label=Whitepapers linking to /docs/whitepapers/intro" + }, + "link.item.label.Telegram": { + "message": "Telegram", + "description": "The label of footer link with label=Telegram linking to https://mxc.news/telegram" + }, + "link.item.label.Discord": { + "message": "Discord", + "description": "The label of footer link with label=Discord linking to https://mxc.news/discord" + }, + "link.item.label.Twitter": { + "message": "Twitter", + "description": "The label of footer link with label=Twitter linking to https://twitter.com/mxcfoundation" + }, + "link.item.label.Developer Blog": { + "message": "Developer Blog", + "description": "The label of footer link with label=Developer Blog linking to /blog" + }, + "link.item.label.GitHub": { + "message": "GitHub", + "description": "The label of footer link with label=GitHub linking to https://github.com/mxc-foundation/" + }, + "link.item.label.MXC Website": { + "message": "MXC Website", + "description": "The label of footer link with label=MXC Website linking to https://www.mxc.org" + }, + "link.item.label.User Documentation": { + "message": "User Documentation", + "description": "The label of footer link with label=User Documentation linking to https://www.mxc.wiki" + }, + "link.item.label.Imprint": { + "message": "Imprint", + "description": "The label of footer link with label=Imprint linking to https://www.mxc.org/imprint" + }, + "link.item.label.Privacy Policy": { + "message": "Privacy Policy", + "description": "The label of footer link with label=Privacy Policy linking to https://www.mxc.org/privacy-policy" + }, + "copyright": { + "message": "Copyright © 2021 MXC Foundation gGmbH.", + "description": "The footer copyright" + } +} \ No newline at end of file diff --git a/i18n/fr/docusaurus-theme-classic/navbar.json b/i18n/fr/docusaurus-theme-classic/navbar.json new file mode 100644 index 0000000..63fefb5 --- /dev/null +++ b/i18n/fr/docusaurus-theme-classic/navbar.json @@ -0,0 +1,26 @@ +{ + "title": { + "message": "Developer Documentation", + "description": "The title in the navbar" + }, + "item.label.Docs": { + "message": "Docs", + "description": "Navbar item with label Docs" + }, + "item.label.API": { + "message": "API", + "description": "Navbar item with label API" + }, + "item.label.Whitepapers": { + "message": "Whitepapers", + "description": "Navbar item with label Whitepapers" + }, + "item.label.Blog": { + "message": "Blog", + "description": "Navbar item with label Blog" + }, + "item.label.GitHub": { + "message": "GitHub", + "description": "Navbar item with label GitHub" + } +} \ No newline at end of file diff --git a/i18n/ko/code.json b/i18n/ko/code.json new file mode 100644 index 0000000..b4bed9b --- /dev/null +++ b/i18n/ko/code.json @@ -0,0 +1,175 @@ +{ + "Leverage the MXProtocol on LPWAN Miners to build the free Global IoT Network.": { + "message": "Leverage the MXProtocol on LPWAN Miners to build the free Global IoT Network." + }, + "Configure your LPWAN devices and sensors to use the MXProtocol's unique provisioning method providing your users with a turnkey experience.": { + "message": "Configure your LPWAN devices and sensors to use the MXProtocol's unique provisioning method providing your users with a turnkey experience." + }, + "Connect to your LPWAN devices with data analysis tools.": { + "message": "Connect to your LPWAN devices with data analysis tools." + }, + "theme.NotFound.title": { + "message": "Page Not Found", + "description": "The title of the 404 page" + }, + "theme.NotFound.p1": { + "message": "We could not find what you were looking for.", + "description": "The first paragraph of the 404 page" + }, + "theme.NotFound.p2": { + "message": "Please contact the owner of the site that linked you to the original URL and let them know their link is broken.", + "description": "The 2nd paragraph of the 404 page" + }, + "theme.blog.paginator.navAriaLabel": { + "message": "Blog list page navigation", + "description": "The ARIA label for the blog pagination" + }, + "theme.blog.paginator.newerEntries": { + "message": "Newer Entries", + "description": "The label used to navigate to the newer blog posts page (previous page)" + }, + "theme.blog.paginator.olderEntries": { + "message": "Older Entries", + "description": "The label used to navigate to the older blog posts page (next page)" + }, + "theme.blog.post.readingTime.plurals": { + "message": "One min read|{readingTime} min read", + "description": "Pluralized label for \"{readingTime} min read\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" + }, + "theme.tags.tagsListLabel": { + "message": "Tags:", + "description": "The label alongside a tag list" + }, + "theme.blog.post.readMore": { + "message": "Read More", + "description": "The label used in blog post item excerpts to link to full blog posts" + }, + "theme.blog.post.paginator.navAriaLabel": { + "message": "Blog post page navigation", + "description": "The ARIA label for the blog posts pagination" + }, + "theme.blog.post.paginator.newerPost": { + "message": "Newer Post", + "description": "The blog post button label to navigate to the newer/previous post" + }, + "theme.blog.post.paginator.olderPost": { + "message": "Older Post", + "description": "The blog post button label to navigate to the older/next post" + }, + "theme.blog.sidebar.navAriaLabel": { + "message": "Blog recent posts navigation", + "description": "The ARIA label for recent posts in the blog sidebar" + }, + "theme.AnnouncementBar.closeButtonAriaLabel": { + "message": "Close", + "description": "The ARIA label for close button of announcement bar" + }, + "theme.tags.tagsPageTitle": { + "message": "Tags", + "description": "The title of the tag list page" + }, + "theme.blog.post.plurals": { + "message": "One post|{count} posts", + "description": "Pluralized label for \"{count} posts\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" + }, + "theme.blog.tagTitle": { + "message": "{nPosts} tagged with \"{tagName}\"", + "description": "The title of the page for a blog tag" + }, + "theme.tags.tagsPageLink": { + "message": "View All Tags", + "description": "The label of the link targeting the tag list page" + }, + "theme.CodeBlock.copyButtonAriaLabel": { + "message": "Copy code to clipboard", + "description": "The ARIA label for copy code blocks button" + }, + "theme.CodeBlock.copied": { + "message": "Copied", + "description": "The copied button label on code blocks" + }, + "theme.CodeBlock.copy": { + "message": "Copy", + "description": "The copy button label on code blocks" + }, + "theme.docs.sidebar.expandButtonTitle": { + "message": "Expand sidebar", + "description": "The ARIA label and title attribute for expand button of doc sidebar" + }, + "theme.docs.sidebar.expandButtonAriaLabel": { + "message": "Expand sidebar", + "description": "The ARIA label and title attribute for expand button of doc sidebar" + }, + "theme.docs.paginator.navAriaLabel": { + "message": "Docs pages navigation", + "description": "The ARIA label for the docs pagination" + }, + "theme.docs.paginator.previous": { + "message": "Previous", + "description": "The label used to navigate to the previous doc" + }, + "theme.docs.paginator.next": { + "message": "Next", + "description": "The label used to navigate to the next doc" + }, + "theme.docs.sidebar.collapseButtonTitle": { + "message": "Collapse sidebar", + "description": "The title attribute for collapse button of doc sidebar" + }, + "theme.docs.sidebar.collapseButtonAriaLabel": { + "message": "Collapse sidebar", + "description": "The title attribute for collapse button of doc sidebar" + }, + "theme.docs.sidebar.responsiveCloseButtonLabel": { + "message": "Close menu", + "description": "The ARIA label for close button of mobile doc sidebar" + }, + "theme.docs.sidebar.responsiveOpenButtonLabel": { + "message": "Open menu", + "description": "The ARIA label for open button of mobile doc sidebar" + }, + "theme.docs.sidebar.navAriaLabel": { + "message": "Sidebar navigation", + "description": "The ARIA label for documentation menu" + }, + "theme.docs.versions.unreleasedVersionLabel": { + "message": "This is unreleased documentation for {siteTitle} {versionLabel} version.", + "description": "The label used to tell the user that he's browsing an unreleased doc version" + }, + "theme.docs.versions.unmaintainedVersionLabel": { + "message": "This is documentation for {siteTitle} {versionLabel}, which is no longer actively maintained.", + "description": "The label used to tell the user that he's browsing an unmaintained doc version" + }, + "theme.docs.versions.latestVersionSuggestionLabel": { + "message": "For up-to-date documentation, see the {latestVersionLink} ({versionLabel}).", + "description": "The label userd to tell the user that he's browsing an unmaintained doc version" + }, + "theme.docs.versions.latestVersionLinkLabel": { + "message": "latest version", + "description": "The label used for the latest version suggestion link label" + }, + "theme.common.editThisPage": { + "message": "Edit this page", + "description": "The link label to edit the current page" + }, + "theme.common.headingLinkTitle": { + "message": "Direct link to heading", + "description": "Title for link to heading" + }, + "theme.lastUpdated.atDate": { + "message": " on {date}", + "description": "The words used to describe on which date a page has been last updated" + }, + "theme.lastUpdated.byUser": { + "message": " by {user}", + "description": "The words used to describe by who the page has been last updated" + }, + "theme.lastUpdated.lastUpdatedAtBy": { + "message": "Last updated{atDate}{byUser}", + "description": "The sentence used to display when a page has been last updated, and by who" + }, + "theme.common.skipToMainContent": { + "message": "Skip to main content", + "description": "The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation" + } +} \ No newline at end of file diff --git a/i18n/ko/docusaurus-plugin-content-blog/2019-05-30-welcome.md b/i18n/ko/docusaurus-plugin-content-blog/2019-05-30-welcome.md new file mode 100644 index 0000000..592f3ed --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-blog/2019-05-30-welcome.md @@ -0,0 +1,13 @@ +--- +slug: welcome +title: Welcome +author: Jeff Stahlnecker +author_title: Head of Development at MXC Foundation +author_url: https://github.com/jeffstahlnecker +author_image_url: https://avatars.githubusercontent.com/u/45363541?v=4 +tags: + - welcome + - intro +--- + +It's the beginning. Since I returned to the community following the Miner Health release, I've been saying that we'll impove transparency in development at MXC. This site is the beginning of this transparency. More content will be added here. diff --git a/i18n/ko/docusaurus-plugin-content-blog/2021-05-30-welcome.md b/i18n/ko/docusaurus-plugin-content-blog/2021-05-30-welcome.md new file mode 100644 index 0000000..592f3ed --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-blog/2021-05-30-welcome.md @@ -0,0 +1,13 @@ +--- +slug: welcome +title: Welcome +author: Jeff Stahlnecker +author_title: Head of Development at MXC Foundation +author_url: https://github.com/jeffstahlnecker +author_image_url: https://avatars.githubusercontent.com/u/45363541?v=4 +tags: + - welcome + - intro +--- + +It's the beginning. Since I returned to the community following the Miner Health release, I've been saying that we'll impove transparency in development at MXC. This site is the beginning of this transparency. More content will be added here. diff --git a/i18n/ko/docusaurus-plugin-content-blog/2021-07-05-tech-update.md b/i18n/ko/docusaurus-plugin-content-blog/2021-07-05-tech-update.md new file mode 100644 index 0000000..2dd0bc2 --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-blog/2021-07-05-tech-update.md @@ -0,0 +1,36 @@ +--- +slug: 2021-07-05-tech-update +title: Tech Update - July 5, 2021 +author: Jeff Stahlnecker +author_title: Head of Development @ MXC Foundation +author_url: https://github.com/jeffstahlnecker +author_image_url: https://avatars.githubusercontent.com/u/45363541?v=4 +tags: + - tech update + - datadash + - supernode + - dhx +--- + +Welcome to the very first MXC tech update! + +This week the tech team has been extremely busy. Throughout the past sprint we've focused on closing any and all ongoing projects. That brought us back to a few "low hanging" items that will add some EPIC value to our users -- especially those interested in connecting LoRa devices. + +## Device Provisioning +Our very own backend engineer Lixuan took a deep dive to test the device provisioning system built by Ian to ensure that it was ready to be added with our live code. She solved a number of conflicts (device provisioning has been *ready* since January!), then ran it through a round of rigorous testing. This was done in collaboration with MatchX embedded software engineer Ian. They did some great work, and you'll see device provisioning going live early this week. In the meantime, you can check out the technical documentation here: [Device Provisioning FAQ](/docs/tutorials/devices/provisioning) + +As part of our focus on devices during the past two weeks, Lixuan also solved an issue which kept users from adding new devices on a supernode. We should be in ship-shape, and ready for some developer interaction. Feel free to send us your feedback! :) + +## Foundation for DHX Simulator Improvement +The DataDash DHX Simulator has been a long-standing issue. While it works, it's a little buggy, and once in a while spits out something unexpected. Our backend developer Pavel decided enough is enough, and jumped in to solve the challenge of the buggy simulator. To accomplish this he brought together the required information from a ton of different sources and built an API for the DataDash team to integrate. For those developers out there, I'll update this post with a link to the API as soon as it is live. + +## Improved Technical Support +We've been working hard to improve the technical support services provided by both MXC and MatchX. Our Tech Support Engineer Latifah has been hard at work building a ticketing system, integrating Discord, writing an internal support knowledgebase, while naturally also responding to your support requests. She's done an excellent job, and has set a strong foundation for reliable support moving forward. + +## Cleaning up the DataDash +Over the past two weeks our DataDash team has focused primarily on solving some pesky issues with the app. We also added support for DHX in the in-app address book. Just another feature to make life a little easier for you. + +## Contributing to DataHighway +Team members Luke, Ayush and Christian updated the DataHighway blockchain to add multisig functionality. They also made a number of improvements, and fixed issues with the Harbour testnet. You can review the full release notes [here](https://github.com/DataHighway-DHX/node/releases/tag/v3.0.5). + +That's the newest from Tech, and I'll be sure to update this post with that API link as soon as it goes live. \ No newline at end of file diff --git a/i18n/ko/docusaurus-plugin-content-blog/2021-07-20-tech-update.md b/i18n/ko/docusaurus-plugin-content-blog/2021-07-20-tech-update.md new file mode 100644 index 0000000..0a2127b --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-blog/2021-07-20-tech-update.md @@ -0,0 +1,66 @@ +--- +slug: 2021-07-20-tech-update +title: Tech Update - July 20, 2021 +author: Jeff Stahlnecker +author_title: Head of Development @ MXC Foundation +author_url: https://github.com/jeffstahlnecker +author_image_url: https://avatars.githubusercontent.com/u/45363541?v=4 +tags: + - tech update + - datadash + - dhx + - mxc controller + - device provisioning +--- + +It's hard to believe it's been another two weeks --- and we've been EXTREMELY busy polishing up some pretty epic features. + +### All About Device Provisioning +It took us quite some time to get the [device provisioning](/docs/tutorials/devices/provisioning) developer preview ready. A bit longer than expected. Device provisioning interacts with a number of supernode systems on a regular basis, meaning that each of these interactions had to be thoroughly tested. During that process we found some items that could cause issues when the system scales, so we went ahead and took the time to resolve those before pushing out the feature. I'm excited to say that the device provisioning developer preview is now live and ready for action. If you want to get a manufacturer ID and begin testing the system, email support@mxc.org. + +In the meantime, Ian is actively working on providing a sample lora device source code to make it easier for manufacturers (and tinkerers) to get started. + +### DataDash Goes Dark (for beta testers) +That's right! We're working hard on getting dark mode out there for all of you night owls. If you want to get a sneak peek at dark mode and provide some epic feedback for us, you can join the live beta by using the command `!role ios` or `!role android` in our [Discord Community](https://mxc.news/discord). This will get you access to the dedicated beta channel for your phone, which provides you with the information you need to get signed up. + +:::caution + +Beta releases have bugs. By joining the beta, you will experience these bugs. If you find an issue, always report it directly to us in our [GitHub Repo](https://github.com/mxc-foundation/supernode-app/issues/new?assignees=&labels=bug%2Ctriage&template=bug_report.yml&title=%5BBug%5D%3A+). + +::: + +### Tech Support Continues to Amaze +Ok I just had to say this one. Yes it sounds markety, and I know not everyone is always amazed, but I'm very happy with it. Within a few weeks our new Tech Support Engineer Latifah has gone from "first day with LoRa" to actively troubleshooting miners, certifying issues, finding solutions for said issues, and of course ensuring that each member of our community receives top of the line technical support. + +Keep in mind, the only way to get "official" technical support is to email support@mxc.org or by using the `/support` command in our [Discord Server](https://mxc.news/discord). + +### MXC Controller - the news on the Web App +For those of you digging into the nitty-gritty of the LoRa/LPWAN infrastructure, I'm sure you've noticed a few issues with the current web app. We know about those, and we're working on rolling out a new web app to solve all of these issues. Because we've decided to move from React to a Flutter based web app, it will take us just a bit of time to get started. + +This week we started cross-training our React developer Nam to start working with Flutter. While he's been studying, he also worked with the Flutter team to outline the base architecture of the application so that we can finalize the overall design in our upcoming sprint. + +The MXC Controller will be available as beta during development. This will provide you with early access to key pages, while keeping you informed that it's beta, and will probably have a few bugs. + +:::caution + +Beta releases will have bugs. Just pointing that out again. + +::: + +Our first release will include: +* Base architecture +* Sign-in / Register +* Device Management/Configuration pages + +I'll keep you updated on the status of this as we move forward, and of course I'll share the GitHub repo when the development begins. + + +### Continuing our Contribution to DataHighway +We haven't forgotten DataHighway and we still strongly believe in the future of this project. Blockchain developers Luke and Ayush have been hard at work to both improve the DataHighway, and bring governance on chain. There's been some progress made in that direction, however we're being über careful. As we progress further with the development, we'll start contributing to the documentation as well to ensure it's easier for others to participate. + +### Community Contributions +This documentation is fluid, and anyone can work to help improve it. If you see something that you know about, and feel confident writing an article about, feel free to fork the repo, make the changes, and submit a pull request. + +Now I know that not everyone is familiar with GitHub. In that case, let me know on Discord and I'll open up a channel for us to chat. Either I'll teach you what you need to know to participate directly on GitHub, or you can just send me the article you believe should be in the documentation. + +That's been this week's news update --- uh yeah ok wrong channel. ;) \ No newline at end of file diff --git a/i18n/ko/docusaurus-plugin-content-blog/2021-07-5-tech-update.md b/i18n/ko/docusaurus-plugin-content-blog/2021-07-5-tech-update.md new file mode 100644 index 0000000..2dd0bc2 --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-blog/2021-07-5-tech-update.md @@ -0,0 +1,36 @@ +--- +slug: 2021-07-05-tech-update +title: Tech Update - July 5, 2021 +author: Jeff Stahlnecker +author_title: Head of Development @ MXC Foundation +author_url: https://github.com/jeffstahlnecker +author_image_url: https://avatars.githubusercontent.com/u/45363541?v=4 +tags: + - tech update + - datadash + - supernode + - dhx +--- + +Welcome to the very first MXC tech update! + +This week the tech team has been extremely busy. Throughout the past sprint we've focused on closing any and all ongoing projects. That brought us back to a few "low hanging" items that will add some EPIC value to our users -- especially those interested in connecting LoRa devices. + +## Device Provisioning +Our very own backend engineer Lixuan took a deep dive to test the device provisioning system built by Ian to ensure that it was ready to be added with our live code. She solved a number of conflicts (device provisioning has been *ready* since January!), then ran it through a round of rigorous testing. This was done in collaboration with MatchX embedded software engineer Ian. They did some great work, and you'll see device provisioning going live early this week. In the meantime, you can check out the technical documentation here: [Device Provisioning FAQ](/docs/tutorials/devices/provisioning) + +As part of our focus on devices during the past two weeks, Lixuan also solved an issue which kept users from adding new devices on a supernode. We should be in ship-shape, and ready for some developer interaction. Feel free to send us your feedback! :) + +## Foundation for DHX Simulator Improvement +The DataDash DHX Simulator has been a long-standing issue. While it works, it's a little buggy, and once in a while spits out something unexpected. Our backend developer Pavel decided enough is enough, and jumped in to solve the challenge of the buggy simulator. To accomplish this he brought together the required information from a ton of different sources and built an API for the DataDash team to integrate. For those developers out there, I'll update this post with a link to the API as soon as it is live. + +## Improved Technical Support +We've been working hard to improve the technical support services provided by both MXC and MatchX. Our Tech Support Engineer Latifah has been hard at work building a ticketing system, integrating Discord, writing an internal support knowledgebase, while naturally also responding to your support requests. She's done an excellent job, and has set a strong foundation for reliable support moving forward. + +## Cleaning up the DataDash +Over the past two weeks our DataDash team has focused primarily on solving some pesky issues with the app. We also added support for DHX in the in-app address book. Just another feature to make life a little easier for you. + +## Contributing to DataHighway +Team members Luke, Ayush and Christian updated the DataHighway blockchain to add multisig functionality. They also made a number of improvements, and fixed issues with the Harbour testnet. You can review the full release notes [here](https://github.com/DataHighway-DHX/node/releases/tag/v3.0.5). + +That's the newest from Tech, and I'll be sure to update this post with that API link as soon as it goes live. \ No newline at end of file diff --git a/i18n/ko/docusaurus-plugin-content-docs/current.json b/i18n/ko/docusaurus-plugin-content-docs/current.json new file mode 100644 index 0000000..893a6c4 --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-docs/current.json @@ -0,0 +1,18 @@ +{ + "version.label": { + "message": "Next", + "description": "The label for version current" + }, + "sidebar.tutorialSidebar.category.M2 Pro Miner": { + "message": "M2 Pro Miner", + "description": "The label for category M2 Pro Miner in sidebar tutorialSidebar" + }, + "sidebar.tutorialSidebar.category.Devices": { + "message": "Devices", + "description": "The label for category Devices in sidebar tutorialSidebar" + }, + "sidebar.tutorialSidebar.category.Supernode": { + "message": "Supernode", + "description": "The label for category Supernode in sidebar tutorialSidebar" + } +} \ No newline at end of file diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/api/intro.md b/i18n/ko/docusaurus-plugin-content-docs/current/api/intro.md new file mode 100644 index 0000000..ab0d5c0 --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-docs/current/api/intro.md @@ -0,0 +1,7 @@ +--- +title: Introduction +sidebar_position: 1 +--- + +# MXC API +Public Access API \ No newline at end of file diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/datadash/_category_.json b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/datadash/_category_.json new file mode 100644 index 0000000..96eea63 --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/datadash/_category_.json @@ -0,0 +1,4 @@ +{ + "label": "DataDash", + "position": 6 +} diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/datadash/beta.md b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/datadash/beta.md new file mode 100644 index 0000000..70fd43e --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/datadash/beta.md @@ -0,0 +1,20 @@ +--- +sidebar_position: 2 +title: DataDash Beta Testing +--- + +# DataDash Ongoing Beta +At the moment we have an open beta DataDash group for both iOS and Android. We consider this a semi-closed beta because we require participants to join our beta discord channels. This is key for discussions among participants, and provides us with an easy way to interact with beta participants. + + +To participate as a beta tester follow the following steps: +1. Join our [Discord Community](https://mxc.news/discord) +1. Use the #bot-talk channel to send one of the following commands: + * `!role ios` + * `!role android` +1. You will then see a new channel in the `development` category. Follow the steps outlined at the top of the channel to join your selected test group. + +## DataDash Closed Beta +Before a major release, we will do a call for closed beta participants. This will have a limited number of available seats per operating system, and will only be available to current beta testers who actively submit feedback. + +Closed betas will provide users access to new and unreleased features that require a major backend change. Because of this, each participant will receive a test account on a "fake" supernode to work with. \ No newline at end of file diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/datadash/bugs.md b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/datadash/bugs.md new file mode 100644 index 0000000..01e11de --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/datadash/bugs.md @@ -0,0 +1,19 @@ +--- +sidebar_position: 2 +title: Reporting Bugs +--- + +# How to report DataDash Bugs + +The DataDash app codebase is [Publicly available on GitHub](https://github.com/mxc-foundation/supernode-app). Therefore the best way to submit a DataDash bug, is directly as a [GitHub issue](https://github.com/mxc-foundation/supernode-app/issues). + +Please include the following information in your bug report: + +* What is the problem? +* What is the expected behavior? +* Mark the issue with the appropriate labels: + * `bug` + * `ios` or `android` +* Provide any additional information, screenshots, or videos you believe might be helpful. + +**GitHub Issues are public! Do not share any personal or identifiable information. If you believe the issue is specific to you, it should be submitted as a support ticket to [support@mxc.org](mailto:support.mxc.org).** diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/datadash/intro.md b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/datadash/intro.md new file mode 100644 index 0000000..5df58e1 --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/datadash/intro.md @@ -0,0 +1,35 @@ +--- +sidebar_position: 1 +title: Intro +--- + +# Introducing the DataDash App + +Our DataDash app has the following core functionality: +* LPWAN Functionality + * M2 Pro Miner + * Register + * Manage Miner Health + * MXProtocol enabled devices (coming soon) + * Register + * View live data frames + * Generate MQTT credentials (for external data management tools) +* Token Management + * MXC M2M Wallet + * DHX Wallet + * BTC Wallet (Withdrawals Only) + + +## Downloading the DataDash App + +You can get the DataDash app at the following locations: + +**Android** +* [Google Play Store](https://play.google.com/store/apps/details?id=com.mxc.smartcity) +* [APK Download](https://datadash.oss-accelerate.aliyuncs.com/app-prod-release.apk) + +**iOS** +* [App Store](https://apps.apple.com/us/app/datadash-app/id1509218470) + +## Participating with DataDash Development +Our DataDash app is [open on GitHub](https://github.com/mxc-foundation/supernode-app) and anyone is welcome to participate in its improvement. To participate, clone the repo, and then tackle a [GitHub issue](https://github.com/mxc-foundation/supernode-app/issues). When you think you've solved it, submit a pull request for our team to review. Before getting started, take a look at the rules [here](https://github.com/mxc-foundation/supernode-app/blob/master/RETHINK.md). \ No newline at end of file diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/devices/_category_.json b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/devices/_category_.json new file mode 100644 index 0000000..e6288dd --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/devices/_category_.json @@ -0,0 +1,4 @@ +{ + "label": "Devices", + "position": 3 +} diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/devices/integrations.md b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/devices/integrations.md new file mode 100644 index 0000000..cbeabdb --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/devices/integrations.md @@ -0,0 +1,221 @@ +--- +sidebar_position: 3 +title: Integrations +--- + +# Device Integrations + +By default supernode provides MQTT broker service for users to subscribe or pushlish events on their devices. + +Users can subscribe to MQTT broker under topics in the servers after authentication. Before that, you need to make sure you have mosquitto package installed. Use the package manager apt to install these dependencies on the Ubuntu 18.04 LTS server: + +``` +sudo apt-add-repository ppa:mosquitto-dev/mosquitto-ppa +sudo apt-get update +sudo apt install mosquitto mosquitto-clients +``` + +## Subscription + +You can either subscribe to the broker in your console or you can use package for Subscription inside your program. + +A template of subscribing to the topic: + +```shell +mosquitto_sub -h {{ .SUPERNODE_URL }} -p 8883 -t '{{ .EVENT_TOPIC_STRING }}' -v -u '{{ .USER_MQTT_AUTH_JWT }}' -P 'default' -i '`hostname`-$$' --capath /etc/ssl/certs +``` + +### How to get `{{ .SUPERNODE_URL }}` + +`{{ .SUPERNODE_URL }}` is the URL of supernode where you registered your devices: + +- matchx EU `lora.supernode.matchx.io` +- matchx US `ussn.matchx.io` +- hHuaweikeji `lora.hunanhuaweikeji.com` +- mxcxy `mxcxy.com` +- k-supernode `k-supernode.com` +- enlink `lora.rosanetworks.com` +- du-capital `supernode.iot-ducapital.net` + +### How to get `{{ .EVENT_TOPIC_STRING }}` + +1. Get JWT for supernode user account, in the following content, we call it `{{ .SUPERNODE_JWT }}` + +`{{ .SUPERNODE_JWT }}` will be used for authenticate your further requests. + +Call + +```shell +curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' -d '{ "password": "{{ .SUPERNODE_PASSWORD }}", "username": "{{ .SUPERNODE_USERNAME }}"}' 'https://{{ .SUPERNODE_URL }}/api/internal/login' +``` + +Response + +```json +{ + "jwt": "{{ .SUPERNODE_JWT }}", + "is2faRequired": false +} +``` + +2. Get organization list + +`{{ .ORG_ID }}` is important parameter for your further requests. + +Call + +```shell +curl -X GET --header 'Accept: application/json' --header 'Grpc-Metadata-Authorization: Bearer {{ .SUPERNODE_JWT }}' 'https://{{ .SUPERNODE_URL }}/api/organizations?limit=999&offset=0' +``` + +Response + +```json +{ + "totalCount": "1", + "result": [ + { + "id": "{{ .ORG_ID }}", + "name": "Your Organization Name", + "displayName": "Your Organization Display Name", + "canHaveGateways": true, + "createdAt": "2020-04-22T09:53:38.928940Z", + "updatedAt": "2021-05-12T12:50:02.391191Z" + } + ] +} +``` + +3. Get application list with given `{{ .ORG_ID }}` + +Call + +```shell +curl -X GET --header 'Accept: application/json' --header 'Grpc-Metadata-Authorization: Bearer {{ .SUPERNODE_JWT }}' 'https://{{ .SUPERNODE_URL }}/api/applications?limit=999&offset=0&organizationID={{ .ORG_ID }}' +``` + +Response + +```json +{ + "totalCount": "1", + "result": [ + { + "id": "{{ .APPLICATION_ID }}", + "name": "Your application name", + "description": "description", + "organizationID": "{{ .ORG_ID }}", + "serviceProfileID": "service profile id", + "serviceProfileName": "service proile name" + } + ] +} +``` + +4. Get `{{ .EVENT_TOPIC_STRING }}` for subscribing to all devices' events under same application + +Call + +```shell +curl -X GET --header 'Accept: application/json' --header 'Grpc-Metadata-Authorization: Bearer {{ .SUPERNODE_JWT }}' 'https://{{ .SUPERNODE_URL }}/api/mosquitto-auth/subscribe-application-events?applicationId={{ .APPLICATION_ID }}&organizationId={{ .ORG_ID }}' +``` + +Response + +```json +{ + "topic": "Topic for subscribing to application {{ .APPLICATION_ID }}: 'application/{{ .APPLICATION_ID }}/device/+/event/+'" +} +``` + +5. Get `{{ .EVENT_TOPIC_STRING }}` for subscribing to events with given {{ .DEV_EUI }} and {{ .ORG_ID }} + +Call + +```shell +curl -X GET --header 'Accept: application/json' --header 'Grpc-Metadata-Authorization: Bearer {{ .SUPERNODE_JWT }}' 'https://{{ .SUPERNODE_URL }}/api/mosquitto-auth/subscribe-device-events?devEui={{ .DEV_EUI }}&organizationId={{ .ORG_ID }}' + +``` + +Response + +```json +{ + "topic": [ + "Topic for subscribing to device {{ .DEV_EUI }} on event up: 'application/{{ .APPLICATION_ID }}/device/{{ .DEV_EUI }}/event/up'", + "Topic for subscribing to device {{ .DEV_EUI }} on event join: 'application/{{ .APPLICATION_ID }}/device/{{ .DEV_EUI }}/event/join'", + "Topic for subscribing to device {{ .DEV_EUI }} on event ack: 'application/{{ .APPLICATION_ID }}/device/{{ .DEV_EUI }}/event/ack'", + "Topic for subscribing to device {{ .DEV_EUI }} on event error: 'application/{{ .APPLICATION_ID }}/device/{{ .DEV_EUI }}/event/error'", + "Topic for subscribing to device {{ .DEV_EUI }} on event status: 'application/{{ .APPLICATION_ID }}/device/{{ .DEV_EUI }}/event/status'", + "Topic for subscribing to device {{ .DEV_EUI }} on event location: 'application/{{ .APPLICATION_ID }}/device/{{ .DEV_EUI }}/event/location'", + "Topic for subscribing to device {{ .DEV_EUI }} on event txack: 'application/{{ .APPLICATION_ID }}/device/{{ .DEV_EUI }}/event/txack'", + "Topic for subscribing to device {{ .DEV_EUI }} on all events: 'application/{{ .APPLICATION_ID }}/device/{{ .DEV_EUI }}/event/+'" + ] +} +``` + +### How to get `{{ .USER_MQTT_AUTH_JWT }}` + +Call + +```shell +curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'Grpc-Metadata-Authorization: Bearer {{ .SUPERNODE_JWT }}' -d '{ "organizationId": "{{ .ORG_ID }}", "ttlInSeconds": "{{ .TIME_TO_LIVE_IN_SECONDS }}"}' 'https://{{ .SUPERNODE_URL }}/api/mosquitto-auth/login' +``` + +Response + +```json +{ + "jwtMqttAuth": "{{ .USER_MQTT_AUTH_JWT }}" +} +``` + +## Publishing + +A template of publishing with mosquitto_pub looks as this: + +```shell +mosquitto_pub -h {{ .SUPERNODE_URL }} -p 8883 -u '{{ .USER_MQTT_AUTH_JWT }}' -P 'default' -i '`hostname`-$$' -t '{{ .COMMAND_TOPIC_STRING }}' -m '{{ .MESSAGE }}' --capath /etc/ssl/certs + +``` + +### How to get `{{ .COMMAND_TOPIC_STRING }}` + +Call + +```shell +curl -X GET --header 'Accept: application/json' --header 'Grpc-Metadata-Authorization: Bearer {{ .SUPERNODE_JWT }}' 'https://{{ .SUPERNODE_URL }}/api/mosquitto-auth/send-command?devEui={{ .DEV_EUI }}&organizationId={{ .ORG_ID }}' +``` + +Response + +```json +{ + "topic": "Topic for publishing to device {{ .DEV_EUI }}: 'application/{{ .APPLICATION_ID }}/device/{{ .DEV_EUI }}/command/down'" +} +``` + +### How to get `{{ .MESSAGE }}` + +The message format should be as follow: + +```json +{ + "confirmed": true, + "fPort": 10, + "data": "....", + "object": { + "temperatureSensor": { + "1": 25 + }, + "humiditySensor": { + "1": 32 + } + } +} +``` + +- `confirmed`: whether the payload must be sent as confirmed data down or not +- `fPort`: FPort to use (must be > 0) +- `data`: base64 encoded data (plaintext, will be encrypted by Network Server) +- `object`: decoded object (when application codec has been configured), when providing the 'object', you can omit ' data' diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/devices/intro.md b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/devices/intro.md new file mode 100644 index 0000000..b0dafc2 --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/devices/intro.md @@ -0,0 +1,6 @@ +--- +sidebar_position: 1 +title: Introduction +--- + +# MXProtocol Enabled Devices \ No newline at end of file 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.
0: Low or OFF, 1: High or ON, -1 Unknown or Invalid. | +| 20 (0x14) | percent | 1 | A generic value in percent. | +| 21 (0x15) | powerFactor | 2 or 4 | Power factor for AC power system.
Value range from 0 to 1. | +| 254 (0xfe) | uplinkPower | 1 | Exact value of TX Power in dBm. | + + + +#### GPS data format + +When data length is 1 + +| Offset | Length | Description | +| ------ | ------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 0 | 1 | Indicates whether the node has moved since last GPS fix. Possible values are:
    0: Node is stable since last GPS fix
    1: Node has moved, or has not received a GPS fix since boot; waiting for GPS fix | + +When data length is 11 + +| Offset | Length | Description | +| ------ | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 0 | 1 | $GPGGA Position Fix Indicator. Possible values are:
* 0 Fix not available or invalid
* 1 GPS SPS Mode, fix valid
* 2 Differential GPS, SPS Mode, fix valid
* 6 Dead Reckoning Mode, fix valid | +| 1 | 4 | Latitude in 1/1000 of minutes, as little-endian int32. Positive is north, negative is south. To get the value in degrees, divide by 600000. | +| 5 | 4 | Longitude in 1/1000 of minutes, as little-endian int32. Positive is east, negative is west. To get the value in degrees, divide by 600000. | +| 9 | 2 | Altitude above geoid mean sea level in decimeters (0.1m), as little-endian int16. | + + + +#### Data format for 1 byte value + +It is a signed 8-bits integer (int8_t), giving the range between -128 and +127. + +```javascript +// Decoding +if (offset_0 > 0x7f) { + value = ((offset_0 ^ 0xff) + 1) * -1; +} +else { + value = offset_0; +} +``` + + + +#### Data format for 2 bytes value + +It is a signed 16-bits fixed point number. Offset 0 is the sign bit and integer part. Offset 1 is the fractional part. + +```javascript +// Decoding in Javascript +let raw_value = (offset_0 << 8) | offset_1; +if (raw_value > 0x7fff) { + value = ((raw_value ^ 0xffff) + 1) * -1; +} +else { + value = raw_value; +} +value = value / 256; +``` + + + +#### Data format for 4 bytes value + +It is a 32-bits floating point number (IEEE 754). Offset 0 is the MSB. + +For example, a value of 54.12 will has a 32-bits value of 0x42587ae1. + +The payload will become <0x42><0x58><0x7a><0xe1>. + +```javascript +// Decoding in Javascript +let raw_value = (offset_0 << 24) | (offset_1 << 16) | (offset_2 << 8) | offset_3; +let v_temp = new DataView(new ArrayBuffer(4)) +v_temp.setUint32(0, raw_value) +value = v_temp.getFloat32(0) +``` + + + +The NAN (Not A Number) (0x7fc00000), means the sensor value is unknown or invalid. + + + +### Event Data + +Event data is information about change that occurs at a point in time. A event will contain the type value and additional event data. + +| Number | Name | Length | Description | +| --------- | ------------- | ------ | ------------------------------------------------------------------ | +| 0 (0x00) | unknown | 0 | No data. | +| 11 (0x0b) | opened | 1 | The unit is opened by a user. Data is the user ID. | +| 12 (0x0c) | specialOpened | 0 | The unit is opened in a special way. For example, a key or button. | +| 13 (0x0d) | forceOpened | 0 | The unit is opened in a abnormal way. | + + + +## Downlink Payload Data Format + +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 | Get params | 1 | Get parameter described by first byte. | +| 1 | Set params | >=2 | Set parameter described by first byte to the value specified in the rest of the message. | +| 2 | Reboot | 0 | Reboot the node immediately. | +| 3 | Reboot/upgrade | 1 | Reboot the node after the specified timeout; optionally turn BLE and SUOTA on for upgrades. The argument is as follows:bit [7]:0: just reboot1: BLE onbits [6:3]: Reservedbits [2:0]: Timeout0: TBD1: 5 minutes2: 15 minutes3: 30 minutes4: 1 hour5: 2 hours6: 4 hours7: TBD | +| 4 | Set Controls | \>=1 | Set a value to the control. For example, turn on/off a digital output. | + + + +### Parameters + +| Number | Name | Length | Description | +| ------ | ------- | ------ | ------------------------------------------------------------------------- | +| 0 | deveui | 6 | DevEUI-48 and BLE MAC address (MSBF)
Only for DevKit. Please don't use it at final product. | +| 1 | appeui | 8 | AppEUI-64 (MSBF)
Only for DevKit. Please don't use it at final product. | +| 2 | appkey | 16 | AppKey (write-only)
Only for DevKit. Please don't use it at final product. | +| 3 | period | 1 | Sensor period | +| 4 | sf | 1 | Minimal LoRa Spread Factor (valid values: 7-12) | +| 5 | version | 2 | Version number.
01 00 => V1.0 | + +Parameters 0, 1, 2 and 4 are actualized after reboot. + +Sensor period is as follows: + +| Number | Period | +| ------ | -------- | +| 0 | Default | +| 1 | 10 sec | +| 2 | 30 sec | +| 3 | 1 min | +| 4 | 2 min | +| 5 | 5 min | +| 6 | 10 min | +| 7 | 30 min | +| 8 | 1 hour | +| 9 | 2 hours | +| 10 | 5 hours | +| 11 | 12 hours | + + + +### Controls + +Controls are used for the user to change a value or state of the device. The control data consists of a byte signifying the data type, and zero or more bytes of the data. The defined types and corresponding data formats are: + +| Number | Name | Length | Description | +| --------- | ------- | ------ | ----------------------------------------------------------------- | +| 0 (0x00) | unknown | 0 | No data. | +| 19 (0x13) | digital | 1 | A generic digital value.
0: Low or OFF, 1: High or ON. | +| 20 (0x14) | percent | 1 | A generic value in percent. | diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/devices/provisioning.md b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/devices/provisioning.md new file mode 100644 index 0000000..f608ab2 --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/devices/provisioning.md @@ -0,0 +1,5 @@ +--- +sidebar_position: 2 +--- + +# Device Provisioning \ No newline at end of file diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/devices/provisioning.mdx b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/devices/provisioning.mdx new file mode 100644 index 0000000..b56498c --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/devices/provisioning.mdx @@ -0,0 +1,514 @@ +--- +sidebar_position: 4 +sidebar_label: Device Provisioning +--- + +# Device Provisioning + +## What is Device Provisioning? + +Device Provisioning is a process of exchanging sensitive information between a device and a server. This process will store the encryption keys required for LoRaWAN communication on the device and the server. The whole process will be completed through LoRa communication. Therefore, no additional hardware is required on the device. + +In terms of security, Elliptic-curve Diffie-Hellman is used as the key exchange, which enables subsequent sensitive data to be exchanged between the device and the server in a secure manner. + + +## What is the advantage of it? + +With the provisioning is done and the key is ready on both server and device. The operation on the user side will become simple. The user needs only a few steps to register the device to the system. He/She just needs to use our DataDash mobile APP to scan the QR-code label on the device. Then enter a few more information about the device, such as name. After that the device will start to join the network. The user didn’t need to enter any keys that the traditional way needs. During production no keys need to be sent to the assembly house, further improving the security by preventing unwanted compromise of the keys by the 3rd party. + + +## What about the QR-code label? + +The QR-code label stored the identity of the device. There is no sensitive information on it, just an ID code (called Provision ID). A minimal label just needs the Provision ID. The mobile APP will use this Provision ID to register the device to the system. It is a secure way to do the task which no encryption keys content appears during the whole process. + +Here is an example of a minimal label. + + + + + + + +
+ alt_text + PID:PROVISIONIDOOOOOOOOO
+ +For a big device that has more space for the label, a long version label could be used to store more information. + + + + + + +
+ lora provisioning label +
+ +``` +{ + "PROVID": "PROVISIONIDOOOOOOOOO", + "BRAND": "MatchX", + "MODEL": "MX1234", + "SN": "S123456" +} + +``` + + +## What device developer needs to do? + +The firmware needs to implement the flow device provisioning. It is a two steps process and needs to be done for a new produced device. The details of this process is listed on the later part of this document. + +During the device provisioning, it required the Provision ID to identify the device. We suggest the device firmware add an interface to let the manufacturer set this information at the end of the quality assurance (QA) procedure. + +An example method is to use a UART interface to program the information. Our example device uses an “AT” command to achieve this. But any other serial protocol should be fine. + + +![alt_text](/img/provisioning/lora-provisioning-stack.png "image_tooltip") + + +## What device manufacturer needs to do? + +To successfully provision a device, it required the information of Provision ID. The manufacturer needs to request it from us, MatchX. We will prepare a spreadsheet that has the assigned Provision ID and related information for the manufacturer. The Manufacturer needs to make sure the information is set to the device with the correct matched QR-Code label. + +We suggest the manufacturer to add an extra step at their quality assurance (QA) procedure. The step included setting the Provision ID to the device with a matched QR-Code label. Then verify the device is being provisioned, that means it exchanged key information with the server. + + +![alt_text](/img/provisioning/lora-provisioning-steps.png "image_tooltip") + + + + + +## Device Provisioning Implementation Details + +Source code of our example device: TBD + + +### Provision ID + +The Provision ID is a unique string for each device. During the provisioning, it is used as an identity at the provisioning server to access the device information. The Provision ID is 20 characters long and uses the RFC4648 Base32 alphabet. + + +### Hash of Provision ID + +It is the result of the SHA256 hash on the Provision ID. The device provisioning process uses this value when doing authentication with the server. To minimize the complexity of the device implementation, we suggest the device also store this value to its FLASH, instead of calculating it by itself. + + +``` +provisionIdHash = SHA256(provisionId | '.MatchX') +``` + + +For example: + + +``` +PID = 'TESTPIDOOOOOOOOOOOOO' +HASH = 'c8c7564b46b91c91ef6c4f37bcca8cf7e81baac6eb869dcc62e5fafdd0242497' +``` + + + +### Message integrity code (MIC) + +The message integrity code (MIC) value at LoRa PHYPayload for HELLO and AUTH messages is calculated as below. + + +``` +FixedKey[] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, +0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f}; + +cmac = aes128_cmac(FixedKey, message) +MIC = cmac[0..3] +``` + + +### Verification Code + +The verification code is used when the device authenticates with the server. The calculation is shown below. + + +``` + FixedKey[] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, + 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f}; + + cal_buf = provisionId + nonce; + verifyCode = aes128_cmac(FixedKey, cal_buf) +``` + +Example: + + +``` +// Input + privisionid = "SERIALNUMBEROOOOOOOO"; + servernonce = {0x01, 0x02, 0x03, 0x04}; + +// Output + verifyCode = {0x2E, 0x69, 0xBB, 0x5E, 0xD7, 0x8B, 0x5E, 0xE8, + 0x0C, 0x6A, 0x8A, 0xDC, 0x81, 0x91, 0xDD, 0xF8}; +``` + + + +### AES + +The encryption scheme used in aes128_encrypt() and aes128_cmac() are the same as LoRaWAN specification. This approach will minimize the need for extra code on the device side. + + +### LoRa + +The device provisioning using the “Proprietary” LoRa frame for communication, it means the MType on MHDR is set to ‘111’. + +The receiving windows using RX1 and delay is 5s. + +Data Rate: + + + + + + + + + + + + + + + + + + + + + + + +
Region + Data Rate + Configuration +
EU868 + 3 + Up and Down: SF9 / 125 kHz +
US915 + 3 + Up: SF7 / 125 kHz +

+ Down: SF7 / 500 kHz +

+
CN470 + 3 + Up and Down: SF9 / 125 kHz +
+ +### Sequence Diagram + +The device provisioning has two steps. First, it is a ECDH key exchange process, called “Hello” by us. The device and the server will exchange their public key on this step. Then the next step is the authentication. The device will submit its hashed Provision ID to the server. If it is a valid ID on the server, the server will accept the request and send back the EUI information. + +The keys used for LoRaWAN OTAA are derived from the ECDH shared key. All this information will not appear on the communication message. + +![alt_text](/img/provisioning/lora-device-provisioning-sequence.png "image_tooltip") + + +### Message format + +The messages shown below are the content of the MACPayload of the Proprietary MAC message of LoRaWAN. + +LoRaWAN PHYPayload: + + + + + + + + +
MHDR + MACPayload +

+ (Hello / Auth) +

+ 		MIC +
+ +##### Hello message + + +``` + | Type | rDevEUI | devPubKey | version | + | 0x01 | 8 bytes | 64 bytes | 1 byte | +``` + + + +##### Hello response + + +``` + | Type | rDevEUI | serverPubKey | serverNonce | + | 0x81 | 8 bytes | 64 bytes | 4 bytes | +``` + + + +##### Auth request + + +``` + | Type | rDevEUI | Encrypted Payload | + | 0x11 | 8 bytes | 52 bytes | + + | provisionIdHash | verifyCode | devNonce | + | 32 bytes | 16 bytes | 4 bytes | +``` + + + +##### Auth accepted + + +``` + | Type | rDevEUI | Encrypted Payload | + | 0x91 | 8 bytes | 32 bytes | + ​ + | devEUI | appEUI | verifyCode | + | 8 bytes | 8 bytes | 16 bytes | +``` + + + +##### Auth rejected + + +``` + | Type | rDevEUI | + | 0x92 | 8 bytes | +``` + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
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. + + + + + +![alt_text](/img/provisioning/lora-provisioning-spreadsheet-view.png "image_tooltip") + + +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. + + +![alt_text](/img/provisioning/device-provisioning-report.png "image_tooltip") + + +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 +``` + + + + + + +![alt_text](/img/provisioning/lora-provisioning-spreadsheet-view-1.png "image_tooltip") + diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/dhx/_category_.json b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/dhx/_category_.json new file mode 100644 index 0000000..6f5f53d --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/dhx/_category_.json @@ -0,0 +1,4 @@ +{ + "label": "Mining DHX", + "position": 4 +} diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/dhx/intro.md b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/dhx/intro.md new file mode 100644 index 0000000..18d2c90 --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/dhx/intro.md @@ -0,0 +1 @@ +# What is DHX \ No newline at end of file diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/intro.md b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/intro.md new file mode 100644 index 0000000..5e1be6f --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/intro.md @@ -0,0 +1,51 @@ +--- +title: Introduction +sidebar_position: 1 +--- + +# Introduction + +There are a number of ways for developers to interact with the MXC ecosystem. These forms of participation are integral to the further development and deployment of the MXProtocol. + +## Direct Participation + +### Beta Testing +Beta testing new features before they are released is a great way to help us improve the overall user experience with our products. Here are beta opportunities currently available: + +| Product | Beta Type | How to Participate | +| --------------- | --------- | ------------------------------------------ | +| DataDash | Closed | [Instructions](tutorials/datadash/beta.md) | +| MXC Controller | Closed | *Coming Soon* | +| M2 Pro (MatchX) | Open | *Coming Soon* | + +*A beta version is pre-release and considered unstable. This means that you may experience some issues. Normally these will be minimal, however participating in an M2 Pro beta could potentially affect your mining. MXC Controller and DataDash betas will not have any influence on your overall mining potential.* + + +### Coding and Translating +We have a number of public repos with active issues that could use assistance. Our team is still growing, and community support is always appreciated, encouraged and in some cases rewarded. + +Here is an updated list of repos that could use assistance. +* [DataDash App](https://github.com/mxc-foundation/supernode-app) [Flutter / Dart] + * [Translate the DataDash](https://crowdin.com/project/mxc-mobile-app) +* [Developer Documentation](https://github.com/mxc-foundation/developer-documentation) [Markdown, Javascript] + * [Translate the Docs Today](https://crowdin.com/project/mxc-documentation) + +We will continue to add repositories to this list as we work to increase transparency with our code and development process. + +## Manufacturing / Configuring Devices +Without devices the network has no purpose. Therefore, we've created an easy way for manufacturers to get involved with the network, making it possible for their devices to be deployed as a turnkey solution in the MXC ecosystem. + +In order to increase security of the entire network, we've worked with MatchX to develop a novel provisioning concept for LoRa devices. This provisioning process is a requirement for any devices intending to be MXProtocol compatible. We have made this decision as: +1. Device provisioning increases the security of the device data +1. Users will be able to deploy devices without any additional hassle +1. Improve device data integration and compatibility + +You can discover more about device provisioning for the MXProtocol in Devices. + +## Reporting Issues +Even though we attempt to do rigorous QA before every release, some pesky bugs still slip through. Actively reporting bugs is an extremely important form of participation, and helps us to improve the stability of the entire network. + +You can report bugs in the #bugs channel in our [Discord Server](https://mxc.news/discord) + +Bugs can also be reported directly as issues in the relevant GitHub Repo: +* [DataDash App Bugs](https://github.com/mxc-foundation/supernode-app/issues) \ No newline at end of file diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/m2-pro/_category_.json b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/m2-pro/_category_.json new file mode 100644 index 0000000..c3a9dcb --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/m2-pro/_category_.json @@ -0,0 +1,4 @@ +{ + "label": "M2 Pro Miner", + "position": 2 +} diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/m2-pro/gui.md b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/m2-pro/gui.md new file mode 100644 index 0000000..ab0362b --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/m2-pro/gui.md @@ -0,0 +1,5 @@ +--- +sidebar_position: 3 +--- + +# Web GUI \ No newline at end of file diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/m2-pro/intro.md b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/m2-pro/intro.md new file mode 100644 index 0000000..aa259e4 --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/m2-pro/intro.md @@ -0,0 +1,6 @@ +--- +title: Introduction +sidebar_position: 1 +--- + +# The M2 Pro Miner \ No newline at end of file diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/m2-pro/miner-health.md b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/m2-pro/miner-health.md new file mode 100644 index 0000000..8b65ad3 --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/m2-pro/miner-health.md @@ -0,0 +1,5 @@ +--- +sidebar_position: 4 +--- + +# Miner Health 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. diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/m2-pro/setup.md b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/m2-pro/setup.md new file mode 100644 index 0000000..e65e163 --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/m2-pro/setup.md @@ -0,0 +1,5 @@ +--- +sidebar_position: 2 +--- + +# Setup \ No newline at end of file diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/m2-pro/troubleshooting.md b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/m2-pro/troubleshooting.md new file mode 100644 index 0000000..a397b99 --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/m2-pro/troubleshooting.md @@ -0,0 +1,67 @@ +--- +sidebar_position: 5 +--- + +# Troubleshooting +Experiencing a problem with your M2 Pro? This tutorial will help you find it. Naturally you can also ask for help in one of our communities, or reach out for manufacturer support by writing [support@matchx.io](mailto:support@matchx.io). + +## Connectivity (uptime) +If your uptime is taking a hit, there's an easy way to find out if the miner is at fault, or your local network connection. To do that follow the following steps: +### 1. Access the M2 Pro Miner web interface +You can find the interface here: `http://yourSerialNumber.local` + * Your computer or phone must be on the same network as the M2 Pro Miner + * This URL works only on iOS, Win10 and Linux. It doesn't work on Android. +``` +Username: admin +Password: your serial number using all caps +``` + + + +### 2. View the miner logs: +1. After logging in, you can view or download your logs by clicking on `SysLog` in the menu ![log file structure](/img/troubleshooting/sysLog.png) + * If you're having an ongoing issue, you may want to download your logs regularly. The miner can only store logs for the past 48 hours, so if additional troubleshooting is needed, you should download your logs once every two days. +### 3. Reading the logs + +First step is to check if offline is happening due to failed heartbeat. Use the search/find function (ctl+f, cmd+f) and type in the word failure to see any failed heartbeat. + +This is the example of a successful heartbeat session. + ``` + Jun 29 04:58:09 M2XLCTRM3ZW daemon.info gwconfd[619]: Received hb response: fw conf + ``` +Here is an example of a failed heartbeat session. + +``` +Jun 29 04:56:07 M2XLCTRM3ZW daemon.err gwconfd[619]: Heartbeat api failure:4: Deadline Exceeded +``` +A failed heartbeat can happen due to many reason but the most common reason is an unstable network connection. To rule this out, you need to check if the internet connection is good. + +These are the list of common errors which indicates unstable, loss or bad internet connection. +1. Connectivity error from network issue +``` +Jun 24 06:49:53 M2XLCTRM3ZW daemon.err tlsDaemon[606]: Setup TLS error: TCP Connection error. +``` + +2. Unstable/dropping WiFi connection +``` +Jun 17 07:25:29 M2XLCTRM3ZW user.info kernel: CFG80211-ERROR) wl_is_linkdown : Link down Reason : WLC_E_LINK +``` +3. Internet connection loss +``` +Jun 13 15:05:50 M2XLCTRM3ZW daemon.info netMgmtDaemon[614]: Internet connection loss +``` + +In most cases, the issue is related to unstable internet connection at user's end and the miner is working fine (not a hardware issue). + +To isolate this further, you can try the following: +* If the miner is connected using wireless connection – try using wired connection. +* If wired connection is not possible – move the miner closer to the router as see if the uptime improves +* If both still not solving the issue - try putting the miner on a different network (such as, at friend's home). If the miner is working fine on another network, the issue is related to your home network connection. + +### 4. Checking LoRa Connectivity [in the LoRa Log menu option] +For LoRa, when you see that a miner is offline you can check on the Last Seen. This is pretty straight forward as you just need to search these two lines. If you get PUSH_ACK, that means it is fine. +``` +[2021-06-17 08:58:48.437] [loraMgmtDaemon] [info] INFO: [up] PUSH_ACK received in 43 ms +``` +This message is sent every 30 seconds. + diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/supernode/_category_.json b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/supernode/_category_.json new file mode 100644 index 0000000..9cffdf1 --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/supernode/_category_.json @@ -0,0 +1,4 @@ +{ + "label": "Supernode", + "position": 4 +} diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/supernode/intro.md b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/supernode/intro.md new file mode 100644 index 0000000..3414fdc --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-docs/current/tutorials/supernode/intro.md @@ -0,0 +1,6 @@ +--- +sidebar_position: 1 +title: Introduction +--- + +# Introducing Supernodes \ No newline at end of file diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/images/fig1_lpwan_comparison.png b/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/images/fig1_lpwan_comparison.png new file mode 100644 index 0000000..b481449 Binary files /dev/null and b/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/images/fig1_lpwan_comparison.png differ diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/images/fig2_dataflow.png b/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/images/fig2_dataflow.png new file mode 100644 index 0000000..e223f70 Binary files /dev/null and b/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/images/fig2_dataflow.png differ diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/images/fig3_MXProtocol_stack.png b/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/images/fig3_MXProtocol_stack.png new file mode 100644 index 0000000..e0e3584 Binary files /dev/null and b/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/images/fig3_MXProtocol_stack.png differ diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/images/fig4_mxp_smart_bidding.png b/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/images/fig4_mxp_smart_bidding.png new file mode 100644 index 0000000..067516d Binary files /dev/null and b/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/images/fig4_mxp_smart_bidding.png differ diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/images/fig5_anti_collision_coordinator.png b/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/images/fig5_anti_collision_coordinator.png new file mode 100644 index 0000000..2249468 Binary files /dev/null and b/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/images/fig5_anti_collision_coordinator.png differ diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/images/fig6_anti_collision_integration.png b/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/images/fig6_anti_collision_integration.png new file mode 100644 index 0000000..0523fca Binary files /dev/null and b/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/images/fig6_anti_collision_integration.png differ diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/images/fig7_inter_chain_market.png b/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/images/fig7_inter_chain_market.png new file mode 100644 index 0000000..a062843 Binary files /dev/null and b/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/images/fig7_inter_chain_market.png differ diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/images/fig8_LPWAN.png b/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/images/fig8_LPWAN.png new file mode 100644 index 0000000..48e0618 Binary files /dev/null and b/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/images/fig8_LPWAN.png differ diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/intro.md b/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/intro.md new file mode 100644 index 0000000..adeb6a8 --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/intro.md @@ -0,0 +1,8 @@ +--- +title: Introduction +sidebar_position: 1 +--- + +# MXC Whitepapers + +Overview of the WhitePapers \ No newline at end of file diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/mxc-data-economy.md b/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/mxc-data-economy.md new file mode 100644 index 0000000..7bcfc32 --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/mxc-data-economy.md @@ -0,0 +1,6 @@ +--- +title: MXC Data Economy +sidebar_position: 3 +--- + +# MXC Data Economy \ No newline at end of file diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/mxprotocol.md b/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/mxprotocol.md new file mode 100644 index 0000000..b9c416b --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/mxprotocol.md @@ -0,0 +1,513 @@ +--- +title: MXProtocol +sidebar_position: 2 +--- + +# MXProtocol (Machine eXchange Protocol): Premium Network Infrastructure, Infinite Data Stream + +## Table of Contents + +- [Machine eXchange Protocol: Premium Network Infrastructure, Infinite Data Stream](#machine-exchange-protocol-premium-network-infrastructure-infinite-data-stream) + - [1. MXC Vision](#1-mxc-vision) + - [2. Background](#2-background) + - [2.1 LPWAN vs other technologies](#21-lpwan-vs-other-technologies) + - [2.1.1 LoRaWAN](#211-lorawan) + - [2.1.2 NB-IoT](#212-nb-iot) + - [2.1.3 Deployment considerations](#213-deployment-considerations) + - [MXC economy](#mxc-economy) + - [3.1 Commerce network effect](#31-commerce-network-effect) + - [3.2 Asset-Backed Securitization](#32-asset-backed-securitization) + - [3.3 Data bloom](#33-data-bloom) + - [3.3.1 MXC-assisted garbage collection](#331-mxc-assisted-garbage-collection) + - [3.3.2 MXC-assisted car sharing](#332-mxc-assisted-car-sharing) + - [4. MXProtocol stack](#4-mxprotocol-stack) + - [4.1 Permissionless Blockchain](#41-permissionless-blockchain) + - [4.1.1 Features](#411-features) + - [4.1.2 Security and efficiency](#412-security-and-efficiency) + - [4.1.3 Long-term adoptions](#413-long-term-adoptions) + - [5. Smart Bidding](#5-smart-bidding) + - [5.1 Goals of design](#51-goals-of-design) + - [5.2 Design and implementation](#52-design-and-implementation) + - [5.3 Gateway status](#53-gateway-status) + - [5.4 Smart Bidding strategy](#54-smart-bidding-strategy) + - [5.5 Sensor Smart Bidding code](#55-sensor-smart-bidding-code) + - [6. Anti-Collision Coordinator](#6-anti-collision-coordinator) + - [6.1 Goals of the design](#61-goals-of-the-design) + - [6.2 Design and implementation](#62-design-and-implementation) + - [6.3 Third party integration](#63-third-party-integration) + - [7. Inter-Chain Data Market](#7-inter-chain-data-market) + - [7.1 Goals of the design](#71-goals-of-the-design) + - [7.2 Design and implementation](#72-design-and-implementation) + - [7.3 Polkadot and Aeternity](#73-polkadot-and-aeternity) + - [8. Smart Bidding use cases](#8-smart-bidding-use-cases) + - [8.1 Downlink resource auction](#81-downlink-resource-auction) + - [8.2 Network coverage market](#82-network-coverage-market) + - [8.3 Service market](#83-service-market) + - [9. Development progress](#9-development-progress) + - [10. References](#10-references) + +## 1. MXC Vision + +> The MXC vision is to introduce a systematic process to both simplify and increase IoT data transactions. + +The decentralized infrastructure upon which MXC’s system is based is the future of Low Power Wide Access Network (LPWAN) and the Machine eXchange Protocol (MXProtocol). Utilizing this solid device network foundation, MXC is introducing an extraordinarily unique coin offering, Machine eXchange Coin (MXC), which allows for increased data transactions and an idiosyncratic data flow monetization within the mammoth data market. + +MXProtocol places a keen focus on reducing collision between networks, constructing an inter-chain data market, developing a market for network coverage and introducing an independent Quality of Services (QoS) framework for both data providers and receivers. For the first time ever, individual network users, corporations and enterprises can all participate in the construction of decentralized, ubiquitous and secure LPWAN. Simply by connecting “anything” to the network, adopters will be able to profit and trade MXC. + +The trading network is built on the premise of the “sharing economy.” Therefore, it is uniquely and exclusively owned by users — both individuals and enterprises — who take advantage of the monetization of the network in two ways: + +1. By increasing uplink and downlink coverage via a Gateway, e.g. a MatchBox LPWAN Gateway, Cisco LPWAN Gateway +2. By unleashing access to a massive network of published and traded data to the marketplace which is securely traded using blockchain technology + +Both sensors and connected devices bid (via the integrated QoS) for the downlink network resource to, for example, unlock a door or, alternatively, shut down a faulty radiator, subsequently offering a market-devised price for the uncovered regions. This ultimately increases data network coverage. “Things” can autonomously pay each other with MXC tokens and get accredited by sharing the data with different users/marketplaces. + +There has been a phenomenal increase in the sourcing, collection and transmission of big data within the past five years. Additionally, the increasing use of artificial intelligence feeding off this data has assisted people to simplify tedious tasks and to make better informed decisions on everything from projecting a weather forecast, to saving household energy, to even choosing the right music to play at home. The tone has now been set for decades to come. Machines interacting with one another has seen a significant increase over such a short period. This will only increase as our interdependency on machines and machine learning grows and becomes ever more significant in day to day life. + +Whether for individuals or big companies, the need for a specified network concentrating on machines and machine data is here to stay. It will play a bigger part in supporting both individuals and businesses than ever before. MXProtocol introduces the next generation of LPWAN with a superior IoT data platform and a premium network experience, allowing for a simplified and expedited way to create a secure and efficient solution for IoT. + +The following sections elaborate on the unique advantages of MXProtocol, including its components — permissionless blockchain, Smart Bidding, Anti-Collision Coordinator and Inter-Chain Data Market — that make it a truly innovative technology. + +## 2. Background + +MXC is a German non-profit organization based in the country’s start-up and blockchain capital, Berlin. MXC is partnering with various LPWAN companies. MXProtocol is a revolutionary design that solves the problem of LPWAN and bridges the data gap between different infrastructures. + +IoT is a hot topic that has been intently discussed for over a decade. The one focus and premise of the IoT network is connecting “things” to the Internet and collecting/using this data from the objects that can’t speak for themselves. The application of this new founded, increased data is highly limited due to the current methods offering low range and high power consumption. For example, standard WiFi can generally reach an absolute maximum of around 100 meters, and using 3G/4G consumes a significant amount of power, thus reducing effective battery life and increasing maintenance costs significantly. The fact is, current implementations for data networks are extremely expensive and offer very low usability. The need for a new technology is here and the need for LPWAN will only increase as it solves the current problems of low range/high cost data transmissions. + +The fact is, current implementations for data networks are extremely expensive and offer very low usability. The need for a new technology is here and the need for LPWAN will only increase as it solves the current problems of low range/high cost data transmissions. + + + +
+ LPWAN +
+ +### 2.1 LPWAN vs other technologies + +LPWAN technology emerged to the forefront in recent years with the goal of finding a better data transmission solution to the shortfalls of WiFi, Bluetooth and 3G & 4G networks. These earlier established networks were originally targeted at connecting people, not at connecting the data generated by “things.” The amount of machine-generated data has multiplied significantly in recent times. The new LPWAN technology offers aspects where others simply can’t compete: + +- 10 year sensor battery life +- 20 km data reach with just a single Gateway +- Offers an extreme amount of connection points (over 60,000 for a single network cell) supported by LPWAN Gateways at an extremely low cost + +Now, when compared to the current wireless network, it’s easy to see the superior advancements that the MXC solutions offer. As illustrated in Figure 1, LoRa and NB-IoT are simply the most potent solutions on the LPWAN market. + +#### 2.1.1 LoRaWAN + +LoRaWAN is an open-source protocol defined by the LoRa Alliance, which is already supported by industrial giants such as Cisco, Alibaba, Comcast, IBM and SK Telecom and many more. Advantages of LoRaWAN are 20 km open space coverage, low data rates (low-level kbps) and ultra-low power, allowing for 10 years continued operation on a single battery. + +Both the Gateways and end sensor devices use the LoRaWAN protocol. In fact, devices of any brand are supported and can be connected to the network as long as they are LoRa/LPWAN compatible. + +#### 2.1.2 NB-IoT + +NB-IoT is a narrowband radio technology specified by 3GPP as a licensed telecommuni- cation protocol. NB-IoT focuses specifically on indoor coverage, low throughput and long battery life, enabling a large number of connected devices. + +The advantage for an MXC IoT user is that it gives an individual the power to host their own network wherever and whenever they like. Compare that with the NB-IoT base stations (which are owned by telecommunications conglomerates) which charge users expensive SIM card fees to send data messages over the Internet through NB-IoT protocol. MXProtocol supports all LPWAN technologies, developed LoRaWAN Gateways, NB-IoT and LoRaWAN sensors. That’s decentralization. That’s yet another MXC advantage. + +#### 2.1.3 Deployment considerations + +When deploying LPWAN, the first consideration is understanding how to avoid a col- lision between different competing networks residing in the same region. Generally, the issue comes from the fact that both may use the same channel to send out the message at the same time and leave the other available channel empty due to the chosen preferences. As a result, it’s generally hard to reach a consensus between these networks and thus the deployment suffers as network usage increases. The decentralization and distributed mech- anism of MXProtocol solves this issue by coordinating the networks. The network evolves by having users pay micro-payments for the resources that another one offers. + +The second concern is due to the shortage of downlink resources for the dense sensor/ end device deployment. Usually there are some sensors/end devices which require no downlink or can bear with the loss of downlinks. This is usually associated with low-activity sensors, such as garbage bins or electricity meters. However, end devices like bike locks or location tracker devices need to receive regular and reliable confirmations from the cloud for every uplink. Hence, they are willing to pay a premium for this reliability and a QoS provided by the networks. MXProtocol provides this bidding resource, ensuring that, for example, a garbage bin sensor won’t take first preference over the vital downlink resource of something like a bike lock. + +Another consideration pertains to the requirements for multi-national cooperations (MNC) and small to medium enterprises (SME) trading their data assets publicly generated using LPWAN technology. Within LPWAN, both the data stream and asset trading features are simplified, easy to read and can be digitally transmitted from many kilometers away. This makes the data exchange a clear necessity for the needs of the LPWAN market of tomorrow. + +With respect to the needs of MNCs or SMEs, it’s likely that such enterprises will wish to deploy their own LPWAN to cover an entire city or a region for its own specific applica- tions such as asset tracking (e.g. automobile) or sensor data management. This is a perfect solution for “Big Business.” LPWAN technology delivers via its long reach ensuring that sensor/end device uplink packets are securely received as per the protocol design. + +This leads to one of the key aspects of the MXProtocol: bringing the monetization of data services to the forefront. Using the MXProtocol, micro-payments within the LPWAN infrastructure will be traded from third party sensors/end devices, ensuring data is conveniently, correctly and concisely transmitted in a secure manner, whilst being maintained by the support of system administrators. The industry has been waiting for a decentralized and consensus-based mechanism to improve the usability of LPWAN, and MXC is delivering. + +MXC has designed this next generation LPWAN infrastructure using MXProtocol in order to significantly boost the applications of blockchain and IoT within the real-world context. + +## MXC economy + +Machine eXchange Coin (MXC) offers a unique and specifically designed decentralized technological “Data Trade Network” to the global Token economy. Data can be shared on a mass scale whilst ensuring complete end to end privacy. The MXC intends to be distributed amongst data owners, data receivers and data network hosts, allowing for a facilitated cross-over from a “commodity” based Coin into an everyday trading Coin currency. + +### 3.1 Commerce network effect + +Machine eXchange Coin is the first Token designed to bridge current commodity-based trading of cryptocurrency tokens and the cash-based global economy. Utilizing the “sharing economy,” MXC uses this as an axis, allowing large businesses, SMEs and individuals to borrow or rent assets owned by someone else. + +Individuals place LoRa-based protocol hardware in opportune positions in order to benefit and profit from their locations and their decentralized LoRaWAN network. Businesses benefit by using these user-based networks to send sensor/device data, building a new “sharing economy.” Wallets are stored in the cloud allowing individuals to profit from businesses sending sensor data via their LoRaWAN LPWAN. The coins are then sent and traded from the sensor holders that MXProtocol addresses to the Gateway distributor. + +MXProtocol gives network participants incentives to use, deploy and trade their network elements. In addition to that, it is a people-owned secure and private network that won’t suffer from public congestion like what Ethereum encountered with cryptokitties. + +### 3.2 Asset-Backed Securitization + +MXC has been highly successful with regards to the design and production of high-end LPWAN hardware. Using the coins and sharing economy will allow for a massive influx of shared sensor data amongst individuals and companies, giving better insights into consumer behavior, environmental impacts and machine-based optimizations. + +With MXC, Asset-Backed Securitization (ABS) adds a completely new way for individuals and companies to both trade and manage their data and physical assets. Current methods see sensitive data easily being passed and reproduced to a number of parties without any of them knowing that the data has potentially already been corrupted, seen and/or shared amongst potential competitors/untrusted parties. MXC makes it possible for corporations and individuals to track both physical goods and intangible data, ensuring that buyers/ receivers of the goods are the only party who have received the data/physical good, and for this information to come from a qualified and reliable source. + +By applying ABS, the individual data is allocated to one dedicated source. In contrast, a buyer of a tangible paper certificate, for example, has no way of knowing that the same certificate hasn’t been sold/reproduced and assigned to potentially multiple parties. + +### 3.3 Data bloom + +MXC is a blockchain-based decentralized platform designed to revolutionize three core functions based around the basic financial theory: Lend, Send and Spend. + +#### 3.3.1 MXC-assisted garbage collection + +The future is here. The one constant in everyone’s life from now on will be the data surrounding all of us. In the past such a statement referred to “people-generated data.” However, times have changed. “Machine-generated data” is taking over at a phenomenal rate. + +The beauty of machine-based data, when compared with human-based data, is it doesn’t sleep. Machine-based data is constant and it’s reliability is unmatched when compared with any people-generated data. So why is this important? + +Take, for example, a local city council. Their task is to ensure safety, security and general well-being of the local city. One of these responsibilities includes simple tasks such as garbage collection. The simple act of emptying city trash may seem like a monotonous task, but it in fact requires planning and chain management: When do collections occur? How often should trash collections occur? How many employees are required to empty garbage cans across the city? MXC simplifies such tasks using MXProtocol. + +Using sensor/end devices situated in garbage cans and allowing them to transmit device data via a Gateway allows the city council to detect the levels of garbage built up within the can. What does this mean for the council? + +- Saving fuel: The council only needs to send out garbage trucks when necessary, as opposed to sending out trucks to check cans, irrespective of whether they are full or even completely empty. +- Saving wages: By only sending out employees at the moment a garbage can needs to be emptied, the council can then reallocate human resources, thus saving employee wages. +- Reducing traffic congestion: Garbage trucks are often frustrating for commuters. When parked on the side of the road, they can increase general traffic significantly. Being aware of the need for garbage removal in certain areas can reduce the need for trucks and allow for smoother traffic flows. + +Many of these highlighted aspects make up the chain of events associated with what are deemed to be “menial tasks” but, as shown, the flow on effect is quite significant. MXC IoT is ready to solve such issues, allowing for simple tasks to be categorized and ensuring exact resources are allocated only when needed. + +#### 3.3.1 MXC-assisted car sharing + +Using LoRaWAN sensor/end devices and Gateways can also reduce the cost of car sharing partners. + +Covering an entire city center in LPWAN allows individuals to simply build their own completely independent network, free from telecommunications companies and net- works charging exorbitant costs. + +The benefits of doing this for a company such as a “car sharing” company allows them to track their vehicles without the need to depend on Telecommunication coverage. Using LPWAN significantly reduces the costs, especially when compared with the costs of tracking using a SIM card. + +In addition to GPS tracking, car doors can be locked and unlocked using LPWAN, increasing security for users, all at a very low cost compared to current methods. + +By bringing such key services, MXC provides transparency and greatly enhances customer experience. MXC’s mission is to intensify data sharing whilst forging a unity between those with finance and data service needs and those without finance but who have private access to network integration and distribution, thus eliminating borders, intermediaries and prejudices. + +MXProtocol focuses on three foundational pillars: + +- Extend and support the massive device data economy +- Utilize the decentralized “sharing economy” +- Trade of assets within the current coin economy + +MXProtocol connects “things” utilizing a market-based economy, which adds a plethora of new transmission points allowing more data to be shared, traded, sold and analyzed for data mining. + +Within the new decentralized MXC economy, everyone can profit from the sharing of data; end to end encryption grants authorized usage of the data; and entire communities can benefit from using their locations to act as a network facility to transport this data — trading assets, profiting from the coin economy. + +## 4. MXProtocol stack + +MXProtocol infrastructure consists of both sensor and end devices, Gateway and cloud. Sensors and end devices collect data from “things,” and send to the cloud via the Gateway. This is uniquely designed to specifically be a decentralized solution allowing for everyone to suit their/the market’s needs. The usability of the hardware has been specifically designed as a “plug and play” solution, making installation simple without the need for a professional configuration. It is designed to be easy to set up and easy to share data. + +As the flow in [Figure 2](#fig2) demonstrates, LPWAN Gateways connect to each other to form either a mesh network as a collective cloud or the Internet. The sensors or end devices communicate with Gateways using LPWAN technology for bi-directional communication. Notably, the sensors and end devices are not purely limited to a single LPWAN product. In fact, any LoRaWAN compatible sensors are able to connect to the LPWAN network and can start sending and receiving messages. + + +
+ dataflow +
+ +MXProtocol facilitates the data and value flow of the LPWAN. Inside this ecosystem, each sensor or end device has a MXC wallet address assigned to an individual user. This is required in order to both pay for the network usage and to receive money from selling the data and services. The sensor wallet is stored in the cloud in order to maintain the LPWAN low-power requirements. This is also due to the fact that the CPU is usually resource-constrained. The same wallet is used as the Gateway wallet (also found in a user account and stored in the cloud). This wallet will receive coins from uploading/downloading the data from the cloud to the sensor and assists in paying for the other LPWAN’s resource or data. + +Coinciding with the current LPWAN infrastructure protocol, the data link between the Gateway and sensor end devices is unregulated. As a result, there would be no possibility to be rewarded for forwarding data from the sensor to cloud via the Gateway, and ultimately the downlink resource would be limited, only being allocated on a “first come, first served” basis. This system as is would negatively impact low-level data procurement services offered by things such as a door lock or car charging station system and would result in the data link not being appropriately monetized. MXC LPWAN infrastructure solves such issues, delivering the ultimate user experience to SMEs and MNCs. + + +
+ dataflow-mxprotocol +
+ +[Figure 3](#fig3) shows the detailed technical stack of the MXProtocol infrastructure. The decentralized and autonomous LPWAN can be built on any permissionless blockchain, such as IOTA, Stellar, Skywire and NEO. + +Based on this, the Anti-Collision Coordinator between LPWANs, Smart Bidding and Inter-chain data market are introduced to answer the LPWAN deployment considerations mentioned in the previous chapter [see 2.1.3](#213-deployment-considerations). + +### 4.1 Permissionless Blockchain + +There are various kinds of blockchain. Anyone can use cryptographic keys, anyone can be a node and join the network, and anyone can become a participant to service the network and seek a reward. Participants can walk away from being a node, return if and when they feel like it and get a full account of all network activity since they left. + +In a permissionless blockchain, anyone can read the chain, anyone can make legitimate changes and anyone can write a new block into the chain as long as they follow the rules. Decisions on a permissionless blockchain are made by the network participants. The protocol is based on a consensus protocol. The permissionless blockchain provides a way to reach consensus without relying on a closed system to accurately record financial transactions. + +#### 4.1.1 Features + +MXC built MXProtocol as an inclusive platform where all participants are encouraged to contribute. MXProtocol is a distributed network protocol backed by monetization of the resources and incentives from enterprises and individuals based on permissionless blockchain. The permissionless blockchain design makes MXProtocol efficient and independent: the more people use it, the more robust the network will be. + +The blockchain should have four key properties: decentralized control, low latency, flexible trust, and asymptotic security. In other words, MXProtocol should run on a permissionless blockchain that has: + +- A true decentralized network. +- It has eliminated mining rewards. +- All transactions get confirmed quickly. +- There is an anti-spam role. There should be a preventive measure against nefarious users flooding the network (a DoS attack). + +#### 4.1.2 Security and efficiency + +Often, the speed and privacy of a network is the concern for SMEs and MNCs. Public blockchains, such as Ethereum and Bitcoin, often suffer from big computing slow downs, practically grinding the systems to a halt, leading to a situation where the whole network and the 51 percent resources can attack the blocks. There should be a blockchain providing more privacy and efficiency for businesses and individuals collectively. MXProtocol needs to be run on a secure and efficient blockchain that can provide the devices with good connectivity. + +The MXC-introduced LPWAN application requires further fragmented and discrete transactions for sensitive data and services in an IoT realm. That is why MXC continues to develop upon the permissionless blockchain, making MXProtocol more efficient and more suitable for the needs of LPWAN and IoT applications. + +#### 4.1.3 Long-term adoptions + +As previously stated, MXProtocol is a LPWAN platform protocol that brings efficiency and robustness to the users. There are, however, still several components inside permissionless blockchain itself that MXC feels necessary to emphasize. For example, to ensure the long term stability of the LPWAN IoT projects, continued research is still required with regards to the current data interface. Real field deployment will need to be conducted in order to properly satisfy the plethora of data streams connecting from the LPWAN sensors/end devices and ensure they are routed to the network seamlessly. + +## 5. Smart Bidding + +Due to governmental regulations of the LPWAN spectrum, the downlink is a precious resource that is closely guarded by sensors and end devices. The majority of the world uses eight downlink channels for acknowledgement or confirmation of the sensor data, and each channel usually has to wait anywhere from a few milliseconds up to a few minutes in order to send another packet. + +The downlink channels are fixed in the protocol and code, and the waiting time for each downlink is dependent on the data rate of the sensor/end device. A key side note to this point is that LPWAN Gateways use the latest in “Listen Before Talk” technology allowing them to send data more regularly. This means that data may be sent when the channel is free, and therefore doesn’t have to wait for a specific time period to elapse. + +### 5.1 Goals of design + +To further overcome such industry-wide issues, MXProtocol implements a bidding mechanism, designed to bring the needed resources to those devices that are willing to bid the most. Generally public LPWAN deployment is pushed by both individuals and corporations who do so in order to extend their own individual network reach. Introducing a bidding mechanism will cause network reaches to multiply due to the fact that users can both earn and learn from the data that are sent by the sensors. The purpose of this section is to examine the Smart Bidding design that would support a well-functioning LPWAN ecosystem. The goals of the design are to: + +- Allocate downlink resources adequately +- Allow all sensors/end devices to compete on a market platform for network resources +- Offer network deployments incentives, assisting them to monetize +- Ensure LPWAN services are monetized +- Power the decentralized ledger with MXProtocol to simplify and resolve any issues + +### 5.2 Design and implementation + +There are different bidding models, ranges and methods to be set in Smart Bidding. The goal is to assign the network resource to the highest bidder. The design and functionality of the Smart Bidding process is proposed in [Figure 4](#fig4). Sensors/end devices bid on one single downlink channel out of the eight available on the LPWAN Gateway. The Smart Bidding code sensors/end devices are hosted on the cloud code, enabling them to place a bid. The LPWAN Gateway then provides the status of the network and provides resources to the sensors/end devices. + +In the example illustrated in in Figure 4, there are three sensors/end devices are bidding on one single channel for the downlink resource. The sensor on the right doesn’t participate in the auction due to the specification of its code. Let’s say this is due to the sensor that is used for a minor purpose, e.g. to monitor a garbage can or electricity meter, so the downlink confirmation can acceptably be lost. This leaves the other two devices to bid for the downlink. In this case, the door lock wins the auction. Should the downlink arrive, the payment is then automatically sent from the sensor wallet to the Gateway wallet which provided the resource. + +Usually one Gateway offers eight channels for the sensors/end devices to bid and the prices change dynamically due to the status of the Gateway, or alternatively, the willingness of the sensors. + + + +
+ MXP-smart-bidding +
+ +### 5.3 Gateway status + +Sensors and end devices will already be aware of the status of the Gateway in advance in order to make an appropriate bid for the resources and the services that provided by the network. To motivate the network administrator to maintain a robust LPWAN, we define the following metrics of the Gateway to let sensors/end devices to bid for the dynamic prices: + +- Mean time between failures (MTBF) +- Number of downlink packets sent +- Gateway density +- List of services available + +The first key parameter used to measure the stability of a Gateway on the network is determined by measuring the down time. It is recommended that a smaller MTBF be used than a larger one, because of the QoS that is required for the sensors. Thus, the high QoS sensors/end devices are willing to pay for the more stable LPWAN Gateways. + +The number of downlink packets sent by the Gateway represents the popularity of the device. This usually means the end devices/sensors around the Gateway are dense. If a sensor requires a downlink from the Gateway, which has a high number of downlink packets, it will need to place a higher bid or increase the overall bidding range accordingly. + +Gateway density is a parameter which is expected to motivate network administrators to deploy more Gateways in the areas that have little to no coverage. As demonstrated, it’s already clear that sensors will be willing to pay for low Gateway density with higher prices. Low density means the downlink channels and the services are limited and that the prices will be high when sensors are competing with each other. Overall, it’s expected that this metric will push people to expand the network in order to provide better network access to the LPWAN devices. + +From time to time, LPWAN will provide a list of services, e.g. firmware upgrades, GPS-free localization, network configuration optimization. This allows all hardware to be regularly kept up to date. Sensors and end devices would then choose from the Gateway bids for services, combined with the MTBF and the number of downlinks sent for the auction. + +### 5.4 Smart Bidding strategy + +The following are the standard auction methods found in the system: + +- Auction + - Increase: When the initial bid fails, an increased bid is made in order to secure the auction. + - Decrease: Similar to the Google Keyword style bidding auctions, the user states their bidding range. The system then states (considering all factors) the nec- essary bidding rate. In many instances, this will save customer coins. +- Fixed price + - The network resource or service are offered at a fixed price, with limited or unlimited quantity. Sensors/end devices just pay per use. +- Quantitative purchase + - The network resource or service are bid by quantitative metrics, like a period of time for downlink resource, the region of a whole city’s downlink and the amount of resources that are needed. + +### 5.5 Sensor Smart Bidding code + +Sensors and end devices are programmed with a snippet of code to enable them to bid for network resources and services that are provided by Gateways. This is implemented on the cloud so third party sensors can still use the logic easily by porting the code. There are several parameters to receive from a Gateway in advance, such as the density of the deployment and the list of services that are available to the sensors, just to name a few. + +After the information has been obtained by the Gateway, sensors would bid for resources of the service according to the type of the auction. For example, a bike lock would bid for a downlink resource using the increase method. This specifies the range of the coins that the bike lock is willing to pay for each transaction and the market dictates the end price. + +A dedicated technical white paper about the logic, design and implementation of the Smart Bidding will be released and the APIs with documentation will be available on the MXC website. + +```cpp +bid bike lock { + + /* Define the willingness to pay for the services or resources */ + type bidder + + /* Define the gateway status it will use for the auction */ + struct gw { + uint mtbf; + uint numdl; + uint density; + address service; + } + + address lock1; + gw[] gwstats; + + /* Parse the status that received from the gateway */ + function Parse(gwstats) public { + gwstats [ lock1 ] = msg. sender + lock1 = gwstats [ lock1 ]. service + } + + fuction bid(coin) constant returns (bytes32) { + coin.maximum = 10 + coin.minimum = 6 + auction.type = liner + auction.block = once + + return coin + } +} +``` + +## 6. Anti-Collision Coordinator + +With the increasing amount of LPWAN field deployments, the problem of network congestion is anticipated to rapidly increase. This is especially so when the network coverage targets ultra-long ranges of 20 km or more. + +In 2020, there are expected to be more than 75 billion devices connected to the Internet. If the majority of these are to use LPWAN, it can be assumed that it would put quite a strain on the network resources. As a result, MXProtocol infrastructure has bridged the gap between different networks using the innovative protocol. + +### 6.1 Goals of the design + +> The MXProtocol also offers a general overwhelming consensus for all public LPWAN by adding a community-based consensus, permissions and deployment permission etiquette. + +Here we define the goals of the design for the LPWAN ecosystem: + +- Minimize packet collision for uplinks in the same region deployed with multiple networks. +- Allocate new resources to the sensors/end devices that need downlink for the networks. +- Enable individual networks to pay for other networks resources and services, i.e. network roaming. +- Settle all monetary transactions in MXC. + +### 6.2 Design and implementation + +The design of the Anti-Collision Coordinator is illustrated in [Figure 5](#fig5). The coordinator has two responsibilities. The first is to make payments between networks using MXC. The second is to coordinate between networks about the downlink and uplink status. In the example illustrated in [Figure 5](#fig5), we see the door lock has successfully bid the downlink from the MXProtocol at downlink channel 1. However, the network that deployed over 1 km is also using the downlink channel 1 for the garbage sensor, and the pending collision is obvious. The solution would be that the Anti-Collision. + + +
+ anti-collision-coordinator +
+ +Coordinator would pay for Cisco’s network resource, allowing the Gateway to pause downlink channel 1 for this time’s message, thus allowing the door lock to receive the “unlock door” confirmation from the cloud. + +On the other side, the two networks report each other’s uplink lost message, since the LoRaWAN protocol has the counter for the uplink. Later, the coordinator finds out that the majority of the packets that are lost come from both street lighting and the parking meter due to the fact that their sending intervals are overlapped and they are quite close to each other. + +The coordinator then delays the street light’s sending interval or, alternatively, it changes the data rate to make sure that they won’t collide with each other, and the fees for a delay should be paid by the parking meter. Such network coordination is expected to occur quite often when future deployment of LPWAN sensors becomes more dense. Thus, the Anti-Collision Coordinator solves the problem of the network resource allocation in free-licensed bands completely. + +### 6.3 Third party integration + +The Anti-Collision Coordinator is indeed a protocol plug-in for the LoRaWAN server to control the Media Access Control (MAC) layer of LoRaWAN uplinks and downlinks. + +There are two ways to integrate the Anti-Collision Coordinator into the LPWAN server. First is to run the full node which integrates the anti-collision mechanism into the protocol layer like illustrated in [Figure 3](#fig3). Another solution is to run a light node with the anti-collision module that could be compatible with all the LoRaWAN servers. + +As [Figure 6](#fig6) shows, the Anti-Collision Coordinator is essentially a plug-in for the other LoRaWAN servers that is compatible with LoRaWAN protocol. The plug-in is a protocol enhancement that controls the uplink and downlink based on the payment logic and resource requirement between two or more networks. + +A light node connects to the full node to assign the LPWAN a wallet for sending and receiving MXCs. The Anti-Collision Coordinator controls the MAC layer for all the LoRaWAN devices. A separate white paper will be released about the protocol design of the Anti-Collision Coordinator and its APIs for LoRaWAN servers. + +
+ anti-collision-third-party-integration +
+ +## 7. Inter-Chain Data Market + +Currently, there are several traditional data markets that originate from cryptocurrencies, e.g. Streamr, IOTA and Mobius. All provide a secure mechanism to make sure that the data stream can be copied and transmitted from the owner to the consumer in a sequential manner. + +Most cryptocurrencies are in need of data. This data is fed into the system to provide checks and balances, ensuring all players along the chain have performed their role correctly. For example, a smart contract specifies which goods need to be delivered from city A to city B and this requires the buyer to pay the seller, e.g. 10 ETH. So, how can one determine whether the goods have been successfully delivered? The smart contract must rely on external Oracles from either the GPS data from the package or the LPWAN tag reading from the warehouse. + +> The entire industry continually requires chains such as Mobius or MXC to feed other chains smart contracts and the interdependent information to the applications. + +Oracles are third party services which are not part of the blockchain consensus mechanism. The main challenge with Oracles is that people need to trust these sources of information. Whether a website or a sensor, the source of information needs to be consistently trustworthy. In order to solve these issues, Oracles have different trusted computing techniques. + +### 7.1 Goals of the design + +Blockchains support Oracles in order to assist with fetching external data. The reason for this comes from the fact that blockchain applications, such as Bitcoin scripts and smart contracts cannot access and fetch data directly. As a result, they require pricing feeds for assets and financial applications and weather-related information for peer-to-peer insurance, all written with smart contracts. Here we define the goals of the MXProtocol data market with respect to designing for Oracles: + +- Facilitate data usage between different blockchains +- Establish a trusted resource for the external Oracles +- Stack up the data for later purchase +- Enable purchase of a live data stream +- Provide APIs for non-blockchain applications to access the data +- Settle all monetary transfers within MXC + +### 7.2 Design and implementation + +The MXProtocol Inter-Chain Data Market provides an effective method to feed the other smart contracts with LPWAN data captured by sensors or end devices. + + +
+ inter-chain-data-market +
+ +[Figure 7](#fig7) shows the example of the transaction between MXProtocol data and blockchains like Ethereum. + +MXProtocol feeds data to Ethereum smart contracts, and gets Ethereum payments as rewards. It only requires a simple protocol to trust that the data fetched from the MXProtocol data source is genuine and untampered. In addition to that, the rich data stream can also be used by external non-blockchain applications via Web APIs. + +Major block chains like Ethereum are short in data for smart contracts, and the data that is provided by external Oracles essentially may not be trustworthy. With the MXProtocol Inter-chain data market, the generation and flow of the data can be tracked and verified publicly on the chain. Hence, the security issue is solved internally with MXProtocol. + +### 7.3 Polkadot and Aeternity + +Polkadot is essentially a protocol that communicates between different networks. It solves consensus and transaction delivery between different chains. + +Aeternity is created to be the interface between real world data and smart contracts. Instead of using Oracles that can cause a single point of failure, Aeternity’s design provides decen- tralized infrastructure for holding and transferring the data to smart contracts. + +The MXProtocol Inter-chain data market uses the idea and mechanism developed by both Polkadot and Aeternity to deal with consensus, privacy, transaction delivery and security. A separate white paper will be released about this design. + +## 8. Smart Bidding use cases + +### 8.1 Downlink resource auction + +Downlink resource auctions occur when it is the only option for the Gateways to decide which sensor/end devices to communicate with. The Gateway usually has eight downlink channels, supporting more than 60,000 sensors that need to be acknowledged in sequence. Uplinks are free for the sensors since all the Gateways will pick up the packets and forward them within the same network, and the Anti-Collision Coordinator needs to pay the other network when collisions need to be avoided. The downlink resources need to be allocated to some sensors that need downlinks to execute the commands ([See Figure 8](#fig8)). Smart Bidding codes decide the willingness for the sensor/end devices to pay for the resources, and all the transactions are settled in MXC. + +Both the European and U.S. radio committees impose regulations on the spectrum access for LPWAN radios using 868/915Mhz bands. These regulations cover issues from maximum time on air to maximum duty cycle, which, in turn, introduces waiting times between two packets. For Gateways without Listen-Before-Talk Technology, this waiting time can range anywhere from a few milliseconds to minutes depending on the data rate and number of bytes being sent. + + +
+ LPWAN +
+ +Currently, the downlink resource is distributed on a “first come first served” basis, which can lead to many potential problems for various devices. For example, if an electricity monitoring meter were to get downlink priority over a door lock, the door lock in turn doesn’t receive the confirmation to unlock the door. The MXProtocol Smart Bidding solves this problem as covered in the following two aspects: + +- Allocate the downlink resource within the same LPWAN using the Smart Bidding code snippet for the auction. +- Enable different networks to trade for the downlink resources for the sensors/ end devices that are willing to pay. + +The snippet of code inside the sensors/end devices decides the market prices of the LPWAN. For a dense Gateway deployment like a city center, the prices can be lower due to the abundant resources of the downlink channels available. While in the mountains or suburban areas, few sensors would compete for the downlink resources and thus the prices will rise. The sensors will bid according to the MTBF, downlink numbers and the density of the network. + +The auction method and logic behind the bidding can be programmed by the owner of the sensor. It is expected that AI-driven algorithms will later be introduced to offer smarter bidding strategy for the sensors and end devices. + +### 8.2 Network coverage market + +It is expected that the supply of downlink resources will gradually increase with the demand of the sensors/end devices. The bidders will pay for the high prices for the lower Gateway density, which gives SMEs and MNCs incentives to expand the network coverage to get more MXC coin rewards. + +Figure 6 illustrates the market placed by Smart Bidding codes. The prices are lower at the dense deployment where the two LPWAN coverages overlap, and higher where there is only one LPWAN coverage. + +Some sensors travel around the city. Their code specifies the maximum amount of coins that it would like to pay for a single downlink. However, they have been to the places where no LPWAN coverage is available. Once they are back to the network, they put the last off-chain bid to the chain, and notify the whole network that they are willing to pay a pre-determined price from the Smart Bidding code. + +The prices and the amount of off-chain bids will surely motivate companies and individuals to deploy the LPWAN Gateway to the field, thus expanding the network coverage for the chain. MXProtocol shifts control from telecommunication conglomerates to companies and individuals by allowing them to deploy their own LPWAN. + +### 8.3 Service market + +There are lists of services that LPWAN can provide to the sensors/end devices. For example, an Over-the-air firmware update should be multi-casted to the sensors with downlink and it requires the sensors to bid for the resource. + +The most attractive aspect of the LPWAN is to implement GPS-free localization, which also works indoors and underground. In contrast to GPS or SIM card’s high power consumption and limited reach, LPWAN localization uses the packets sent by the sensors to calculate the position, which requires no computation from the resource-limited sensors. + +Such a service requires the resources of both a Gateway and the cloud. Hence, the Smart Bidding code will specify whether it is willing to pay for the service and its accuracy. The more Gateways that receive the packets, the more accurate the position will be. + +LPWAN sometimes needs to change the channel configurations like the arrangement or the allowed data rate. This kind of coordination will need to be applied globally and the network will have to try to synchronize such a configuration as much as possible. Smart Bidding can also accept “free auctions” where they require no one to pay. + +Through the MXProtocol Smart Bidding design, it is possible that sensors/end devices pay for the services that the network offers to them. The outcome of the design will be: + +- Some sensors/end devices get the services and the resources that they demand through auction +- Network deployment receives reward by offering services and resources to the LPWAN sensors/end devices +- All the monetary transactions are done automatically in MXC without human intervention + +## 9. Development progress + +MXC Foundation’s partner MatchX has released the MatchBox LPWAN Gateway, and the LPWAN module with development kits. It has reached more than 40 countries with distributors in Australia, North America, Asia and Europe. + +The first Proof-of-Concept has been performed in conjunction with the Stellar Development Foundation, utilizing the LPWAN coverage and enabling sensors to pay with each other. + +## 10. References + +- _What is LPWAN (low-power wide area network)?_ - Definition from WhatIs.com. (2018). IoT Agenda. Retrieved 8 January 2018, from +- _LoRa Alliance._ (2018). LoRa Alliance. Retrieved 8 January 2018, from +- _Skywire and Viscript | Skycoin Blog._ (2018). Blog.skycoin.net. Retrieved 8 January 2018, from +- _Skywire - Skycoin Meshnet Project | Skycoin Blog._ (2018). Blog.skycoin.net. Retrieved 8 January 2018, from +- _contributors, S._ (2018). Create an Account | Stellar Developers. Stellar.org. Retrieved 5 February 2018, from +- Kusmierz, B. (2017). _The first glance at the simulation of the Tangle: discrete model._ +- Popov, S. (2016). _The tangle._ IOTA. +- Kim, J. (2014). _Introducing Stellar - Stellar CN._ Stellar CN. Retrieved 5 February 2018, from +- _Ethereum Project._ (2018). Ethereum.org. Retrieved 8 January 2018, from +- _RSK._ (2018). RSK. Retrieved 8 January 2018, from +- Dudley, J., Hochstetler, G., Dudley, J., Hearn, M., Hearn, M., \& Hearn, M. (2018). _Corda: Frictionless Commerce._ corda.net. Retrieved 8 January 2018, from +- _LoRaWAN in Europe._ (2017). Matchx.io. Retrieved 8 January 2018, from +- _LoRaWAN regulations in Korea, Australia, India Japan and South East Asia._ (2017). Matchx.io. Retrieved 8 January 2018, from diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/smart-machine-bidding.md b/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/smart-machine-bidding.md new file mode 100644 index 0000000..72dd182 --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/smart-machine-bidding.md @@ -0,0 +1,6 @@ +--- +title: Smart Machine Bidding +sidebar_position: 3 +--- + +# Smart Machine Bidding \ No newline at end of file diff --git a/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/tokenomics.md b/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/tokenomics.md new file mode 100644 index 0000000..e7fca3d --- /dev/null +++ b/i18n/ko/docusaurus-plugin-content-docs/current/whitepapers/tokenomics.md @@ -0,0 +1,6 @@ +--- +title: Tokenomics +sidebar_position: 4 +--- + +# Tokenomics \ No newline at end of file diff --git a/i18n/ko/docusaurus-theme-classic/footer.json b/i18n/ko/docusaurus-theme-classic/footer.json new file mode 100644 index 0000000..0cb80f5 --- /dev/null +++ b/i18n/ko/docusaurus-theme-classic/footer.json @@ -0,0 +1,66 @@ +{ + "link.title.Docs": { + "message": "Docs", + "description": "The title of the footer links column with title=Docs in the footer" + }, + "link.title.Community": { + "message": "Community", + "description": "The title of the footer links column with title=Community in the footer" + }, + "link.title.More": { + "message": "More", + "description": "The title of the footer links column with title=More in the footer" + }, + "link.item.label.Tutorials": { + "message": "Tutorials", + "description": "The label of footer link with label=Tutorials linking to /docs/tutorials/intro" + }, + "link.item.label.API": { + "message": "API", + "description": "The label of footer link with label=API linking to /docs/api/intro" + }, + "link.item.label.Whitepapers": { + "message": "Whitepapers", + "description": "The label of footer link with label=Whitepapers linking to /docs/whitepapers/intro" + }, + "link.item.label.Telegram": { + "message": "Telegram", + "description": "The label of footer link with label=Telegram linking to https://mxc.news/telegram" + }, + "link.item.label.Discord": { + "message": "Discord", + "description": "The label of footer link with label=Discord linking to https://mxc.news/discord" + }, + "link.item.label.Twitter": { + "message": "Twitter", + "description": "The label of footer link with label=Twitter linking to https://twitter.com/mxcfoundation" + }, + "link.item.label.Developer Blog": { + "message": "Developer Blog", + "description": "The label of footer link with label=Developer Blog linking to /blog" + }, + "link.item.label.GitHub": { + "message": "GitHub", + "description": "The label of footer link with label=GitHub linking to https://github.com/mxc-foundation/" + }, + "link.item.label.MXC Website": { + "message": "MXC Website", + "description": "The label of footer link with label=MXC Website linking to https://www.mxc.org" + }, + "link.item.label.User Documentation": { + "message": "User Documentation", + "description": "The label of footer link with label=User Documentation linking to https://www.mxc.wiki" + }, + "link.item.label.Imprint": { + "message": "Imprint", + "description": "The label of footer link with label=Imprint linking to https://www.mxc.org/imprint" + }, + "link.item.label.Privacy Policy": { + "message": "Privacy Policy", + "description": "The label of footer link with label=Privacy Policy linking to https://www.mxc.org/privacy-policy" + }, + "copyright": { + "message": "Copyright © 2021 MXC Foundation gGmbH.", + "description": "The footer copyright" + } +} \ No newline at end of file diff --git a/i18n/ko/docusaurus-theme-classic/navbar.json b/i18n/ko/docusaurus-theme-classic/navbar.json new file mode 100644 index 0000000..63fefb5 --- /dev/null +++ b/i18n/ko/docusaurus-theme-classic/navbar.json @@ -0,0 +1,26 @@ +{ + "title": { + "message": "Developer Documentation", + "description": "The title in the navbar" + }, + "item.label.Docs": { + "message": "Docs", + "description": "Navbar item with label Docs" + }, + "item.label.API": { + "message": "API", + "description": "Navbar item with label API" + }, + "item.label.Whitepapers": { + "message": "Whitepapers", + "description": "Navbar item with label Whitepapers" + }, + "item.label.Blog": { + "message": "Blog", + "description": "Navbar item with label Blog" + }, + "item.label.GitHub": { + "message": "GitHub", + "description": "Navbar item with label GitHub" + } +} \ No newline at end of file diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/2019-05-30-welcome.md b/i18n/zh-CN/docusaurus-plugin-content-blog/2019-05-30-welcome.md new file mode 100644 index 0000000..592f3ed --- /dev/null +++ b/i18n/zh-CN/docusaurus-plugin-content-blog/2019-05-30-welcome.md @@ -0,0 +1,13 @@ +--- +slug: welcome +title: Welcome +author: Jeff Stahlnecker +author_title: Head of Development at MXC Foundation +author_url: https://github.com/jeffstahlnecker +author_image_url: https://avatars.githubusercontent.com/u/45363541?v=4 +tags: + - welcome + - intro +--- + +It's the beginning. Since I returned to the community following the Miner Health release, I've been saying that we'll impove transparency in development at MXC. This site is the beginning of this transparency. More content will be added here. diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/2021-05-30-welcome.md b/i18n/zh-CN/docusaurus-plugin-content-blog/2021-05-30-welcome.md new file mode 100644 index 0000000..592f3ed --- /dev/null +++ b/i18n/zh-CN/docusaurus-plugin-content-blog/2021-05-30-welcome.md @@ -0,0 +1,13 @@ +--- +slug: welcome +title: Welcome +author: Jeff Stahlnecker +author_title: Head of Development at MXC Foundation +author_url: https://github.com/jeffstahlnecker +author_image_url: https://avatars.githubusercontent.com/u/45363541?v=4 +tags: + - welcome + - intro +--- + +It's the beginning. Since I returned to the community following the Miner Health release, I've been saying that we'll impove transparency in development at MXC. This site is the beginning of this transparency. More content will be added here. diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/2021-07-05-tech-update.md b/i18n/zh-CN/docusaurus-plugin-content-blog/2021-07-05-tech-update.md new file mode 100644 index 0000000..2dd0bc2 --- /dev/null +++ b/i18n/zh-CN/docusaurus-plugin-content-blog/2021-07-05-tech-update.md @@ -0,0 +1,36 @@ +--- +slug: 2021-07-05-tech-update +title: Tech Update - July 5, 2021 +author: Jeff Stahlnecker +author_title: Head of Development @ MXC Foundation +author_url: https://github.com/jeffstahlnecker +author_image_url: https://avatars.githubusercontent.com/u/45363541?v=4 +tags: + - tech update + - datadash + - supernode + - dhx +--- + +Welcome to the very first MXC tech update! + +This week the tech team has been extremely busy. Throughout the past sprint we've focused on closing any and all ongoing projects. That brought us back to a few "low hanging" items that will add some EPIC value to our users -- especially those interested in connecting LoRa devices. + +## Device Provisioning +Our very own backend engineer Lixuan took a deep dive to test the device provisioning system built by Ian to ensure that it was ready to be added with our live code. She solved a number of conflicts (device provisioning has been *ready* since January!), then ran it through a round of rigorous testing. This was done in collaboration with MatchX embedded software engineer Ian. They did some great work, and you'll see device provisioning going live early this week. In the meantime, you can check out the technical documentation here: [Device Provisioning FAQ](/docs/tutorials/devices/provisioning) + +As part of our focus on devices during the past two weeks, Lixuan also solved an issue which kept users from adding new devices on a supernode. We should be in ship-shape, and ready for some developer interaction. Feel free to send us your feedback! :) + +## Foundation for DHX Simulator Improvement +The DataDash DHX Simulator has been a long-standing issue. While it works, it's a little buggy, and once in a while spits out something unexpected. Our backend developer Pavel decided enough is enough, and jumped in to solve the challenge of the buggy simulator. To accomplish this he brought together the required information from a ton of different sources and built an API for the DataDash team to integrate. For those developers out there, I'll update this post with a link to the API as soon as it is live. + +## Improved Technical Support +We've been working hard to improve the technical support services provided by both MXC and MatchX. Our Tech Support Engineer Latifah has been hard at work building a ticketing system, integrating Discord, writing an internal support knowledgebase, while naturally also responding to your support requests. She's done an excellent job, and has set a strong foundation for reliable support moving forward. + +## Cleaning up the DataDash +Over the past two weeks our DataDash team has focused primarily on solving some pesky issues with the app. We also added support for DHX in the in-app address book. Just another feature to make life a little easier for you. + +## Contributing to DataHighway +Team members Luke, Ayush and Christian updated the DataHighway blockchain to add multisig functionality. They also made a number of improvements, and fixed issues with the Harbour testnet. You can review the full release notes [here](https://github.com/DataHighway-DHX/node/releases/tag/v3.0.5). + +That's the newest from Tech, and I'll be sure to update this post with that API link as soon as it goes live. \ No newline at end of file diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/2021-07-20-tech-update.md b/i18n/zh-CN/docusaurus-plugin-content-blog/2021-07-20-tech-update.md new file mode 100644 index 0000000..0a2127b --- /dev/null +++ b/i18n/zh-CN/docusaurus-plugin-content-blog/2021-07-20-tech-update.md @@ -0,0 +1,66 @@ +--- +slug: 2021-07-20-tech-update +title: Tech Update - July 20, 2021 +author: Jeff Stahlnecker +author_title: Head of Development @ MXC Foundation +author_url: https://github.com/jeffstahlnecker +author_image_url: https://avatars.githubusercontent.com/u/45363541?v=4 +tags: + - tech update + - datadash + - dhx + - mxc controller + - device provisioning +--- + +It's hard to believe it's been another two weeks --- and we've been EXTREMELY busy polishing up some pretty epic features. + +### All About Device Provisioning +It took us quite some time to get the [device provisioning](/docs/tutorials/devices/provisioning) developer preview ready. A bit longer than expected. Device provisioning interacts with a number of supernode systems on a regular basis, meaning that each of these interactions had to be thoroughly tested. During that process we found some items that could cause issues when the system scales, so we went ahead and took the time to resolve those before pushing out the feature. I'm excited to say that the device provisioning developer preview is now live and ready for action. If you want to get a manufacturer ID and begin testing the system, email support@mxc.org. + +In the meantime, Ian is actively working on providing a sample lora device source code to make it easier for manufacturers (and tinkerers) to get started. + +### DataDash Goes Dark (for beta testers) +That's right! We're working hard on getting dark mode out there for all of you night owls. If you want to get a sneak peek at dark mode and provide some epic feedback for us, you can join the live beta by using the command `!role ios` or `!role android` in our [Discord Community](https://mxc.news/discord). This will get you access to the dedicated beta channel for your phone, which provides you with the information you need to get signed up. + +:::caution + +Beta releases have bugs. By joining the beta, you will experience these bugs. If you find an issue, always report it directly to us in our [GitHub Repo](https://github.com/mxc-foundation/supernode-app/issues/new?assignees=&labels=bug%2Ctriage&template=bug_report.yml&title=%5BBug%5D%3A+). + +::: + +### Tech Support Continues to Amaze +Ok I just had to say this one. Yes it sounds markety, and I know not everyone is always amazed, but I'm very happy with it. Within a few weeks our new Tech Support Engineer Latifah has gone from "first day with LoRa" to actively troubleshooting miners, certifying issues, finding solutions for said issues, and of course ensuring that each member of our community receives top of the line technical support. + +Keep in mind, the only way to get "official" technical support is to email support@mxc.org or by using the `/support` command in our [Discord Server](https://mxc.news/discord). + +### MXC Controller - the news on the Web App +For those of you digging into the nitty-gritty of the LoRa/LPWAN infrastructure, I'm sure you've noticed a few issues with the current web app. We know about those, and we're working on rolling out a new web app to solve all of these issues. Because we've decided to move from React to a Flutter based web app, it will take us just a bit of time to get started. + +This week we started cross-training our React developer Nam to start working with Flutter. While he's been studying, he also worked with the Flutter team to outline the base architecture of the application so that we can finalize the overall design in our upcoming sprint. + +The MXC Controller will be available as beta during development. This will provide you with early access to key pages, while keeping you informed that it's beta, and will probably have a few bugs. + +:::caution + +Beta releases will have bugs. Just pointing that out again. + +::: + +Our first release will include: +* Base architecture +* Sign-in / Register +* Device Management/Configuration pages + +I'll keep you updated on the status of this as we move forward, and of course I'll share the GitHub repo when the development begins. + + +### Continuing our Contribution to DataHighway +We haven't forgotten DataHighway and we still strongly believe in the future of this project. Blockchain developers Luke and Ayush have been hard at work to both improve the DataHighway, and bring governance on chain. There's been some progress made in that direction, however we're being über careful. As we progress further with the development, we'll start contributing to the documentation as well to ensure it's easier for others to participate. + +### Community Contributions +This documentation is fluid, and anyone can work to help improve it. If you see something that you know about, and feel confident writing an article about, feel free to fork the repo, make the changes, and submit a pull request. + +Now I know that not everyone is familiar with GitHub. In that case, let me know on Discord and I'll open up a channel for us to chat. Either I'll teach you what you need to know to participate directly on GitHub, or you can just send me the article you believe should be in the documentation. + +That's been this week's news update --- uh yeah ok wrong channel. ;) \ No newline at end of file diff --git a/i18n/zh-CN/docusaurus-plugin-content-blog/2021-07-5-tech-update.md b/i18n/zh-CN/docusaurus-plugin-content-blog/2021-07-5-tech-update.md new file mode 100644 index 0000000..2dd0bc2 --- /dev/null +++ b/i18n/zh-CN/docusaurus-plugin-content-blog/2021-07-5-tech-update.md @@ -0,0 +1,36 @@ +--- +slug: 2021-07-05-tech-update +title: Tech Update - July 5, 2021 +author: Jeff Stahlnecker +author_title: Head of Development @ MXC Foundation +author_url: https://github.com/jeffstahlnecker +author_image_url: https://avatars.githubusercontent.com/u/45363541?v=4 +tags: + - tech update + - datadash + - supernode + - dhx +--- + +Welcome to the very first MXC tech update! + +This week the tech team has been extremely busy. Throughout the past sprint we've focused on closing any and all ongoing projects. That brought us back to a few "low hanging" items that will add some EPIC value to our users -- especially those interested in connecting LoRa devices. + +## Device Provisioning +Our very own backend engineer Lixuan took a deep dive to test the device provisioning system built by Ian to ensure that it was ready to be added with our live code. She solved a number of conflicts (device provisioning has been *ready* since January!), then ran it through a round of rigorous testing. This was done in collaboration with MatchX embedded software engineer Ian. They did some great work, and you'll see device provisioning going live early this week. In the meantime, you can check out the technical documentation here: [Device Provisioning FAQ](/docs/tutorials/devices/provisioning) + +As part of our focus on devices during the past two weeks, Lixuan also solved an issue which kept users from adding new devices on a supernode. We should be in ship-shape, and ready for some developer interaction. Feel free to send us your feedback! :) + +## Foundation for DHX Simulator Improvement +The DataDash DHX Simulator has been a long-standing issue. While it works, it's a little buggy, and once in a while spits out something unexpected. Our backend developer Pavel decided enough is enough, and jumped in to solve the challenge of the buggy simulator. To accomplish this he brought together the required information from a ton of different sources and built an API for the DataDash team to integrate. For those developers out there, I'll update this post with a link to the API as soon as it is live. + +## Improved Technical Support +We've been working hard to improve the technical support services provided by both MXC and MatchX. Our Tech Support Engineer Latifah has been hard at work building a ticketing system, integrating Discord, writing an internal support knowledgebase, while naturally also responding to your support requests. She's done an excellent job, and has set a strong foundation for reliable support moving forward. + +## Cleaning up the DataDash +Over the past two weeks our DataDash team has focused primarily on solving some pesky issues with the app. We also added support for DHX in the in-app address book. Just another feature to make life a little easier for you. + +## Contributing to DataHighway +Team members Luke, Ayush and Christian updated the DataHighway blockchain to add multisig functionality. They also made a number of improvements, and fixed issues with the Harbour testnet. You can review the full release notes [here](https://github.com/DataHighway-DHX/node/releases/tag/v3.0.5). + +That's the newest from Tech, and I'll be sure to update this post with that API link as soon as it goes live. \ No newline at end of file diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/datadash/_category_.json b/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/datadash/_category_.json new file mode 100644 index 0000000..96eea63 --- /dev/null +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/datadash/_category_.json @@ -0,0 +1,4 @@ +{ + "label": "DataDash", + "position": 6 +} diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/datadash/beta.md b/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/datadash/beta.md new file mode 100644 index 0000000..70fd43e --- /dev/null +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/datadash/beta.md @@ -0,0 +1,20 @@ +--- +sidebar_position: 2 +title: DataDash Beta Testing +--- + +# DataDash Ongoing Beta +At the moment we have an open beta DataDash group for both iOS and Android. We consider this a semi-closed beta because we require participants to join our beta discord channels. This is key for discussions among participants, and provides us with an easy way to interact with beta participants. + + +To participate as a beta tester follow the following steps: +1. Join our [Discord Community](https://mxc.news/discord) +1. Use the #bot-talk channel to send one of the following commands: + * `!role ios` + * `!role android` +1. You will then see a new channel in the `development` category. Follow the steps outlined at the top of the channel to join your selected test group. + +## DataDash Closed Beta +Before a major release, we will do a call for closed beta participants. This will have a limited number of available seats per operating system, and will only be available to current beta testers who actively submit feedback. + +Closed betas will provide users access to new and unreleased features that require a major backend change. Because of this, each participant will receive a test account on a "fake" supernode to work with. \ No newline at end of file diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/datadash/bugs.md b/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/datadash/bugs.md new file mode 100644 index 0000000..01e11de --- /dev/null +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/datadash/bugs.md @@ -0,0 +1,19 @@ +--- +sidebar_position: 2 +title: Reporting Bugs +--- + +# How to report DataDash Bugs + +The DataDash app codebase is [Publicly available on GitHub](https://github.com/mxc-foundation/supernode-app). Therefore the best way to submit a DataDash bug, is directly as a [GitHub issue](https://github.com/mxc-foundation/supernode-app/issues). + +Please include the following information in your bug report: + +* What is the problem? +* What is the expected behavior? +* Mark the issue with the appropriate labels: + * `bug` + * `ios` or `android` +* Provide any additional information, screenshots, or videos you believe might be helpful. + +**GitHub Issues are public! Do not share any personal or identifiable information. If you believe the issue is specific to you, it should be submitted as a support ticket to [support@mxc.org](mailto:support.mxc.org).** diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/datadash/intro.md b/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/datadash/intro.md new file mode 100644 index 0000000..5df58e1 --- /dev/null +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/datadash/intro.md @@ -0,0 +1,35 @@ +--- +sidebar_position: 1 +title: Intro +--- + +# Introducing the DataDash App + +Our DataDash app has the following core functionality: +* LPWAN Functionality + * M2 Pro Miner + * Register + * Manage Miner Health + * MXProtocol enabled devices (coming soon) + * Register + * View live data frames + * Generate MQTT credentials (for external data management tools) +* Token Management + * MXC M2M Wallet + * DHX Wallet + * BTC Wallet (Withdrawals Only) + + +## Downloading the DataDash App + +You can get the DataDash app at the following locations: + +**Android** +* [Google Play Store](https://play.google.com/store/apps/details?id=com.mxc.smartcity) +* [APK Download](https://datadash.oss-accelerate.aliyuncs.com/app-prod-release.apk) + +**iOS** +* [App Store](https://apps.apple.com/us/app/datadash-app/id1509218470) + +## Participating with DataDash Development +Our DataDash app is [open on GitHub](https://github.com/mxc-foundation/supernode-app) and anyone is welcome to participate in its improvement. To participate, clone the repo, and then tackle a [GitHub issue](https://github.com/mxc-foundation/supernode-app/issues). When you think you've solved it, submit a pull request for our team to review. Before getting started, take a look at the rules [here](https://github.com/mxc-foundation/supernode-app/blob/master/RETHINK.md). \ No newline at end of file diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/devices/integrations.md b/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/devices/integrations.md index 9b2116c..cbeabdb 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/devices/integrations.md +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/devices/integrations.md @@ -1,5 +1,5 @@ --- -sidebar_position: 3 +sidebar_position: 3 title: Integrations --- @@ -7,9 +7,7 @@ title: Integrations By default supernode provides MQTT broker service for users to subscribe or pushlish events on their devices. -Users can subscribe to MQTT broker under topics in the servers after authentication. Before that, you need to make sure -you have mosquitto package installed. Use the package manager apt to install these dependencies on the Ubuntu 18.04 LTS -server: +Users can subscribe to MQTT broker under topics in the servers after authentication. Before that, you need to make sure you have mosquitto package installed. Use the package manager apt to install these dependencies on the Ubuntu 18.04 LTS server: ``` sudo apt-add-repository ppa:mosquitto-dev/mosquitto-ppa @@ -161,7 +159,7 @@ Response Call ```shell -curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'Grpc-Metadata-Authorization: Bearer {{ .SUPERNODE_JWT }}' -d '{ "organizationId": "{{ .ORG_ID }}"}' 'https://{{ .SUPERNODE_URL }}/api/mosquitto-auth/login' +curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'Grpc-Metadata-Authorization: Bearer {{ .SUPERNODE_JWT }}' -d '{ "organizationId": "{{ .ORG_ID }}", "ttlInSeconds": "{{ .TIME_TO_LIVE_IN_SECONDS }}"}' 'https://{{ .SUPERNODE_URL }}/api/mosquitto-auth/login' ``` Response @@ -220,5 +218,4 @@ The message format should be as follow: - `confirmed`: whether the payload must be sent as confirmed data down or not - `fPort`: FPort to use (must be > 0) - `data`: base64 encoded data (plaintext, will be encrypted by Network Server) -- `object`: decoded object (when application codec has been configured), when providing the 'object', you can omit ' - data' +- `object`: decoded object (when application codec has been configured), when providing the 'object', you can omit ' data' 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.
0: Low or OFF, 1: High or ON, -1 Unknown or Invalid. | +| 20 (0x14) | percent | 1 | A generic value in percent. | +| 21 (0x15) | powerFactor | 2 or 4 | Power factor for AC power system.
Value range from 0 to 1. | +| 254 (0xfe) | uplinkPower | 1 | Exact value of TX Power in dBm. | + + + +#### GPS data format + +When data length is 1 + +| Offset | Length | Description | +| ------ | ------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 0 | 1 | Indicates whether the node has moved since last GPS fix. Possible values are:
    0: Node is stable since last GPS fix
    1: Node has moved, or has not received a GPS fix since boot; waiting for GPS fix | + +When data length is 11 + +| Offset | Length | Description | +| ------ | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 0 | 1 | $GPGGA Position Fix Indicator. Possible values are:
* 0 Fix not available or invalid
* 1 GPS SPS Mode, fix valid
* 2 Differential GPS, SPS Mode, fix valid
* 6 Dead Reckoning Mode, fix valid | +| 1 | 4 | Latitude in 1/1000 of minutes, as little-endian int32. Positive is north, negative is south. To get the value in degrees, divide by 600000. | +| 5 | 4 | Longitude in 1/1000 of minutes, as little-endian int32. Positive is east, negative is west. To get the value in degrees, divide by 600000. | +| 9 | 2 | Altitude above geoid mean sea level in decimeters (0.1m), as little-endian int16. | + + + +#### Data format for 1 byte value + +It is a signed 8-bits integer (int8_t), giving the range between -128 and +127. + +```javascript +// Decoding +if (offset_0 > 0x7f) { + value = ((offset_0 ^ 0xff) + 1) * -1; +} +else { + value = offset_0; +} +``` + + + +#### Data format for 2 bytes value + +It is a signed 16-bits fixed point number. Offset 0 is the sign bit and integer part. Offset 1 is the fractional part. + +```javascript +// Decoding in Javascript +let raw_value = (offset_0 << 8) | offset_1; +if (raw_value > 0x7fff) { + value = ((raw_value ^ 0xffff) + 1) * -1; +} +else { + value = raw_value; +} +value = value / 256; +``` + + + +#### Data format for 4 bytes value + +It is a 32-bits floating point number (IEEE 754). Offset 0 is the MSB. + +For example, a value of 54.12 will has a 32-bits value of 0x42587ae1. + +The payload will become <0x42><0x58><0x7a><0xe1>. + +```javascript +// Decoding in Javascript +let raw_value = (offset_0 << 24) | (offset_1 << 16) | (offset_2 << 8) | offset_3; +let v_temp = new DataView(new ArrayBuffer(4)) +v_temp.setUint32(0, raw_value) +value = v_temp.getFloat32(0) +``` + + + +The NAN (Not A Number) (0x7fc00000), means the sensor value is unknown or invalid. + + + +### Event Data + +Event data is information about change that occurs at a point in time. A event will contain the type value and additional event data. + +| Number | Name | Length | Description | +| --------- | ------------- | ------ | ------------------------------------------------------------------ | +| 0 (0x00) | unknown | 0 | No data. | +| 11 (0x0b) | opened | 1 | The unit is opened by a user. Data is the user ID. | +| 12 (0x0c) | specialOpened | 0 | The unit is opened in a special way. For example, a key or button. | +| 13 (0x0d) | forceOpened | 0 | The unit is opened in a abnormal way. | + + + +## Downlink Payload Data Format + +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 | Get params | 1 | Get parameter described by first byte. | +| 1 | Set params | >=2 | Set parameter described by first byte to the value specified in the rest of the message. | +| 2 | Reboot | 0 | Reboot the node immediately. | +| 3 | Reboot/upgrade | 1 | Reboot the node after the specified timeout; optionally turn BLE and SUOTA on for upgrades. The argument is as follows:bit [7]:0: just reboot1: BLE onbits [6:3]: Reservedbits [2:0]: Timeout0: TBD1: 5 minutes2: 15 minutes3: 30 minutes4: 1 hour5: 2 hours6: 4 hours7: TBD | +| 4 | Set Controls | \>=1 | Set a value to the control. For example, turn on/off a digital output. | + + + +### Parameters + +| Number | Name | Length | Description | +| ------ | ------- | ------ | ------------------------------------------------------------------------- | +| 0 | deveui | 6 | DevEUI-48 and BLE MAC address (MSBF)
Only for DevKit. Please don't use it at final product. | +| 1 | appeui | 8 | AppEUI-64 (MSBF)
Only for DevKit. Please don't use it at final product. | +| 2 | appkey | 16 | AppKey (write-only)
Only for DevKit. Please don't use it at final product. | +| 3 | period | 1 | Sensor period | +| 4 | sf | 1 | Minimal LoRa Spread Factor (valid values: 7-12) | +| 5 | version | 2 | Version number.
01 00 => V1.0 | + +Parameters 0, 1, 2 and 4 are actualized after reboot. + +Sensor period is as follows: + +| Number | Period | +| ------ | -------- | +| 0 | Default | +| 1 | 10 sec | +| 2 | 30 sec | +| 3 | 1 min | +| 4 | 2 min | +| 5 | 5 min | +| 6 | 10 min | +| 7 | 30 min | +| 8 | 1 hour | +| 9 | 2 hours | +| 10 | 5 hours | +| 11 | 12 hours | + + + +### Controls + +Controls are used for the user to change a value or state of the device. The control data consists of a byte signifying the data type, and zero or more bytes of the data. The defined types and corresponding data formats are: + +| Number | Name | Length | Description | +| --------- | ------- | ------ | ----------------------------------------------------------------- | +| 0 (0x00) | unknown | 0 | No data. | +| 19 (0x13) | digital | 1 | A generic digital value.
0: Low or OFF, 1: High or ON. | +| 20 (0x14) | percent | 1 | A generic value in percent. | diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/devices/provisioning.mdx b/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/devices/provisioning.mdx new file mode 100644 index 0000000..b56498c --- /dev/null +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/devices/provisioning.mdx @@ -0,0 +1,514 @@ +--- +sidebar_position: 4 +sidebar_label: Device Provisioning +--- + +# Device Provisioning + +## What is Device Provisioning? + +Device Provisioning is a process of exchanging sensitive information between a device and a server. This process will store the encryption keys required for LoRaWAN communication on the device and the server. The whole process will be completed through LoRa communication. Therefore, no additional hardware is required on the device. + +In terms of security, Elliptic-curve Diffie-Hellman is used as the key exchange, which enables subsequent sensitive data to be exchanged between the device and the server in a secure manner. + + +## What is the advantage of it? + +With the provisioning is done and the key is ready on both server and device. The operation on the user side will become simple. The user needs only a few steps to register the device to the system. He/She just needs to use our DataDash mobile APP to scan the QR-code label on the device. Then enter a few more information about the device, such as name. After that the device will start to join the network. The user didn’t need to enter any keys that the traditional way needs. During production no keys need to be sent to the assembly house, further improving the security by preventing unwanted compromise of the keys by the 3rd party. + + +## What about the QR-code label? + +The QR-code label stored the identity of the device. There is no sensitive information on it, just an ID code (called Provision ID). A minimal label just needs the Provision ID. The mobile APP will use this Provision ID to register the device to the system. It is a secure way to do the task which no encryption keys content appears during the whole process. + +Here is an example of a minimal label. + + + + + + + +
+ alt_text + PID:PROVISIONIDOOOOOOOOO
+ +For a big device that has more space for the label, a long version label could be used to store more information. + + + + + + +
+ lora provisioning label +
+ +``` +{ + "PROVID": "PROVISIONIDOOOOOOOOO", + "BRAND": "MatchX", + "MODEL": "MX1234", + "SN": "S123456" +} + +``` + + +## What device developer needs to do? + +The firmware needs to implement the flow device provisioning. It is a two steps process and needs to be done for a new produced device. The details of this process is listed on the later part of this document. + +During the device provisioning, it required the Provision ID to identify the device. We suggest the device firmware add an interface to let the manufacturer set this information at the end of the quality assurance (QA) procedure. + +An example method is to use a UART interface to program the information. Our example device uses an “AT” command to achieve this. But any other serial protocol should be fine. + + +![alt_text](/img/provisioning/lora-provisioning-stack.png "image_tooltip") + + +## What device manufacturer needs to do? + +To successfully provision a device, it required the information of Provision ID. The manufacturer needs to request it from us, MatchX. We will prepare a spreadsheet that has the assigned Provision ID and related information for the manufacturer. The Manufacturer needs to make sure the information is set to the device with the correct matched QR-Code label. + +We suggest the manufacturer to add an extra step at their quality assurance (QA) procedure. The step included setting the Provision ID to the device with a matched QR-Code label. Then verify the device is being provisioned, that means it exchanged key information with the server. + + +![alt_text](/img/provisioning/lora-provisioning-steps.png "image_tooltip") + + + + + +## Device Provisioning Implementation Details + +Source code of our example device: TBD + + +### Provision ID + +The Provision ID is a unique string for each device. During the provisioning, it is used as an identity at the provisioning server to access the device information. The Provision ID is 20 characters long and uses the RFC4648 Base32 alphabet. + + +### Hash of Provision ID + +It is the result of the SHA256 hash on the Provision ID. The device provisioning process uses this value when doing authentication with the server. To minimize the complexity of the device implementation, we suggest the device also store this value to its FLASH, instead of calculating it by itself. + + +``` +provisionIdHash = SHA256(provisionId | '.MatchX') +``` + + +For example: + + +``` +PID = 'TESTPIDOOOOOOOOOOOOO' +HASH = 'c8c7564b46b91c91ef6c4f37bcca8cf7e81baac6eb869dcc62e5fafdd0242497' +``` + + + +### Message integrity code (MIC) + +The message integrity code (MIC) value at LoRa PHYPayload for HELLO and AUTH messages is calculated as below. + + +``` +FixedKey[] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, +0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f}; + +cmac = aes128_cmac(FixedKey, message) +MIC = cmac[0..3] +``` + + +### Verification Code + +The verification code is used when the device authenticates with the server. The calculation is shown below. + + +``` + FixedKey[] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, + 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f}; + + cal_buf = provisionId + nonce; + verifyCode = aes128_cmac(FixedKey, cal_buf) +``` + +Example: + + +``` +// Input + privisionid = "SERIALNUMBEROOOOOOOO"; + servernonce = {0x01, 0x02, 0x03, 0x04}; + +// Output + verifyCode = {0x2E, 0x69, 0xBB, 0x5E, 0xD7, 0x8B, 0x5E, 0xE8, + 0x0C, 0x6A, 0x8A, 0xDC, 0x81, 0x91, 0xDD, 0xF8}; +``` + + + +### AES + +The encryption scheme used in aes128_encrypt() and aes128_cmac() are the same as LoRaWAN specification. This approach will minimize the need for extra code on the device side. + + +### LoRa + +The device provisioning using the “Proprietary” LoRa frame for communication, it means the MType on MHDR is set to ‘111’. + +The receiving windows using RX1 and delay is 5s. + +Data Rate: + + + + + + + + + + + + + + + + + + + + + + + +
Region + Data Rate + Configuration +
EU868 + 3 + Up and Down: SF9 / 125 kHz +
US915 + 3 + Up: SF7 / 125 kHz +

+ Down: SF7 / 500 kHz +

+
CN470 + 3 + Up and Down: SF9 / 125 kHz +
+ +### Sequence Diagram + +The device provisioning has two steps. First, it is a ECDH key exchange process, called “Hello” by us. The device and the server will exchange their public key on this step. Then the next step is the authentication. The device will submit its hashed Provision ID to the server. If it is a valid ID on the server, the server will accept the request and send back the EUI information. + +The keys used for LoRaWAN OTAA are derived from the ECDH shared key. All this information will not appear on the communication message. + +![alt_text](/img/provisioning/lora-device-provisioning-sequence.png "image_tooltip") + + +### Message format + +The messages shown below are the content of the MACPayload of the Proprietary MAC message of LoRaWAN. + +LoRaWAN PHYPayload: + + + + + + + + +
MHDR + MACPayload +

+ (Hello / Auth) +

+ 		MIC +
+ +##### Hello message + + +``` + | Type | rDevEUI | devPubKey | version | + | 0x01 | 8 bytes | 64 bytes | 1 byte | +``` + + + +##### Hello response + + +``` + | Type | rDevEUI | serverPubKey | serverNonce | + | 0x81 | 8 bytes | 64 bytes | 4 bytes | +``` + + + +##### Auth request + + +``` + | Type | rDevEUI | Encrypted Payload | + | 0x11 | 8 bytes | 52 bytes | + + | provisionIdHash | verifyCode | devNonce | + | 32 bytes | 16 bytes | 4 bytes | +``` + + + +##### Auth accepted + + +``` + | Type | rDevEUI | Encrypted Payload | + | 0x91 | 8 bytes | 32 bytes | + ​ + | devEUI | appEUI | verifyCode | + | 8 bytes | 8 bytes | 16 bytes | +``` + + + +##### Auth rejected + + +``` + | Type | rDevEUI | + | 0x92 | 8 bytes | +``` + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
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. + + + + + +![alt_text](/img/provisioning/lora-provisioning-spreadsheet-view.png "image_tooltip") + + +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. + + +![alt_text](/img/provisioning/device-provisioning-report.png "image_tooltip") + + +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 +``` + + + + + + +![alt_text](/img/provisioning/lora-provisioning-spreadsheet-view-1.png "image_tooltip") + diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/dhx/_category_.json b/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/dhx/_category_.json new file mode 100644 index 0000000..6f5f53d --- /dev/null +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/dhx/_category_.json @@ -0,0 +1,4 @@ +{ + "label": "Mining DHX", + "position": 4 +} diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/dhx/intro.md b/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/dhx/intro.md new file mode 100644 index 0000000..18d2c90 --- /dev/null +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/dhx/intro.md @@ -0,0 +1 @@ +# What is DHX \ No newline at end of file diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/intro.md b/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/intro.md index b92ff53..5e1be6f 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/intro.md +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/intro.md @@ -8,16 +8,32 @@ sidebar_position: 1 There are a number of ways for developers to interact with the MXC ecosystem. These forms of participation are integral to the further development and deployment of the MXProtocol. ## Direct Participation + +### Beta Testing +Beta testing new features before they are released is a great way to help us improve the overall user experience with our products. Here are beta opportunities currently available: + +| Product | Beta Type | How to Participate | +| --------------- | --------- | ------------------------------------------ | +| DataDash | Closed | [Instructions](tutorials/datadash/beta.md) | +| MXC Controller | Closed | *Coming Soon* | +| M2 Pro (MatchX) | Open | *Coming Soon* | + +*A beta version is pre-release and considered unstable. This means that you may experience some issues. Normally these will be minimal, however participating in an M2 Pro beta could potentially affect your mining. MXC Controller and DataDash betas will not have any influence on your overall mining potential.* + + +### Coding and Translating We have a number of public repos with active issues that could use assistance. Our team is still growing, and community support is always appreciated, encouraged and in some cases rewarded. -Here is an updated list of repos that could use assistance. +Here is an updated list of repos that could use assistance. * [DataDash App](https://github.com/mxc-foundation/supernode-app) [Flutter / Dart] + * [Translate the DataDash](https://crowdin.com/project/mxc-mobile-app) * [Developer Documentation](https://github.com/mxc-foundation/developer-documentation) [Markdown, Javascript] + * [Translate the Docs Today](https://crowdin.com/project/mxc-documentation) -We will continue to add repositories to this list as we work to increase transparency with our code and development process. +We will continue to add repositories to this list as we work to increase transparency with our code and development process. ## Manufacturing / Configuring Devices -Without devices the network has no purpose. Therefore, we've created an easy way for manufacturers to get involved with the network, making it possible for their devices to be deployed as a turnkey solution in the MXC ecosystem. +Without devices the network has no purpose. Therefore, we've created an easy way for manufacturers to get involved with the network, making it possible for their devices to be deployed as a turnkey solution in the MXC ecosystem. In order to increase security of the entire network, we've worked with MatchX to develop a novel provisioning concept for LoRa devices. This provisioning process is a requirement for any devices intending to be MXProtocol compatible. We have made this decision as: 1. Device provisioning increases the security of the device data @@ -27,7 +43,7 @@ In order to increase security of the entire network, we've worked with MatchX to You can discover more about device provisioning for the MXProtocol in Devices. ## Reporting Issues -Even though we attempt to do rigorous QA before every release, some pesky bugs still slip through. Actively reporting bugs is an extremely important form of participation, and helps us to improve the stability of the entire network. +Even though we attempt to do rigorous QA before every release, some pesky bugs still slip through. Actively reporting bugs is an extremely important form of participation, and helps us to improve the stability of the entire network. You can report bugs in the #bugs channel in our [Discord Server](https://mxc.news/discord) diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/m2-pro/intro.md b/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/m2-pro/intro.md index 743d33c..aa259e4 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/m2-pro/intro.md +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/m2-pro/intro.md @@ -2,4 +2,5 @@ title: Introduction sidebar_position: 1 --- + # The M2 Pro Miner \ No newline at end of file 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. diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/m2-pro/troubleshooting.md b/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/m2-pro/troubleshooting.md index 569c821..a397b99 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/m2-pro/troubleshooting.md +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/tutorials/m2-pro/troubleshooting.md @@ -2,4 +2,66 @@ sidebar_position: 5 --- -# Troubleshooting \ No newline at end of file +# Troubleshooting +Experiencing a problem with your M2 Pro? This tutorial will help you find it. Naturally you can also ask for help in one of our communities, or reach out for manufacturer support by writing [support@matchx.io](mailto:support@matchx.io). + +## Connectivity (uptime) +If your uptime is taking a hit, there's an easy way to find out if the miner is at fault, or your local network connection. To do that follow the following steps: +### 1. Access the M2 Pro Miner web interface +You can find the interface here: `http://yourSerialNumber.local` + * Your computer or phone must be on the same network as the M2 Pro Miner + * This URL works only on iOS, Win10 and Linux. It doesn't work on Android. +``` +Username: admin +Password: your serial number using all caps +``` + + + +### 2. View the miner logs: +1. After logging in, you can view or download your logs by clicking on `SysLog` in the menu ![log file structure](/img/troubleshooting/sysLog.png) + * If you're having an ongoing issue, you may want to download your logs regularly. The miner can only store logs for the past 48 hours, so if additional troubleshooting is needed, you should download your logs once every two days. +### 3. Reading the logs + +First step is to check if offline is happening due to failed heartbeat. Use the search/find function (ctl+f, cmd+f) and type in the word failure to see any failed heartbeat. + +This is the example of a successful heartbeat session. + ``` + Jun 29 04:58:09 M2XLCTRM3ZW daemon.info gwconfd[619]: Received hb response: fw conf + ``` +Here is an example of a failed heartbeat session. + +``` +Jun 29 04:56:07 M2XLCTRM3ZW daemon.err gwconfd[619]: Heartbeat api failure:4: Deadline Exceeded +``` +A failed heartbeat can happen due to many reason but the most common reason is an unstable network connection. To rule this out, you need to check if the internet connection is good. + +These are the list of common errors which indicates unstable, loss or bad internet connection. +1. Connectivity error from network issue +``` +Jun 24 06:49:53 M2XLCTRM3ZW daemon.err tlsDaemon[606]: Setup TLS error: TCP Connection error. +``` + +2. Unstable/dropping WiFi connection +``` +Jun 17 07:25:29 M2XLCTRM3ZW user.info kernel: CFG80211-ERROR) wl_is_linkdown : Link down Reason : WLC_E_LINK +``` +3. Internet connection loss +``` +Jun 13 15:05:50 M2XLCTRM3ZW daemon.info netMgmtDaemon[614]: Internet connection loss +``` + +In most cases, the issue is related to unstable internet connection at user's end and the miner is working fine (not a hardware issue). + +To isolate this further, you can try the following: +* If the miner is connected using wireless connection – try using wired connection. +* If wired connection is not possible – move the miner closer to the router as see if the uptime improves +* If both still not solving the issue - try putting the miner on a different network (such as, at friend's home). If the miner is working fine on another network, the issue is related to your home network connection. + +### 4. Checking LoRa Connectivity [in the LoRa Log menu option] +For LoRa, when you see that a miner is offline you can check on the Last Seen. This is pretty straight forward as you just need to search these two lines. If you get PUSH_ACK, that means it is fine. +``` +[2021-06-17 08:58:48.437] [loraMgmtDaemon] [info] INFO: [up] PUSH_ACK received in 43 ms +``` +This message is sent every 30 seconds. + diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/images/fig1_lpwan_comparison.png b/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/images/fig1_lpwan_comparison.png new file mode 100644 index 0000000..b481449 Binary files /dev/null and b/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/images/fig1_lpwan_comparison.png differ diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/images/fig2_dataflow.png b/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/images/fig2_dataflow.png new file mode 100644 index 0000000..e223f70 Binary files /dev/null and b/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/images/fig2_dataflow.png differ diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/images/fig3_MXProtocol_stack.png b/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/images/fig3_MXProtocol_stack.png new file mode 100644 index 0000000..e0e3584 Binary files /dev/null and b/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/images/fig3_MXProtocol_stack.png differ diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/images/fig4_mxp_smart_bidding.png b/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/images/fig4_mxp_smart_bidding.png new file mode 100644 index 0000000..067516d Binary files /dev/null and b/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/images/fig4_mxp_smart_bidding.png differ diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/images/fig5_anti_collision_coordinator.png b/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/images/fig5_anti_collision_coordinator.png new file mode 100644 index 0000000..2249468 Binary files /dev/null and b/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/images/fig5_anti_collision_coordinator.png differ diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/images/fig6_anti_collision_integration.png b/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/images/fig6_anti_collision_integration.png new file mode 100644 index 0000000..0523fca Binary files /dev/null and b/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/images/fig6_anti_collision_integration.png differ diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/images/fig7_inter_chain_market.png b/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/images/fig7_inter_chain_market.png new file mode 100644 index 0000000..a062843 Binary files /dev/null and b/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/images/fig7_inter_chain_market.png differ diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/images/fig8_LPWAN.png b/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/images/fig8_LPWAN.png new file mode 100644 index 0000000..48e0618 Binary files /dev/null and b/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/images/fig8_LPWAN.png differ diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/intro.md b/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/intro.md index 61c574b..adeb6a8 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/intro.md +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/intro.md @@ -2,6 +2,7 @@ title: Introduction sidebar_position: 1 --- + # MXC Whitepapers Overview of the WhitePapers \ No newline at end of file diff --git a/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/mxprotocol.md b/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/mxprotocol.md index 6768da7..b9c416b 100644 --- a/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/mxprotocol.md +++ b/i18n/zh-CN/docusaurus-plugin-content-docs/current/whitepapers/mxprotocol.md @@ -3,4 +3,511 @@ title: MXProtocol sidebar_position: 2 --- -# MXProtocol \ No newline at end of file +# MXProtocol (Machine eXchange Protocol): Premium Network Infrastructure, Infinite Data Stream + +## Table of Contents + +- [Machine eXchange Protocol: Premium Network Infrastructure, Infinite Data Stream](#machine-exchange-protocol-premium-network-infrastructure-infinite-data-stream) + - [1. MXC Vision](#1-mxc-vision) + - [2. Background](#2-background) + - [2.1 LPWAN vs other technologies](#21-lpwan-vs-other-technologies) + - [2.1.1 LoRaWAN](#211-lorawan) + - [2.1.2 NB-IoT](#212-nb-iot) + - [2.1.3 Deployment considerations](#213-deployment-considerations) + - [MXC economy](#mxc-economy) + - [3.1 Commerce network effect](#31-commerce-network-effect) + - [3.2 Asset-Backed Securitization](#32-asset-backed-securitization) + - [3.3 Data bloom](#33-data-bloom) + - [3.3.1 MXC-assisted garbage collection](#331-mxc-assisted-garbage-collection) + - [3.3.2 MXC-assisted car sharing](#332-mxc-assisted-car-sharing) + - [4. MXProtocol stack](#4-mxprotocol-stack) + - [4.1 Permissionless Blockchain](#41-permissionless-blockchain) + - [4.1.1 Features](#411-features) + - [4.1.2 Security and efficiency](#412-security-and-efficiency) + - [4.1.3 Long-term adoptions](#413-long-term-adoptions) + - [5. Smart Bidding](#5-smart-bidding) + - [5.1 Goals of design](#51-goals-of-design) + - [5.2 Design and implementation](#52-design-and-implementation) + - [5.3 Gateway status](#53-gateway-status) + - [5.4 Smart Bidding strategy](#54-smart-bidding-strategy) + - [5.5 Sensor Smart Bidding code](#55-sensor-smart-bidding-code) + - [6. Anti-Collision Coordinator](#6-anti-collision-coordinator) + - [6.1 Goals of the design](#61-goals-of-the-design) + - [6.2 Design and implementation](#62-design-and-implementation) + - [6.3 Third party integration](#63-third-party-integration) + - [7. Inter-Chain Data Market](#7-inter-chain-data-market) + - [7.1 Goals of the design](#71-goals-of-the-design) + - [7.2 Design and implementation](#72-design-and-implementation) + - [7.3 Polkadot and Aeternity](#73-polkadot-and-aeternity) + - [8. Smart Bidding use cases](#8-smart-bidding-use-cases) + - [8.1 Downlink resource auction](#81-downlink-resource-auction) + - [8.2 Network coverage market](#82-network-coverage-market) + - [8.3 Service market](#83-service-market) + - [9. Development progress](#9-development-progress) + - [10. References](#10-references) + +## 1. MXC Vision + +> The MXC vision is to introduce a systematic process to both simplify and increase IoT data transactions. + +The decentralized infrastructure upon which MXC’s system is based is the future of Low Power Wide Access Network (LPWAN) and the Machine eXchange Protocol (MXProtocol). Utilizing this solid device network foundation, MXC is introducing an extraordinarily unique coin offering, Machine eXchange Coin (MXC), which allows for increased data transactions and an idiosyncratic data flow monetization within the mammoth data market. + +MXProtocol places a keen focus on reducing collision between networks, constructing an inter-chain data market, developing a market for network coverage and introducing an independent Quality of Services (QoS) framework for both data providers and receivers. For the first time ever, individual network users, corporations and enterprises can all participate in the construction of decentralized, ubiquitous and secure LPWAN. Simply by connecting “anything” to the network, adopters will be able to profit and trade MXC. + +The trading network is built on the premise of the “sharing economy.” Therefore, it is uniquely and exclusively owned by users — both individuals and enterprises — who take advantage of the monetization of the network in two ways: + +1. By increasing uplink and downlink coverage via a Gateway, e.g. a MatchBox LPWAN Gateway, Cisco LPWAN Gateway +2. By unleashing access to a massive network of published and traded data to the marketplace which is securely traded using blockchain technology + +Both sensors and connected devices bid (via the integrated QoS) for the downlink network resource to, for example, unlock a door or, alternatively, shut down a faulty radiator, subsequently offering a market-devised price for the uncovered regions. This ultimately increases data network coverage. “Things” can autonomously pay each other with MXC tokens and get accredited by sharing the data with different users/marketplaces. + +There has been a phenomenal increase in the sourcing, collection and transmission of big data within the past five years. Additionally, the increasing use of artificial intelligence feeding off this data has assisted people to simplify tedious tasks and to make better informed decisions on everything from projecting a weather forecast, to saving household energy, to even choosing the right music to play at home. The tone has now been set for decades to come. Machines interacting with one another has seen a significant increase over such a short period. This will only increase as our interdependency on machines and machine learning grows and becomes ever more significant in day to day life. + +Whether for individuals or big companies, the need for a specified network concentrating on machines and machine data is here to stay. It will play a bigger part in supporting both individuals and businesses than ever before. MXProtocol introduces the next generation of LPWAN with a superior IoT data platform and a premium network experience, allowing for a simplified and expedited way to create a secure and efficient solution for IoT. + +The following sections elaborate on the unique advantages of MXProtocol, including its components — permissionless blockchain, Smart Bidding, Anti-Collision Coordinator and Inter-Chain Data Market — that make it a truly innovative technology. + +## 2. Background + +MXC is a German non-profit organization based in the country’s start-up and blockchain capital, Berlin. MXC is partnering with various LPWAN companies. MXProtocol is a revolutionary design that solves the problem of LPWAN and bridges the data gap between different infrastructures. + +IoT is a hot topic that has been intently discussed for over a decade. The one focus and premise of the IoT network is connecting “things” to the Internet and collecting/using this data from the objects that can’t speak for themselves. The application of this new founded, increased data is highly limited due to the current methods offering low range and high power consumption. For example, standard WiFi can generally reach an absolute maximum of around 100 meters, and using 3G/4G consumes a significant amount of power, thus reducing effective battery life and increasing maintenance costs significantly. The fact is, current implementations for data networks are extremely expensive and offer very low usability. The need for a new technology is here and the need for LPWAN will only increase as it solves the current problems of low range/high cost data transmissions. + +The fact is, current implementations for data networks are extremely expensive and offer very low usability. The need for a new technology is here and the need for LPWAN will only increase as it solves the current problems of low range/high cost data transmissions. + + + +
+ LPWAN +
+ +### 2.1 LPWAN vs other technologies + +LPWAN technology emerged to the forefront in recent years with the goal of finding a better data transmission solution to the shortfalls of WiFi, Bluetooth and 3G & 4G networks. These earlier established networks were originally targeted at connecting people, not at connecting the data generated by “things.” The amount of machine-generated data has multiplied significantly in recent times. The new LPWAN technology offers aspects where others simply can’t compete: + +- 10 year sensor battery life +- 20 km data reach with just a single Gateway +- Offers an extreme amount of connection points (over 60,000 for a single network cell) supported by LPWAN Gateways at an extremely low cost + +Now, when compared to the current wireless network, it’s easy to see the superior advancements that the MXC solutions offer. As illustrated in Figure 1, LoRa and NB-IoT are simply the most potent solutions on the LPWAN market. + +#### 2.1.1 LoRaWAN + +LoRaWAN is an open-source protocol defined by the LoRa Alliance, which is already supported by industrial giants such as Cisco, Alibaba, Comcast, IBM and SK Telecom and many more. Advantages of LoRaWAN are 20 km open space coverage, low data rates (low-level kbps) and ultra-low power, allowing for 10 years continued operation on a single battery. + +Both the Gateways and end sensor devices use the LoRaWAN protocol. In fact, devices of any brand are supported and can be connected to the network as long as they are LoRa/LPWAN compatible. + +#### 2.1.2 NB-IoT + +NB-IoT is a narrowband radio technology specified by 3GPP as a licensed telecommuni- cation protocol. NB-IoT focuses specifically on indoor coverage, low throughput and long battery life, enabling a large number of connected devices. + +The advantage for an MXC IoT user is that it gives an individual the power to host their own network wherever and whenever they like. Compare that with the NB-IoT base stations (which are owned by telecommunications conglomerates) which charge users expensive SIM card fees to send data messages over the Internet through NB-IoT protocol. MXProtocol supports all LPWAN technologies, developed LoRaWAN Gateways, NB-IoT and LoRaWAN sensors. That’s decentralization. That’s yet another MXC advantage. + +#### 2.1.3 Deployment considerations + +When deploying LPWAN, the first consideration is understanding how to avoid a col- lision between different competing networks residing in the same region. Generally, the issue comes from the fact that both may use the same channel to send out the message at the same time and leave the other available channel empty due to the chosen preferences. As a result, it’s generally hard to reach a consensus between these networks and thus the deployment suffers as network usage increases. The decentralization and distributed mech- anism of MXProtocol solves this issue by coordinating the networks. The network evolves by having users pay micro-payments for the resources that another one offers. + +The second concern is due to the shortage of downlink resources for the dense sensor/ end device deployment. Usually there are some sensors/end devices which require no downlink or can bear with the loss of downlinks. This is usually associated with low-activity sensors, such as garbage bins or electricity meters. However, end devices like bike locks or location tracker devices need to receive regular and reliable confirmations from the cloud for every uplink. Hence, they are willing to pay a premium for this reliability and a QoS provided by the networks. MXProtocol provides this bidding resource, ensuring that, for example, a garbage bin sensor won’t take first preference over the vital downlink resource of something like a bike lock. + +Another consideration pertains to the requirements for multi-national cooperations (MNC) and small to medium enterprises (SME) trading their data assets publicly generated using LPWAN technology. Within LPWAN, both the data stream and asset trading features are simplified, easy to read and can be digitally transmitted from many kilometers away. This makes the data exchange a clear necessity for the needs of the LPWAN market of tomorrow. + +With respect to the needs of MNCs or SMEs, it’s likely that such enterprises will wish to deploy their own LPWAN to cover an entire city or a region for its own specific applica- tions such as asset tracking (e.g. automobile) or sensor data management. This is a perfect solution for “Big Business.” LPWAN technology delivers via its long reach ensuring that sensor/end device uplink packets are securely received as per the protocol design. + +This leads to one of the key aspects of the MXProtocol: bringing the monetization of data services to the forefront. Using the MXProtocol, micro-payments within the LPWAN infrastructure will be traded from third party sensors/end devices, ensuring data is conveniently, correctly and concisely transmitted in a secure manner, whilst being maintained by the support of system administrators. The industry has been waiting for a decentralized and consensus-based mechanism to improve the usability of LPWAN, and MXC is delivering. + +MXC has designed this next generation LPWAN infrastructure using MXProtocol in order to significantly boost the applications of blockchain and IoT within the real-world context. + +## MXC economy + +Machine eXchange Coin (MXC) offers a unique and specifically designed decentralized technological “Data Trade Network” to the global Token economy. Data can be shared on a mass scale whilst ensuring complete end to end privacy. The MXC intends to be distributed amongst data owners, data receivers and data network hosts, allowing for a facilitated cross-over from a “commodity” based Coin into an everyday trading Coin currency. + +### 3.1 Commerce network effect + +Machine eXchange Coin is the first Token designed to bridge current commodity-based trading of cryptocurrency tokens and the cash-based global economy. Utilizing the “sharing economy,” MXC uses this as an axis, allowing large businesses, SMEs and individuals to borrow or rent assets owned by someone else. + +Individuals place LoRa-based protocol hardware in opportune positions in order to benefit and profit from their locations and their decentralized LoRaWAN network. Businesses benefit by using these user-based networks to send sensor/device data, building a new “sharing economy.” Wallets are stored in the cloud allowing individuals to profit from businesses sending sensor data via their LoRaWAN LPWAN. The coins are then sent and traded from the sensor holders that MXProtocol addresses to the Gateway distributor. + +MXProtocol gives network participants incentives to use, deploy and trade their network elements. In addition to that, it is a people-owned secure and private network that won’t suffer from public congestion like what Ethereum encountered with cryptokitties. + +### 3.2 Asset-Backed Securitization + +MXC has been highly successful with regards to the design and production of high-end LPWAN hardware. Using the coins and sharing economy will allow for a massive influx of shared sensor data amongst individuals and companies, giving better insights into consumer behavior, environmental impacts and machine-based optimizations. + +With MXC, Asset-Backed Securitization (ABS) adds a completely new way for individuals and companies to both trade and manage their data and physical assets. Current methods see sensitive data easily being passed and reproduced to a number of parties without any of them knowing that the data has potentially already been corrupted, seen and/or shared amongst potential competitors/untrusted parties. MXC makes it possible for corporations and individuals to track both physical goods and intangible data, ensuring that buyers/ receivers of the goods are the only party who have received the data/physical good, and for this information to come from a qualified and reliable source. + +By applying ABS, the individual data is allocated to one dedicated source. In contrast, a buyer of a tangible paper certificate, for example, has no way of knowing that the same certificate hasn’t been sold/reproduced and assigned to potentially multiple parties. + +### 3.3 Data bloom + +MXC is a blockchain-based decentralized platform designed to revolutionize three core functions based around the basic financial theory: Lend, Send and Spend. + +#### 3.3.1 MXC-assisted garbage collection + +The future is here. The one constant in everyone’s life from now on will be the data surrounding all of us. In the past such a statement referred to “people-generated data.” However, times have changed. “Machine-generated data” is taking over at a phenomenal rate. + +The beauty of machine-based data, when compared with human-based data, is it doesn’t sleep. Machine-based data is constant and it’s reliability is unmatched when compared with any people-generated data. So why is this important? + +Take, for example, a local city council. Their task is to ensure safety, security and general well-being of the local city. One of these responsibilities includes simple tasks such as garbage collection. The simple act of emptying city trash may seem like a monotonous task, but it in fact requires planning and chain management: When do collections occur? How often should trash collections occur? How many employees are required to empty garbage cans across the city? MXC simplifies such tasks using MXProtocol. + +Using sensor/end devices situated in garbage cans and allowing them to transmit device data via a Gateway allows the city council to detect the levels of garbage built up within the can. What does this mean for the council? + +- Saving fuel: The council only needs to send out garbage trucks when necessary, as opposed to sending out trucks to check cans, irrespective of whether they are full or even completely empty. +- Saving wages: By only sending out employees at the moment a garbage can needs to be emptied, the council can then reallocate human resources, thus saving employee wages. +- Reducing traffic congestion: Garbage trucks are often frustrating for commuters. When parked on the side of the road, they can increase general traffic significantly. Being aware of the need for garbage removal in certain areas can reduce the need for trucks and allow for smoother traffic flows. + +Many of these highlighted aspects make up the chain of events associated with what are deemed to be “menial tasks” but, as shown, the flow on effect is quite significant. MXC IoT is ready to solve such issues, allowing for simple tasks to be categorized and ensuring exact resources are allocated only when needed. + +#### 3.3.1 MXC-assisted car sharing + +Using LoRaWAN sensor/end devices and Gateways can also reduce the cost of car sharing partners. + +Covering an entire city center in LPWAN allows individuals to simply build their own completely independent network, free from telecommunications companies and net- works charging exorbitant costs. + +The benefits of doing this for a company such as a “car sharing” company allows them to track their vehicles without the need to depend on Telecommunication coverage. Using LPWAN significantly reduces the costs, especially when compared with the costs of tracking using a SIM card. + +In addition to GPS tracking, car doors can be locked and unlocked using LPWAN, increasing security for users, all at a very low cost compared to current methods. + +By bringing such key services, MXC provides transparency and greatly enhances customer experience. MXC’s mission is to intensify data sharing whilst forging a unity between those with finance and data service needs and those without finance but who have private access to network integration and distribution, thus eliminating borders, intermediaries and prejudices. + +MXProtocol focuses on three foundational pillars: + +- Extend and support the massive device data economy +- Utilize the decentralized “sharing economy” +- Trade of assets within the current coin economy + +MXProtocol connects “things” utilizing a market-based economy, which adds a plethora of new transmission points allowing more data to be shared, traded, sold and analyzed for data mining. + +Within the new decentralized MXC economy, everyone can profit from the sharing of data; end to end encryption grants authorized usage of the data; and entire communities can benefit from using their locations to act as a network facility to transport this data — trading assets, profiting from the coin economy. + +## 4. MXProtocol stack + +MXProtocol infrastructure consists of both sensor and end devices, Gateway and cloud. Sensors and end devices collect data from “things,” and send to the cloud via the Gateway. This is uniquely designed to specifically be a decentralized solution allowing for everyone to suit their/the market’s needs. The usability of the hardware has been specifically designed as a “plug and play” solution, making installation simple without the need for a professional configuration. It is designed to be easy to set up and easy to share data. + +As the flow in [Figure 2](#fig2) demonstrates, LPWAN Gateways connect to each other to form either a mesh network as a collective cloud or the Internet. The sensors or end devices communicate with Gateways using LPWAN technology for bi-directional communication. Notably, the sensors and end devices are not purely limited to a single LPWAN product. In fact, any LoRaWAN compatible sensors are able to connect to the LPWAN network and can start sending and receiving messages. + + +
+ dataflow +
+ +MXProtocol facilitates the data and value flow of the LPWAN. Inside this ecosystem, each sensor or end device has a MXC wallet address assigned to an individual user. This is required in order to both pay for the network usage and to receive money from selling the data and services. The sensor wallet is stored in the cloud in order to maintain the LPWAN low-power requirements. This is also due to the fact that the CPU is usually resource-constrained. The same wallet is used as the Gateway wallet (also found in a user account and stored in the cloud). This wallet will receive coins from uploading/downloading the data from the cloud to the sensor and assists in paying for the other LPWAN’s resource or data. + +Coinciding with the current LPWAN infrastructure protocol, the data link between the Gateway and sensor end devices is unregulated. As a result, there would be no possibility to be rewarded for forwarding data from the sensor to cloud via the Gateway, and ultimately the downlink resource would be limited, only being allocated on a “first come, first served” basis. This system as is would negatively impact low-level data procurement services offered by things such as a door lock or car charging station system and would result in the data link not being appropriately monetized. MXC LPWAN infrastructure solves such issues, delivering the ultimate user experience to SMEs and MNCs. + + +
+ dataflow-mxprotocol +
+ +[Figure 3](#fig3) shows the detailed technical stack of the MXProtocol infrastructure. The decentralized and autonomous LPWAN can be built on any permissionless blockchain, such as IOTA, Stellar, Skywire and NEO. + +Based on this, the Anti-Collision Coordinator between LPWANs, Smart Bidding and Inter-chain data market are introduced to answer the LPWAN deployment considerations mentioned in the previous chapter [see 2.1.3](#213-deployment-considerations). + +### 4.1 Permissionless Blockchain + +There are various kinds of blockchain. Anyone can use cryptographic keys, anyone can be a node and join the network, and anyone can become a participant to service the network and seek a reward. Participants can walk away from being a node, return if and when they feel like it and get a full account of all network activity since they left. + +In a permissionless blockchain, anyone can read the chain, anyone can make legitimate changes and anyone can write a new block into the chain as long as they follow the rules. Decisions on a permissionless blockchain are made by the network participants. The protocol is based on a consensus protocol. The permissionless blockchain provides a way to reach consensus without relying on a closed system to accurately record financial transactions. + +#### 4.1.1 Features + +MXC built MXProtocol as an inclusive platform where all participants are encouraged to contribute. MXProtocol is a distributed network protocol backed by monetization of the resources and incentives from enterprises and individuals based on permissionless blockchain. The permissionless blockchain design makes MXProtocol efficient and independent: the more people use it, the more robust the network will be. + +The blockchain should have four key properties: decentralized control, low latency, flexible trust, and asymptotic security. In other words, MXProtocol should run on a permissionless blockchain that has: + +- A true decentralized network. +- It has eliminated mining rewards. +- All transactions get confirmed quickly. +- There is an anti-spam role. There should be a preventive measure against nefarious users flooding the network (a DoS attack). + +#### 4.1.2 Security and efficiency + +Often, the speed and privacy of a network is the concern for SMEs and MNCs. Public blockchains, such as Ethereum and Bitcoin, often suffer from big computing slow downs, practically grinding the systems to a halt, leading to a situation where the whole network and the 51 percent resources can attack the blocks. There should be a blockchain providing more privacy and efficiency for businesses and individuals collectively. MXProtocol needs to be run on a secure and efficient blockchain that can provide the devices with good connectivity. + +The MXC-introduced LPWAN application requires further fragmented and discrete transactions for sensitive data and services in an IoT realm. That is why MXC continues to develop upon the permissionless blockchain, making MXProtocol more efficient and more suitable for the needs of LPWAN and IoT applications. + +#### 4.1.3 Long-term adoptions + +As previously stated, MXProtocol is a LPWAN platform protocol that brings efficiency and robustness to the users. There are, however, still several components inside permissionless blockchain itself that MXC feels necessary to emphasize. For example, to ensure the long term stability of the LPWAN IoT projects, continued research is still required with regards to the current data interface. Real field deployment will need to be conducted in order to properly satisfy the plethora of data streams connecting from the LPWAN sensors/end devices and ensure they are routed to the network seamlessly. + +## 5. Smart Bidding + +Due to governmental regulations of the LPWAN spectrum, the downlink is a precious resource that is closely guarded by sensors and end devices. The majority of the world uses eight downlink channels for acknowledgement or confirmation of the sensor data, and each channel usually has to wait anywhere from a few milliseconds up to a few minutes in order to send another packet. + +The downlink channels are fixed in the protocol and code, and the waiting time for each downlink is dependent on the data rate of the sensor/end device. A key side note to this point is that LPWAN Gateways use the latest in “Listen Before Talk” technology allowing them to send data more regularly. This means that data may be sent when the channel is free, and therefore doesn’t have to wait for a specific time period to elapse. + +### 5.1 Goals of design + +To further overcome such industry-wide issues, MXProtocol implements a bidding mechanism, designed to bring the needed resources to those devices that are willing to bid the most. Generally public LPWAN deployment is pushed by both individuals and corporations who do so in order to extend their own individual network reach. Introducing a bidding mechanism will cause network reaches to multiply due to the fact that users can both earn and learn from the data that are sent by the sensors. The purpose of this section is to examine the Smart Bidding design that would support a well-functioning LPWAN ecosystem. The goals of the design are to: + +- Allocate downlink resources adequately +- Allow all sensors/end devices to compete on a market platform for network resources +- Offer network deployments incentives, assisting them to monetize +- Ensure LPWAN services are monetized +- Power the decentralized ledger with MXProtocol to simplify and resolve any issues + +### 5.2 Design and implementation + +There are different bidding models, ranges and methods to be set in Smart Bidding. The goal is to assign the network resource to the highest bidder. The design and functionality of the Smart Bidding process is proposed in [Figure 4](#fig4). Sensors/end devices bid on one single downlink channel out of the eight available on the LPWAN Gateway. The Smart Bidding code sensors/end devices are hosted on the cloud code, enabling them to place a bid. The LPWAN Gateway then provides the status of the network and provides resources to the sensors/end devices. + +In the example illustrated in in Figure 4, there are three sensors/end devices are bidding on one single channel for the downlink resource. The sensor on the right doesn’t participate in the auction due to the specification of its code. Let’s say this is due to the sensor that is used for a minor purpose, e.g. to monitor a garbage can or electricity meter, so the downlink confirmation can acceptably be lost. This leaves the other two devices to bid for the downlink. In this case, the door lock wins the auction. Should the downlink arrive, the payment is then automatically sent from the sensor wallet to the Gateway wallet which provided the resource. + +Usually one Gateway offers eight channels for the sensors/end devices to bid and the prices change dynamically due to the status of the Gateway, or alternatively, the willingness of the sensors. + + + +
+ MXP-smart-bidding +
+ +### 5.3 Gateway status + +Sensors and end devices will already be aware of the status of the Gateway in advance in order to make an appropriate bid for the resources and the services that provided by the network. To motivate the network administrator to maintain a robust LPWAN, we define the following metrics of the Gateway to let sensors/end devices to bid for the dynamic prices: + +- Mean time between failures (MTBF) +- Number of downlink packets sent +- Gateway density +- List of services available + +The first key parameter used to measure the stability of a Gateway on the network is determined by measuring the down time. It is recommended that a smaller MTBF be used than a larger one, because of the QoS that is required for the sensors. Thus, the high QoS sensors/end devices are willing to pay for the more stable LPWAN Gateways. + +The number of downlink packets sent by the Gateway represents the popularity of the device. This usually means the end devices/sensors around the Gateway are dense. If a sensor requires a downlink from the Gateway, which has a high number of downlink packets, it will need to place a higher bid or increase the overall bidding range accordingly. + +Gateway density is a parameter which is expected to motivate network administrators to deploy more Gateways in the areas that have little to no coverage. As demonstrated, it’s already clear that sensors will be willing to pay for low Gateway density with higher prices. Low density means the downlink channels and the services are limited and that the prices will be high when sensors are competing with each other. Overall, it’s expected that this metric will push people to expand the network in order to provide better network access to the LPWAN devices. + +From time to time, LPWAN will provide a list of services, e.g. firmware upgrades, GPS-free localization, network configuration optimization. This allows all hardware to be regularly kept up to date. Sensors and end devices would then choose from the Gateway bids for services, combined with the MTBF and the number of downlinks sent for the auction. + +### 5.4 Smart Bidding strategy + +The following are the standard auction methods found in the system: + +- Auction + - Increase: When the initial bid fails, an increased bid is made in order to secure the auction. + - Decrease: Similar to the Google Keyword style bidding auctions, the user states their bidding range. The system then states (considering all factors) the nec- essary bidding rate. In many instances, this will save customer coins. +- Fixed price + - The network resource or service are offered at a fixed price, with limited or unlimited quantity. Sensors/end devices just pay per use. +- Quantitative purchase + - The network resource or service are bid by quantitative metrics, like a period of time for downlink resource, the region of a whole city’s downlink and the amount of resources that are needed. + +### 5.5 Sensor Smart Bidding code + +Sensors and end devices are programmed with a snippet of code to enable them to bid for network resources and services that are provided by Gateways. This is implemented on the cloud so third party sensors can still use the logic easily by porting the code. There are several parameters to receive from a Gateway in advance, such as the density of the deployment and the list of services that are available to the sensors, just to name a few. + +After the information has been obtained by the Gateway, sensors would bid for resources of the service according to the type of the auction. For example, a bike lock would bid for a downlink resource using the increase method. This specifies the range of the coins that the bike lock is willing to pay for each transaction and the market dictates the end price. + +A dedicated technical white paper about the logic, design and implementation of the Smart Bidding will be released and the APIs with documentation will be available on the MXC website. + +```cpp +bid bike lock { + + /* Define the willingness to pay for the services or resources */ + type bidder + + /* Define the gateway status it will use for the auction */ + struct gw { + uint mtbf; + uint numdl; + uint density; + address service; + } + + address lock1; + gw[] gwstats; + + /* Parse the status that received from the gateway */ + function Parse(gwstats) public { + gwstats [ lock1 ] = msg. sender + lock1 = gwstats [ lock1 ]. service + } + + fuction bid(coin) constant returns (bytes32) { + coin.maximum = 10 + coin.minimum = 6 + auction.type = liner + auction.block = once + + return coin + } +} +``` + +## 6. Anti-Collision Coordinator + +With the increasing amount of LPWAN field deployments, the problem of network congestion is anticipated to rapidly increase. This is especially so when the network coverage targets ultra-long ranges of 20 km or more. + +In 2020, there are expected to be more than 75 billion devices connected to the Internet. If the majority of these are to use LPWAN, it can be assumed that it would put quite a strain on the network resources. As a result, MXProtocol infrastructure has bridged the gap between different networks using the innovative protocol. + +### 6.1 Goals of the design + +> The MXProtocol also offers a general overwhelming consensus for all public LPWAN by adding a community-based consensus, permissions and deployment permission etiquette. + +Here we define the goals of the design for the LPWAN ecosystem: + +- Minimize packet collision for uplinks in the same region deployed with multiple networks. +- Allocate new resources to the sensors/end devices that need downlink for the networks. +- Enable individual networks to pay for other networks resources and services, i.e. network roaming. +- Settle all monetary transactions in MXC. + +### 6.2 Design and implementation + +The design of the Anti-Collision Coordinator is illustrated in [Figure 5](#fig5). The coordinator has two responsibilities. The first is to make payments between networks using MXC. The second is to coordinate between networks about the downlink and uplink status. In the example illustrated in [Figure 5](#fig5), we see the door lock has successfully bid the downlink from the MXProtocol at downlink channel 1. However, the network that deployed over 1 km is also using the downlink channel 1 for the garbage sensor, and the pending collision is obvious. The solution would be that the Anti-Collision. + + +
+ anti-collision-coordinator +
+ +Coordinator would pay for Cisco’s network resource, allowing the Gateway to pause downlink channel 1 for this time’s message, thus allowing the door lock to receive the “unlock door” confirmation from the cloud. + +On the other side, the two networks report each other’s uplink lost message, since the LoRaWAN protocol has the counter for the uplink. Later, the coordinator finds out that the majority of the packets that are lost come from both street lighting and the parking meter due to the fact that their sending intervals are overlapped and they are quite close to each other. + +The coordinator then delays the street light’s sending interval or, alternatively, it changes the data rate to make sure that they won’t collide with each other, and the fees for a delay should be paid by the parking meter. Such network coordination is expected to occur quite often when future deployment of LPWAN sensors becomes more dense. Thus, the Anti-Collision Coordinator solves the problem of the network resource allocation in free-licensed bands completely. + +### 6.3 Third party integration + +The Anti-Collision Coordinator is indeed a protocol plug-in for the LoRaWAN server to control the Media Access Control (MAC) layer of LoRaWAN uplinks and downlinks. + +There are two ways to integrate the Anti-Collision Coordinator into the LPWAN server. First is to run the full node which integrates the anti-collision mechanism into the protocol layer like illustrated in [Figure 3](#fig3). Another solution is to run a light node with the anti-collision module that could be compatible with all the LoRaWAN servers. + +As [Figure 6](#fig6) shows, the Anti-Collision Coordinator is essentially a plug-in for the other LoRaWAN servers that is compatible with LoRaWAN protocol. The plug-in is a protocol enhancement that controls the uplink and downlink based on the payment logic and resource requirement between two or more networks. + +A light node connects to the full node to assign the LPWAN a wallet for sending and receiving MXCs. The Anti-Collision Coordinator controls the MAC layer for all the LoRaWAN devices. A separate white paper will be released about the protocol design of the Anti-Collision Coordinator and its APIs for LoRaWAN servers. + +
+ anti-collision-third-party-integration +
+ +## 7. Inter-Chain Data Market + +Currently, there are several traditional data markets that originate from cryptocurrencies, e.g. Streamr, IOTA and Mobius. All provide a secure mechanism to make sure that the data stream can be copied and transmitted from the owner to the consumer in a sequential manner. + +Most cryptocurrencies are in need of data. This data is fed into the system to provide checks and balances, ensuring all players along the chain have performed their role correctly. For example, a smart contract specifies which goods need to be delivered from city A to city B and this requires the buyer to pay the seller, e.g. 10 ETH. So, how can one determine whether the goods have been successfully delivered? The smart contract must rely on external Oracles from either the GPS data from the package or the LPWAN tag reading from the warehouse. + +> The entire industry continually requires chains such as Mobius or MXC to feed other chains smart contracts and the interdependent information to the applications. + +Oracles are third party services which are not part of the blockchain consensus mechanism. The main challenge with Oracles is that people need to trust these sources of information. Whether a website or a sensor, the source of information needs to be consistently trustworthy. In order to solve these issues, Oracles have different trusted computing techniques. + +### 7.1 Goals of the design + +Blockchains support Oracles in order to assist with fetching external data. The reason for this comes from the fact that blockchain applications, such as Bitcoin scripts and smart contracts cannot access and fetch data directly. As a result, they require pricing feeds for assets and financial applications and weather-related information for peer-to-peer insurance, all written with smart contracts. Here we define the goals of the MXProtocol data market with respect to designing for Oracles: + +- Facilitate data usage between different blockchains +- Establish a trusted resource for the external Oracles +- Stack up the data for later purchase +- Enable purchase of a live data stream +- Provide APIs for non-blockchain applications to access the data +- Settle all monetary transfers within MXC + +### 7.2 Design and implementation + +The MXProtocol Inter-Chain Data Market provides an effective method to feed the other smart contracts with LPWAN data captured by sensors or end devices. + + +
+ inter-chain-data-market +
+ +[Figure 7](#fig7) shows the example of the transaction between MXProtocol data and blockchains like Ethereum. + +MXProtocol feeds data to Ethereum smart contracts, and gets Ethereum payments as rewards. It only requires a simple protocol to trust that the data fetched from the MXProtocol data source is genuine and untampered. In addition to that, the rich data stream can also be used by external non-blockchain applications via Web APIs. + +Major block chains like Ethereum are short in data for smart contracts, and the data that is provided by external Oracles essentially may not be trustworthy. With the MXProtocol Inter-chain data market, the generation and flow of the data can be tracked and verified publicly on the chain. Hence, the security issue is solved internally with MXProtocol. + +### 7.3 Polkadot and Aeternity + +Polkadot is essentially a protocol that communicates between different networks. It solves consensus and transaction delivery between different chains. + +Aeternity is created to be the interface between real world data and smart contracts. Instead of using Oracles that can cause a single point of failure, Aeternity’s design provides decen- tralized infrastructure for holding and transferring the data to smart contracts. + +The MXProtocol Inter-chain data market uses the idea and mechanism developed by both Polkadot and Aeternity to deal with consensus, privacy, transaction delivery and security. A separate white paper will be released about this design. + +## 8. Smart Bidding use cases + +### 8.1 Downlink resource auction + +Downlink resource auctions occur when it is the only option for the Gateways to decide which sensor/end devices to communicate with. The Gateway usually has eight downlink channels, supporting more than 60,000 sensors that need to be acknowledged in sequence. Uplinks are free for the sensors since all the Gateways will pick up the packets and forward them within the same network, and the Anti-Collision Coordinator needs to pay the other network when collisions need to be avoided. The downlink resources need to be allocated to some sensors that need downlinks to execute the commands ([See Figure 8](#fig8)). Smart Bidding codes decide the willingness for the sensor/end devices to pay for the resources, and all the transactions are settled in MXC. + +Both the European and U.S. radio committees impose regulations on the spectrum access for LPWAN radios using 868/915Mhz bands. These regulations cover issues from maximum time on air to maximum duty cycle, which, in turn, introduces waiting times between two packets. For Gateways without Listen-Before-Talk Technology, this waiting time can range anywhere from a few milliseconds to minutes depending on the data rate and number of bytes being sent. + + +
+ LPWAN +
+ +Currently, the downlink resource is distributed on a “first come first served” basis, which can lead to many potential problems for various devices. For example, if an electricity monitoring meter were to get downlink priority over a door lock, the door lock in turn doesn’t receive the confirmation to unlock the door. The MXProtocol Smart Bidding solves this problem as covered in the following two aspects: + +- Allocate the downlink resource within the same LPWAN using the Smart Bidding code snippet for the auction. +- Enable different networks to trade for the downlink resources for the sensors/ end devices that are willing to pay. + +The snippet of code inside the sensors/end devices decides the market prices of the LPWAN. For a dense Gateway deployment like a city center, the prices can be lower due to the abundant resources of the downlink channels available. While in the mountains or suburban areas, few sensors would compete for the downlink resources and thus the prices will rise. The sensors will bid according to the MTBF, downlink numbers and the density of the network. + +The auction method and logic behind the bidding can be programmed by the owner of the sensor. It is expected that AI-driven algorithms will later be introduced to offer smarter bidding strategy for the sensors and end devices. + +### 8.2 Network coverage market + +It is expected that the supply of downlink resources will gradually increase with the demand of the sensors/end devices. The bidders will pay for the high prices for the lower Gateway density, which gives SMEs and MNCs incentives to expand the network coverage to get more MXC coin rewards. + +Figure 6 illustrates the market placed by Smart Bidding codes. The prices are lower at the dense deployment where the two LPWAN coverages overlap, and higher where there is only one LPWAN coverage. + +Some sensors travel around the city. Their code specifies the maximum amount of coins that it would like to pay for a single downlink. However, they have been to the places where no LPWAN coverage is available. Once they are back to the network, they put the last off-chain bid to the chain, and notify the whole network that they are willing to pay a pre-determined price from the Smart Bidding code. + +The prices and the amount of off-chain bids will surely motivate companies and individuals to deploy the LPWAN Gateway to the field, thus expanding the network coverage for the chain. MXProtocol shifts control from telecommunication conglomerates to companies and individuals by allowing them to deploy their own LPWAN. + +### 8.3 Service market + +There are lists of services that LPWAN can provide to the sensors/end devices. For example, an Over-the-air firmware update should be multi-casted to the sensors with downlink and it requires the sensors to bid for the resource. + +The most attractive aspect of the LPWAN is to implement GPS-free localization, which also works indoors and underground. In contrast to GPS or SIM card’s high power consumption and limited reach, LPWAN localization uses the packets sent by the sensors to calculate the position, which requires no computation from the resource-limited sensors. + +Such a service requires the resources of both a Gateway and the cloud. Hence, the Smart Bidding code will specify whether it is willing to pay for the service and its accuracy. The more Gateways that receive the packets, the more accurate the position will be. + +LPWAN sometimes needs to change the channel configurations like the arrangement or the allowed data rate. This kind of coordination will need to be applied globally and the network will have to try to synchronize such a configuration as much as possible. Smart Bidding can also accept “free auctions” where they require no one to pay. + +Through the MXProtocol Smart Bidding design, it is possible that sensors/end devices pay for the services that the network offers to them. The outcome of the design will be: + +- Some sensors/end devices get the services and the resources that they demand through auction +- Network deployment receives reward by offering services and resources to the LPWAN sensors/end devices +- All the monetary transactions are done automatically in MXC without human intervention + +## 9. Development progress + +MXC Foundation’s partner MatchX has released the MatchBox LPWAN Gateway, and the LPWAN module with development kits. It has reached more than 40 countries with distributors in Australia, North America, Asia and Europe. + +The first Proof-of-Concept has been performed in conjunction with the Stellar Development Foundation, utilizing the LPWAN coverage and enabling sensors to pay with each other. + +## 10. References + +- _What is LPWAN (low-power wide area network)?_ - Definition from WhatIs.com. (2018). IoT Agenda. Retrieved 8 January 2018, from +- _LoRa Alliance._ (2018). LoRa Alliance. Retrieved 8 January 2018, from +- _Skywire and Viscript | Skycoin Blog._ (2018). Blog.skycoin.net. Retrieved 8 January 2018, from +- _Skywire - Skycoin Meshnet Project | Skycoin Blog._ (2018). Blog.skycoin.net. Retrieved 8 January 2018, from +- _contributors, S._ (2018). Create an Account | Stellar Developers. Stellar.org. Retrieved 5 February 2018, from +- Kusmierz, B. (2017). _The first glance at the simulation of the Tangle: discrete model._ +- Popov, S. (2016). _The tangle._ IOTA. +- Kim, J. (2014). _Introducing Stellar - Stellar CN._ Stellar CN. Retrieved 5 February 2018, from +- _Ethereum Project._ (2018). Ethereum.org. Retrieved 8 January 2018, from +- _RSK._ (2018). RSK. Retrieved 8 January 2018, from +- Dudley, J., Hochstetler, G., Dudley, J., Hearn, M., Hearn, M., \& Hearn, M. (2018). _Corda: Frictionless Commerce._ corda.net. Retrieved 8 January 2018, from +- _LoRaWAN in Europe._ (2017). Matchx.io. Retrieved 8 January 2018, from +- _LoRaWAN regulations in Korea, Australia, India Japan and South East Asia._ (2017). Matchx.io. Retrieved 8 January 2018, from diff --git a/i18n/zh-TW/docusaurus-plugin-content-blog/2019-05-30-welcome.md b/i18n/zh-TW/docusaurus-plugin-content-blog/2019-05-30-welcome.md new file mode 100644 index 0000000..592f3ed --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-blog/2019-05-30-welcome.md @@ -0,0 +1,13 @@ +--- +slug: welcome +title: Welcome +author: Jeff Stahlnecker +author_title: Head of Development at MXC Foundation +author_url: https://github.com/jeffstahlnecker +author_image_url: https://avatars.githubusercontent.com/u/45363541?v=4 +tags: + - welcome + - intro +--- + +It's the beginning. Since I returned to the community following the Miner Health release, I've been saying that we'll impove transparency in development at MXC. This site is the beginning of this transparency. More content will be added here. diff --git a/i18n/zh-TW/docusaurus-plugin-content-blog/2021-05-30-welcome.md b/i18n/zh-TW/docusaurus-plugin-content-blog/2021-05-30-welcome.md new file mode 100644 index 0000000..592f3ed --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-blog/2021-05-30-welcome.md @@ -0,0 +1,13 @@ +--- +slug: welcome +title: Welcome +author: Jeff Stahlnecker +author_title: Head of Development at MXC Foundation +author_url: https://github.com/jeffstahlnecker +author_image_url: https://avatars.githubusercontent.com/u/45363541?v=4 +tags: + - welcome + - intro +--- + +It's the beginning. Since I returned to the community following the Miner Health release, I've been saying that we'll impove transparency in development at MXC. This site is the beginning of this transparency. More content will be added here. diff --git a/i18n/zh-TW/docusaurus-plugin-content-blog/2021-07-05-tech-update.md b/i18n/zh-TW/docusaurus-plugin-content-blog/2021-07-05-tech-update.md new file mode 100644 index 0000000..2dd0bc2 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-blog/2021-07-05-tech-update.md @@ -0,0 +1,36 @@ +--- +slug: 2021-07-05-tech-update +title: Tech Update - July 5, 2021 +author: Jeff Stahlnecker +author_title: Head of Development @ MXC Foundation +author_url: https://github.com/jeffstahlnecker +author_image_url: https://avatars.githubusercontent.com/u/45363541?v=4 +tags: + - tech update + - datadash + - supernode + - dhx +--- + +Welcome to the very first MXC tech update! + +This week the tech team has been extremely busy. Throughout the past sprint we've focused on closing any and all ongoing projects. That brought us back to a few "low hanging" items that will add some EPIC value to our users -- especially those interested in connecting LoRa devices. + +## Device Provisioning +Our very own backend engineer Lixuan took a deep dive to test the device provisioning system built by Ian to ensure that it was ready to be added with our live code. She solved a number of conflicts (device provisioning has been *ready* since January!), then ran it through a round of rigorous testing. This was done in collaboration with MatchX embedded software engineer Ian. They did some great work, and you'll see device provisioning going live early this week. In the meantime, you can check out the technical documentation here: [Device Provisioning FAQ](/docs/tutorials/devices/provisioning) + +As part of our focus on devices during the past two weeks, Lixuan also solved an issue which kept users from adding new devices on a supernode. We should be in ship-shape, and ready for some developer interaction. Feel free to send us your feedback! :) + +## Foundation for DHX Simulator Improvement +The DataDash DHX Simulator has been a long-standing issue. While it works, it's a little buggy, and once in a while spits out something unexpected. Our backend developer Pavel decided enough is enough, and jumped in to solve the challenge of the buggy simulator. To accomplish this he brought together the required information from a ton of different sources and built an API for the DataDash team to integrate. For those developers out there, I'll update this post with a link to the API as soon as it is live. + +## Improved Technical Support +We've been working hard to improve the technical support services provided by both MXC and MatchX. Our Tech Support Engineer Latifah has been hard at work building a ticketing system, integrating Discord, writing an internal support knowledgebase, while naturally also responding to your support requests. She's done an excellent job, and has set a strong foundation for reliable support moving forward. + +## Cleaning up the DataDash +Over the past two weeks our DataDash team has focused primarily on solving some pesky issues with the app. We also added support for DHX in the in-app address book. Just another feature to make life a little easier for you. + +## Contributing to DataHighway +Team members Luke, Ayush and Christian updated the DataHighway blockchain to add multisig functionality. They also made a number of improvements, and fixed issues with the Harbour testnet. You can review the full release notes [here](https://github.com/DataHighway-DHX/node/releases/tag/v3.0.5). + +That's the newest from Tech, and I'll be sure to update this post with that API link as soon as it goes live. \ No newline at end of file diff --git a/i18n/zh-TW/docusaurus-plugin-content-blog/2021-07-20-tech-update.md b/i18n/zh-TW/docusaurus-plugin-content-blog/2021-07-20-tech-update.md new file mode 100644 index 0000000..0a2127b --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-blog/2021-07-20-tech-update.md @@ -0,0 +1,66 @@ +--- +slug: 2021-07-20-tech-update +title: Tech Update - July 20, 2021 +author: Jeff Stahlnecker +author_title: Head of Development @ MXC Foundation +author_url: https://github.com/jeffstahlnecker +author_image_url: https://avatars.githubusercontent.com/u/45363541?v=4 +tags: + - tech update + - datadash + - dhx + - mxc controller + - device provisioning +--- + +It's hard to believe it's been another two weeks --- and we've been EXTREMELY busy polishing up some pretty epic features. + +### All About Device Provisioning +It took us quite some time to get the [device provisioning](/docs/tutorials/devices/provisioning) developer preview ready. A bit longer than expected. Device provisioning interacts with a number of supernode systems on a regular basis, meaning that each of these interactions had to be thoroughly tested. During that process we found some items that could cause issues when the system scales, so we went ahead and took the time to resolve those before pushing out the feature. I'm excited to say that the device provisioning developer preview is now live and ready for action. If you want to get a manufacturer ID and begin testing the system, email support@mxc.org. + +In the meantime, Ian is actively working on providing a sample lora device source code to make it easier for manufacturers (and tinkerers) to get started. + +### DataDash Goes Dark (for beta testers) +That's right! We're working hard on getting dark mode out there for all of you night owls. If you want to get a sneak peek at dark mode and provide some epic feedback for us, you can join the live beta by using the command `!role ios` or `!role android` in our [Discord Community](https://mxc.news/discord). This will get you access to the dedicated beta channel for your phone, which provides you with the information you need to get signed up. + +:::caution + +Beta releases have bugs. By joining the beta, you will experience these bugs. If you find an issue, always report it directly to us in our [GitHub Repo](https://github.com/mxc-foundation/supernode-app/issues/new?assignees=&labels=bug%2Ctriage&template=bug_report.yml&title=%5BBug%5D%3A+). + +::: + +### Tech Support Continues to Amaze +Ok I just had to say this one. Yes it sounds markety, and I know not everyone is always amazed, but I'm very happy with it. Within a few weeks our new Tech Support Engineer Latifah has gone from "first day with LoRa" to actively troubleshooting miners, certifying issues, finding solutions for said issues, and of course ensuring that each member of our community receives top of the line technical support. + +Keep in mind, the only way to get "official" technical support is to email support@mxc.org or by using the `/support` command in our [Discord Server](https://mxc.news/discord). + +### MXC Controller - the news on the Web App +For those of you digging into the nitty-gritty of the LoRa/LPWAN infrastructure, I'm sure you've noticed a few issues with the current web app. We know about those, and we're working on rolling out a new web app to solve all of these issues. Because we've decided to move from React to a Flutter based web app, it will take us just a bit of time to get started. + +This week we started cross-training our React developer Nam to start working with Flutter. While he's been studying, he also worked with the Flutter team to outline the base architecture of the application so that we can finalize the overall design in our upcoming sprint. + +The MXC Controller will be available as beta during development. This will provide you with early access to key pages, while keeping you informed that it's beta, and will probably have a few bugs. + +:::caution + +Beta releases will have bugs. Just pointing that out again. + +::: + +Our first release will include: +* Base architecture +* Sign-in / Register +* Device Management/Configuration pages + +I'll keep you updated on the status of this as we move forward, and of course I'll share the GitHub repo when the development begins. + + +### Continuing our Contribution to DataHighway +We haven't forgotten DataHighway and we still strongly believe in the future of this project. Blockchain developers Luke and Ayush have been hard at work to both improve the DataHighway, and bring governance on chain. There's been some progress made in that direction, however we're being über careful. As we progress further with the development, we'll start contributing to the documentation as well to ensure it's easier for others to participate. + +### Community Contributions +This documentation is fluid, and anyone can work to help improve it. If you see something that you know about, and feel confident writing an article about, feel free to fork the repo, make the changes, and submit a pull request. + +Now I know that not everyone is familiar with GitHub. In that case, let me know on Discord and I'll open up a channel for us to chat. Either I'll teach you what you need to know to participate directly on GitHub, or you can just send me the article you believe should be in the documentation. + +That's been this week's news update --- uh yeah ok wrong channel. ;) \ No newline at end of file diff --git a/i18n/zh-TW/docusaurus-plugin-content-blog/2021-07-5-tech-update.md b/i18n/zh-TW/docusaurus-plugin-content-blog/2021-07-5-tech-update.md new file mode 100644 index 0000000..2dd0bc2 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-blog/2021-07-5-tech-update.md @@ -0,0 +1,36 @@ +--- +slug: 2021-07-05-tech-update +title: Tech Update - July 5, 2021 +author: Jeff Stahlnecker +author_title: Head of Development @ MXC Foundation +author_url: https://github.com/jeffstahlnecker +author_image_url: https://avatars.githubusercontent.com/u/45363541?v=4 +tags: + - tech update + - datadash + - supernode + - dhx +--- + +Welcome to the very first MXC tech update! + +This week the tech team has been extremely busy. Throughout the past sprint we've focused on closing any and all ongoing projects. That brought us back to a few "low hanging" items that will add some EPIC value to our users -- especially those interested in connecting LoRa devices. + +## Device Provisioning +Our very own backend engineer Lixuan took a deep dive to test the device provisioning system built by Ian to ensure that it was ready to be added with our live code. She solved a number of conflicts (device provisioning has been *ready* since January!), then ran it through a round of rigorous testing. This was done in collaboration with MatchX embedded software engineer Ian. They did some great work, and you'll see device provisioning going live early this week. In the meantime, you can check out the technical documentation here: [Device Provisioning FAQ](/docs/tutorials/devices/provisioning) + +As part of our focus on devices during the past two weeks, Lixuan also solved an issue which kept users from adding new devices on a supernode. We should be in ship-shape, and ready for some developer interaction. Feel free to send us your feedback! :) + +## Foundation for DHX Simulator Improvement +The DataDash DHX Simulator has been a long-standing issue. While it works, it's a little buggy, and once in a while spits out something unexpected. Our backend developer Pavel decided enough is enough, and jumped in to solve the challenge of the buggy simulator. To accomplish this he brought together the required information from a ton of different sources and built an API for the DataDash team to integrate. For those developers out there, I'll update this post with a link to the API as soon as it is live. + +## Improved Technical Support +We've been working hard to improve the technical support services provided by both MXC and MatchX. Our Tech Support Engineer Latifah has been hard at work building a ticketing system, integrating Discord, writing an internal support knowledgebase, while naturally also responding to your support requests. She's done an excellent job, and has set a strong foundation for reliable support moving forward. + +## Cleaning up the DataDash +Over the past two weeks our DataDash team has focused primarily on solving some pesky issues with the app. We also added support for DHX in the in-app address book. Just another feature to make life a little easier for you. + +## Contributing to DataHighway +Team members Luke, Ayush and Christian updated the DataHighway blockchain to add multisig functionality. They also made a number of improvements, and fixed issues with the Harbour testnet. You can review the full release notes [here](https://github.com/DataHighway-DHX/node/releases/tag/v3.0.5). + +That's the newest from Tech, and I'll be sure to update this post with that API link as soon as it goes live. \ No newline at end of file diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/datadash/_category_.json b/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/datadash/_category_.json new file mode 100644 index 0000000..96eea63 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/datadash/_category_.json @@ -0,0 +1,4 @@ +{ + "label": "DataDash", + "position": 6 +} diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/datadash/beta.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/datadash/beta.md new file mode 100644 index 0000000..70fd43e --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/datadash/beta.md @@ -0,0 +1,20 @@ +--- +sidebar_position: 2 +title: DataDash Beta Testing +--- + +# DataDash Ongoing Beta +At the moment we have an open beta DataDash group for both iOS and Android. We consider this a semi-closed beta because we require participants to join our beta discord channels. This is key for discussions among participants, and provides us with an easy way to interact with beta participants. + + +To participate as a beta tester follow the following steps: +1. Join our [Discord Community](https://mxc.news/discord) +1. Use the #bot-talk channel to send one of the following commands: + * `!role ios` + * `!role android` +1. You will then see a new channel in the `development` category. Follow the steps outlined at the top of the channel to join your selected test group. + +## DataDash Closed Beta +Before a major release, we will do a call for closed beta participants. This will have a limited number of available seats per operating system, and will only be available to current beta testers who actively submit feedback. + +Closed betas will provide users access to new and unreleased features that require a major backend change. Because of this, each participant will receive a test account on a "fake" supernode to work with. \ No newline at end of file diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/datadash/bugs.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/datadash/bugs.md new file mode 100644 index 0000000..01e11de --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/datadash/bugs.md @@ -0,0 +1,19 @@ +--- +sidebar_position: 2 +title: Reporting Bugs +--- + +# How to report DataDash Bugs + +The DataDash app codebase is [Publicly available on GitHub](https://github.com/mxc-foundation/supernode-app). Therefore the best way to submit a DataDash bug, is directly as a [GitHub issue](https://github.com/mxc-foundation/supernode-app/issues). + +Please include the following information in your bug report: + +* What is the problem? +* What is the expected behavior? +* Mark the issue with the appropriate labels: + * `bug` + * `ios` or `android` +* Provide any additional information, screenshots, or videos you believe might be helpful. + +**GitHub Issues are public! Do not share any personal or identifiable information. If you believe the issue is specific to you, it should be submitted as a support ticket to [support@mxc.org](mailto:support.mxc.org).** diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/datadash/intro.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/datadash/intro.md new file mode 100644 index 0000000..5df58e1 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/datadash/intro.md @@ -0,0 +1,35 @@ +--- +sidebar_position: 1 +title: Intro +--- + +# Introducing the DataDash App + +Our DataDash app has the following core functionality: +* LPWAN Functionality + * M2 Pro Miner + * Register + * Manage Miner Health + * MXProtocol enabled devices (coming soon) + * Register + * View live data frames + * Generate MQTT credentials (for external data management tools) +* Token Management + * MXC M2M Wallet + * DHX Wallet + * BTC Wallet (Withdrawals Only) + + +## Downloading the DataDash App + +You can get the DataDash app at the following locations: + +**Android** +* [Google Play Store](https://play.google.com/store/apps/details?id=com.mxc.smartcity) +* [APK Download](https://datadash.oss-accelerate.aliyuncs.com/app-prod-release.apk) + +**iOS** +* [App Store](https://apps.apple.com/us/app/datadash-app/id1509218470) + +## Participating with DataDash Development +Our DataDash app is [open on GitHub](https://github.com/mxc-foundation/supernode-app) and anyone is welcome to participate in its improvement. To participate, clone the repo, and then tackle a [GitHub issue](https://github.com/mxc-foundation/supernode-app/issues). When you think you've solved it, submit a pull request for our team to review. Before getting started, take a look at the rules [here](https://github.com/mxc-foundation/supernode-app/blob/master/RETHINK.md). \ No newline at end of file diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/devices/integrations.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/devices/integrations.md index 9b2116c..cbeabdb 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/devices/integrations.md +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/devices/integrations.md @@ -1,5 +1,5 @@ --- -sidebar_position: 3 +sidebar_position: 3 title: Integrations --- @@ -7,9 +7,7 @@ title: Integrations By default supernode provides MQTT broker service for users to subscribe or pushlish events on their devices. -Users can subscribe to MQTT broker under topics in the servers after authentication. Before that, you need to make sure -you have mosquitto package installed. Use the package manager apt to install these dependencies on the Ubuntu 18.04 LTS -server: +Users can subscribe to MQTT broker under topics in the servers after authentication. Before that, you need to make sure you have mosquitto package installed. Use the package manager apt to install these dependencies on the Ubuntu 18.04 LTS server: ``` sudo apt-add-repository ppa:mosquitto-dev/mosquitto-ppa @@ -161,7 +159,7 @@ Response Call ```shell -curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'Grpc-Metadata-Authorization: Bearer {{ .SUPERNODE_JWT }}' -d '{ "organizationId": "{{ .ORG_ID }}"}' 'https://{{ .SUPERNODE_URL }}/api/mosquitto-auth/login' +curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'Grpc-Metadata-Authorization: Bearer {{ .SUPERNODE_JWT }}' -d '{ "organizationId": "{{ .ORG_ID }}", "ttlInSeconds": "{{ .TIME_TO_LIVE_IN_SECONDS }}"}' 'https://{{ .SUPERNODE_URL }}/api/mosquitto-auth/login' ``` Response @@ -220,5 +218,4 @@ The message format should be as follow: - `confirmed`: whether the payload must be sent as confirmed data down or not - `fPort`: FPort to use (must be > 0) - `data`: base64 encoded data (plaintext, will be encrypted by Network Server) -- `object`: decoded object (when application codec has been configured), when providing the 'object', you can omit ' - data' +- `object`: decoded object (when application codec has been configured), when providing the 'object', you can omit ' data' 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.
0: Low or OFF, 1: High or ON, -1 Unknown or Invalid. | +| 20 (0x14) | percent | 1 | A generic value in percent. | +| 21 (0x15) | powerFactor | 2 or 4 | Power factor for AC power system.
Value range from 0 to 1. | +| 254 (0xfe) | uplinkPower | 1 | Exact value of TX Power in dBm. | + + + +#### GPS data format + +When data length is 1 + +| Offset | Length | Description | +| ------ | ------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 0 | 1 | Indicates whether the node has moved since last GPS fix. Possible values are:
    0: Node is stable since last GPS fix
    1: Node has moved, or has not received a GPS fix since boot; waiting for GPS fix | + +When data length is 11 + +| Offset | Length | Description | +| ------ | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 0 | 1 | $GPGGA Position Fix Indicator. Possible values are:
* 0 Fix not available or invalid
* 1 GPS SPS Mode, fix valid
* 2 Differential GPS, SPS Mode, fix valid
* 6 Dead Reckoning Mode, fix valid | +| 1 | 4 | Latitude in 1/1000 of minutes, as little-endian int32. Positive is north, negative is south. To get the value in degrees, divide by 600000. | +| 5 | 4 | Longitude in 1/1000 of minutes, as little-endian int32. Positive is east, negative is west. To get the value in degrees, divide by 600000. | +| 9 | 2 | Altitude above geoid mean sea level in decimeters (0.1m), as little-endian int16. | + + + +#### Data format for 1 byte value + +It is a signed 8-bits integer (int8_t), giving the range between -128 and +127. + +```javascript +// Decoding +if (offset_0 > 0x7f) { + value = ((offset_0 ^ 0xff) + 1) * -1; +} +else { + value = offset_0; +} +``` + + + +#### Data format for 2 bytes value + +It is a signed 16-bits fixed point number. Offset 0 is the sign bit and integer part. Offset 1 is the fractional part. + +```javascript +// Decoding in Javascript +let raw_value = (offset_0 << 8) | offset_1; +if (raw_value > 0x7fff) { + value = ((raw_value ^ 0xffff) + 1) * -1; +} +else { + value = raw_value; +} +value = value / 256; +``` + + + +#### Data format for 4 bytes value + +It is a 32-bits floating point number (IEEE 754). Offset 0 is the MSB. + +For example, a value of 54.12 will has a 32-bits value of 0x42587ae1. + +The payload will become <0x42><0x58><0x7a><0xe1>. + +```javascript +// Decoding in Javascript +let raw_value = (offset_0 << 24) | (offset_1 << 16) | (offset_2 << 8) | offset_3; +let v_temp = new DataView(new ArrayBuffer(4)) +v_temp.setUint32(0, raw_value) +value = v_temp.getFloat32(0) +``` + + + +The NAN (Not A Number) (0x7fc00000), means the sensor value is unknown or invalid. + + + +### Event Data + +Event data is information about change that occurs at a point in time. A event will contain the type value and additional event data. + +| Number | Name | Length | Description | +| --------- | ------------- | ------ | ------------------------------------------------------------------ | +| 0 (0x00) | unknown | 0 | No data. | +| 11 (0x0b) | opened | 1 | The unit is opened by a user. Data is the user ID. | +| 12 (0x0c) | specialOpened | 0 | The unit is opened in a special way. For example, a key or button. | +| 13 (0x0d) | forceOpened | 0 | The unit is opened in a abnormal way. | + + + +## Downlink Payload Data Format + +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 | Get params | 1 | Get parameter described by first byte. | +| 1 | Set params | >=2 | Set parameter described by first byte to the value specified in the rest of the message. | +| 2 | Reboot | 0 | Reboot the node immediately. | +| 3 | Reboot/upgrade | 1 | Reboot the node after the specified timeout; optionally turn BLE and SUOTA on for upgrades. The argument is as follows:bit [7]:0: just reboot1: BLE onbits [6:3]: Reservedbits [2:0]: Timeout0: TBD1: 5 minutes2: 15 minutes3: 30 minutes4: 1 hour5: 2 hours6: 4 hours7: TBD | +| 4 | Set Controls | \>=1 | Set a value to the control. For example, turn on/off a digital output. | + + + +### Parameters + +| Number | Name | Length | Description | +| ------ | ------- | ------ | ------------------------------------------------------------------------- | +| 0 | deveui | 6 | DevEUI-48 and BLE MAC address (MSBF)
Only for DevKit. Please don't use it at final product. | +| 1 | appeui | 8 | AppEUI-64 (MSBF)
Only for DevKit. Please don't use it at final product. | +| 2 | appkey | 16 | AppKey (write-only)
Only for DevKit. Please don't use it at final product. | +| 3 | period | 1 | Sensor period | +| 4 | sf | 1 | Minimal LoRa Spread Factor (valid values: 7-12) | +| 5 | version | 2 | Version number.
01 00 => V1.0 | + +Parameters 0, 1, 2 and 4 are actualized after reboot. + +Sensor period is as follows: + +| Number | Period | +| ------ | -------- | +| 0 | Default | +| 1 | 10 sec | +| 2 | 30 sec | +| 3 | 1 min | +| 4 | 2 min | +| 5 | 5 min | +| 6 | 10 min | +| 7 | 30 min | +| 8 | 1 hour | +| 9 | 2 hours | +| 10 | 5 hours | +| 11 | 12 hours | + + + +### Controls + +Controls are used for the user to change a value or state of the device. The control data consists of a byte signifying the data type, and zero or more bytes of the data. The defined types and corresponding data formats are: + +| Number | Name | Length | Description | +| --------- | ------- | ------ | ----------------------------------------------------------------- | +| 0 (0x00) | unknown | 0 | No data. | +| 19 (0x13) | digital | 1 | A generic digital value.
0: Low or OFF, 1: High or ON. | +| 20 (0x14) | percent | 1 | A generic value in percent. | diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/devices/provisioning.mdx b/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/devices/provisioning.mdx new file mode 100644 index 0000000..b56498c --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/devices/provisioning.mdx @@ -0,0 +1,514 @@ +--- +sidebar_position: 4 +sidebar_label: Device Provisioning +--- + +# Device Provisioning + +## What is Device Provisioning? + +Device Provisioning is a process of exchanging sensitive information between a device and a server. This process will store the encryption keys required for LoRaWAN communication on the device and the server. The whole process will be completed through LoRa communication. Therefore, no additional hardware is required on the device. + +In terms of security, Elliptic-curve Diffie-Hellman is used as the key exchange, which enables subsequent sensitive data to be exchanged between the device and the server in a secure manner. + + +## What is the advantage of it? + +With the provisioning is done and the key is ready on both server and device. The operation on the user side will become simple. The user needs only a few steps to register the device to the system. He/She just needs to use our DataDash mobile APP to scan the QR-code label on the device. Then enter a few more information about the device, such as name. After that the device will start to join the network. The user didn’t need to enter any keys that the traditional way needs. During production no keys need to be sent to the assembly house, further improving the security by preventing unwanted compromise of the keys by the 3rd party. + + +## What about the QR-code label? + +The QR-code label stored the identity of the device. There is no sensitive information on it, just an ID code (called Provision ID). A minimal label just needs the Provision ID. The mobile APP will use this Provision ID to register the device to the system. It is a secure way to do the task which no encryption keys content appears during the whole process. + +Here is an example of a minimal label. + + + + + + + +
+ alt_text + PID:PROVISIONIDOOOOOOOOO
+ +For a big device that has more space for the label, a long version label could be used to store more information. + + + + + + +
+ lora provisioning label +
+ +``` +{ + "PROVID": "PROVISIONIDOOOOOOOOO", + "BRAND": "MatchX", + "MODEL": "MX1234", + "SN": "S123456" +} + +``` + + +## What device developer needs to do? + +The firmware needs to implement the flow device provisioning. It is a two steps process and needs to be done for a new produced device. The details of this process is listed on the later part of this document. + +During the device provisioning, it required the Provision ID to identify the device. We suggest the device firmware add an interface to let the manufacturer set this information at the end of the quality assurance (QA) procedure. + +An example method is to use a UART interface to program the information. Our example device uses an “AT” command to achieve this. But any other serial protocol should be fine. + + +![alt_text](/img/provisioning/lora-provisioning-stack.png "image_tooltip") + + +## What device manufacturer needs to do? + +To successfully provision a device, it required the information of Provision ID. The manufacturer needs to request it from us, MatchX. We will prepare a spreadsheet that has the assigned Provision ID and related information for the manufacturer. The Manufacturer needs to make sure the information is set to the device with the correct matched QR-Code label. + +We suggest the manufacturer to add an extra step at their quality assurance (QA) procedure. The step included setting the Provision ID to the device with a matched QR-Code label. Then verify the device is being provisioned, that means it exchanged key information with the server. + + +![alt_text](/img/provisioning/lora-provisioning-steps.png "image_tooltip") + + + + + +## Device Provisioning Implementation Details + +Source code of our example device: TBD + + +### Provision ID + +The Provision ID is a unique string for each device. During the provisioning, it is used as an identity at the provisioning server to access the device information. The Provision ID is 20 characters long and uses the RFC4648 Base32 alphabet. + + +### Hash of Provision ID + +It is the result of the SHA256 hash on the Provision ID. The device provisioning process uses this value when doing authentication with the server. To minimize the complexity of the device implementation, we suggest the device also store this value to its FLASH, instead of calculating it by itself. + + +``` +provisionIdHash = SHA256(provisionId | '.MatchX') +``` + + +For example: + + +``` +PID = 'TESTPIDOOOOOOOOOOOOO' +HASH = 'c8c7564b46b91c91ef6c4f37bcca8cf7e81baac6eb869dcc62e5fafdd0242497' +``` + + + +### Message integrity code (MIC) + +The message integrity code (MIC) value at LoRa PHYPayload for HELLO and AUTH messages is calculated as below. + + +``` +FixedKey[] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, +0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f}; + +cmac = aes128_cmac(FixedKey, message) +MIC = cmac[0..3] +``` + + +### Verification Code + +The verification code is used when the device authenticates with the server. The calculation is shown below. + + +``` + FixedKey[] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, + 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f}; + + cal_buf = provisionId + nonce; + verifyCode = aes128_cmac(FixedKey, cal_buf) +``` + +Example: + + +``` +// Input + privisionid = "SERIALNUMBEROOOOOOOO"; + servernonce = {0x01, 0x02, 0x03, 0x04}; + +// Output + verifyCode = {0x2E, 0x69, 0xBB, 0x5E, 0xD7, 0x8B, 0x5E, 0xE8, + 0x0C, 0x6A, 0x8A, 0xDC, 0x81, 0x91, 0xDD, 0xF8}; +``` + + + +### AES + +The encryption scheme used in aes128_encrypt() and aes128_cmac() are the same as LoRaWAN specification. This approach will minimize the need for extra code on the device side. + + +### LoRa + +The device provisioning using the “Proprietary” LoRa frame for communication, it means the MType on MHDR is set to ‘111’. + +The receiving windows using RX1 and delay is 5s. + +Data Rate: + + + + + + + + + + + + + + + + + + + + + + + +
Region + Data Rate + Configuration +
EU868 + 3 + Up and Down: SF9 / 125 kHz +
US915 + 3 + Up: SF7 / 125 kHz +

+ Down: SF7 / 500 kHz +

+
CN470 + 3 + Up and Down: SF9 / 125 kHz +
+ +### Sequence Diagram + +The device provisioning has two steps. First, it is a ECDH key exchange process, called “Hello” by us. The device and the server will exchange their public key on this step. Then the next step is the authentication. The device will submit its hashed Provision ID to the server. If it is a valid ID on the server, the server will accept the request and send back the EUI information. + +The keys used for LoRaWAN OTAA are derived from the ECDH shared key. All this information will not appear on the communication message. + +![alt_text](/img/provisioning/lora-device-provisioning-sequence.png "image_tooltip") + + +### Message format + +The messages shown below are the content of the MACPayload of the Proprietary MAC message of LoRaWAN. + +LoRaWAN PHYPayload: + + + + + + + + +
MHDR + MACPayload +

+ (Hello / Auth) +

+ 		MIC +
+ +##### Hello message + + +``` + | Type | rDevEUI | devPubKey | version | + | 0x01 | 8 bytes | 64 bytes | 1 byte | +``` + + + +##### Hello response + + +``` + | Type | rDevEUI | serverPubKey | serverNonce | + | 0x81 | 8 bytes | 64 bytes | 4 bytes | +``` + + + +##### Auth request + + +``` + | Type | rDevEUI | Encrypted Payload | + | 0x11 | 8 bytes | 52 bytes | + + | provisionIdHash | verifyCode | devNonce | + | 32 bytes | 16 bytes | 4 bytes | +``` + + + +##### Auth accepted + + +``` + | Type | rDevEUI | Encrypted Payload | + | 0x91 | 8 bytes | 32 bytes | + ​ + | devEUI | appEUI | verifyCode | + | 8 bytes | 8 bytes | 16 bytes | +``` + + + +##### Auth rejected + + +``` + | Type | rDevEUI | + | 0x92 | 8 bytes | +``` + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
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. + + + + + +![alt_text](/img/provisioning/lora-provisioning-spreadsheet-view.png "image_tooltip") + + +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. + + +![alt_text](/img/provisioning/device-provisioning-report.png "image_tooltip") + + +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 +``` + + + + + + +![alt_text](/img/provisioning/lora-provisioning-spreadsheet-view-1.png "image_tooltip") + diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/dhx/_category_.json b/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/dhx/_category_.json new file mode 100644 index 0000000..6f5f53d --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/dhx/_category_.json @@ -0,0 +1,4 @@ +{ + "label": "Mining DHX", + "position": 4 +} diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/dhx/intro.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/dhx/intro.md new file mode 100644 index 0000000..18d2c90 --- /dev/null +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/dhx/intro.md @@ -0,0 +1 @@ +# What is DHX \ No newline at end of file diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/intro.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/intro.md index b92ff53..5e1be6f 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/intro.md +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/intro.md @@ -8,16 +8,32 @@ sidebar_position: 1 There are a number of ways for developers to interact with the MXC ecosystem. These forms of participation are integral to the further development and deployment of the MXProtocol. ## Direct Participation + +### Beta Testing +Beta testing new features before they are released is a great way to help us improve the overall user experience with our products. Here are beta opportunities currently available: + +| Product | Beta Type | How to Participate | +| --------------- | --------- | ------------------------------------------ | +| DataDash | Closed | [Instructions](tutorials/datadash/beta.md) | +| MXC Controller | Closed | *Coming Soon* | +| M2 Pro (MatchX) | Open | *Coming Soon* | + +*A beta version is pre-release and considered unstable. This means that you may experience some issues. Normally these will be minimal, however participating in an M2 Pro beta could potentially affect your mining. MXC Controller and DataDash betas will not have any influence on your overall mining potential.* + + +### Coding and Translating We have a number of public repos with active issues that could use assistance. Our team is still growing, and community support is always appreciated, encouraged and in some cases rewarded. -Here is an updated list of repos that could use assistance. +Here is an updated list of repos that could use assistance. * [DataDash App](https://github.com/mxc-foundation/supernode-app) [Flutter / Dart] + * [Translate the DataDash](https://crowdin.com/project/mxc-mobile-app) * [Developer Documentation](https://github.com/mxc-foundation/developer-documentation) [Markdown, Javascript] + * [Translate the Docs Today](https://crowdin.com/project/mxc-documentation) -We will continue to add repositories to this list as we work to increase transparency with our code and development process. +We will continue to add repositories to this list as we work to increase transparency with our code and development process. ## Manufacturing / Configuring Devices -Without devices the network has no purpose. Therefore, we've created an easy way for manufacturers to get involved with the network, making it possible for their devices to be deployed as a turnkey solution in the MXC ecosystem. +Without devices the network has no purpose. Therefore, we've created an easy way for manufacturers to get involved with the network, making it possible for their devices to be deployed as a turnkey solution in the MXC ecosystem. In order to increase security of the entire network, we've worked with MatchX to develop a novel provisioning concept for LoRa devices. This provisioning process is a requirement for any devices intending to be MXProtocol compatible. We have made this decision as: 1. Device provisioning increases the security of the device data @@ -27,7 +43,7 @@ In order to increase security of the entire network, we've worked with MatchX to You can discover more about device provisioning for the MXProtocol in Devices. ## Reporting Issues -Even though we attempt to do rigorous QA before every release, some pesky bugs still slip through. Actively reporting bugs is an extremely important form of participation, and helps us to improve the stability of the entire network. +Even though we attempt to do rigorous QA before every release, some pesky bugs still slip through. Actively reporting bugs is an extremely important form of participation, and helps us to improve the stability of the entire network. You can report bugs in the #bugs channel in our [Discord Server](https://mxc.news/discord) diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/m2-pro/intro.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/m2-pro/intro.md index 743d33c..aa259e4 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/m2-pro/intro.md +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/m2-pro/intro.md @@ -2,4 +2,5 @@ title: Introduction sidebar_position: 1 --- + # The M2 Pro Miner \ No newline at end of file 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. diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/m2-pro/troubleshooting.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/m2-pro/troubleshooting.md index 569c821..a397b99 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/m2-pro/troubleshooting.md +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/tutorials/m2-pro/troubleshooting.md @@ -2,4 +2,66 @@ sidebar_position: 5 --- -# Troubleshooting \ No newline at end of file +# Troubleshooting +Experiencing a problem with your M2 Pro? This tutorial will help you find it. Naturally you can also ask for help in one of our communities, or reach out for manufacturer support by writing [support@matchx.io](mailto:support@matchx.io). + +## Connectivity (uptime) +If your uptime is taking a hit, there's an easy way to find out if the miner is at fault, or your local network connection. To do that follow the following steps: +### 1. Access the M2 Pro Miner web interface +You can find the interface here: `http://yourSerialNumber.local` + * Your computer or phone must be on the same network as the M2 Pro Miner + * This URL works only on iOS, Win10 and Linux. It doesn't work on Android. +``` +Username: admin +Password: your serial number using all caps +``` + + + +### 2. View the miner logs: +1. After logging in, you can view or download your logs by clicking on `SysLog` in the menu ![log file structure](/img/troubleshooting/sysLog.png) + * If you're having an ongoing issue, you may want to download your logs regularly. The miner can only store logs for the past 48 hours, so if additional troubleshooting is needed, you should download your logs once every two days. +### 3. Reading the logs + +First step is to check if offline is happening due to failed heartbeat. Use the search/find function (ctl+f, cmd+f) and type in the word failure to see any failed heartbeat. + +This is the example of a successful heartbeat session. + ``` + Jun 29 04:58:09 M2XLCTRM3ZW daemon.info gwconfd[619]: Received hb response: fw conf + ``` +Here is an example of a failed heartbeat session. + +``` +Jun 29 04:56:07 M2XLCTRM3ZW daemon.err gwconfd[619]: Heartbeat api failure:4: Deadline Exceeded +``` +A failed heartbeat can happen due to many reason but the most common reason is an unstable network connection. To rule this out, you need to check if the internet connection is good. + +These are the list of common errors which indicates unstable, loss or bad internet connection. +1. Connectivity error from network issue +``` +Jun 24 06:49:53 M2XLCTRM3ZW daemon.err tlsDaemon[606]: Setup TLS error: TCP Connection error. +``` + +2. Unstable/dropping WiFi connection +``` +Jun 17 07:25:29 M2XLCTRM3ZW user.info kernel: CFG80211-ERROR) wl_is_linkdown : Link down Reason : WLC_E_LINK +``` +3. Internet connection loss +``` +Jun 13 15:05:50 M2XLCTRM3ZW daemon.info netMgmtDaemon[614]: Internet connection loss +``` + +In most cases, the issue is related to unstable internet connection at user's end and the miner is working fine (not a hardware issue). + +To isolate this further, you can try the following: +* If the miner is connected using wireless connection – try using wired connection. +* If wired connection is not possible – move the miner closer to the router as see if the uptime improves +* If both still not solving the issue - try putting the miner on a different network (such as, at friend's home). If the miner is working fine on another network, the issue is related to your home network connection. + +### 4. Checking LoRa Connectivity [in the LoRa Log menu option] +For LoRa, when you see that a miner is offline you can check on the Last Seen. This is pretty straight forward as you just need to search these two lines. If you get PUSH_ACK, that means it is fine. +``` +[2021-06-17 08:58:48.437] [loraMgmtDaemon] [info] INFO: [up] PUSH_ACK received in 43 ms +``` +This message is sent every 30 seconds. + diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/images/fig1_lpwan_comparison.png b/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/images/fig1_lpwan_comparison.png new file mode 100644 index 0000000..b481449 Binary files /dev/null and b/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/images/fig1_lpwan_comparison.png differ diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/images/fig2_dataflow.png b/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/images/fig2_dataflow.png new file mode 100644 index 0000000..e223f70 Binary files /dev/null and b/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/images/fig2_dataflow.png differ diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/images/fig3_MXProtocol_stack.png b/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/images/fig3_MXProtocol_stack.png new file mode 100644 index 0000000..e0e3584 Binary files /dev/null and b/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/images/fig3_MXProtocol_stack.png differ diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/images/fig4_mxp_smart_bidding.png b/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/images/fig4_mxp_smart_bidding.png new file mode 100644 index 0000000..067516d Binary files /dev/null and b/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/images/fig4_mxp_smart_bidding.png differ diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/images/fig5_anti_collision_coordinator.png b/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/images/fig5_anti_collision_coordinator.png new file mode 100644 index 0000000..2249468 Binary files /dev/null and b/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/images/fig5_anti_collision_coordinator.png differ diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/images/fig6_anti_collision_integration.png b/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/images/fig6_anti_collision_integration.png new file mode 100644 index 0000000..0523fca Binary files /dev/null and b/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/images/fig6_anti_collision_integration.png differ diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/images/fig7_inter_chain_market.png b/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/images/fig7_inter_chain_market.png new file mode 100644 index 0000000..a062843 Binary files /dev/null and b/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/images/fig7_inter_chain_market.png differ diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/images/fig8_LPWAN.png b/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/images/fig8_LPWAN.png new file mode 100644 index 0000000..48e0618 Binary files /dev/null and b/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/images/fig8_LPWAN.png differ diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/intro.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/intro.md index 61c574b..adeb6a8 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/intro.md +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/intro.md @@ -2,6 +2,7 @@ title: Introduction sidebar_position: 1 --- + # MXC Whitepapers Overview of the WhitePapers \ No newline at end of file diff --git a/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/mxprotocol.md b/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/mxprotocol.md index 6768da7..b9c416b 100644 --- a/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/mxprotocol.md +++ b/i18n/zh-TW/docusaurus-plugin-content-docs/current/whitepapers/mxprotocol.md @@ -3,4 +3,511 @@ title: MXProtocol sidebar_position: 2 --- -# MXProtocol \ No newline at end of file +# MXProtocol (Machine eXchange Protocol): Premium Network Infrastructure, Infinite Data Stream + +## Table of Contents + +- [Machine eXchange Protocol: Premium Network Infrastructure, Infinite Data Stream](#machine-exchange-protocol-premium-network-infrastructure-infinite-data-stream) + - [1. MXC Vision](#1-mxc-vision) + - [2. Background](#2-background) + - [2.1 LPWAN vs other technologies](#21-lpwan-vs-other-technologies) + - [2.1.1 LoRaWAN](#211-lorawan) + - [2.1.2 NB-IoT](#212-nb-iot) + - [2.1.3 Deployment considerations](#213-deployment-considerations) + - [MXC economy](#mxc-economy) + - [3.1 Commerce network effect](#31-commerce-network-effect) + - [3.2 Asset-Backed Securitization](#32-asset-backed-securitization) + - [3.3 Data bloom](#33-data-bloom) + - [3.3.1 MXC-assisted garbage collection](#331-mxc-assisted-garbage-collection) + - [3.3.2 MXC-assisted car sharing](#332-mxc-assisted-car-sharing) + - [4. MXProtocol stack](#4-mxprotocol-stack) + - [4.1 Permissionless Blockchain](#41-permissionless-blockchain) + - [4.1.1 Features](#411-features) + - [4.1.2 Security and efficiency](#412-security-and-efficiency) + - [4.1.3 Long-term adoptions](#413-long-term-adoptions) + - [5. Smart Bidding](#5-smart-bidding) + - [5.1 Goals of design](#51-goals-of-design) + - [5.2 Design and implementation](#52-design-and-implementation) + - [5.3 Gateway status](#53-gateway-status) + - [5.4 Smart Bidding strategy](#54-smart-bidding-strategy) + - [5.5 Sensor Smart Bidding code](#55-sensor-smart-bidding-code) + - [6. Anti-Collision Coordinator](#6-anti-collision-coordinator) + - [6.1 Goals of the design](#61-goals-of-the-design) + - [6.2 Design and implementation](#62-design-and-implementation) + - [6.3 Third party integration](#63-third-party-integration) + - [7. Inter-Chain Data Market](#7-inter-chain-data-market) + - [7.1 Goals of the design](#71-goals-of-the-design) + - [7.2 Design and implementation](#72-design-and-implementation) + - [7.3 Polkadot and Aeternity](#73-polkadot-and-aeternity) + - [8. Smart Bidding use cases](#8-smart-bidding-use-cases) + - [8.1 Downlink resource auction](#81-downlink-resource-auction) + - [8.2 Network coverage market](#82-network-coverage-market) + - [8.3 Service market](#83-service-market) + - [9. Development progress](#9-development-progress) + - [10. References](#10-references) + +## 1. MXC Vision + +> The MXC vision is to introduce a systematic process to both simplify and increase IoT data transactions. + +The decentralized infrastructure upon which MXC’s system is based is the future of Low Power Wide Access Network (LPWAN) and the Machine eXchange Protocol (MXProtocol). Utilizing this solid device network foundation, MXC is introducing an extraordinarily unique coin offering, Machine eXchange Coin (MXC), which allows for increased data transactions and an idiosyncratic data flow monetization within the mammoth data market. + +MXProtocol places a keen focus on reducing collision between networks, constructing an inter-chain data market, developing a market for network coverage and introducing an independent Quality of Services (QoS) framework for both data providers and receivers. For the first time ever, individual network users, corporations and enterprises can all participate in the construction of decentralized, ubiquitous and secure LPWAN. Simply by connecting “anything” to the network, adopters will be able to profit and trade MXC. + +The trading network is built on the premise of the “sharing economy.” Therefore, it is uniquely and exclusively owned by users — both individuals and enterprises — who take advantage of the monetization of the network in two ways: + +1. By increasing uplink and downlink coverage via a Gateway, e.g. a MatchBox LPWAN Gateway, Cisco LPWAN Gateway +2. By unleashing access to a massive network of published and traded data to the marketplace which is securely traded using blockchain technology + +Both sensors and connected devices bid (via the integrated QoS) for the downlink network resource to, for example, unlock a door or, alternatively, shut down a faulty radiator, subsequently offering a market-devised price for the uncovered regions. This ultimately increases data network coverage. “Things” can autonomously pay each other with MXC tokens and get accredited by sharing the data with different users/marketplaces. + +There has been a phenomenal increase in the sourcing, collection and transmission of big data within the past five years. Additionally, the increasing use of artificial intelligence feeding off this data has assisted people to simplify tedious tasks and to make better informed decisions on everything from projecting a weather forecast, to saving household energy, to even choosing the right music to play at home. The tone has now been set for decades to come. Machines interacting with one another has seen a significant increase over such a short period. This will only increase as our interdependency on machines and machine learning grows and becomes ever more significant in day to day life. + +Whether for individuals or big companies, the need for a specified network concentrating on machines and machine data is here to stay. It will play a bigger part in supporting both individuals and businesses than ever before. MXProtocol introduces the next generation of LPWAN with a superior IoT data platform and a premium network experience, allowing for a simplified and expedited way to create a secure and efficient solution for IoT. + +The following sections elaborate on the unique advantages of MXProtocol, including its components — permissionless blockchain, Smart Bidding, Anti-Collision Coordinator and Inter-Chain Data Market — that make it a truly innovative technology. + +## 2. Background + +MXC is a German non-profit organization based in the country’s start-up and blockchain capital, Berlin. MXC is partnering with various LPWAN companies. MXProtocol is a revolutionary design that solves the problem of LPWAN and bridges the data gap between different infrastructures. + +IoT is a hot topic that has been intently discussed for over a decade. The one focus and premise of the IoT network is connecting “things” to the Internet and collecting/using this data from the objects that can’t speak for themselves. The application of this new founded, increased data is highly limited due to the current methods offering low range and high power consumption. For example, standard WiFi can generally reach an absolute maximum of around 100 meters, and using 3G/4G consumes a significant amount of power, thus reducing effective battery life and increasing maintenance costs significantly. The fact is, current implementations for data networks are extremely expensive and offer very low usability. The need for a new technology is here and the need for LPWAN will only increase as it solves the current problems of low range/high cost data transmissions. + +The fact is, current implementations for data networks are extremely expensive and offer very low usability. The need for a new technology is here and the need for LPWAN will only increase as it solves the current problems of low range/high cost data transmissions. + + + +
+ LPWAN +
+ +### 2.1 LPWAN vs other technologies + +LPWAN technology emerged to the forefront in recent years with the goal of finding a better data transmission solution to the shortfalls of WiFi, Bluetooth and 3G & 4G networks. These earlier established networks were originally targeted at connecting people, not at connecting the data generated by “things.” The amount of machine-generated data has multiplied significantly in recent times. The new LPWAN technology offers aspects where others simply can’t compete: + +- 10 year sensor battery life +- 20 km data reach with just a single Gateway +- Offers an extreme amount of connection points (over 60,000 for a single network cell) supported by LPWAN Gateways at an extremely low cost + +Now, when compared to the current wireless network, it’s easy to see the superior advancements that the MXC solutions offer. As illustrated in Figure 1, LoRa and NB-IoT are simply the most potent solutions on the LPWAN market. + +#### 2.1.1 LoRaWAN + +LoRaWAN is an open-source protocol defined by the LoRa Alliance, which is already supported by industrial giants such as Cisco, Alibaba, Comcast, IBM and SK Telecom and many more. Advantages of LoRaWAN are 20 km open space coverage, low data rates (low-level kbps) and ultra-low power, allowing for 10 years continued operation on a single battery. + +Both the Gateways and end sensor devices use the LoRaWAN protocol. In fact, devices of any brand are supported and can be connected to the network as long as they are LoRa/LPWAN compatible. + +#### 2.1.2 NB-IoT + +NB-IoT is a narrowband radio technology specified by 3GPP as a licensed telecommuni- cation protocol. NB-IoT focuses specifically on indoor coverage, low throughput and long battery life, enabling a large number of connected devices. + +The advantage for an MXC IoT user is that it gives an individual the power to host their own network wherever and whenever they like. Compare that with the NB-IoT base stations (which are owned by telecommunications conglomerates) which charge users expensive SIM card fees to send data messages over the Internet through NB-IoT protocol. MXProtocol supports all LPWAN technologies, developed LoRaWAN Gateways, NB-IoT and LoRaWAN sensors. That’s decentralization. That’s yet another MXC advantage. + +#### 2.1.3 Deployment considerations + +When deploying LPWAN, the first consideration is understanding how to avoid a col- lision between different competing networks residing in the same region. Generally, the issue comes from the fact that both may use the same channel to send out the message at the same time and leave the other available channel empty due to the chosen preferences. As a result, it’s generally hard to reach a consensus between these networks and thus the deployment suffers as network usage increases. The decentralization and distributed mech- anism of MXProtocol solves this issue by coordinating the networks. The network evolves by having users pay micro-payments for the resources that another one offers. + +The second concern is due to the shortage of downlink resources for the dense sensor/ end device deployment. Usually there are some sensors/end devices which require no downlink or can bear with the loss of downlinks. This is usually associated with low-activity sensors, such as garbage bins or electricity meters. However, end devices like bike locks or location tracker devices need to receive regular and reliable confirmations from the cloud for every uplink. Hence, they are willing to pay a premium for this reliability and a QoS provided by the networks. MXProtocol provides this bidding resource, ensuring that, for example, a garbage bin sensor won’t take first preference over the vital downlink resource of something like a bike lock. + +Another consideration pertains to the requirements for multi-national cooperations (MNC) and small to medium enterprises (SME) trading their data assets publicly generated using LPWAN technology. Within LPWAN, both the data stream and asset trading features are simplified, easy to read and can be digitally transmitted from many kilometers away. This makes the data exchange a clear necessity for the needs of the LPWAN market of tomorrow. + +With respect to the needs of MNCs or SMEs, it’s likely that such enterprises will wish to deploy their own LPWAN to cover an entire city or a region for its own specific applica- tions such as asset tracking (e.g. automobile) or sensor data management. This is a perfect solution for “Big Business.” LPWAN technology delivers via its long reach ensuring that sensor/end device uplink packets are securely received as per the protocol design. + +This leads to one of the key aspects of the MXProtocol: bringing the monetization of data services to the forefront. Using the MXProtocol, micro-payments within the LPWAN infrastructure will be traded from third party sensors/end devices, ensuring data is conveniently, correctly and concisely transmitted in a secure manner, whilst being maintained by the support of system administrators. The industry has been waiting for a decentralized and consensus-based mechanism to improve the usability of LPWAN, and MXC is delivering. + +MXC has designed this next generation LPWAN infrastructure using MXProtocol in order to significantly boost the applications of blockchain and IoT within the real-world context. + +## MXC economy + +Machine eXchange Coin (MXC) offers a unique and specifically designed decentralized technological “Data Trade Network” to the global Token economy. Data can be shared on a mass scale whilst ensuring complete end to end privacy. The MXC intends to be distributed amongst data owners, data receivers and data network hosts, allowing for a facilitated cross-over from a “commodity” based Coin into an everyday trading Coin currency. + +### 3.1 Commerce network effect + +Machine eXchange Coin is the first Token designed to bridge current commodity-based trading of cryptocurrency tokens and the cash-based global economy. Utilizing the “sharing economy,” MXC uses this as an axis, allowing large businesses, SMEs and individuals to borrow or rent assets owned by someone else. + +Individuals place LoRa-based protocol hardware in opportune positions in order to benefit and profit from their locations and their decentralized LoRaWAN network. Businesses benefit by using these user-based networks to send sensor/device data, building a new “sharing economy.” Wallets are stored in the cloud allowing individuals to profit from businesses sending sensor data via their LoRaWAN LPWAN. The coins are then sent and traded from the sensor holders that MXProtocol addresses to the Gateway distributor. + +MXProtocol gives network participants incentives to use, deploy and trade their network elements. In addition to that, it is a people-owned secure and private network that won’t suffer from public congestion like what Ethereum encountered with cryptokitties. + +### 3.2 Asset-Backed Securitization + +MXC has been highly successful with regards to the design and production of high-end LPWAN hardware. Using the coins and sharing economy will allow for a massive influx of shared sensor data amongst individuals and companies, giving better insights into consumer behavior, environmental impacts and machine-based optimizations. + +With MXC, Asset-Backed Securitization (ABS) adds a completely new way for individuals and companies to both trade and manage their data and physical assets. Current methods see sensitive data easily being passed and reproduced to a number of parties without any of them knowing that the data has potentially already been corrupted, seen and/or shared amongst potential competitors/untrusted parties. MXC makes it possible for corporations and individuals to track both physical goods and intangible data, ensuring that buyers/ receivers of the goods are the only party who have received the data/physical good, and for this information to come from a qualified and reliable source. + +By applying ABS, the individual data is allocated to one dedicated source. In contrast, a buyer of a tangible paper certificate, for example, has no way of knowing that the same certificate hasn’t been sold/reproduced and assigned to potentially multiple parties. + +### 3.3 Data bloom + +MXC is a blockchain-based decentralized platform designed to revolutionize three core functions based around the basic financial theory: Lend, Send and Spend. + +#### 3.3.1 MXC-assisted garbage collection + +The future is here. The one constant in everyone’s life from now on will be the data surrounding all of us. In the past such a statement referred to “people-generated data.” However, times have changed. “Machine-generated data” is taking over at a phenomenal rate. + +The beauty of machine-based data, when compared with human-based data, is it doesn’t sleep. Machine-based data is constant and it’s reliability is unmatched when compared with any people-generated data. So why is this important? + +Take, for example, a local city council. Their task is to ensure safety, security and general well-being of the local city. One of these responsibilities includes simple tasks such as garbage collection. The simple act of emptying city trash may seem like a monotonous task, but it in fact requires planning and chain management: When do collections occur? How often should trash collections occur? How many employees are required to empty garbage cans across the city? MXC simplifies such tasks using MXProtocol. + +Using sensor/end devices situated in garbage cans and allowing them to transmit device data via a Gateway allows the city council to detect the levels of garbage built up within the can. What does this mean for the council? + +- Saving fuel: The council only needs to send out garbage trucks when necessary, as opposed to sending out trucks to check cans, irrespective of whether they are full or even completely empty. +- Saving wages: By only sending out employees at the moment a garbage can needs to be emptied, the council can then reallocate human resources, thus saving employee wages. +- Reducing traffic congestion: Garbage trucks are often frustrating for commuters. When parked on the side of the road, they can increase general traffic significantly. Being aware of the need for garbage removal in certain areas can reduce the need for trucks and allow for smoother traffic flows. + +Many of these highlighted aspects make up the chain of events associated with what are deemed to be “menial tasks” but, as shown, the flow on effect is quite significant. MXC IoT is ready to solve such issues, allowing for simple tasks to be categorized and ensuring exact resources are allocated only when needed. + +#### 3.3.1 MXC-assisted car sharing + +Using LoRaWAN sensor/end devices and Gateways can also reduce the cost of car sharing partners. + +Covering an entire city center in LPWAN allows individuals to simply build their own completely independent network, free from telecommunications companies and net- works charging exorbitant costs. + +The benefits of doing this for a company such as a “car sharing” company allows them to track their vehicles without the need to depend on Telecommunication coverage. Using LPWAN significantly reduces the costs, especially when compared with the costs of tracking using a SIM card. + +In addition to GPS tracking, car doors can be locked and unlocked using LPWAN, increasing security for users, all at a very low cost compared to current methods. + +By bringing such key services, MXC provides transparency and greatly enhances customer experience. MXC’s mission is to intensify data sharing whilst forging a unity between those with finance and data service needs and those without finance but who have private access to network integration and distribution, thus eliminating borders, intermediaries and prejudices. + +MXProtocol focuses on three foundational pillars: + +- Extend and support the massive device data economy +- Utilize the decentralized “sharing economy” +- Trade of assets within the current coin economy + +MXProtocol connects “things” utilizing a market-based economy, which adds a plethora of new transmission points allowing more data to be shared, traded, sold and analyzed for data mining. + +Within the new decentralized MXC economy, everyone can profit from the sharing of data; end to end encryption grants authorized usage of the data; and entire communities can benefit from using their locations to act as a network facility to transport this data — trading assets, profiting from the coin economy. + +## 4. MXProtocol stack + +MXProtocol infrastructure consists of both sensor and end devices, Gateway and cloud. Sensors and end devices collect data from “things,” and send to the cloud via the Gateway. This is uniquely designed to specifically be a decentralized solution allowing for everyone to suit their/the market’s needs. The usability of the hardware has been specifically designed as a “plug and play” solution, making installation simple without the need for a professional configuration. It is designed to be easy to set up and easy to share data. + +As the flow in [Figure 2](#fig2) demonstrates, LPWAN Gateways connect to each other to form either a mesh network as a collective cloud or the Internet. The sensors or end devices communicate with Gateways using LPWAN technology for bi-directional communication. Notably, the sensors and end devices are not purely limited to a single LPWAN product. In fact, any LoRaWAN compatible sensors are able to connect to the LPWAN network and can start sending and receiving messages. + + +
+ dataflow +
+ +MXProtocol facilitates the data and value flow of the LPWAN. Inside this ecosystem, each sensor or end device has a MXC wallet address assigned to an individual user. This is required in order to both pay for the network usage and to receive money from selling the data and services. The sensor wallet is stored in the cloud in order to maintain the LPWAN low-power requirements. This is also due to the fact that the CPU is usually resource-constrained. The same wallet is used as the Gateway wallet (also found in a user account and stored in the cloud). This wallet will receive coins from uploading/downloading the data from the cloud to the sensor and assists in paying for the other LPWAN’s resource or data. + +Coinciding with the current LPWAN infrastructure protocol, the data link between the Gateway and sensor end devices is unregulated. As a result, there would be no possibility to be rewarded for forwarding data from the sensor to cloud via the Gateway, and ultimately the downlink resource would be limited, only being allocated on a “first come, first served” basis. This system as is would negatively impact low-level data procurement services offered by things such as a door lock or car charging station system and would result in the data link not being appropriately monetized. MXC LPWAN infrastructure solves such issues, delivering the ultimate user experience to SMEs and MNCs. + + +
+ dataflow-mxprotocol +
+ +[Figure 3](#fig3) shows the detailed technical stack of the MXProtocol infrastructure. The decentralized and autonomous LPWAN can be built on any permissionless blockchain, such as IOTA, Stellar, Skywire and NEO. + +Based on this, the Anti-Collision Coordinator between LPWANs, Smart Bidding and Inter-chain data market are introduced to answer the LPWAN deployment considerations mentioned in the previous chapter [see 2.1.3](#213-deployment-considerations). + +### 4.1 Permissionless Blockchain + +There are various kinds of blockchain. Anyone can use cryptographic keys, anyone can be a node and join the network, and anyone can become a participant to service the network and seek a reward. Participants can walk away from being a node, return if and when they feel like it and get a full account of all network activity since they left. + +In a permissionless blockchain, anyone can read the chain, anyone can make legitimate changes and anyone can write a new block into the chain as long as they follow the rules. Decisions on a permissionless blockchain are made by the network participants. The protocol is based on a consensus protocol. The permissionless blockchain provides a way to reach consensus without relying on a closed system to accurately record financial transactions. + +#### 4.1.1 Features + +MXC built MXProtocol as an inclusive platform where all participants are encouraged to contribute. MXProtocol is a distributed network protocol backed by monetization of the resources and incentives from enterprises and individuals based on permissionless blockchain. The permissionless blockchain design makes MXProtocol efficient and independent: the more people use it, the more robust the network will be. + +The blockchain should have four key properties: decentralized control, low latency, flexible trust, and asymptotic security. In other words, MXProtocol should run on a permissionless blockchain that has: + +- A true decentralized network. +- It has eliminated mining rewards. +- All transactions get confirmed quickly. +- There is an anti-spam role. There should be a preventive measure against nefarious users flooding the network (a DoS attack). + +#### 4.1.2 Security and efficiency + +Often, the speed and privacy of a network is the concern for SMEs and MNCs. Public blockchains, such as Ethereum and Bitcoin, often suffer from big computing slow downs, practically grinding the systems to a halt, leading to a situation where the whole network and the 51 percent resources can attack the blocks. There should be a blockchain providing more privacy and efficiency for businesses and individuals collectively. MXProtocol needs to be run on a secure and efficient blockchain that can provide the devices with good connectivity. + +The MXC-introduced LPWAN application requires further fragmented and discrete transactions for sensitive data and services in an IoT realm. That is why MXC continues to develop upon the permissionless blockchain, making MXProtocol more efficient and more suitable for the needs of LPWAN and IoT applications. + +#### 4.1.3 Long-term adoptions + +As previously stated, MXProtocol is a LPWAN platform protocol that brings efficiency and robustness to the users. There are, however, still several components inside permissionless blockchain itself that MXC feels necessary to emphasize. For example, to ensure the long term stability of the LPWAN IoT projects, continued research is still required with regards to the current data interface. Real field deployment will need to be conducted in order to properly satisfy the plethora of data streams connecting from the LPWAN sensors/end devices and ensure they are routed to the network seamlessly. + +## 5. Smart Bidding + +Due to governmental regulations of the LPWAN spectrum, the downlink is a precious resource that is closely guarded by sensors and end devices. The majority of the world uses eight downlink channels for acknowledgement or confirmation of the sensor data, and each channel usually has to wait anywhere from a few milliseconds up to a few minutes in order to send another packet. + +The downlink channels are fixed in the protocol and code, and the waiting time for each downlink is dependent on the data rate of the sensor/end device. A key side note to this point is that LPWAN Gateways use the latest in “Listen Before Talk” technology allowing them to send data more regularly. This means that data may be sent when the channel is free, and therefore doesn’t have to wait for a specific time period to elapse. + +### 5.1 Goals of design + +To further overcome such industry-wide issues, MXProtocol implements a bidding mechanism, designed to bring the needed resources to those devices that are willing to bid the most. Generally public LPWAN deployment is pushed by both individuals and corporations who do so in order to extend their own individual network reach. Introducing a bidding mechanism will cause network reaches to multiply due to the fact that users can both earn and learn from the data that are sent by the sensors. The purpose of this section is to examine the Smart Bidding design that would support a well-functioning LPWAN ecosystem. The goals of the design are to: + +- Allocate downlink resources adequately +- Allow all sensors/end devices to compete on a market platform for network resources +- Offer network deployments incentives, assisting them to monetize +- Ensure LPWAN services are monetized +- Power the decentralized ledger with MXProtocol to simplify and resolve any issues + +### 5.2 Design and implementation + +There are different bidding models, ranges and methods to be set in Smart Bidding. The goal is to assign the network resource to the highest bidder. The design and functionality of the Smart Bidding process is proposed in [Figure 4](#fig4). Sensors/end devices bid on one single downlink channel out of the eight available on the LPWAN Gateway. The Smart Bidding code sensors/end devices are hosted on the cloud code, enabling them to place a bid. The LPWAN Gateway then provides the status of the network and provides resources to the sensors/end devices. + +In the example illustrated in in Figure 4, there are three sensors/end devices are bidding on one single channel for the downlink resource. The sensor on the right doesn’t participate in the auction due to the specification of its code. Let’s say this is due to the sensor that is used for a minor purpose, e.g. to monitor a garbage can or electricity meter, so the downlink confirmation can acceptably be lost. This leaves the other two devices to bid for the downlink. In this case, the door lock wins the auction. Should the downlink arrive, the payment is then automatically sent from the sensor wallet to the Gateway wallet which provided the resource. + +Usually one Gateway offers eight channels for the sensors/end devices to bid and the prices change dynamically due to the status of the Gateway, or alternatively, the willingness of the sensors. + + + +
+ MXP-smart-bidding +
+ +### 5.3 Gateway status + +Sensors and end devices will already be aware of the status of the Gateway in advance in order to make an appropriate bid for the resources and the services that provided by the network. To motivate the network administrator to maintain a robust LPWAN, we define the following metrics of the Gateway to let sensors/end devices to bid for the dynamic prices: + +- Mean time between failures (MTBF) +- Number of downlink packets sent +- Gateway density +- List of services available + +The first key parameter used to measure the stability of a Gateway on the network is determined by measuring the down time. It is recommended that a smaller MTBF be used than a larger one, because of the QoS that is required for the sensors. Thus, the high QoS sensors/end devices are willing to pay for the more stable LPWAN Gateways. + +The number of downlink packets sent by the Gateway represents the popularity of the device. This usually means the end devices/sensors around the Gateway are dense. If a sensor requires a downlink from the Gateway, which has a high number of downlink packets, it will need to place a higher bid or increase the overall bidding range accordingly. + +Gateway density is a parameter which is expected to motivate network administrators to deploy more Gateways in the areas that have little to no coverage. As demonstrated, it’s already clear that sensors will be willing to pay for low Gateway density with higher prices. Low density means the downlink channels and the services are limited and that the prices will be high when sensors are competing with each other. Overall, it’s expected that this metric will push people to expand the network in order to provide better network access to the LPWAN devices. + +From time to time, LPWAN will provide a list of services, e.g. firmware upgrades, GPS-free localization, network configuration optimization. This allows all hardware to be regularly kept up to date. Sensors and end devices would then choose from the Gateway bids for services, combined with the MTBF and the number of downlinks sent for the auction. + +### 5.4 Smart Bidding strategy + +The following are the standard auction methods found in the system: + +- Auction + - Increase: When the initial bid fails, an increased bid is made in order to secure the auction. + - Decrease: Similar to the Google Keyword style bidding auctions, the user states their bidding range. The system then states (considering all factors) the nec- essary bidding rate. In many instances, this will save customer coins. +- Fixed price + - The network resource or service are offered at a fixed price, with limited or unlimited quantity. Sensors/end devices just pay per use. +- Quantitative purchase + - The network resource or service are bid by quantitative metrics, like a period of time for downlink resource, the region of a whole city’s downlink and the amount of resources that are needed. + +### 5.5 Sensor Smart Bidding code + +Sensors and end devices are programmed with a snippet of code to enable them to bid for network resources and services that are provided by Gateways. This is implemented on the cloud so third party sensors can still use the logic easily by porting the code. There are several parameters to receive from a Gateway in advance, such as the density of the deployment and the list of services that are available to the sensors, just to name a few. + +After the information has been obtained by the Gateway, sensors would bid for resources of the service according to the type of the auction. For example, a bike lock would bid for a downlink resource using the increase method. This specifies the range of the coins that the bike lock is willing to pay for each transaction and the market dictates the end price. + +A dedicated technical white paper about the logic, design and implementation of the Smart Bidding will be released and the APIs with documentation will be available on the MXC website. + +```cpp +bid bike lock { + + /* Define the willingness to pay for the services or resources */ + type bidder + + /* Define the gateway status it will use for the auction */ + struct gw { + uint mtbf; + uint numdl; + uint density; + address service; + } + + address lock1; + gw[] gwstats; + + /* Parse the status that received from the gateway */ + function Parse(gwstats) public { + gwstats [ lock1 ] = msg. sender + lock1 = gwstats [ lock1 ]. service + } + + fuction bid(coin) constant returns (bytes32) { + coin.maximum = 10 + coin.minimum = 6 + auction.type = liner + auction.block = once + + return coin + } +} +``` + +## 6. Anti-Collision Coordinator + +With the increasing amount of LPWAN field deployments, the problem of network congestion is anticipated to rapidly increase. This is especially so when the network coverage targets ultra-long ranges of 20 km or more. + +In 2020, there are expected to be more than 75 billion devices connected to the Internet. If the majority of these are to use LPWAN, it can be assumed that it would put quite a strain on the network resources. As a result, MXProtocol infrastructure has bridged the gap between different networks using the innovative protocol. + +### 6.1 Goals of the design + +> The MXProtocol also offers a general overwhelming consensus for all public LPWAN by adding a community-based consensus, permissions and deployment permission etiquette. + +Here we define the goals of the design for the LPWAN ecosystem: + +- Minimize packet collision for uplinks in the same region deployed with multiple networks. +- Allocate new resources to the sensors/end devices that need downlink for the networks. +- Enable individual networks to pay for other networks resources and services, i.e. network roaming. +- Settle all monetary transactions in MXC. + +### 6.2 Design and implementation + +The design of the Anti-Collision Coordinator is illustrated in [Figure 5](#fig5). The coordinator has two responsibilities. The first is to make payments between networks using MXC. The second is to coordinate between networks about the downlink and uplink status. In the example illustrated in [Figure 5](#fig5), we see the door lock has successfully bid the downlink from the MXProtocol at downlink channel 1. However, the network that deployed over 1 km is also using the downlink channel 1 for the garbage sensor, and the pending collision is obvious. The solution would be that the Anti-Collision. + + +
+ anti-collision-coordinator +
+ +Coordinator would pay for Cisco’s network resource, allowing the Gateway to pause downlink channel 1 for this time’s message, thus allowing the door lock to receive the “unlock door” confirmation from the cloud. + +On the other side, the two networks report each other’s uplink lost message, since the LoRaWAN protocol has the counter for the uplink. Later, the coordinator finds out that the majority of the packets that are lost come from both street lighting and the parking meter due to the fact that their sending intervals are overlapped and they are quite close to each other. + +The coordinator then delays the street light’s sending interval or, alternatively, it changes the data rate to make sure that they won’t collide with each other, and the fees for a delay should be paid by the parking meter. Such network coordination is expected to occur quite often when future deployment of LPWAN sensors becomes more dense. Thus, the Anti-Collision Coordinator solves the problem of the network resource allocation in free-licensed bands completely. + +### 6.3 Third party integration + +The Anti-Collision Coordinator is indeed a protocol plug-in for the LoRaWAN server to control the Media Access Control (MAC) layer of LoRaWAN uplinks and downlinks. + +There are two ways to integrate the Anti-Collision Coordinator into the LPWAN server. First is to run the full node which integrates the anti-collision mechanism into the protocol layer like illustrated in [Figure 3](#fig3). Another solution is to run a light node with the anti-collision module that could be compatible with all the LoRaWAN servers. + +As [Figure 6](#fig6) shows, the Anti-Collision Coordinator is essentially a plug-in for the other LoRaWAN servers that is compatible with LoRaWAN protocol. The plug-in is a protocol enhancement that controls the uplink and downlink based on the payment logic and resource requirement between two or more networks. + +A light node connects to the full node to assign the LPWAN a wallet for sending and receiving MXCs. The Anti-Collision Coordinator controls the MAC layer for all the LoRaWAN devices. A separate white paper will be released about the protocol design of the Anti-Collision Coordinator and its APIs for LoRaWAN servers. + +
+ anti-collision-third-party-integration +
+ +## 7. Inter-Chain Data Market + +Currently, there are several traditional data markets that originate from cryptocurrencies, e.g. Streamr, IOTA and Mobius. All provide a secure mechanism to make sure that the data stream can be copied and transmitted from the owner to the consumer in a sequential manner. + +Most cryptocurrencies are in need of data. This data is fed into the system to provide checks and balances, ensuring all players along the chain have performed their role correctly. For example, a smart contract specifies which goods need to be delivered from city A to city B and this requires the buyer to pay the seller, e.g. 10 ETH. So, how can one determine whether the goods have been successfully delivered? The smart contract must rely on external Oracles from either the GPS data from the package or the LPWAN tag reading from the warehouse. + +> The entire industry continually requires chains such as Mobius or MXC to feed other chains smart contracts and the interdependent information to the applications. + +Oracles are third party services which are not part of the blockchain consensus mechanism. The main challenge with Oracles is that people need to trust these sources of information. Whether a website or a sensor, the source of information needs to be consistently trustworthy. In order to solve these issues, Oracles have different trusted computing techniques. + +### 7.1 Goals of the design + +Blockchains support Oracles in order to assist with fetching external data. The reason for this comes from the fact that blockchain applications, such as Bitcoin scripts and smart contracts cannot access and fetch data directly. As a result, they require pricing feeds for assets and financial applications and weather-related information for peer-to-peer insurance, all written with smart contracts. Here we define the goals of the MXProtocol data market with respect to designing for Oracles: + +- Facilitate data usage between different blockchains +- Establish a trusted resource for the external Oracles +- Stack up the data for later purchase +- Enable purchase of a live data stream +- Provide APIs for non-blockchain applications to access the data +- Settle all monetary transfers within MXC + +### 7.2 Design and implementation + +The MXProtocol Inter-Chain Data Market provides an effective method to feed the other smart contracts with LPWAN data captured by sensors or end devices. + + +
+ inter-chain-data-market +
+ +[Figure 7](#fig7) shows the example of the transaction between MXProtocol data and blockchains like Ethereum. + +MXProtocol feeds data to Ethereum smart contracts, and gets Ethereum payments as rewards. It only requires a simple protocol to trust that the data fetched from the MXProtocol data source is genuine and untampered. In addition to that, the rich data stream can also be used by external non-blockchain applications via Web APIs. + +Major block chains like Ethereum are short in data for smart contracts, and the data that is provided by external Oracles essentially may not be trustworthy. With the MXProtocol Inter-chain data market, the generation and flow of the data can be tracked and verified publicly on the chain. Hence, the security issue is solved internally with MXProtocol. + +### 7.3 Polkadot and Aeternity + +Polkadot is essentially a protocol that communicates between different networks. It solves consensus and transaction delivery between different chains. + +Aeternity is created to be the interface between real world data and smart contracts. Instead of using Oracles that can cause a single point of failure, Aeternity’s design provides decen- tralized infrastructure for holding and transferring the data to smart contracts. + +The MXProtocol Inter-chain data market uses the idea and mechanism developed by both Polkadot and Aeternity to deal with consensus, privacy, transaction delivery and security. A separate white paper will be released about this design. + +## 8. Smart Bidding use cases + +### 8.1 Downlink resource auction + +Downlink resource auctions occur when it is the only option for the Gateways to decide which sensor/end devices to communicate with. The Gateway usually has eight downlink channels, supporting more than 60,000 sensors that need to be acknowledged in sequence. Uplinks are free for the sensors since all the Gateways will pick up the packets and forward them within the same network, and the Anti-Collision Coordinator needs to pay the other network when collisions need to be avoided. The downlink resources need to be allocated to some sensors that need downlinks to execute the commands ([See Figure 8](#fig8)). Smart Bidding codes decide the willingness for the sensor/end devices to pay for the resources, and all the transactions are settled in MXC. + +Both the European and U.S. radio committees impose regulations on the spectrum access for LPWAN radios using 868/915Mhz bands. These regulations cover issues from maximum time on air to maximum duty cycle, which, in turn, introduces waiting times between two packets. For Gateways without Listen-Before-Talk Technology, this waiting time can range anywhere from a few milliseconds to minutes depending on the data rate and number of bytes being sent. + + +
+ LPWAN +
+ +Currently, the downlink resource is distributed on a “first come first served” basis, which can lead to many potential problems for various devices. For example, if an electricity monitoring meter were to get downlink priority over a door lock, the door lock in turn doesn’t receive the confirmation to unlock the door. The MXProtocol Smart Bidding solves this problem as covered in the following two aspects: + +- Allocate the downlink resource within the same LPWAN using the Smart Bidding code snippet for the auction. +- Enable different networks to trade for the downlink resources for the sensors/ end devices that are willing to pay. + +The snippet of code inside the sensors/end devices decides the market prices of the LPWAN. For a dense Gateway deployment like a city center, the prices can be lower due to the abundant resources of the downlink channels available. While in the mountains or suburban areas, few sensors would compete for the downlink resources and thus the prices will rise. The sensors will bid according to the MTBF, downlink numbers and the density of the network. + +The auction method and logic behind the bidding can be programmed by the owner of the sensor. It is expected that AI-driven algorithms will later be introduced to offer smarter bidding strategy for the sensors and end devices. + +### 8.2 Network coverage market + +It is expected that the supply of downlink resources will gradually increase with the demand of the sensors/end devices. The bidders will pay for the high prices for the lower Gateway density, which gives SMEs and MNCs incentives to expand the network coverage to get more MXC coin rewards. + +Figure 6 illustrates the market placed by Smart Bidding codes. The prices are lower at the dense deployment where the two LPWAN coverages overlap, and higher where there is only one LPWAN coverage. + +Some sensors travel around the city. Their code specifies the maximum amount of coins that it would like to pay for a single downlink. However, they have been to the places where no LPWAN coverage is available. Once they are back to the network, they put the last off-chain bid to the chain, and notify the whole network that they are willing to pay a pre-determined price from the Smart Bidding code. + +The prices and the amount of off-chain bids will surely motivate companies and individuals to deploy the LPWAN Gateway to the field, thus expanding the network coverage for the chain. MXProtocol shifts control from telecommunication conglomerates to companies and individuals by allowing them to deploy their own LPWAN. + +### 8.3 Service market + +There are lists of services that LPWAN can provide to the sensors/end devices. For example, an Over-the-air firmware update should be multi-casted to the sensors with downlink and it requires the sensors to bid for the resource. + +The most attractive aspect of the LPWAN is to implement GPS-free localization, which also works indoors and underground. In contrast to GPS or SIM card’s high power consumption and limited reach, LPWAN localization uses the packets sent by the sensors to calculate the position, which requires no computation from the resource-limited sensors. + +Such a service requires the resources of both a Gateway and the cloud. Hence, the Smart Bidding code will specify whether it is willing to pay for the service and its accuracy. The more Gateways that receive the packets, the more accurate the position will be. + +LPWAN sometimes needs to change the channel configurations like the arrangement or the allowed data rate. This kind of coordination will need to be applied globally and the network will have to try to synchronize such a configuration as much as possible. Smart Bidding can also accept “free auctions” where they require no one to pay. + +Through the MXProtocol Smart Bidding design, it is possible that sensors/end devices pay for the services that the network offers to them. The outcome of the design will be: + +- Some sensors/end devices get the services and the resources that they demand through auction +- Network deployment receives reward by offering services and resources to the LPWAN sensors/end devices +- All the monetary transactions are done automatically in MXC without human intervention + +## 9. Development progress + +MXC Foundation’s partner MatchX has released the MatchBox LPWAN Gateway, and the LPWAN module with development kits. It has reached more than 40 countries with distributors in Australia, North America, Asia and Europe. + +The first Proof-of-Concept has been performed in conjunction with the Stellar Development Foundation, utilizing the LPWAN coverage and enabling sensors to pay with each other. + +## 10. References + +- _What is LPWAN (low-power wide area network)?_ - Definition from WhatIs.com. (2018). IoT Agenda. Retrieved 8 January 2018, from +- _LoRa Alliance._ (2018). LoRa Alliance. Retrieved 8 January 2018, from +- _Skywire and Viscript | Skycoin Blog._ (2018). Blog.skycoin.net. Retrieved 8 January 2018, from +- _Skywire - Skycoin Meshnet Project | Skycoin Blog._ (2018). Blog.skycoin.net. Retrieved 8 January 2018, from +- _contributors, S._ (2018). Create an Account | Stellar Developers. Stellar.org. Retrieved 5 February 2018, from +- Kusmierz, B. (2017). _The first glance at the simulation of the Tangle: discrete model._ +- Popov, S. (2016). _The tangle._ IOTA. +- Kim, J. (2014). _Introducing Stellar - Stellar CN._ Stellar CN. Retrieved 5 February 2018, from +- _Ethereum Project._ (2018). Ethereum.org. Retrieved 8 January 2018, from +- _RSK._ (2018). RSK. Retrieved 8 January 2018, from +- Dudley, J., Hochstetler, G., Dudley, J., Hearn, M., Hearn, M., \& Hearn, M. (2018). _Corda: Frictionless Commerce._ corda.net. Retrieved 8 January 2018, from +- _LoRaWAN in Europe._ (2017). Matchx.io. Retrieved 8 January 2018, from +- _LoRaWAN regulations in Korea, Australia, India Japan and South East Asia._ (2017). Matchx.io. Retrieved 8 January 2018, from diff --git a/i18n/zh/code.json b/i18n/zh/code.json new file mode 100644 index 0000000..b4bed9b --- /dev/null +++ b/i18n/zh/code.json @@ -0,0 +1,175 @@ +{ + "Leverage the MXProtocol on LPWAN Miners to build the free Global IoT Network.": { + "message": "Leverage the MXProtocol on LPWAN Miners to build the free Global IoT Network." + }, + "Configure your LPWAN devices and sensors to use the MXProtocol's unique provisioning method providing your users with a turnkey experience.": { + "message": "Configure your LPWAN devices and sensors to use the MXProtocol's unique provisioning method providing your users with a turnkey experience." + }, + "Connect to your LPWAN devices with data analysis tools.": { + "message": "Connect to your LPWAN devices with data analysis tools." + }, + "theme.NotFound.title": { + "message": "Page Not Found", + "description": "The title of the 404 page" + }, + "theme.NotFound.p1": { + "message": "We could not find what you were looking for.", + "description": "The first paragraph of the 404 page" + }, + "theme.NotFound.p2": { + "message": "Please contact the owner of the site that linked you to the original URL and let them know their link is broken.", + "description": "The 2nd paragraph of the 404 page" + }, + "theme.blog.paginator.navAriaLabel": { + "message": "Blog list page navigation", + "description": "The ARIA label for the blog pagination" + }, + "theme.blog.paginator.newerEntries": { + "message": "Newer Entries", + "description": "The label used to navigate to the newer blog posts page (previous page)" + }, + "theme.blog.paginator.olderEntries": { + "message": "Older Entries", + "description": "The label used to navigate to the older blog posts page (next page)" + }, + "theme.blog.post.readingTime.plurals": { + "message": "One min read|{readingTime} min read", + "description": "Pluralized label for \"{readingTime} min read\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" + }, + "theme.tags.tagsListLabel": { + "message": "Tags:", + "description": "The label alongside a tag list" + }, + "theme.blog.post.readMore": { + "message": "Read More", + "description": "The label used in blog post item excerpts to link to full blog posts" + }, + "theme.blog.post.paginator.navAriaLabel": { + "message": "Blog post page navigation", + "description": "The ARIA label for the blog posts pagination" + }, + "theme.blog.post.paginator.newerPost": { + "message": "Newer Post", + "description": "The blog post button label to navigate to the newer/previous post" + }, + "theme.blog.post.paginator.olderPost": { + "message": "Older Post", + "description": "The blog post button label to navigate to the older/next post" + }, + "theme.blog.sidebar.navAriaLabel": { + "message": "Blog recent posts navigation", + "description": "The ARIA label for recent posts in the blog sidebar" + }, + "theme.AnnouncementBar.closeButtonAriaLabel": { + "message": "Close", + "description": "The ARIA label for close button of announcement bar" + }, + "theme.tags.tagsPageTitle": { + "message": "Tags", + "description": "The title of the tag list page" + }, + "theme.blog.post.plurals": { + "message": "One post|{count} posts", + "description": "Pluralized label for \"{count} posts\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" + }, + "theme.blog.tagTitle": { + "message": "{nPosts} tagged with \"{tagName}\"", + "description": "The title of the page for a blog tag" + }, + "theme.tags.tagsPageLink": { + "message": "View All Tags", + "description": "The label of the link targeting the tag list page" + }, + "theme.CodeBlock.copyButtonAriaLabel": { + "message": "Copy code to clipboard", + "description": "The ARIA label for copy code blocks button" + }, + "theme.CodeBlock.copied": { + "message": "Copied", + "description": "The copied button label on code blocks" + }, + "theme.CodeBlock.copy": { + "message": "Copy", + "description": "The copy button label on code blocks" + }, + "theme.docs.sidebar.expandButtonTitle": { + "message": "Expand sidebar", + "description": "The ARIA label and title attribute for expand button of doc sidebar" + }, + "theme.docs.sidebar.expandButtonAriaLabel": { + "message": "Expand sidebar", + "description": "The ARIA label and title attribute for expand button of doc sidebar" + }, + "theme.docs.paginator.navAriaLabel": { + "message": "Docs pages navigation", + "description": "The ARIA label for the docs pagination" + }, + "theme.docs.paginator.previous": { + "message": "Previous", + "description": "The label used to navigate to the previous doc" + }, + "theme.docs.paginator.next": { + "message": "Next", + "description": "The label used to navigate to the next doc" + }, + "theme.docs.sidebar.collapseButtonTitle": { + "message": "Collapse sidebar", + "description": "The title attribute for collapse button of doc sidebar" + }, + "theme.docs.sidebar.collapseButtonAriaLabel": { + "message": "Collapse sidebar", + "description": "The title attribute for collapse button of doc sidebar" + }, + "theme.docs.sidebar.responsiveCloseButtonLabel": { + "message": "Close menu", + "description": "The ARIA label for close button of mobile doc sidebar" + }, + "theme.docs.sidebar.responsiveOpenButtonLabel": { + "message": "Open menu", + "description": "The ARIA label for open button of mobile doc sidebar" + }, + "theme.docs.sidebar.navAriaLabel": { + "message": "Sidebar navigation", + "description": "The ARIA label for documentation menu" + }, + "theme.docs.versions.unreleasedVersionLabel": { + "message": "This is unreleased documentation for {siteTitle} {versionLabel} version.", + "description": "The label used to tell the user that he's browsing an unreleased doc version" + }, + "theme.docs.versions.unmaintainedVersionLabel": { + "message": "This is documentation for {siteTitle} {versionLabel}, which is no longer actively maintained.", + "description": "The label used to tell the user that he's browsing an unmaintained doc version" + }, + "theme.docs.versions.latestVersionSuggestionLabel": { + "message": "For up-to-date documentation, see the {latestVersionLink} ({versionLabel}).", + "description": "The label userd to tell the user that he's browsing an unmaintained doc version" + }, + "theme.docs.versions.latestVersionLinkLabel": { + "message": "latest version", + "description": "The label used for the latest version suggestion link label" + }, + "theme.common.editThisPage": { + "message": "Edit this page", + "description": "The link label to edit the current page" + }, + "theme.common.headingLinkTitle": { + "message": "Direct link to heading", + "description": "Title for link to heading" + }, + "theme.lastUpdated.atDate": { + "message": " on {date}", + "description": "The words used to describe on which date a page has been last updated" + }, + "theme.lastUpdated.byUser": { + "message": " by {user}", + "description": "The words used to describe by who the page has been last updated" + }, + "theme.lastUpdated.lastUpdatedAtBy": { + "message": "Last updated{atDate}{byUser}", + "description": "The sentence used to display when a page has been last updated, and by who" + }, + "theme.common.skipToMainContent": { + "message": "Skip to main content", + "description": "The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation" + } +} \ No newline at end of file diff --git a/i18n/zh/docusaurus-plugin-content-blog/2019-05-30-welcome.md b/i18n/zh/docusaurus-plugin-content-blog/2019-05-30-welcome.md new file mode 100644 index 0000000..a85fec8 --- /dev/null +++ b/i18n/zh/docusaurus-plugin-content-blog/2019-05-30-welcome.md @@ -0,0 +1,13 @@ +--- +slug: welcome +title: Welcome +author: Jeff Stahlnecker +author_title: Front End Engineer @ Facebook +author_url: https://github.com/jeffstahlnecker +author_image_url: https://avatars.githubusercontent.com/u/45363541?v=4 +tags: + - welcome + - intro +--- + +It's the beginning. Since I returned to the community following the Miner Health release, I've been saying that we'll impove transparency in development at MXC. This site is the beginning of this transparency. More content will be added here. diff --git a/i18n/zh/docusaurus-plugin-content-docs/current.json b/i18n/zh/docusaurus-plugin-content-docs/current.json new file mode 100644 index 0000000..893a6c4 --- /dev/null +++ b/i18n/zh/docusaurus-plugin-content-docs/current.json @@ -0,0 +1,18 @@ +{ + "version.label": { + "message": "Next", + "description": "The label for version current" + }, + "sidebar.tutorialSidebar.category.M2 Pro Miner": { + "message": "M2 Pro Miner", + "description": "The label for category M2 Pro Miner in sidebar tutorialSidebar" + }, + "sidebar.tutorialSidebar.category.Devices": { + "message": "Devices", + "description": "The label for category Devices in sidebar tutorialSidebar" + }, + "sidebar.tutorialSidebar.category.Supernode": { + "message": "Supernode", + "description": "The label for category Supernode in sidebar tutorialSidebar" + } +} \ No newline at end of file diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/api/intro.md b/i18n/zh/docusaurus-plugin-content-docs/current/api/intro.md new file mode 100644 index 0000000..ab0d5c0 --- /dev/null +++ b/i18n/zh/docusaurus-plugin-content-docs/current/api/intro.md @@ -0,0 +1,7 @@ +--- +title: Introduction +sidebar_position: 1 +--- + +# MXC API +Public Access API \ No newline at end of file diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/devices/_category_.json b/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/devices/_category_.json new file mode 100644 index 0000000..e6288dd --- /dev/null +++ b/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/devices/_category_.json @@ -0,0 +1,4 @@ +{ + "label": "Devices", + "position": 3 +} diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/devices/integrations.md b/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/devices/integrations.md new file mode 100644 index 0000000..00eb445 --- /dev/null +++ b/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/devices/integrations.md @@ -0,0 +1,221 @@ +--- +sidebar_position: 3 +title: Integrations +--- + +# Device Integrations + +By default supernode provides MQTT broker service for users to subscribe or pushlish events on their devices. + +Users can subscribe to MQTT broker under topics in the servers after authentication. Before that, you need to make sure you have mosquitto package installed. Use the package manager apt to install these dependencies on the Ubuntu 18.04 LTS server: + +``` +sudo apt-add-repository ppa:mosquitto-dev/mosquitto-ppa +sudo apt-get update +sudo apt install mosquitto mosquitto-clients +``` + +## Subscription + +You can either subscribe to the broker in your console or you can use package for Subscription inside your program. + +A template of subscribing to the topic: + +```shell +mosquitto_sub -h {{ .SUPERNODE_URL }} -p 8883 -t '{{ .EVENT_TOPIC_STRING }}' -v -u '{{ .USER_MQTT_AUTH_JWT }}' -P 'default' -i '`hostname`-$$' --capath /etc/ssl/certs +``` + +### How to get `{{ .SUPERNODE_URL }}` + +`{{ .SUPERNODE_URL }}` is the URL of supernode where you registered your devices: + +- matchx EU `lora.supernode.matchx.io` +- matchx US `ussn.matchx.io` +- hHuaweikeji `lora.hunanhuaweikeji.com` +- mxcxy `mxcxy.com` +- k-supernode `k-supernode.com` +- enlink `lora.rosanetworks.com` +- du-capital `supernode.iot-ducapital.net` + +### How to get `{{ .EVENT_TOPIC_STRING }}` + +1. Get JWT for supernode user account, in the following content, we call it `{{ .SUPERNODE_JWT }}` + +`{{ .SUPERNODE_JWT }}` will be used for authenticate your further requests. + +Call + +```shell +curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' -d '{ "password": "{{ .SUPERNODE_PASSWORD }}", "username": "{{ .SUPERNODE_USERNAME }}"}' 'https://{{ .SUPERNODE_URL }}/api/internal/login' +``` + +Response + +```json +{ + "jwt": "{{ .SUPERNODE_JWT }}", + "is2faRequired": false +} +``` + +2. Get organization list + +`{{ .ORG_ID }}` is important parameter for your further requests. + +Call + +```shell +curl -X GET --header 'Accept: application/json' --header 'Grpc-Metadata-Authorization: Bearer {{ .SUPERNODE_JWT }}' 'https://{{ .SUPERNODE_URL }}/api/organizations?limit=999&offset=0' +``` + +Response + +```json +{ + "totalCount": "1", + "result": [ + { + "id": "{{ .ORG_ID }}", + "name": "Your Organization Name", + "displayName": "Your Organization Display Name", + "canHaveGateways": true, + "createdAt": "2020-04-22T09:53:38.928940Z", + "updatedAt": "2021-05-12T12:50:02.391191Z" + } + ] +} +``` + +3. Get application list with given `{{ .ORG_ID }}` + +Call + +```shell +curl -X GET --header 'Accept: application/json' --header 'Grpc-Metadata-Authorization: Bearer {{ .SUPERNODE_JWT }}' 'https://{{ .SUPERNODE_URL }}/api/applications?limit=999&offset=0&organizationID={{ .ORG_ID }}' +``` + +Response + +```json +{ + "totalCount": "1", + "result": [ + { + "id": "{{ .APPLICATION_ID }}", + "name": "Your application name", + "description": "description", + "organizationID": "{{ .ORG_ID }}", + "serviceProfileID": "service profile id", + "serviceProfileName": "service proile name" + } + ] +} +``` + +4. Get `{{ .EVENT_TOPIC_STRING }}` for subscribing to all devices' events under same application + +Call + +```shell +curl -X GET --header 'Accept: application/json' --header 'Grpc-Metadata-Authorization: Bearer {{ .SUPERNODE_JWT }}' 'https://{{ .SUPERNODE_URL }}/api/mosquitto-auth/subscribe-application-events?applicationId={{ .APPLICATION_ID }}&organizationId={{ .ORG_ID }}' +``` + +Response + +```json +{ + "topic": "Topic for subscribing to application {{ .APPLICATION_ID }}: 'application/{{ .APPLICATION_ID }}/device/+/event/+'" +} +``` + +5. Get `{{ .EVENT_TOPIC_STRING }}` for subscribing to events with given {{ .DEV_EUI }} and {{ .ORG_ID }} + +Call + +```shell +curl -X GET --header 'Accept: application/json' --header 'Grpc-Metadata-Authorization: Bearer {{ .SUPERNODE_JWT }}' 'https://{{ .SUPERNODE_URL }}/api/mosquitto-auth/subscribe-device-events?devEui={{ .DEV_EUI }}&organizationId={{ .ORG_ID }}' + +``` + +Response + +```json +{ + "topic": [ + "Topic for subscribing to device {{ .DEV_EUI }} on event up: 'application/{{ .APPLICATION_ID }}/device/{{ .DEV_EUI }}/event/up'", + "Topic for subscribing to device {{ .DEV_EUI }} on event join: 'application/{{ .APPLICATION_ID }}/device/{{ .DEV_EUI }}/event/join'", + "Topic for subscribing to device {{ .DEV_EUI }} on event ack: 'application/{{ .APPLICATION_ID }}/device/{{ .DEV_EUI }}/event/ack'", + "Topic for subscribing to device {{ .DEV_EUI }} on event error: 'application/{{ .APPLICATION_ID }}/device/{{ .DEV_EUI }}/event/error'", + "Topic for subscribing to device {{ .DEV_EUI }} on event status: 'application/{{ .APPLICATION_ID }}/device/{{ .DEV_EUI }}/event/status'", + "Topic for subscribing to device {{ .DEV_EUI }} on event location: 'application/{{ .APPLICATION_ID }}/device/{{ .DEV_EUI }}/event/location'", + "Topic for subscribing to device {{ .DEV_EUI }} on event txack: 'application/{{ .APPLICATION_ID }}/device/{{ .DEV_EUI }}/event/txack'", + "Topic for subscribing to device {{ .DEV_EUI }} on all events: 'application/{{ .APPLICATION_ID }}/device/{{ .DEV_EUI }}/event/+'" + ] +} +``` + +### How to get `{{ .USER_MQTT_AUTH_JWT }}` + +Call + +```shell +curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'Grpc-Metadata-Authorization: Bearer {{ .SUPERNODE_JWT }}' -d '{ "organizationId": "{{ .ORG_ID }}"}' 'https://{{ .SUPERNODE_URL }}/api/mosquitto-auth/login' +``` + +Response + +```json +{ + "jwtMqttAuth": "{{ .USER_MQTT_AUTH_JWT }}" +} +``` + +## Publishing + +A template of publishing with mosquitto_pub looks as this: + +```shell +mosquitto_pub -h {{ .SUPERNODE_URL }} -p 8883 -u '{{ .USER_MQTT_AUTH_JWT }}' -P 'default' -i '`hostname`-$$' -t '{{ .COMMAND_TOPIC_STRING }}' -m '{{ .MESSAGE }}' --capath /etc/ssl/certs + +``` + +### How to get `{{ .COMMAND_TOPIC_STRING }}` + +Call + +```shell +curl -X GET --header 'Accept: application/json' --header 'Grpc-Metadata-Authorization: Bearer {{ .SUPERNODE_JWT }}' 'https://{{ .SUPERNODE_URL }}/api/mosquitto-auth/send-command?devEui={{ .DEV_EUI }}&organizationId={{ .ORG_ID }}' +``` + +Response + +```json +{ + "topic": "Topic for publishing to device {{ .DEV_EUI }}: 'application/{{ .APPLICATION_ID }}/device/{{ .DEV_EUI }}/command/down'" +} +``` + +### How to get `{{ .MESSAGE }}` + +The message format should be as follow: + +```json +{ + "confirmed": true, + "fPort": 10, + "data": "....", + "object": { + "temperatureSensor": { + "1": 25 + }, + "humiditySensor": { + "1": 32 + } + } +} +``` + +- `confirmed`: whether the payload must be sent as confirmed data down or not +- `fPort`: FPort to use (must be > 0) +- `data`: base64 encoded data (plaintext, will be encrypted by Network Server) +- `object`: decoded object (when application codec has been configured), when providing the 'object', you can omit ' data' diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/devices/intro.md b/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/devices/intro.md new file mode 100644 index 0000000..b0dafc2 --- /dev/null +++ b/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/devices/intro.md @@ -0,0 +1,6 @@ +--- +sidebar_position: 1 +title: Introduction +--- + +# MXProtocol Enabled Devices \ No newline at end of file diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/devices/provisioning.md b/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/devices/provisioning.md new file mode 100644 index 0000000..f608ab2 --- /dev/null +++ b/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/devices/provisioning.md @@ -0,0 +1,5 @@ +--- +sidebar_position: 2 +--- + +# Device Provisioning \ No newline at end of file diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/intro.md b/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/intro.md new file mode 100644 index 0000000..56a974b --- /dev/null +++ b/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/intro.md @@ -0,0 +1,35 @@ +--- +title: Introduction +sidebar_position: 1 +--- + +# Introduction + +There are a number of ways for developers to interact with the MXC ecosystem. These forms of participation are integral to the further development and deployment of the MXProtocol. + +## Direct Participation +We have a number of public repos with active issues that could use assistance. Our team is still growing, and community support is always appreciated, encouraged and in some cases rewarded. + +Here is an updated list of repos that could use assistance. +* [DataDash App](https://github.com/mxc-foundation/supernode-app) [Flutter / Dart] +* [Developer Documentation](https://github.com/mxc-foundation/developer-documentation) [Markdown, Javascript] + +We will continue to add repositories to this list as we work to increase transparency with our code and development process. + +## Manufacturing / Configuring Devices +Without devices the network has no purpose. Therefore, we've created an easy way for manufacturers to get involved with the network, making it possible for their devices to be deployed as a turnkey solution in the MXC ecosystem. + +In order to increase security of the entire network, we've worked with MatchX to develop a novel provisioning concept for LoRa devices. This provisioning process is a requirement for any devices intending to be MXProtocol compatible. We have made this decision as: +1. Device provisioning increases the security of the device data +1. Users will be able to deploy devices without any additional hassle +1. Improve device data integration and compatibility + +You can discover more about device provisioning for the MXProtocol in Devices. + +## Reporting Issues +Even though we attempt to do rigorous QA before every release, some pesky bugs still slip through. Actively reporting bugs is an extremely important form of participation, and helps us to improve the stability of the entire network. + +You can report bugs in the #bugs channel in our [Discord Server](https://mxc.news/discord) + +Bugs can also be reported directly as issues in the relevant GitHub Repo: +* [DataDash App Bugs](https://github.com/mxc-foundation/supernode-app/issues) \ No newline at end of file diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/m2-pro/_category_.json b/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/m2-pro/_category_.json new file mode 100644 index 0000000..c3a9dcb --- /dev/null +++ b/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/m2-pro/_category_.json @@ -0,0 +1,4 @@ +{ + "label": "M2 Pro Miner", + "position": 2 +} diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/m2-pro/gui.md b/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/m2-pro/gui.md new file mode 100644 index 0000000..ab0362b --- /dev/null +++ b/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/m2-pro/gui.md @@ -0,0 +1,5 @@ +--- +sidebar_position: 3 +--- + +# Web GUI \ No newline at end of file diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/m2-pro/intro.md b/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/m2-pro/intro.md new file mode 100644 index 0000000..aa259e4 --- /dev/null +++ b/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/m2-pro/intro.md @@ -0,0 +1,6 @@ +--- +title: Introduction +sidebar_position: 1 +--- + +# The M2 Pro Miner \ No newline at end of file diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/m2-pro/miner-health.md b/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/m2-pro/miner-health.md new file mode 100644 index 0000000..8b65ad3 --- /dev/null +++ b/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/m2-pro/miner-health.md @@ -0,0 +1,5 @@ +--- +sidebar_position: 4 +--- + +# Miner Health diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/m2-pro/setup.md b/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/m2-pro/setup.md new file mode 100644 index 0000000..e65e163 --- /dev/null +++ b/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/m2-pro/setup.md @@ -0,0 +1,5 @@ +--- +sidebar_position: 2 +--- + +# Setup \ No newline at end of file diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/m2-pro/troubleshooting.md b/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/m2-pro/troubleshooting.md new file mode 100644 index 0000000..569c821 --- /dev/null +++ b/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/m2-pro/troubleshooting.md @@ -0,0 +1,5 @@ +--- +sidebar_position: 5 +--- + +# Troubleshooting \ No newline at end of file diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/supernode/_category_.json b/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/supernode/_category_.json new file mode 100644 index 0000000..9cffdf1 --- /dev/null +++ b/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/supernode/_category_.json @@ -0,0 +1,4 @@ +{ + "label": "Supernode", + "position": 4 +} diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/supernode/intro.md b/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/supernode/intro.md new file mode 100644 index 0000000..3414fdc --- /dev/null +++ b/i18n/zh/docusaurus-plugin-content-docs/current/tutorials/supernode/intro.md @@ -0,0 +1,6 @@ +--- +sidebar_position: 1 +title: Introduction +--- + +# Introducing Supernodes \ No newline at end of file diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/whitepapers/intro.md b/i18n/zh/docusaurus-plugin-content-docs/current/whitepapers/intro.md new file mode 100644 index 0000000..adeb6a8 --- /dev/null +++ b/i18n/zh/docusaurus-plugin-content-docs/current/whitepapers/intro.md @@ -0,0 +1,8 @@ +--- +title: Introduction +sidebar_position: 1 +--- + +# MXC Whitepapers + +Overview of the WhitePapers \ No newline at end of file diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/whitepapers/mxc-data-economy.md b/i18n/zh/docusaurus-plugin-content-docs/current/whitepapers/mxc-data-economy.md new file mode 100644 index 0000000..7bcfc32 --- /dev/null +++ b/i18n/zh/docusaurus-plugin-content-docs/current/whitepapers/mxc-data-economy.md @@ -0,0 +1,6 @@ +--- +title: MXC Data Economy +sidebar_position: 3 +--- + +# MXC Data Economy \ No newline at end of file diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/whitepapers/mxprotocol.md b/i18n/zh/docusaurus-plugin-content-docs/current/whitepapers/mxprotocol.md new file mode 100644 index 0000000..6768da7 --- /dev/null +++ b/i18n/zh/docusaurus-plugin-content-docs/current/whitepapers/mxprotocol.md @@ -0,0 +1,6 @@ +--- +title: MXProtocol +sidebar_position: 2 +--- + +# MXProtocol \ No newline at end of file diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/whitepapers/smart-machine-bidding.md b/i18n/zh/docusaurus-plugin-content-docs/current/whitepapers/smart-machine-bidding.md new file mode 100644 index 0000000..72dd182 --- /dev/null +++ b/i18n/zh/docusaurus-plugin-content-docs/current/whitepapers/smart-machine-bidding.md @@ -0,0 +1,6 @@ +--- +title: Smart Machine Bidding +sidebar_position: 3 +--- + +# Smart Machine Bidding \ No newline at end of file diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/whitepapers/tokenomics.md b/i18n/zh/docusaurus-plugin-content-docs/current/whitepapers/tokenomics.md new file mode 100644 index 0000000..e7fca3d --- /dev/null +++ b/i18n/zh/docusaurus-plugin-content-docs/current/whitepapers/tokenomics.md @@ -0,0 +1,6 @@ +--- +title: Tokenomics +sidebar_position: 4 +--- + +# Tokenomics \ No newline at end of file diff --git a/i18n/zh/docusaurus-theme-classic/footer.json b/i18n/zh/docusaurus-theme-classic/footer.json new file mode 100644 index 0000000..0cb80f5 --- /dev/null +++ b/i18n/zh/docusaurus-theme-classic/footer.json @@ -0,0 +1,66 @@ +{ + "link.title.Docs": { + "message": "Docs", + "description": "The title of the footer links column with title=Docs in the footer" + }, + "link.title.Community": { + "message": "Community", + "description": "The title of the footer links column with title=Community in the footer" + }, + "link.title.More": { + "message": "More", + "description": "The title of the footer links column with title=More in the footer" + }, + "link.item.label.Tutorials": { + "message": "Tutorials", + "description": "The label of footer link with label=Tutorials linking to /docs/tutorials/intro" + }, + "link.item.label.API": { + "message": "API", + "description": "The label of footer link with label=API linking to /docs/api/intro" + }, + "link.item.label.Whitepapers": { + "message": "Whitepapers", + "description": "The label of footer link with label=Whitepapers linking to /docs/whitepapers/intro" + }, + "link.item.label.Telegram": { + "message": "Telegram", + "description": "The label of footer link with label=Telegram linking to https://mxc.news/telegram" + }, + "link.item.label.Discord": { + "message": "Discord", + "description": "The label of footer link with label=Discord linking to https://mxc.news/discord" + }, + "link.item.label.Twitter": { + "message": "Twitter", + "description": "The label of footer link with label=Twitter linking to https://twitter.com/mxcfoundation" + }, + "link.item.label.Developer Blog": { + "message": "Developer Blog", + "description": "The label of footer link with label=Developer Blog linking to /blog" + }, + "link.item.label.GitHub": { + "message": "GitHub", + "description": "The label of footer link with label=GitHub linking to https://github.com/mxc-foundation/" + }, + "link.item.label.MXC Website": { + "message": "MXC Website", + "description": "The label of footer link with label=MXC Website linking to https://www.mxc.org" + }, + "link.item.label.User Documentation": { + "message": "User Documentation", + "description": "The label of footer link with label=User Documentation linking to https://www.mxc.wiki" + }, + "link.item.label.Imprint": { + "message": "Imprint", + "description": "The label of footer link with label=Imprint linking to https://www.mxc.org/imprint" + }, + "link.item.label.Privacy Policy": { + "message": "Privacy Policy", + "description": "The label of footer link with label=Privacy Policy linking to https://www.mxc.org/privacy-policy" + }, + "copyright": { + "message": "Copyright © 2021 MXC Foundation gGmbH.", + "description": "The footer copyright" + } +} \ No newline at end of file diff --git a/i18n/zh/docusaurus-theme-classic/navbar.json b/i18n/zh/docusaurus-theme-classic/navbar.json new file mode 100644 index 0000000..63fefb5 --- /dev/null +++ b/i18n/zh/docusaurus-theme-classic/navbar.json @@ -0,0 +1,26 @@ +{ + "title": { + "message": "Developer Documentation", + "description": "The title in the navbar" + }, + "item.label.Docs": { + "message": "Docs", + "description": "Navbar item with label Docs" + }, + "item.label.API": { + "message": "API", + "description": "Navbar item with label API" + }, + "item.label.Whitepapers": { + "message": "Whitepapers", + "description": "Navbar item with label Whitepapers" + }, + "item.label.Blog": { + "message": "Blog", + "description": "Navbar item with label Blog" + }, + "item.label.GitHub": { + "message": "GitHub", + "description": "Navbar item with label GitHub" + } +} \ No newline at end of file