├── .dir-locals.el ├── .github └── workflows │ └── pre-commit.yml ├── .gitignore ├── .mailmap ├── .mergify.yml ├── .pre-commit-config.yaml ├── CNAME ├── CNAME.license ├── LICENSES ├── 0BSD.txt ├── CC-BY-NC-ND-4.0.txt ├── CC-BY-SA-4.0.txt └── MIT.txt ├── README.md ├── constraints.txt ├── contributing └── reverse-engineered.md ├── foliant.yml ├── mkdocs_theme ├── img │ ├── apple-touch-icon.png │ ├── apple-touch-icon.png.license │ ├── favicon.ico │ ├── favicon.ico.license │ ├── favicon.svg │ └── favicon.svg.license └── main.html ├── requirements.txt └── src ├── abbott ├── freestyle-insulinx.md ├── freestyle-libre-2.md ├── freestyle-libre.md ├── freestyle-lite.md ├── freestyle-optium.md ├── freestyle-precision-neo.md └── shared-hid-protocol.md ├── index.md ├── lifescan ├── onetouch-ultra2.md ├── onetouch-ultraeasy.md ├── onetouch-verio-2015.md ├── onetouch-verio-iq.md └── shared-binary-protocol.md ├── menarini └── glucomen-areo.md ├── sanofi └── bgstar-mystar.md ├── sd-biosensor └── codefree.md └── taidoc └── td42xx.md /.dir-locals.el: -------------------------------------------------------------------------------- 1 | ; SPDX-FileCopyrightText: 2016 The Glucometer Protocols Authors 2 | ; 3 | ; SPDX-License-Identifier: MIT 4 | 5 | ((nil . ((fill-column . 80) 6 | (indent-tabs-mode . nil))) 7 | (markdown-mode . ((mode . flyspell) 8 | (mode . whitespace)))) 9 | -------------------------------------------------------------------------------- /.github/workflows/pre-commit.yml: -------------------------------------------------------------------------------- 1 | # SPDX-FileCopyrightText: Copyright (c) 2019 Anthony Sottile 2 | # 3 | # SPDX-License-Identifier: MIT 4 | 5 | name: pre-commit 6 | 7 | on: 8 | pull_request: 9 | push: 10 | branches: [main] 11 | 12 | jobs: 13 | pre-commit: 14 | runs-on: ubuntu-latest 15 | steps: 16 | - uses: actions/checkout@v2 17 | - uses: actions/setup-python@v2 18 | - uses: pre-commit/action@v2.0.0 19 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # SPDX-FileCopyrightText: 2016 The Glucometer Protocols Authors 2 | # 3 | # SPDX-License-Identifier: MIT 4 | 5 | /*.log 6 | /*.mkdocs 7 | /.diagramscache 8 | *~ 9 | venv/ 10 | -------------------------------------------------------------------------------- /.mailmap: -------------------------------------------------------------------------------- 1 | # SPDX-FileCopyrightText: 2016 The Glucometer Protocols Authors 2 | # 3 | # SPDX-License-Identifier: MIT 4 | 5 | Diego Elio Pettenò 6 | -------------------------------------------------------------------------------- /.mergify.yml: -------------------------------------------------------------------------------- 1 | # SPDX-FileCopyrightText: 2016 The Glucometer Protocols Authors 2 | # 3 | # SPDX-License-Identifier: MIT 4 | 5 | pull_request_rules: 6 | - name: Automatic merge on approval 7 | conditions: 8 | - "#approved-reviews-by>=1" 9 | - "status-success=netlify/glucometer-protocols/deploy-preview" 10 | - "status-success=pre-commit" 11 | actions: 12 | merge: 13 | method: rebase 14 | - name: Automatic merge from Flameeyes 15 | conditions: 16 | - "author=Flameeyes" 17 | - "status-success=netlify/glucometer-protocols/deploy-preview" 18 | - "status-success=pre-commit" 19 | actions: 20 | merge: 21 | method: rebase 22 | -------------------------------------------------------------------------------- /.pre-commit-config.yaml: -------------------------------------------------------------------------------- 1 | # SPDX-FileCopyrightText: 2016 The Glucometer Protocols Authors 2 | # 3 | # SPDX-License-Identifier: MIT 4 | 5 | repos: 6 | - repo: https://github.com/pre-commit/pre-commit-hooks 7 | rev: v4.4.0 8 | hooks: 9 | - id: end-of-file-fixer 10 | - id: trailing-whitespace 11 | - repo: https://github.com/fsfe/reuse-tool 12 | rev: v1.1.2 13 | hooks: 14 | - id: reuse 15 | -------------------------------------------------------------------------------- /CNAME: -------------------------------------------------------------------------------- 1 | protocols.glucometers.tech 2 | -------------------------------------------------------------------------------- /CNAME.license: -------------------------------------------------------------------------------- 1 | SPDX-FileCopyrightText: 2016 The Glucometer Protocols Authors 2 | 3 | SPDX-License-Identifier: MIT 4 | -------------------------------------------------------------------------------- /LICENSES/0BSD.txt: -------------------------------------------------------------------------------- 1 | Copyright (C) YEAR by AUTHOR EMAIL 2 | 3 | Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted. 4 | 5 | THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. 6 | -------------------------------------------------------------------------------- /LICENSES/CC-BY-NC-ND-4.0.txt: -------------------------------------------------------------------------------- 1 | Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International 2 | 3 | Creative Commons Corporation (“Creative Commons”) is not a law firm and does not provide legal services or legal advice. Distribution of Creative Commons public licenses does not create a lawyer-client or other relationship. Creative Commons makes its licenses and related information available on an “as-is” basis. Creative Commons gives no warranties regarding its licenses, any material licensed under their terms and conditions, or any related information. Creative Commons disclaims all liability for damages resulting from their use to the fullest extent possible. 4 | 5 | Using Creative Commons Public Licenses 6 | 7 | Creative Commons public licenses provide a standard set of terms and conditions that creators and other rights holders may use to share original works of authorship and other material subject to copyright and certain other rights specified in the public license below. The following considerations are for informational purposes only, are not exhaustive, and do not form part of our licenses. 8 | 9 | Considerations for licensors: Our public licenses are intended for use by those authorized to give the public permission to use material in ways otherwise restricted by copyright and certain other rights. Our licenses are irrevocable. Licensors should read and understand the terms and conditions of the license they choose before applying it. Licensors should also secure all rights necessary before applying our licenses so that the public can reuse the material as expected. Licensors should clearly mark any material not subject to the license. This includes other CC-licensed material, or material used under an exception or limitation to copyright. More considerations for licensors. 10 | 11 | Considerations for the public: By using one of our public licenses, a licensor grants the public permission to use the licensed material under specified terms and conditions. If the licensor’s permission is not necessary for any reason–for example, because of any applicable exception or limitation to copyright–then that use is not regulated by the license. Our licenses grant only permissions under copyright and certain other rights that a licensor has authority to grant. Use of the licensed material may still be restricted for other reasons, including because others have copyright or other rights in the material. A licensor may make special requests, such as asking that all changes be marked or described. Although not required by our licenses, you are encouraged to respect those requests where reasonable. More considerations for the public. 12 | 13 | Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International Public License 14 | 15 | By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions. 16 | 17 | Section 1 – Definitions. 18 | 19 | a. Adapted Material means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image. 20 | 21 | b. Copyright and Similar Rights means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labeled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights. 22 | 23 | c. Effective Technological Measures means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements. 24 | 25 | d. Exceptions and Limitations means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material. 26 | 27 | e. Licensed Material means the artistic or literary work, database, or other material to which the Licensor applied this Public License. 28 | 29 | f. Licensed Rights means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license. 30 | 31 | g. Licensor means the individual(s) or entity(ies) granting rights under this Public License. 32 | 33 | h. NonCommercial means not primarily intended for or directed towards commercial advantage or monetary compensation. For purposes of this Public License, the exchange of the Licensed Material for other material subject to Copyright and Similar Rights by digital file-sharing or similar means is NonCommercial provided there is no payment of monetary compensation in connection with the exchange. 34 | 35 | i. Share means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them. 36 | 37 | j. Sui Generis Database Rights means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world. 38 | 39 | k. You means the individual or entity exercising the Licensed Rights under this Public License. Your has a corresponding meaning. 40 | 41 | Section 2 – Scope. 42 | 43 | a. License grant. 44 | 45 | 1. Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to: 46 | 47 | A. reproduce and Share the Licensed Material, in whole or in part, for NonCommercial purposes only; and 48 | 49 | B. produce and reproduce, but not Share, Adapted Material for NonCommercial purposes only. 50 | 51 | 2. Exceptions and Limitations. For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions. 52 | 53 | 3. Term. The term of this Public License is specified in Section 6(a). 54 | 55 | 4. Media and formats; technical modifications allowed. The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a)(4) never produces Adapted Material. 56 | 57 | 5. Downstream recipients. 58 | A. Offer from the Licensor – Licensed Material. Every recipient of the Licensed Material automatically receives an offer from the Licensor to exercise the Licensed Rights under the terms and conditions of this Public License. 59 | 60 | B. No downstream restrictions. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material. 61 | 62 | 6. No endorsement. Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i). 63 | 64 | b. Other rights. 65 | 66 | 1. Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise. 67 | 68 | 2. Patent and trademark rights are not licensed under this Public License. 69 | 70 | 3. To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties, including when the Licensed Material is used other than for NonCommercial purposes. 71 | 72 | Section 3 – License Conditions. 73 | 74 | Your exercise of the Licensed Rights is expressly made subject to the following conditions. 75 | 76 | a. Attribution. 77 | 78 | 1. If You Share the Licensed Material, You must: 79 | 80 | A. retain the following if it is supplied by the Licensor with the Licensed Material: 81 | 82 | i. identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated); 83 | 84 | ii. a copyright notice; 85 | 86 | iii. a notice that refers to this Public License; 87 | 88 | iv. a notice that refers to the disclaimer of warranties; 89 | 90 | v. a URI or hyperlink to the Licensed Material to the extent reasonably practicable; 91 | 92 | B. indicate if You modified the Licensed Material and retain an indication of any previous modifications; and 93 | 94 | C. indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License. 95 | 96 | For the avoidance of doubt, You do not have permission under this Public License to Share Adapted Material. 97 | 98 | 2. You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information. 99 | 100 | 3. If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable. 101 | 102 | Section 4 – Sui Generis Database Rights. 103 | 104 | Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material: 105 | 106 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database for NonCommercial purposes only and provided You do not Share Adapted Material; 107 | 108 | b. if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material; and 109 | 110 | c. You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database. 111 | For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights. 112 | 113 | Section 5 – Disclaimer of Warranties and Limitation of Liability. 114 | 115 | a. Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You. 116 | 117 | b. To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You. 118 | 119 | c. The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability. 120 | 121 | Section 6 – Term and Termination. 122 | 123 | a. This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically. 124 | 125 | b. Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates: 126 | 127 | 1. automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or 128 | 129 | 2. upon express reinstatement by the Licensor. 130 | 131 | For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License. 132 | 133 | c. For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License. 134 | 135 | d. Sections 1, 5, 6, 7, and 8 survive termination of this Public License. 136 | 137 | Section 7 – Other Terms and Conditions. 138 | 139 | a. The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed. 140 | 141 | b. Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License. 142 | 143 | Section 8 – Interpretation. 144 | 145 | a. For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License. 146 | 147 | b. To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it shall be severed from this Public License without affecting the enforceability of the remaining terms and conditions. 148 | 149 | c. No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor. 150 | 151 | d. Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority. 152 | 153 | Creative Commons is not a party to its public licenses. Notwithstanding, Creative Commons may elect to apply one of its public licenses to material it publishes and in those instances will be considered the “Licensor.” Except for the limited purpose of indicating that material is shared under a Creative Commons public license or as otherwise permitted by the Creative Commons policies published at creativecommons.org/policies, Creative Commons does not authorize the use of the trademark “Creative Commons” or any other trademark or logo of Creative Commons without its prior written consent including, without limitation, in connection with any unauthorized modifications to any of its public licenses or any other arrangements, understandings, or agreements concerning use of licensed material. For the avoidance of doubt, this paragraph does not form part of the public licenses. 154 | 155 | Creative Commons may be contacted at creativecommons.org. 156 | -------------------------------------------------------------------------------- /LICENSES/CC-BY-SA-4.0.txt: -------------------------------------------------------------------------------- 1 | Creative Commons Attribution-ShareAlike 4.0 International Creative Commons 2 | Corporation ("Creative Commons") is not a law firm and does not provide legal 3 | services or legal advice. Distribution of Creative Commons public licenses 4 | does not create a lawyer-client or other relationship. Creative Commons makes 5 | its licenses and related information available on an "as-is" basis. Creative 6 | Commons gives no warranties regarding its licenses, any material licensed 7 | under their terms and conditions, or any related information. Creative Commons 8 | disclaims all liability for damages resulting from their use to the fullest 9 | extent possible. 10 | 11 | Using Creative Commons Public Licenses 12 | 13 | Creative Commons public licenses provide a standard set of terms and conditions 14 | that creators and other rights holders may use to share original works of 15 | authorship and other material subject to copyright and certain other rights 16 | specified in the public license below. The following considerations are for 17 | informational purposes only, are not exhaustive, and do not form part of our 18 | licenses. 19 | 20 | Considerations for licensors: Our public licenses are intended for use by 21 | those authorized to give the public permission to use material in ways otherwise 22 | restricted by copyright and certain other rights. Our licenses are irrevocable. 23 | Licensors should read and understand the terms and conditions of the license 24 | they choose before applying it. Licensors should also secure all rights necessary 25 | before applying our licenses so that the public can reuse the material as 26 | expected. Licensors should clearly mark any material not subject to the license. 27 | This includes other CC-licensed material, or material used under an exception 28 | or limitation to copyright. More considerations for licensors : wiki.creativecommons.org/Considerations_for_licensors 29 | 30 | Considerations for the public: By using one of our public licenses, a licensor 31 | grants the public permission to use the licensed material under specified 32 | terms and conditions. If the licensor's permission is not necessary for any 33 | reason–for example, because of any applicable exception or limitation to copyright–then 34 | that use is not regulated by the license. Our licenses grant only permissions 35 | under copyright and certain other rights that a licensor has authority to 36 | grant. Use of the licensed material may still be restricted for other reasons, 37 | including because others have copyright or other rights in the material. A 38 | licensor may make special requests, such as asking that all changes be marked 39 | or described. 40 | 41 | Although not required by our licenses, you are encouraged to respect those 42 | requests where reasonable. More considerations for the public : wiki.creativecommons.org/Considerations_for_licensees 43 | 44 | Creative Commons Attribution-ShareAlike 4.0 International Public License 45 | 46 | By exercising the Licensed Rights (defined below), You accept and agree to 47 | be bound by the terms and conditions of this Creative Commons Attribution-ShareAlike 48 | 4.0 International Public License ("Public License"). To the extent this Public 49 | License may be interpreted as a contract, You are granted the Licensed Rights 50 | in consideration of Your acceptance of these terms and conditions, and the 51 | Licensor grants You such rights in consideration of benefits the Licensor 52 | receives from making the Licensed Material available under these terms and 53 | conditions. 54 | 55 | Section 1 – Definitions. 56 | 57 | a. Adapted Material means material subject to Copyright and Similar Rights 58 | that is derived from or based upon the Licensed Material and in which the 59 | Licensed Material is translated, altered, arranged, transformed, or otherwise 60 | modified in a manner requiring permission under the Copyright and Similar 61 | Rights held by the Licensor. For purposes of this Public License, where the 62 | Licensed Material is a musical work, performance, or sound recording, Adapted 63 | Material is always produced where the Licensed Material is synched in timed 64 | relation with a moving image. 65 | 66 | b. Adapter's License means the license You apply to Your Copyright and Similar 67 | Rights in Your contributions to Adapted Material in accordance with the terms 68 | and conditions of this Public License. 69 | 70 | c. BY-SA Compatible License means a license listed at creativecommons.org/compatiblelicenses, 71 | approved by Creative Commons as essentially the equivalent of this Public 72 | License. 73 | 74 | d. Copyright and Similar Rights means copyright and/or similar rights closely 75 | related to copyright including, without limitation, performance, broadcast, 76 | sound recording, and Sui Generis Database Rights, without regard to how the 77 | rights are labeled or categorized. For purposes of this Public License, the 78 | rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights. 79 | 80 | e. Effective Technological Measures means those measures that, in the absence 81 | of proper authority, may not be circumvented under laws fulfilling obligations 82 | under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, 83 | and/or similar international agreements. 84 | 85 | f. Exceptions and Limitations means fair use, fair dealing, and/or any other 86 | exception or limitation to Copyright and Similar Rights that applies to Your 87 | use of the Licensed Material. 88 | 89 | g. License Elements means the license attributes listed in the name of a Creative 90 | Commons Public License. The License Elements of this Public License are Attribution 91 | and ShareAlike. 92 | 93 | h. Licensed Material means the artistic or literary work, database, or other 94 | material to which the Licensor applied this Public License. 95 | 96 | i. Licensed Rights means the rights granted to You subject to the terms and 97 | conditions of this Public License, which are limited to all Copyright and 98 | Similar Rights that apply to Your use of the Licensed Material and that the 99 | Licensor has authority to license. 100 | 101 | j. Licensor means the individual(s) or entity(ies) granting rights under this 102 | Public License. 103 | 104 | k. Share means to provide material to the public by any means or process that 105 | requires permission under the Licensed Rights, such as reproduction, public 106 | display, public performance, distribution, dissemination, communication, or 107 | importation, and to make material available to the public including in ways 108 | that members of the public may access the material from a place and at a time 109 | individually chosen by them. 110 | 111 | l. Sui Generis Database Rights means rights other than copyright resulting 112 | from Directive 96/9/EC of the European Parliament and of the Council of 11 113 | March 1996 on the legal protection of databases, as amended and/or succeeded, 114 | as well as other essentially equivalent rights anywhere in the world. 115 | 116 | m. You means the individual or entity exercising the Licensed Rights under 117 | this Public License. Your has a corresponding meaning. 118 | 119 | Section 2 – Scope. 120 | 121 | a. License grant. 122 | 123 | 1. Subject to the terms and conditions of this Public License, the Licensor 124 | hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, 125 | irrevocable license to exercise the Licensed Rights in the Licensed Material 126 | to: 127 | 128 | A. reproduce and Share the Licensed Material, in whole or in part; and 129 | 130 | B. produce, reproduce, and Share Adapted Material. 131 | 132 | 2. Exceptions and Limitations. For the avoidance of doubt, where Exceptions 133 | and Limitations apply to Your use, this Public License does not apply, and 134 | You do not need to comply with its terms and conditions. 135 | 136 | 3. Term. The term of this Public License is specified in Section 6(a). 137 | 138 | 4. Media and formats; technical modifications allowed. The Licensor authorizes 139 | You to exercise the Licensed Rights in all media and formats whether now known 140 | or hereafter created, and to make technical modifications necessary to do 141 | so. The Licensor waives and/or agrees not to assert any right or authority 142 | to forbid You from making technical modifications necessary to exercise the 143 | Licensed Rights, including technical modifications necessary to circumvent 144 | Effective Technological Measures. For purposes of this Public License, simply 145 | making modifications authorized by this Section 2(a)(4) never produces Adapted 146 | Material. 147 | 148 | 5. Downstream recipients. 149 | 150 | A. Offer from the Licensor – Licensed Material. Every recipient of the Licensed 151 | Material automatically receives an offer from the Licensor to exercise the 152 | Licensed Rights under the terms and conditions of this Public License. 153 | 154 | B. Additional offer from the Licensor – Adapted Material. Every recipient 155 | of Adapted Material from You automatically receives an offer from the Licensor 156 | to exercise the Licensed Rights in the Adapted Material under the conditions 157 | of the Adapter's License You apply. 158 | 159 | C. No downstream restrictions. You may not offer or impose any additional 160 | or different terms or conditions on, or apply any Effective Technological 161 | Measures to, the Licensed Material if doing so restricts exercise of the Licensed 162 | Rights by any recipient of the Licensed Material. 163 | 164 | 6. No endorsement. Nothing in this Public License constitutes or may be construed 165 | as permission to assert or imply that You are, or that Your use of the Licensed 166 | Material is, connected with, or sponsored, endorsed, or granted official status 167 | by, the Licensor or others designated to receive attribution as provided in 168 | Section 3(a)(1)(A)(i). 169 | 170 | b. Other rights. 171 | 172 | 1. Moral rights, such as the right of integrity, are not licensed under this 173 | Public License, nor are publicity, privacy, and/or other similar personality 174 | rights; however, to the extent possible, the Licensor waives and/or agrees 175 | not to assert any such rights held by the Licensor to the limited extent necessary 176 | to allow You to exercise the Licensed Rights, but not otherwise. 177 | 178 | 2. Patent and trademark rights are not licensed under this Public License. 179 | 180 | 3. To the extent possible, the Licensor waives any right to collect royalties 181 | from You for the exercise of the Licensed Rights, whether directly or through 182 | a collecting society under any voluntary or waivable statutory or compulsory 183 | licensing scheme. In all other cases the Licensor expressly reserves any right 184 | to collect such royalties. 185 | 186 | Section 3 – License Conditions. 187 | 188 | Your exercise of the Licensed Rights is expressly made subject to the following 189 | conditions. 190 | 191 | a. Attribution. 192 | 193 | 1. If You Share the Licensed Material (including in modified form), You must: 194 | 195 | A. retain the following if it is supplied by the Licensor with the Licensed 196 | Material: 197 | 198 | i. identification of the creator(s) of the Licensed Material and any others 199 | designated to receive attribution, in any reasonable manner requested by the 200 | Licensor (including by pseudonym if designated); 201 | 202 | ii. a copyright notice; 203 | 204 | iii. a notice that refers to this Public License; 205 | 206 | iv. a notice that refers to the disclaimer of warranties; 207 | 208 | v. a URI or hyperlink to the Licensed Material to the extent reasonably practicable; 209 | 210 | B. indicate if You modified the Licensed Material and retain an indication 211 | of any previous modifications; and 212 | 213 | C. indicate the Licensed Material is licensed under this Public License, and 214 | include the text of, or the URI or hyperlink to, this Public License. 215 | 216 | 2. You may satisfy the conditions in Section 3(a)(1) in any reasonable manner 217 | based on the medium, means, and context in which You Share the Licensed Material. 218 | For example, it may be reasonable to satisfy the conditions by providing a 219 | URI or hyperlink to a resource that includes the required information. 220 | 221 | 3. If requested by the Licensor, You must remove any of the information required 222 | by Section 3(a)(1)(A) to the extent reasonably practicable. 223 | 224 | b. ShareAlike.In addition to the conditions in Section 3(a), if You Share 225 | Adapted Material You produce, the following conditions also apply. 226 | 227 | 1. The Adapter's License You apply must be a Creative Commons license with 228 | the same License Elements, this version or later, or a BY-SA Compatible License. 229 | 230 | 2. You must include the text of, or the URI or hyperlink to, the Adapter's 231 | License You apply. You may satisfy this condition in any reasonable manner 232 | based on the medium, means, and context in which You Share Adapted Material. 233 | 234 | 3. You may not offer or impose any additional or different terms or conditions 235 | on, or apply any Effective Technological Measures to, Adapted Material that 236 | restrict exercise of the rights granted under the Adapter's License You apply. 237 | 238 | Section 4 – Sui Generis Database Rights. 239 | 240 | Where the Licensed Rights include Sui Generis Database Rights that apply to 241 | Your use of the Licensed Material: 242 | 243 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, 244 | reuse, reproduce, and Share all or a substantial portion of the contents of 245 | the database; 246 | 247 | b. if You include all or a substantial portion of the database contents in 248 | a database in which You have Sui Generis Database Rights, then the database 249 | in which You have Sui Generis Database Rights (but not its individual contents) 250 | is Adapted Material, including for purposes of Section 3(b); and 251 | 252 | c. You must comply with the conditions in Section 3(a) if You Share all or 253 | a substantial portion of the contents of the database. 254 | 255 | For the avoidance of doubt, this Section 4 supplements and does not replace 256 | Your obligations under this Public License where the Licensed Rights include 257 | other Copyright and Similar Rights. 258 | 259 | Section 5 – Disclaimer of Warranties and Limitation of Liability. 260 | 261 | a. Unless otherwise separately undertaken by the Licensor, to the extent possible, 262 | the Licensor offers the Licensed Material as-is and as-available, and makes 263 | no representations or warranties of any kind concerning the Licensed Material, 264 | whether express, implied, statutory, or other. This includes, without limitation, 265 | warranties of title, merchantability, fitness for a particular purpose, non-infringement, 266 | absence of latent or other defects, accuracy, or the presence or absence of 267 | errors, whether or not known or discoverable. Where disclaimers of warranties 268 | are not allowed in full or in part, this disclaimer may not apply to You. 269 | 270 | b. To the extent possible, in no event will the Licensor be liable to You 271 | on any legal theory (including, without limitation, negligence) or otherwise 272 | for any direct, special, indirect, incidental, consequential, punitive, exemplary, 273 | or other losses, costs, expenses, or damages arising out of this Public License 274 | or use of the Licensed Material, even if the Licensor has been advised of 275 | the possibility of such losses, costs, expenses, or damages. Where a limitation 276 | of liability is not allowed in full or in part, this limitation may not apply 277 | to You. 278 | 279 | c. The disclaimer of warranties and limitation of liability provided above 280 | shall be interpreted in a manner that, to the extent possible, most closely 281 | approximates an absolute disclaimer and waiver of all liability. 282 | 283 | Section 6 – Term and Termination. 284 | 285 | a. This Public License applies for the term of the Copyright and Similar Rights 286 | licensed here. However, if You fail to comply with this Public License, then 287 | Your rights under this Public License terminate automatically. 288 | 289 | b. Where Your right to use the Licensed Material has terminated under Section 290 | 6(a), it reinstates: 291 | 292 | 1. automatically as of the date the violation is cured, provided it is cured 293 | within 30 days of Your discovery of the violation; or 294 | 295 | 2. upon express reinstatement by the Licensor. 296 | 297 | c. For the avoidance of doubt, this Section 6(b) does not affect any right 298 | the Licensor may have to seek remedies for Your violations of this Public 299 | License. 300 | 301 | d. For the avoidance of doubt, the Licensor may also offer the Licensed Material 302 | under separate terms or conditions or stop distributing the Licensed Material 303 | at any time; however, doing so will not terminate this Public License. 304 | 305 | e. Sections 1, 5, 6, 7, and 8 survive termination of this Public License. 306 | 307 | Section 7 – Other Terms and Conditions. 308 | 309 | a. The Licensor shall not be bound by any additional or different terms or 310 | conditions communicated by You unless expressly agreed. 311 | 312 | b. Any arrangements, understandings, or agreements regarding the Licensed 313 | Material not stated herein are separate from and independent of the terms 314 | and conditions of this Public License. 315 | 316 | Section 8 – Interpretation. 317 | 318 | a. For the avoidance of doubt, this Public License does not, and shall not 319 | be interpreted to, reduce, limit, restrict, or impose conditions on any use 320 | of the Licensed Material that could lawfully be made without permission under 321 | this Public License. 322 | 323 | b. To the extent possible, if any provision of this Public License is deemed 324 | unenforceable, it shall be automatically reformed to the minimum extent necessary 325 | to make it enforceable. If the provision cannot be reformed, it shall be severed 326 | from this Public License without affecting the enforceability of the remaining 327 | terms and conditions. 328 | 329 | c. No term or condition of this Public License will be waived and no failure 330 | to comply consented to unless expressly agreed to by the Licensor. 331 | 332 | d. Nothing in this Public License constitutes or may be interpreted as a limitation 333 | upon, or waiver of, any privileges and immunities that apply to the Licensor 334 | or You, including from the legal processes of any jurisdiction or authority. 335 | 336 | Creative Commons is not a party to its public licenses. Notwithstanding, Creative 337 | Commons may elect to apply one of its public licenses to material it publishes 338 | and in those instances will be considered the "Licensor." The text of the 339 | Creative Commons public licenses is dedicated to the public domain under the 340 | CC0 Public Domain Dedication. Except for the limited purpose of indicating 341 | that material is shared under a Creative Commons public license or as otherwise 342 | permitted by the Creative Commons policies published at creativecommons.org/policies, 343 | Creative Commons does not authorize the use of the trademark "Creative Commons" 344 | or any other trademark or logo of Creative Commons without its prior written 345 | consent including, without limitation, in connection with any unauthorized 346 | modifications to any of its public licenses or any other arrangements, understandings, 347 | or agreements concerning use of licensed material. For the avoidance of doubt, 348 | this paragraph does not form part of the public licenses. 349 | 350 | Creative Commons may be contacted at creativecommons.org. 351 | -------------------------------------------------------------------------------- /LICENSES/MIT.txt: -------------------------------------------------------------------------------- 1 | MIT License Copyright (c) 2 | 3 | Permission is hereby granted, free of charge, to any person obtaining a copy 4 | of this software and associated documentation files (the "Software"), to deal 5 | in the Software without restriction, including without limitation the rights 6 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 7 | copies of the Software, and to permit persons to whom the Software is furnished 8 | to do so, subject to the following conditions: 9 | 10 | The above copyright notice and this permission notice (including the next 11 | paragraph) shall be included in all copies or substantial portions of the 12 | Software. 13 | 14 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 15 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS 16 | FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS 17 | OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, 18 | WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF 19 | OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. 20 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | 6 | 7 | # Glucometer Protocols 8 | 9 | This repository contains description of protocols for various glucometers. 10 | 11 | The actual information is in the src/ directory. 12 | 13 | ## Build Instructions 14 | 15 | With Docker Compose: 16 | 17 | ```bash 18 | # Site: 19 | $ docker-compose run --rm foliant make site 20 | # PDF: 21 | $ docker-compose run --rm foliant make pdf 22 | ``` 23 | 24 | With pip and stuff (requires Python 3.6+, Pandoc, and TeXLive): 25 | 26 | ```bash 27 | $ pip install -r requirements.txt 28 | # Site: 29 | $ foliant make site 30 | # PDF: 31 | $ foliant make pdf 32 | ``` 33 | 34 | ## License 35 | 36 | This work is licensed under a [Creative Commons Attribution 4.0 International 37 | License](https://creativecommons.org/licenses/by/4.0/). 38 | 39 | Use the information you'll find in this page for whatever purpose you see fit, 40 | but there is no warranty about the accuracy of this information. 41 | 42 | Most of the information has been reverse engineerd by individual contributors, 43 | see the individual page for details. 44 | -------------------------------------------------------------------------------- /constraints.txt: -------------------------------------------------------------------------------- 1 | # SPDX-FileCopyrightText: 2016 The Glucometer Protocols Authors 2 | # 3 | # SPDX-License-Identifier: MIT 4 | 5 | # See https://github.com/foliant-docs/foliant/issues/71 6 | cython < 3 7 | 8 | # See https://github.com/blockdiag/blockdiag/issues/176 9 | Pillow < 10 10 | -------------------------------------------------------------------------------- /contributing/reverse-engineered.md: -------------------------------------------------------------------------------- 1 | 6 | 7 | # Contributing Reverse Engineered Protocols 8 | 9 | Please create a top-level directory for each of the manufacturers, and place the 10 | protocol specifications within those directories. If the same device is marketed 11 | under different brand names, use the manufacturer's name and then list the known 12 | aliases in the document. 13 | 14 | Use Markdown format to describe the protocol, and try to use 15 | [ABNF](https://en.wikipedia.org/wiki/Augmented_Backus%E2%80%93Naur_Form) for the 16 | description of the protocol, particularly for binary-based protocols. 17 | -------------------------------------------------------------------------------- /foliant.yml: -------------------------------------------------------------------------------- 1 | # SPDX-FileCopyrightText: 2016 The Glucometer Protocols Authors 2 | # 3 | # SPDX-License-Identifier: MIT 4 | 5 | title: Glucometer Protocols 6 | 7 | chapters: 8 | - index.md 9 | 10 | backend_config: 11 | mkdocs: 12 | slug: glucometer-protocols 13 | use_headings: true 14 | mkdocs.yml: 15 | use_directory_urls: false 16 | plugins: [] 17 | repo_url: https://github.com/glucometers-tech/glucometer-protocols 18 | edit_uri: 'edit/master/src/' 19 | theme: 20 | name: mkdocs 21 | custom_dir: !path ./mkdocs_theme/ 22 | 23 | preprocessors: 24 | - blockdiag: 25 | params: 26 | format: svg 27 | -------------------------------------------------------------------------------- /mkdocs_theme/img/apple-touch-icon.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/glucometers-tech/glucometer-protocols/777b03281276cee26f32e576d8c056de5f579d6a/mkdocs_theme/img/apple-touch-icon.png -------------------------------------------------------------------------------- /mkdocs_theme/img/apple-touch-icon.png.license: -------------------------------------------------------------------------------- 1 | SPDX-FileCopyrightText: 2021 Diego Elio Pettenò 2 | 3 | SPDX-License-Identifier: CC-BY-NC-ND-4.0 4 | -------------------------------------------------------------------------------- /mkdocs_theme/img/favicon.ico: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/glucometers-tech/glucometer-protocols/777b03281276cee26f32e576d8c056de5f579d6a/mkdocs_theme/img/favicon.ico -------------------------------------------------------------------------------- /mkdocs_theme/img/favicon.ico.license: -------------------------------------------------------------------------------- 1 | SPDX-FileCopyrightText: 2021 Diego Elio Pettenò 2 | 3 | SPDX-License-Identifier: CC-BY-NC-ND-4.0 4 | -------------------------------------------------------------------------------- /mkdocs_theme/img/favicon.svg.license: -------------------------------------------------------------------------------- 1 | SPDX-FileCopyrightText: 2021 Diego Elio Pettenò 2 | 3 | SPDX-License-Identifier: CC-BY-NC-ND-4.0 4 | -------------------------------------------------------------------------------- /mkdocs_theme/main.html: -------------------------------------------------------------------------------- 1 | 6 | {%- extends "base.html" %} 7 | {%- block site_meta %} 8 | {{ super() }} 9 | 10 | 11 | {%- endblock %} 12 | -------------------------------------------------------------------------------- /requirements.txt: -------------------------------------------------------------------------------- 1 | # SPDX-FileCopyrightText: 2016 The Glucometer Protocols Authors 2 | # 3 | # SPDX-License-Identifier: MIT 4 | 5 | -c constraints.txt 6 | 7 | # List the required Foliant backends and extensions, as well as other Python packages, e.g. MkDocs theme: 8 | foliantcontrib.mkdocs 9 | git+https://github.com/Flameeyes/foliantcontrib.blockdiag 10 | pre-commit 11 | -------------------------------------------------------------------------------- /src/abbott/freestyle-insulinx.md: -------------------------------------------------------------------------------- 1 | 6 | 7 | # FreeStyle InsuLinx 8 | 9 | Reverse engineered by [Xavier Claessens](mailto:xclaesse@gmail.com). 10 | 11 | ## Protocol 12 | 13 | This device uses the [shared HID protocol](shared-hid-protocol.md) used by other 14 | meters in the FreeStyle family. All messages that have been identified are 15 | considered text commands and use message type `0x60`. 16 | 17 | ## Commands 18 | 19 | All commands supported by the shared protocol are supported by the device. Those 20 | that deviate from said protocol are here documented. 21 | 22 | ### `$result?` 23 | 24 | The `$result?` command is used to dump the readings records from the device, and 25 | it follows the *Multiple records command* output format as described in the 26 | shared protocol documentation. 27 | 28 | The first field in the record specify the type of record; type 0 is a blood 29 | glucose reading. 30 | 31 | #### Blood glucose record fields 32 | 33 | 1. `type = "0"` 34 | 2. `id` 35 | 3. `month = 1*2DIGIT` 36 | 4. `day = 1*2DIGIT` 37 | 5. `year = 1*2DIGIT` 38 | 6. `hour = 1*2DIGIT` 39 | 7. `minute = 1*2DIGIT` 40 | 8. `unknown` 41 | 9. `unknown` 42 | 10. `unknown` 43 | 11. `unknown` 44 | 12. `unknown` 45 | 13. `unknown` 46 | 14. `value = 1*DIGIT` 47 | 48 | Unknown (but likely) whether this includes HI / LO constants. 49 | 50 | 15. `unknown` 51 | 16. `unknown` 52 | 53 | ### Other commands 54 | 55 | The following commands appear to also be supported, but their meanings are not 56 | known: 57 | 58 | * `$getrmndrst,0` 59 | * `$getrmndr,0` 60 | * `$rmdstrorder?` 61 | * `$actthm?` 62 | * `$wktrend?` 63 | * `$gunits?` 64 | * `$clktyp?` 65 | * `$alllang?` 66 | * `$lang?` 67 | * `$inslock?` 68 | * `$actinscal?` 69 | * `$iobstatus?` 70 | * `$foodunits?` 71 | * `$svgsdef?` 72 | * `$corsetup?` 73 | * `$insdose?` 74 | * `$inslog?` 75 | * `$inscalsetup?` 76 | * `$carbratio?` 77 | * `$svgsratio?` 78 | * `$mlcalget,3` 79 | * `$cttype?` 80 | * `$bgdrop?` 81 | * `$bgtrgt?` 82 | * `$bgtgrng?` 83 | * `$ntsound?` 84 | * `$btsound?` 85 | * `$custthm?` 86 | * `$taglang?` 87 | * `$tagsenbl?` 88 | * `$tagorder?` 89 | * `$result?` 90 | * `$gettags,2,2` 91 | * `$frststrt?` 92 | -------------------------------------------------------------------------------- /src/abbott/freestyle-libre-2.md: -------------------------------------------------------------------------------- 1 | 6 | 7 | # FreeStyle Libre 2 8 | 9 | Reverse engineering in progress. 10 | 11 | 12 | ## Important device notes 13 | 14 | ### USB IDs 15 | 16 | | Device | Vendor ID | Product ID | 17 | | --- | --- | --- | 18 | | FreeStyle Libre 2 | 1a61 | 3950 | 19 | 20 | ## Protocol 21 | 22 | This device uses the [shared HID protocol](shared-hid-protocol.md) used by other 23 | meters in the FreeStyle family, but introduces encryption. 24 | 25 | Text commands are sent by the original software as message type `0x21`, with 26 | responses as `0x60`. 27 | 28 | ## Encryption 29 | 30 | Following the handshake (Authorization), most of the messages sent to and by the 31 | Libre 2 devices are encrypted and protected with a 32-bit Message Authorization 32 | Code (MAC), and a 32-bit sequence number, independent between software and 33 | device. 34 | 35 | The encryption covers the 55 bytes following the message type, while the MAC is 36 | calculated on the first 60 bytes of the message. A 64-bit MAC is calculated, but 37 | only 4 bytes of it are used. 38 | 39 | Known messages that are not encrypt are pre-initialization commands, keep-alive 40 | commands (`0x22`) and error responses. 41 | 42 | ### Authorization Sequence 43 | 44 | 45 | { 46 | edge_length = 300; 47 | span_height = 20; 48 | default_fontsize = 12; 49 | 50 | software => reader [label = "0x05 QUERY SERIAL", return = "0x06 SERIAL NUMBER"] 51 | 52 | software -> reader [label = "0x14, 0x11 START AUTHORIZE"] 53 | software <-- reader [label = "0x33, 0x16 CHALLENGE"] 54 | 55 | software -> reader [label = "0x14, 0x17 CHALLENGE RESPONSE"] 56 | software <-- reader [label = "0x14, 0x18 CHALLENGE ACCEPTED"] 57 | 58 | software -> reader [label = "0x01 INIT"] 59 | software <-- reader [label = "0x071 INIT COMPLETE"] 60 | } 61 | 62 | 63 | ### START AUTHORIZE, CHALLENGE 64 | 65 | The START AUTHORIZE message contains nothing but the sub-command itself. 66 | 67 | The CHALLENGE response message contains the 8 bytes of the challenge, as well as 68 | 7 bytes of the initialization vector for encryption (zero-padded). 69 | 70 | request-challenge-cmd = %x14 %x01 %x11 71 | challenge-response = %x33 %x10 %x16 challenge-content challenge-iv 72 | challenge-content = 8OCTET 73 | challenge-iv = 7OCTET 74 | 75 | ### CHALLENGE RESPONSE 76 | 77 | The CHALLENGE RESPONSE message contains the response to the challenge expected 78 | by the device to authorize the requests from the software. The format of the 79 | message is as follows: 80 | 81 | challenge-response-cmd = %x14 %x1A %x17 82 | challenge-response-encrypted %x01 83 | challenge-response-mac 84 | challenge-response-encrypted = 16 OCTET 85 | challenge-response-mac = 8 OCTET 86 | 87 | The procedure to calculate the challenge is not currently reversed, but some 88 | useful notes: 89 | 90 | * The authorization keys are generated based on the serial number of the device 91 | and the strings `AuthrEnc` (for encryption) and `AuthrMac` (for MAC). 92 | * The `challenge-response-encrypted` buffer is generated by encrypting 93 | `challenge-content` together with 8 bytes of random. The encryption is 94 | initialized with the initialization vector `challenge-iv`. 95 | * The `challenge-response-mac` is calculated on the first 20-bytes of the 96 | message, _including the message type, length, and the constant `0x01`_. 97 | 98 | ### CHALLENGE ACCEPTED 99 | 100 | challenge-accepted-response = %x14 %x22 %x18 101 | encrypted-challenge-response 102 | (13 OCTET) 103 | challenge-response-mac 104 | encrypted-challenge-response = 16 OCTET 105 | -------------------------------------------------------------------------------- /src/abbott/freestyle-libre.md: -------------------------------------------------------------------------------- 1 | 6 | 7 | # FreeStyle Libre 8 | 9 | Reverse engineered by Pascal Fribi, editing and expansion by Diego Elio Pettenò. 10 | 11 | ## Important device notes 12 | 13 | ### USB IDs 14 | 15 | | Device | Vendor ID | Product ID | 16 | | --- | --- | --- | 17 | | FreeStyle Libre | 1a61 | 3650 | 18 | 19 | ## Protocol 20 | 21 | This device uses the [shared HID protocol](shared-hid-protocol.md) used by other 22 | meters in the FreeStyle family. Text commands are sent by the original software 23 | as message type `0x21`, with responses as `0x60`, but the device appears to 24 | accept the commands as type `0x60` as well (compatible with other FreeStyle 25 | devices). 26 | 27 | ### Strings Handling 28 | 29 | The official software has known UTF-8 handling bugs, but the device itself 30 | appears to display strings correctly if encoded in UTF-8. 31 | 32 | ## Commands 33 | 34 | The Libre supports a distinct set of commands from those described in the shared 35 | protocol. In particular, the following commands are not supported: 36 | 37 | * `$serlnum?` — replaced by `$sn?`. 38 | 39 | A number of new text commands are added instead. 40 | 41 | ### `$dbrnum?` 42 | 43 | dbrnum-response = "DBRECORDS = " 1*DIGIT CRLF 44 | 45 | The response includes the number of records in the database (history results.) 46 | 47 | This number is permanent across factory resets. 48 | 49 | ### `$history?` 50 | 51 | The `$history?` command returns all the automatic measurements taken by the 52 | sensors. It does not include the immediate measurements on user request, nor 53 | strip measurements (blood glucose and β-ketone). 54 | 55 | The output follows the *Multiple record command* output format as described in 56 | the shared protocol documentation. 57 | 58 | #### Record fields 59 | 60 | 1. `record-id = 1*5DIGIT` 61 | 2. `unknown = "12"` 62 | 3. `month = 1*2DIGIT` 63 | 4. `day = 1*2DIGIT` 64 | 5. `year = 1*2DIGIT` 65 | 6. `hour = 1*2DIGIT` 66 | 7. `minute = 1*2DIGIT` 67 | 8. `second = 1*2DIGIT` 68 | 9. `unknown = "1"` 69 | 10. `unknown = "0"` 70 | 11. `unknown = "0"` 71 | 12. `unknown = "0"` 72 | 13. `unknown = "0" / "1"` 73 | 74 | This value appears to only be 1 for the first reading of the sensor (with 75 | sensor runtime reporting 15 minutes). 76 | 77 | 14. `value = 1*DIGIT` 78 | 15. `sensor-runtime-minutes = 1*DIGIT` 79 | 16. `error-bitfield = 1*5DIGIT` 80 | 81 | This field needs to be interpreted as a bitfield (in decimal 82 | representation). Flag 0x8000 indicates an error (invalid reading). If the 83 | error flag is set, the remaining bits refer to more error details that are 84 | not clear. 85 | 86 | ### `$arresult?` 87 | 88 | The `$arresult?` returns manual measurements taken by the user, either by 89 | scanning the sensor or using a testing strip (for either blood sugar or β-ketone 90 | measurement) 91 | 92 | The output follows the *Multiple record command* output format as described in 93 | the shared protocol documentation. 94 | 95 | Multiple record types have been identified; the second value in the record 96 | identifies the type; type 2 is a manual reading, record type 5 identifies a time 97 | change event. 98 | 99 | #### Reading record fields 100 | 101 | 1. `record-id = 1*5DIGIT` 102 | 2. `record-type = "2"` 103 | 3. `month = 1*2DIGIT` 104 | 4. `day = 1*2DIGIT` 105 | 5. `year = 1*2DIGIT` 106 | 6. `hour = 1*2DIGIT` 107 | 7. `minute = 1*2DIGIT` 108 | 8. `second = 1*2DIGIT` 109 | 9. `unknown = "1"` 110 | 10. Identifies the type of reading in the record 111 | 112 | reading-type = blood-glucose / blood-ketone / sensor-glucose 113 | blood-glucose = "0" 114 | blood-ketone = "1" 115 | sensor-glucose = "2" 116 | 117 | 11. `unknown = "0"` 118 | 12. `unknown = "0" / "1"` 119 | 120 | This appears to be 1 when either an error is present, or when the read 121 | value is LO. 122 | 123 | 13. `value = 1*DIGIT` 124 | 125 | When `reading-type` is either `blood-glucose` or `sensor-glucose`, this 126 | represent the blood sugar reading in mg/dL. 127 | 128 | When `reading-type` is `blood-ketone`, this represent the β-ketone reading 129 | in mmol/l after apply `value`/18. It seems that the value is reported in 130 | mg/dL and the conversion is using the wrong molar mass system for 131 | conversion. But based on actual measurements the results are correct this 132 | way. 133 | 134 | 14. `unknown = "0" / "1"` 135 | 136 | This appears to be 0 for values read from a blood strip, and 1 for values 137 | read from sensor. Appears redundant with the `reading-type` field. 138 | 139 | 15. Corresponds to the arrow indicator in the UI. 140 | 141 | direction-indicator = none / down-fast / down / steady / up / up-fast 142 | none = "0" 143 | down-fast = "1" 144 | down = "2" 145 | steady = "3" 146 | up = "4" 147 | up-fast = "5" 148 | 149 | 16. `sports-flag = "0" / "1"` 150 | 17. `medication-flag = "0" / "1"` 151 | 18. `rapid-acting-insulin-flag = "0" / "1"` 152 | 153 | See field 44 for value†. 154 | 155 | 19. `long-acting-insulin-flag = "0" / "1"` 156 | 157 | See field 24 for value. 158 | 159 | 20. `custom-comments-bitfield = 1*DIGIT` 160 | 161 | Custom comments 1-6 flags. To be interpreted as a bitfield, LSB first. 162 | 163 | 21. `unknown = "0"` 164 | 22. `unknown = "0"` 165 | 23. `unknown = "0" / "1" / "2" / "3" / "4" / "5"` 166 | 24. Value of long Acting insulin in 0.5 IE. If you want proper IE, divide by 2 167 | 25. `unknown = "0" / "1"` 168 | 26. `food-flag = "0" / "1"` 169 | 170 | See field 27 for value. 171 | 172 | 27. `food-carbs-grams = 1*DIGIT` 173 | 28. `unknown = "0"` 174 | 29. `error-bitfield = 1*5DIGIT` 175 | 176 | This field needs to be interpreted as a bitfield (in decimal 177 | representation). Flag 0x8000 indicates an error (invalid reading). If the 178 | error flag is set, the remaining bits refer to more error details that are 179 | not clear. 180 | 181 | In the Event View on the device, these correspond to Err3 errors. 182 | 183 | 30. `custom-comment-1 = DQUOTE *VCHAR DQUOTE` ‡ 184 | 31. `custom-comment-2 = DQUOTE *VCHAR DQUOTE` ‡ 185 | 32. `custom-comment-3 = DQUOTE *VCHAR DQUOTE` ‡ 186 | 33. `custom-comment-4 = DQUOTE *VCHAR DQUOTE` ‡ 187 | 34. `custom-comment-5 = DQUOTE *VCHAR DQUOTE` ‡ 188 | 35. `custom-comment-6 = DQUOTE *VCHAR DQUOTE` ‡ 189 | 36. `unknown = "7"` † 190 | 37. `month = 1*2DIGIT` * † 191 | 38. `day = 1*2DIGIT` * † 192 | 39. `year = 1*2DIGIT` * † 193 | 40. `hour = 1*2DIGIT` * † 194 | 41. `minute = 1*2DIGIT` * † 195 | 42. `second = 1*2DIGIT` * † 196 | 43. `unknown = "1"` * † 197 | 44. Value of rapid acting insulin in 0.5 IE. If you want proper IE, divide by 198 | 2. 199 | 200 | \* These values are identical to values 3-9, regardless of what time the notes were added to the record. Which seems to make them entirely redundant. 201 | 202 | † The number of columns in a record can be different. If a rapid acting insulin 203 | value has been set, then it is > 44, otherwise the record has only entries up to 204 | comment 6. 205 | 206 | ‡ Be aware that custom comments are shown in every record. The bitfield in 207 | field 19. shows which comments are actually set. 208 | 209 | 210 | #### Time change record fields 211 | 212 | 1. `record-id = 1*5DIGIT` 213 | 2. `record-type = "5"` 214 | 3. `new-month = 1*2DIGIT` 215 | 4. `new-day = 1*2DIGIT` 216 | 5. `new-year = 1*2DIGIT` 217 | 6. `new-hour = 1*2DIGIT` 218 | 7. `new-minute = 1*2DIGIT` 219 | 8. `new-second = 1*2DIGIT` 220 | 9. `unknown` 221 | 10. `old-month = 1*2DIGIT` 222 | 11. `old-day = 1*2DIGIT` 223 | 12. `old-year = 1*2DIGIT` 224 | 13. `old-hour = 1*2DIGIT` 225 | 14. `old-minute = 1*2DIGIT` 226 | 15. `old-second = 1*2DIGIT` 227 | 16. `unknown` 228 | 17. `unknown` 229 | 18. `unknown` 230 | 19. `unknown` 231 | 20. `unknown` 232 | 233 | ### `$swreset` 234 | 235 | Restart the Libre device, not erasing any information. 236 | 237 | swreset-cmd = "$swreset" 238 | swreset-response = CRLF 239 | 240 | ### `$resetpatient` 241 | 242 | This command completely resets the FreeStyle Libre reader, bringing it 243 | effectively to factory reset. 244 | 245 | CAUTION! This erases all information on the device, including currently-enabled 246 | sensors. 247 | 248 | While not accessible via the protocol, a reset does not erases the "Event Log" 249 | as available on the device. 250 | 251 | resetpatient-cmd = "$resetpatient" 252 | resetpatient-response = *("Erasing Sector @ 0x" 6 HEXDIGIT CRLF) 253 | 254 | ### Sound Settings 255 | 256 | It's possible to query and set the notification and touch tone settings of 257 | FreeStyle Libre devices through two commands. 258 | 259 | The commands have first been identified on [FreeStyle 260 | Insulinx](freestyle-insulinx) but are not tested on it. 261 | 262 | notifications = notifications-enabled / notifications-disabled 263 | notifications-enabled = "1" 264 | notifications-disabled = "0" 265 | 266 | vibrate = vibrate-enabled / vibrate-disabled 267 | vibrate-enabled = "1" 268 | vibrate-disabled = "0" 269 | 270 | touch-tone = touch-tone-enabled / touch-tone-disabled 271 | touch-tone-enabled = "1" 272 | touch-tone-disabled = "0" 273 | 274 | volume = volume-high / volume-low 275 | volume-high = "1" 276 | volume-low = "0" 277 | 278 | ntsound-cmd = "$ntsound" ("?" / "," notifications "," vibrate) 279 | ntsound-query-response = notifications "," vibrate CRLF 280 | 281 | btsound-cmd = "$btsound" ("?" / "," touch-tone "," volume) 282 | btsound-query-response = touch-tone "," volume 283 | 284 | ### Reminders (`$getrmndr`) 285 | 286 | It's possible to read the reminders status for the reader device. 287 | 288 | The commands have first been identified on [FreeStyle 289 | Insulinx](freestyle-insulinx) but are not tested on it. 290 | 291 | get-reminder-command = "$getrmndr,0" 292 | get-reminder-response = 12 (reminder-entry CRLF) 293 | reminder-entry = reminder-repeat "," 294 | reminder-action "," 295 | ( reminder-enabled / reminder-disabled ) "," 296 | reminder-hour "," reminder-minute 297 | 298 | reminder-repeat = reminder-off / reminder-daily / reminder-timer 299 | reminer-off = "0" 300 | reminder-once = "1" 301 | reminder-daily = "2" 302 | reminder-timer = "3" 303 | 304 | reminder-action = reminder-glucose / reminder-insulin / reminder-alarm 305 | reminder-glucose = "10" 306 | reminder-insulin = "11" 307 | reminder-alarm = "12" 308 | 309 | reminder-enabled = "1" 310 | reminder-disabled = "0" 311 | 312 | reminder-hour = 1*2 DIGIT 313 | reminder-minute = 1*2 DIGIT 314 | 315 | Note that while other `$getrmndr` arguments than 0 will be accepted by the 316 | device, they return no data at all. 317 | 318 | When the repeat is "off" (`0`), all other fields are also `0`. 319 | 320 | When the repeat is timer, the hour/minutes are the repeat time from the 321 | beginning of the reminder. 322 | 323 | ### Native Glucose Units 324 | 325 | The `$uom?` command reports the native unit of measure of the device. 326 | 327 | uom-cmd = "$uom?" 328 | uom-msg = uom-mmoll / uom-mgdl CRLF 329 | 330 | uom-mmol = "0" 331 | uom-mgdl = "1" 332 | 333 | ### Other Commands 334 | 335 | The following commands are sent by various software used by the Libre, but their 336 | output is not obvious. 337 | 338 | #### `$brandname?` 339 | 340 | Appears to report the brand name of the device, possibly differing among 341 | marketing regions. 342 | 343 | brandname-cmd = "$brandname?" 344 | brandname-msg = "FreeStyle Libre" CRLF 345 | 346 | #### `$marketlev?` 347 | 348 | Unknown respoonse. 349 | 350 | marketlev-cmd = "$marketlev?" 351 | marketlev-msg = "1,0,0,0" CRLF 352 | 353 | #### Language settings 354 | 355 | The command `$lang?` reports the currently configured language. 356 | 357 | The command `$lang,` allows changing the configured language (if available in 358 | the firmware of the device.) Note that this allows to configure a language 359 | that is not visible to set in the interface, though in that case the reader 360 | will display the selected language as Español. 361 | 362 | The command `$langset?` reports the list of languages available to set through 363 | the UI itself. 364 | 365 | And similarly the `$langset,` command allows to change the list of available 366 | languages. 367 | 368 | get-lang-cmd = "$lang?" 369 | get-lang-msg = language-code CRLF 370 | 371 | set-lang-cmd = "$lang," language-code 372 | set-lang-msg = CRLF 373 | 374 | get-configured-langs-cmd = "$langset?" 375 | get-configured-langs-msg = language-code *("," language-code) 376 | 377 | set-configured-langs-cmd = "$langset" 1*("," language-code) 378 | set-configured-langs-msg = CRLF 379 | 380 | language-code = pt-br / es-us / en-us / de / fr / it / en-gb / fr-ca / 381 | zh / jp / nl / sv / es-es / no / dk / fi / el / pl / 382 | pt-pt / ru / tr / ar / he 383 | 384 | pt-br = "0" 385 | es-us = "1" 386 | en-us = "2" 387 | de = "3" 388 | fr = "4" 389 | it = "5" 390 | en-gb = "6" 391 | fr-ca = "7" 392 | zh = "8" 393 | jp = "9" 394 | nl = "10" 395 | sv = "11" 396 | es-es = "12" 397 | no = "13" 398 | dk = "14" 399 | fi = "15" 400 | el = "16" 401 | pl = "17" 402 | pt-pt = "18" 403 | ru = "19" 404 | tr = "20" 405 | ar = "21" 406 | he = "22" 407 | 408 | #### `$iobstatus?` 409 | 410 | Originally identified on [FreeStyle Insulinx](freestyle-insulinx). 411 | 412 | iobstatus-cmd = "$iobstatus?" 413 | iobstatus-msg = "255,255" CRLF 414 | 415 | #### `$foodunits?` 416 | 417 | Originally identified on [FreeStyle Insulinx](freestyle-insulinx). 418 | 419 | foodunits-cmd = "$foodunits?" 420 | foodunits-msg = "0" CRLF 421 | 422 | #### `$svgsdef?` 423 | 424 | Originally identified on [FreeStyle Insulinx](freestyle-insulinx). 425 | 426 | svgsdef-cmd = "$svgsdef?" 427 | svgsdef-msg = "255" CRLF 428 | 429 | #### `$corsetup?` 430 | 431 | Originally identified on [FreeStyle Insulinx](freestyle-insulinx). 432 | 433 | corsetup-cmd = "$corsetup?" 434 | corsetup-msg = "255" CRLF 435 | 436 | #### `$insdose?` 437 | 438 | Originally identified on [FreeStyle Insulinx](freestyle-insulinx). 439 | 440 | insdose-cmd = "$insdose?" 441 | insdose-msg = "1" CRLF 442 | 443 | #### `$inscalsetup?` 444 | 445 | Originally identified on [FreeStyle Insulinx](freestyle-insulinx). 446 | 447 | inscalsetup-cmd = "$inscalsetup?" 448 | inscalsetup-msg = "0,0" CRLF 449 | 450 | #### `$carbratio?` 451 | 452 | Originally identified on [FreeStyle Insulinx](freestyle-insulinx). 453 | 454 | carbratio-cmd = "$carbratio?" 455 | carbratio-msg = "0,0" CRLF 456 | "1,0" CRLF 457 | "2,0" CRLF 458 | "3,0" CRLF 459 | "4,0" CRLF 460 | "0" CRLF 461 | 462 | #### `$svgsratio?` 463 | 464 | Originally identified on [FreeStyle Insulinx](freestyle-insulinx). 465 | 466 | svgsratio-cmd = "$svgsratio?" 467 | svgsratio-msg = "0,0" CRLF 468 | "1,0" CRLF 469 | "2,0" CRLF 470 | "3,0" CRLF 471 | "4,0" CRLF 472 | "0" CRLF 473 | 474 | #### `$cttype?` 475 | 476 | Originally identified on [FreeStyle Insulinx](freestyle-insulinx). 477 | 478 | cttype-cmd = "$cttype?" 479 | cttype-msg = "255" CRLF 480 | 481 | #### `$bgdrop?` 482 | 483 | Originally identified on [FreeStyle Insulinx](freestyle-insulinx). 484 | 485 | bgdrop-cmd = "$bgdrop?" 486 | bgdrop-msg = "0,255" CRLF 487 | "1,0" CRLF 488 | "2,0" CRLF 489 | "3,0" CRLF 490 | "4,0" CRLF 491 | "0" CRLF 492 | 493 | #### `$bgtrgt?` 494 | 495 | Originally identified on [FreeStyle Insulinx](freestyle-insulinx). 496 | 497 | bgtrgt-cmd = "$bgtrgt?" 498 | bgtrgt-msg = "0,0" CRLF 499 | "1,0" CRLF 500 | "2,0" CRLF 501 | "3,0" CRLF 502 | "4,0" CRLF 503 | "0" CRLF 504 | 505 | #### `$bgtgrng?` 506 | 507 | Originally identified on [FreeStyle Insulinx](freestyle-insulinx). 508 | 509 | bgtgrng-cmd = "$bgtgrng?" 510 | bgtgrng-msg = "0,0,0" CRLF 511 | "1,0,0" CRLF 512 | "2,0,0" CRLF 513 | "3,0,0" CRLF 514 | "4,0,0" CRLF 515 | "0" CRLF 516 | 517 | #### `$tagsenbl?` 518 | 519 | Originally identified on [FreeStyle Insulinx](freestyle-insulinx). 520 | 521 | tagsenbl-cmd = "$tagsenbl?" 522 | tagsenbl-msg = CRLF 523 | 524 | #### `$patch?` 525 | 526 | Return information about the sensors (patches) that the device initialized. 527 | 528 | The returned message is in a similar text format to "multi records" responses, 529 | but with a different structure. 530 | 531 | patch-response = empty-log / patch-response-detailed 532 | empty-log = "Log Empty" CRLF 533 | 534 | csv-line = *( value "," ) value 535 | value = 1*DIGIT 536 | checksum = 8HEXDIGIT 537 | 538 | patch-response-detailed = csv-line CRLF 539 | "PID: " csv-line CRLF 540 | "SW Versions: " csv-line CRLF 541 | csv-line CRLF 542 | "Event Log: " csv-line CRLF 543 | csv-line CRLF 544 | "AFE Cal Data: " csv-line CRLF 545 | "Unused: " csv-line 546 | "1," checksum 547 | 548 | The `` field is calculated in the same way as multiple records 549 | commands: by summing up the ASCII value of each of the bytes forming the 550 | response set, up to and including the final newline before `1,`. 551 | -------------------------------------------------------------------------------- /src/abbott/freestyle-lite.md: -------------------------------------------------------------------------------- 1 | 6 | 7 | # FreeStyle Freedom Lite / Lite / Mini 8 | 9 | Reverse Engineered by [Alexander 10 | Schrijver](http://www.flupzor.nl/protocol.html) (@flupzor). 11 | 12 | ## Important device notes 13 | 14 | This protocol is used in the following devices: 15 | 16 | * FreeStyle Freedom Lite 17 | * FreeStyle Lite 18 | * FreeStyle Mini 19 | 20 | ## Cable 21 | 22 | These devices connect to a computer with a TRS (mini-jack) to RS232 cable. 23 | 24 | Abbott provides a TIUSB3410 USB-to-Serial adapter by Texas Instruments. This 25 | cable is supported at least from Linux 3.14 and later. 26 | 27 | ## Protocol 28 | 29 | ### Serial port configuration 30 | 31 | The serial port should be configured as such: 32 | 33 | * 8 data bits; 34 | * no parity bits; 35 | * 1 stop bit; 36 | * 19200 baud rate. 37 | 38 | ### Messages and commands 39 | 40 | The FreeStyle protocol has 2 types of messages a command and a result. Currently 41 | only one command exists which returns multiple results. 42 | 43 | generic-message = command / result 44 | 45 | The host starts with setting up the connection. After that it should send the 46 | following command: 47 | 48 | command = "mem" 49 | 50 | The device then sends the following data. 51 | 52 | result = CR LF 53 | serial-number CR LF 54 | software-version CR LF 55 | currentdatetime 56 | log 57 | 58 | serial-number = 7( ALPHA / DIGIT ) "-" 5( ALPHA / DIGIT ) 59 | software-version = CR LF 1*DIGIT "." 1*DIGIT *SP "-P" 60 | 61 | The serial number is provided in the same format as other FreeStyle devices. 62 | 63 | The software revision doesn't seem to be very consistent. It usually includes a 64 | dot-version, as a normal software revision, and terminate with the `-P` 65 | string. Sometimes the version is space-padded, and sometimes it's not. 66 | 67 | ### Date and Time Format 68 | 69 | currentdatetime = datetime 70 | 71 | datetime = month SP day SP year SP time 72 | month = "Jan " / "Feb " / "Mar " / "Apr " / "May " / "June" / "July" / 73 | "Aug " / "Sep " / "Oct " / "Nov " / "Dec " 74 | ; N.B. Except June and July all months have spaces at the end. 75 | day = 2DIGIT 76 | year = 4DIGIT 77 | 78 | time = hour ':' minute ':' second 79 | hour = 2DIGIT 80 | minute = 2DIGIT 81 | second = 2DIGIT 82 | 83 | ### Log 84 | 85 | log = empty-log / log-contents 86 | empty-log = "Log Empty END" 87 | log-contents = CR LF 88 | nrresult CR LF LF 89 | resultline *(CR LF resultline) 90 | checksum "END" 91 | 92 | nrresults = 3DIGIT; e.g. 001 or 250 93 | 94 | resultline = result-value datetime2 plasmatype "0x00" 95 | result-value = 3DIGIT 96 | datetime2 = month SP day SP year SP time2 97 | time2 = hour ':' minute 98 | plasmatype = 2DIGIT 99 | 100 | checksum = "0x" 4HEXDIG 101 | 102 | There is probably is a maximum number of results. At the moment we are guessing 103 | it is 450 which is the maximum the Abbott Precision Xceed can store. The minimum 104 | is 1 105 | 106 | Note that the inconsistent spacing (including the additional LF) is intentional. 107 | 108 | NOTE: `result-value` minimum and maximum are not known; comparing with other 109 | Abbott device, it's possible that they use the constants `HI` and `LO` instead. 110 | 111 | The `checksum` is a simple accumulation of the ASCII values of the characters, 112 | up until the `0x` literal (excluded), including the `CR LF` terminations. 113 | -------------------------------------------------------------------------------- /src/abbott/freestyle-optium.md: -------------------------------------------------------------------------------- 1 | 6 | 7 | # FreeStyle Optium 8 | 9 | Reverse engineered by [Diego Elio Pettenò](mailto:flameeyes@flameeyes.com). 10 | 11 | ## Important device notes 12 | 13 | The FreeStyle Optium device is a glucometer that can also read special β-ketones 14 | testing strips. This will become clear in the protocol description. 15 | 16 | There is no option to clear the meter's memory from the *FreeStyle Auto-Assist* 17 | software provided by Abbott. 18 | 19 | ## Cable 20 | 21 | The Abbott FreeStyle Optium device uses a special cable, that connects 22 | through the same port as the testing strips, and puts the device into 23 | PC connection mode. 24 | 25 | In PC connection mode, the screen will display the following: 26 | 27 | ]--PC 28 | 29 | The cable itself, as provided by Abbott, uses a TIUSB3410 USB-to-Serial adapter 30 | provided by Texas Instruments, similar to the TRS (stereo-jack) of previous 31 | versions. 32 | 33 | The strip-port adapter is fully suppored by Linux kernel 3.14 and 34 | later. Previous kernels only support the TRS cable. 35 | 36 | ## Protocol 37 | 38 | The communication protcol of this device is a serial, text-based protocol, 39 | similar to previous FreeStyle devices, but not compatible. 40 | 41 | ### Serial port configuration 42 | 43 | The serial port should be configured as such: 44 | 45 | * 8 data bits; 46 | * no parity bits; 47 | * 1 stop bit; 48 | * 19200 baud rate. 49 | 50 | ### Messages and commands 51 | 52 | The protocol knows two type of messages: commands and responses. 53 | 54 | generic-message = command / response 55 | 56 | Exchange is initiated by the host by sending one of the known commands. The 57 | first command sent by the host is sometimes ignored by the device, so if a 58 | single empty response is returned, the command should be retried. 59 | 60 | The only known command that accept parameters is `tim`. 61 | 62 | command = "$" *ALPHA [parameters] CR LF 63 | parameters = "," *VCHAR 64 | 65 | Lines are generally terminated by the `CR LF` sequence. Most commands are 66 | terminated by a success sequence. 67 | 68 | command-succeeded = "CMD OK" CR LF 69 | 70 | #### `$colq` command 71 | 72 | The `$colq` command provides detailed information on the device: 73 | 74 | colq-response = "S/N:" HTAB serial-number CR LF 75 | "Ver:" HTAB software-version HTAB glucose-unit CR LF 76 | "Clock:" HTAB date-1-sec CR LF 77 | "Market:" HTAB DIGIT HTAB DIGIT CR LF 78 | "ROM:" HTAB DIGIT HTAB DIGIT HTAB DIGIT HTAB DIGIT CR LF 79 | "Usage:" HTAB usage-count CR LF 80 | command-succeded 81 | usage-count-1 = 1*DIGIT 82 | 83 | serial-number = 7( ALPHA / DIGIT ) "-" 5( ALPHA / DIGIT ) 84 | software-version = 1*DIGIT "." 1*DIGIT 85 | 86 | glucose-unit = "MMOL" / ??? ; the output for mg/dL is not known 87 | 88 | The `usage-count` is the number of readings available in the memory of the 89 | device. 90 | 91 | Serial number, software version, market and ROM output are really opaque 92 | identifiers. The serial number is unique to the device (corresponds to the one 93 | printed on its back) and can be used to match an user to their glucometer. All 94 | these parameters are constant. 95 | 96 | The `glucose-unit` of the device is reported together with the version. *Note:* as 97 | I live in Ireland, and the unit is specified in mmol/L, I have no idea what the 98 | string would be for glucometers in the rest of the world. 99 | 100 | #### `$xmem` command 101 | 102 | The `$xmem` command reports the content of the device's memory. 103 | 104 | xmem-response = CR LF 105 | serial-number CR LF 106 | software-version CR LF 107 | date-2-sec CR LF 108 | usage-count-2 CR LF 109 | *(result CR LF) 110 | checksum SP SP "END" CR LF 111 | usage-count-2 = 3DIGIT 112 | checksum = "0x" 4HEXDIG 113 | 114 | The `usage-count-2` value matches `usage-count-1`, zero-padded to align at three 115 | digits. 116 | 117 | The `checksum` is a simple accumulation of the ASCII values of the characters, 118 | up until the `0x` literal (excluded), including the `CR LF` terminations. 119 | 120 | Each result is returned in its own line complete with the timestamp and some 121 | (mostly opaque) metadata: 122 | 123 | result = result-value SP 124 | SP date-2-nosec 125 | SP result-type 126 | SP "0x00" 127 | result-value = 3DIGIT / ( "HI" SP ) 128 | result-type = "G" / "K" 129 | 130 | The result type literal distinguishes between blood glucose (`G`) and β-ketones 131 | (`K`) test results. 132 | 133 | For glucose results, the value is given in mg/dL, even if the glucometer is set 134 | to report mmol/L in its configuration. Conversion happens at display time, both 135 | on the device and on the software. 136 | 137 | For β-ketones results, the unit of the value is currently unknown; where the 138 | display shows (0.2 mmol/l, the value provided is 003.) 139 | 140 | The `HI` literal signify a reading that was outside the range of the device (or 141 | more likely of the strip.) For glucose results, this is unknown, where for 142 | β-ketones it is known as 8.0 mmol/l. 143 | 144 | #### `$tim` command 145 | 146 | Setting the time on the device is the only command that accept parameters. 147 | 148 | tim-command = "$tim" tim-parameters 149 | tim-parameters = "," tim-month "," tim-day "," tim-year 150 | "," tim-hour "," tim-minute 151 | 152 | tim-response = command-succeeded ; not other output 153 | 154 | The time on the device can only be set for full minutes, without including 155 | seconds. 156 | 157 | Years are represented in two-digits only, which are interpreted between 2000 158 | and 2099. The device **can** keep track of time beyond that, as can be proven by 159 | setting the time to 2099-12-31 23:59. 160 | 161 | The device does not suffer from [Year 2038](https://en.wikipedia.org/wiki/Y2038) 162 | problem. 163 | 164 | #### `$temp` command 165 | 166 | The device appears to contain a temperature sensor that can be accessed with the 167 | `$temp` command: 168 | 169 | temp-response = "Temperature =" SP temperature SP "*C" SP "/" SP 170 | temperature SP "*F" CR LF 171 | command-succeeded 172 | temperature = SP 2DIGIT "." 2DIGIT ; not tested with numbers over 100. 173 | 174 | Temperature is reported in both Celsius and Farenheit. The leading space to the 175 | number is suspected to be a padding for values over 100. 176 | 177 | #### Other commands 178 | 179 | The following commands have been identified as valid by bruteforcing (they 180 | return `command-succeeded`), but are not understood: 181 | 182 | * `$cksm`: returns a checksum (of memory? storage? ROM?). 183 | * `$coly`: appears to disconnect and power off the meter. 184 | * `$dtim`: no visible effect. 185 | * `$vrom`: no visible effect (verify rom?). 186 | 187 | #### Date formats 188 | 189 | This device, similarly to previous Abbott devices, implements multiple date 190 | formats, that are not interchangable: 191 | 192 | date-1-sec = month1 SP SP day SP year HTAB timesec 193 | date-2-sec = month2 SP day SP year SP timesec 194 | date-2-nosec = month2 SP day SP year SP time 195 | 196 | time = hour ":" minute 197 | timesec = time ":" second 198 | year = 4DIGIT 199 | day = 2DIGIT 200 | hour = 2DIGIT 201 | minute = 2DIGIT 202 | second = 2DIGIT 203 | 204 | month1 = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / "Jul" / 205 | "Aug" / "Sep" / "Oct" / "Nov" / "Dec" 206 | ; In this case, months are 4-characters strings, padded by space with the 207 | ; exception of June and July. 208 | month2 = "Jan " / "Feb " / "Mar " / "Apr " / "May " / "June" / "July" / 209 | "Aug " / "Sep " / "Oct " / "Nov " / "Dec " 210 | 211 | The two formats used in the response for `$xmem` include the same idiosyncrasy 212 | as previous devices, in which month names are truncated to three letters and 213 | followed by a space character, with the exclusions of `June` and `July` which 214 | are written in full. This behaviour is not present in the `$colq` response. 215 | 216 | ## Missing information 217 | 218 | As the analyzed logs used to compile this specification are minimal, there are 219 | currently a number of "known unknowns". If anyone is able to provide further 220 | information, it would be welcome. 221 | 222 | * Behaviour of the device when no results are stored; since there is no command 223 | to reset the device's memory this is not currently known. 224 | * Expected constant to indicate the device reports values in mg/dL on its 225 | screen. 226 | * Whether a `LO` constant exists to match the `HI` constant. **Dangerous! Don't 227 | try this yourself, only report back if you happen to have triggered it!** 228 | * How the β-ketones results are reported by the device. 229 | * How the control solution results are reported by the device. 230 | 231 | ## References 232 | 233 | * [TIUSB3410 datasheet](http://www.ti.com/lit/ds/symlink/tusb3410.pdf) 234 | * [Alexander Schrijver's FreeStyle reverse engineering](http://www.flupzor.nl/protocol.html) 235 | -------------------------------------------------------------------------------- /src/abbott/freestyle-precision-neo.md: -------------------------------------------------------------------------------- 1 | 6 | 7 | # FreeStyle Precision Neo, Optium Neo, Optium Neo H 8 | 9 | Reverse engineered by [Diego Elio Pettenò](mailto:flameeyes@flameeyes.com). 10 | 11 | ## Important device notes 12 | 13 | Abbott markets a number of similar meters with a different set of features 14 | enabled for each in different markets. These differences appear to be 15 | implemented similarly to the selection of glucose units used in 16 | display/reporting. 17 | 18 | The known devices sharing the same base protocol are the following: 19 | 20 | * **FreeStyle Precision Neo**, marketed in the United States; 21 | * **FreeStyle Optium Neo**, marketed in Europe; 22 | * **FreeStyle Optium Neo H**. 23 | 24 | The FreeStyle Precision Neo (at the very least) can also read special β-ketones 25 | testing strips. 26 | 27 | ### USB IDs 28 | 29 | | Device | Vendor ID | Product ID | 30 | | --- | --- | --- | 31 | | FreeStyle Precision Neo | 1a61 | 3850 | 32 | 33 | ## Protocol 34 | 35 | This device uses the [shared HID protocol](shared-hid-protocol.md) used by other 36 | meters in the FreeStyle family. All messages that have been identified are 37 | considered text commands and use message type `0x60`. 38 | 39 | ## Commands 40 | 41 | All commands supported by the shared protocol are supported by the device. Those 42 | that deviate from said protocol are here documented. 43 | 44 | ### `$result?` 45 | 46 | The `$result?` command is used to dump the readings records from the device, and 47 | it follows the *Multiple records command* output format as described in the 48 | shared protocol documentation. 49 | 50 | The first field in the record specify the type of record; type 7 is a blood 51 | glucose reading, type 10 is an insulin input that was made on the device. 52 | 53 | 54 | #### Blood glucose record fields 55 | 56 | 1. `type = "7"` 57 | 2. `id` 58 | 3. `month = 1*2DIGIT` 59 | 4. `day = 1*2DIGIT` 60 | 5. `year = 1*2DIGIT` 61 | 6. `hour = 1*2DIGIT` 62 | 7. `minute = 1*2DIGIT` 63 | 8. `unknown` 64 | 9. `value = 1*DIGIT / "HI"` 65 | 10. `unknown` 66 | 11. `unknown` 67 | 12. `unknown` 68 | 13. `unknown` 69 | 14. `unknown` 70 | 15. `unknown` 71 | 16. `unknown` 72 | 17. `unknown` 73 | 18. `unknown` 74 | 19. `unknown` 75 | 76 | The `HI` literal signifies a reading that was outside the range of the device 77 | (or more likely of the strip.) For glucose results, this is an unknown value. 78 | 79 | #### Insulin record fields 80 | 81 | 1. `type = "10"` 82 | 2. `id` 83 | 3. `month = 1*2DIGIT` 84 | 4. `day = 1*2DIGIT` 85 | 5. `year = 1*2DIGIT` 86 | 6. `hour = 1*2DIGIT` 87 | 7. `minute = 1*2DIGIT` 88 | 8. `unknown` 89 | 9. `insulin-type` 90 | 10. `value = 1*DIGIT` 91 | 11. `unknown` 92 | 12. `unknown` 93 | 13. `unknown` 94 | 95 | The insulin type is defined as follows: 96 | 97 | insulin-type = morning-long-acting / breakfast-short-acting / 98 | lunch-short-acting / evening-long-acting / 99 | dinner-short-acting 100 | morning-long-acting = "0" 101 | breakfast-short-acting = "1" 102 | lunch-short-acting = "2" 103 | evening-long-acting = "3" 104 | dinner-short-acting = "4" 105 | 106 | #### β-ketones record fields 107 | 108 | 1. `type = "9"` 109 | 2. `id` 110 | 3. `month = 1*2DIGIT` 111 | 4. `day = 1*2DIGIT` 112 | 5. `year = 1*2DIGIT` 113 | 6. `hour = 1*2DIGIT` 114 | 7. `minute = 1*2DIGIT` 115 | 8. `unknown` 116 | 9. `value = 1*DIGIT` 117 | 10. `unknown` 118 | 119 | The Ketone value is in mg/dL not in mmol/L as it should be. Divide the value by 120 | 18 to get a proper Ketone value in mmol/L. 121 | 122 | ### Other Commands 123 | 124 | The following commands, used by other meters using the shared HID protocol, are 125 | identified as supported by the device: 126 | 127 | #### `$gunits?` 128 | 129 | Originally identified on [FreeStyle Insulinx](freestyle-insulinx). 130 | 131 | Unknown response. Best guess this _may_ be "Glucose Units". 132 | 133 | gunits-cmd = "$gunits?" 134 | gunits-msg = "1" CRLF ; on a mg/dL device 135 | 136 | The theory of this being the unit of measure is supported by the `$uom?` command 137 | reporting `0` for a mmol/L FreeStyle Libre reader. 138 | 139 | #### `$marketlev?` 140 | 141 | Originally identified on [FreeStyle Libre](freestyle-libre). 142 | 143 | marketlev-cmd = "$marketlev?" 144 | marketlev-msg = "1,0" CRLF 145 | -------------------------------------------------------------------------------- /src/abbott/shared-hid-protocol.md: -------------------------------------------------------------------------------- 1 | 6 | 7 | # Abbott Shared HID protocol 8 | 9 | Multiple Abbott devices of the FreeStyle family share a common communication 10 | protocol based on USB HID. These devices all provide a direct USB connector and 11 | require no special cable nor driver to speak with a PC. 12 | 13 | While most of the commands are not compatible between each other, the devices do 14 | share a basic framing protocol and basic text command format. 15 | 16 | Credit for the reverse engineering go to Xavier Claessens for 17 | [OpenGlucose](https://github.com/xclaesse/OpenGlucose/blob/master/src/insulinx.c). 18 | 19 | ## Communication Protocol 20 | 21 | These devices appears on the USB bus as a HID device. The communication between 22 | the software and the device happens through HID **Set Report**/**Get Report** 23 | interfaces, in a way that is compatible with the 24 | [Linux hidraw](https://www.kernel.org/doc/Documentation/hid/hidraw.txt) 25 | interface. 26 | 27 | In particular the packets are sent on the *Control* endpoint, as *Class 28 | Interface* messages (`bRequestType = 0x21, bRequest = 0x09, wValue = 0x0200, 29 | wIndex = 0x0000`), and received on the interrupt endpoint (`0x81`). Report 30 | numbers are not used. 31 | 32 | The "reports" are not following the HID standard. They are of a fixed 64-bytes 33 | size, even if most of the commands themselves are shorter. Replies can span 34 | multiple inbound reports. 35 | 36 | message = message-type message-length 62OCTET 37 | message-type = OCTET ; this will more properly defined later. 38 | message-length = %x00-3E 39 | 40 | The `message-type` is not fully understood, and its valid values differ 41 | between different devices, so please reference the specific device document. 42 | 43 | The `message-length` represent the number of significant bytes in the message 44 | *excluding type and length*. 45 | 46 | Some devices (notably the Libre 2 reader) encrypt the message following 47 | `message-type`, and as such don't have a valid `message-length` value. 48 | 49 | ## Binary Messages 50 | 51 | Abbott's original software sends a number of pre-initialization commands to 52 | identify the model and software version of the device, and choose the 53 | appropriate protocol implementation. These are all binary (i.e. non-text) 54 | commands. The names are arbitrary to provide a mnemonic reference. 55 | 56 | ### INIT (`0x01`) 57 | 58 | init = %x01 %x00 59 | init-reply = %x71 %x01 %x01 60 | 61 | This is the same exact request/reply pair in all the currently observed 62 | devices. Most devices will respond to text commands following this 63 | initialization. 64 | 65 | ### `0x04` 66 | 67 | x04-command = %x04 %x00 68 | x04-command-reply = %x34 %x01 OCTET 69 | 70 | The octet returned by this command appears not to be constant per device, 71 | according to Xavier's notes and experimentation. It is not constant across 72 | devices. No meaning is known for this. 73 | 74 | ### QUERY SERIAL (`0x05`) 75 | 76 | init-query-serial = %x05 %x00 77 | init-query-serial-reply = %x06 %x0e 78 | ( serial-number / no-serial-number ) %x00 79 | serial-number = 7( ALPHA / DIGIT ) "-" 5( ALPHA / DIGIT ) 80 | no-serial-number = "00000000 (No SerialNum)" 81 | 82 | Note: the serial number definition is common to most Abbott device, except newer 83 | devices have a longer, and non-compatible serial number format. It is possible 84 | that the Abbott software can determine the driver to use based on this serial 85 | number. 86 | 87 | ### QUERY SWVER (`0x15`) 88 | 89 | init-query-swver = %x15 %x00 90 | init-query-swver-reply = %x35 message-length software-version %x00 91 | software-version = VCHAR *( VCHAR / SP ) 92 | 93 | The software version definition is effectively free-form. Some newer models 94 | appear to include a date. 95 | 96 | ## Error Conditions 97 | 98 | ### UNKNOWN COMMAND 99 | 100 | Whenever an invalid (unknown) message type is sent to a device, it will respond 101 | with the following message: 102 | 103 | error-reply = %x30 %x01 %x85 104 | 105 | ## Synchronization packets 106 | 107 | Some devices send what appears like a "synchronization packet" every few reports 108 | read, that is so defined: 109 | 110 | synchronization-packet = %x22 %x01 OCTET 111 | 112 | The frequency of these packets appears to depend on the device (some devices 113 | appear to send it exactly every three reports sent), and so does the content of 114 | the packet. 115 | 116 | ## Text commands 117 | 118 | Most of the devices using this HID-based protocol can be sent commands that 119 | receive ASCII text responses. These responses can span multiple frames, allowing 120 | the single response to cross the 62-bytes length limit. 121 | 122 | Each text response, once reconstructed, complies to the following specs: 123 | 124 | response = message "CKSM:" checksum CRLF 125 | "CMD" SP command-status CRLF 126 | 127 | checksum = 8HEXDIG 128 | message = *( VCHAR / SP / CRLF ) 129 | command-status ("OK" / "Fail!") 130 | 131 | The `` is calculated by summing up the ASCII value of each of the 132 | bytes forming the message, including the final newline that usually terminates 133 | the message. 134 | 135 | Since no message is present in case of message failure, the checksum is null and 136 | is represented by the string `00000000`. 137 | 138 | ## Multiple records commands 139 | 140 | Different commands can return a list of records. While their meaning depends on 141 | the issued command, the reported format fits the same syntax: 142 | 143 | multi-records = empty-log / log 144 | 145 | empty-log = "Log Empty" CRLF 146 | log = *( record CRLF ) 147 | record-count "," checksum 148 | 149 | record = *( value "," ) value 150 | value = *VCHAR 151 | record-count = 1*DIGIT 152 | checksum = 8HEXDIGIT 153 | 154 | The `` field will contain the number of records that were 155 | returned; the `` field is calculated the same way as the overall 156 | command one by summing up the ASCII value of each of the bytes forming the 157 | record set, up to and including the final newline, and excluding the record 158 | count. 159 | 160 | ## Common commands 161 | 162 | There are a number of commands that appear shared across FreeStyle devices, and 163 | are thus documented here to avoid duplication. 164 | 165 | As devices may not support all these common commands, please refer to the 166 | detailed protocol definition to note inconsistencies. 167 | 168 | The majority of these commands are getters and setters of variables, some 169 | free-form and some structured. The generic syntax for these commands is: 170 | 171 | command = "$" variable-name ( "?" / "," variable-value ) 172 | variable-name = 1*VCHAR 173 | variable-value = *( VCHAR / SP ) 174 | 175 | Some variable (such as the software version and serial number) are 176 | read-only. Those commands are documented with their full value, including the 177 | terminating question mark. 178 | 179 | ### `$swver?` 180 | 181 | swver-response = 1* ( VCHAR / SP ) CRLF 182 | 183 | Returns the software version of the device. The returned value is free-form, as 184 | it changes among devices. 185 | 186 | ### `$serlnum?` 187 | 188 | serlnum-response = 1* ( ALPHA / DIGIT ) CRLF 189 | 190 | Returns the serial number of the device. The serial number format appears to be 191 | different from previous Abbott devices and as such is to be considered 192 | free-form. 193 | 194 | Please note that this command may provide a serial number even for devices that 195 | respond with `` during initialization. 196 | 197 | ### `$date` 198 | 199 | date-cmd = "$date" ("?" / "," date-value) 200 | date-query-response = date-value CRLF 201 | 202 | date-value = ( month "," day "," year ) 203 | month = 1*3DIGIT 204 | day = 1*3DIGIT 205 | year 1*3DIGIT 206 | 207 | Fetch or set the current date as seen by the device. If a date value is passed 208 | following the command, it'll be interpreted as a set-date. 209 | 210 | If the device does not have a valid date settings (e.g. the real time clock lost 211 | its power), the value 255 is reported for all fields. 212 | 213 | Note the year value is defined at most with two digits, the value 2000 needs to 214 | be added (or subtracted) to match the current year. 215 | 216 | In case of successful setting of date, the command is confirmed with no further 217 | information; in case of error, the `` field will report the encountered 218 | error. 219 | 220 | ### `$time` 221 | 222 | time-cmd = "$time" ("?" / "," time-value) 223 | time-query-response = time-value CRLF 224 | 225 | time-value = hour "," minute 226 | hour = 1*3DIGIT 227 | minute = 1*3DIGIT 228 | 229 | Fetch or set the current time as seen by the device. 230 | 231 | If the device does not have a valid time settings (e.g. the real time clock lost 232 | its power), the value 255 is reported for all fields. 233 | 234 | In case of successful setting of date, the command is confirmed with no further 235 | information; in case of error, the `` field will report the encountered 236 | error. 237 | 238 | ### `$ptname` 239 | 240 | ptname-cmd = "$ptname" ("?" / "," patient-name) 241 | ptname-query-response = patient-name CRLF 242 | 243 | patient-name-setting = 1*VCHAR 244 | patient-name-response = *VCHAR 245 | 246 | Returns the patient name as configured in the device. 247 | 248 | Note that while an empty response is valid, an empty value when setting the 249 | variable is not always accepted. The behaviour depends meter by meter. 250 | 251 | ### `$ptid` 252 | 253 | ptid-cmd = "$ptname" ("?" / "," patient-id) 254 | ptid-query-response = patient-id CRLF 255 | 256 | patient-id-setting = 1*VCHAR 257 | patient-id-response = *VCHAR 258 | 259 | Returns the patient ID as configured in the device. 260 | 261 | Note that while an empty response is valid, an empty value when setting the 262 | variable is not accepted. 263 | -------------------------------------------------------------------------------- /src/index.md: -------------------------------------------------------------------------------- 1 | 6 | 7 | # Glucometers Protocol Specifications 8 | 9 | This website is intended to provide description of protocols (or "Computer 10 | Interface Specifications") for various glucometers. 11 | 12 | As few manufacturers publish documentation of their meters' protocols, the 13 | majority of the content is produced by reverse engineering the data transmission 14 | between meters and PCs, and documenting it. 15 | 16 | ## Reversed Engineered Protocols 17 | 18 | * Abbott Laboratories 19 | - [FreeStyle Lite](abbott/freestyle-lite.md) 20 | - [FreeStyle Optium](abbott/freestyle-optium.md) 21 | - [Shared HID protocol](abbott/shared-hid-protocol.md) 22 | - [FreeStyle InsuLinx](abbott/freestyle-insulinx.md) 23 | - [FreeStyle Libre](abbott/freestyle-libre.md) 24 | - [FreeStyle Libre 2](abbott/freestyle-libre-2.md) 25 | - [FreeStyle Precision Neo](abbott/freestyle-precision-neo.md) 26 | * LifeScan 27 | - [Shared Binary Protocol](lifescan/shared-binary-protocol.md) 28 | - [OneTouch Verio IQ](lifescan/onetouch-verio-iq.md) 29 | - [OneTouch Verio (2015)](lifescan/onetouch-verio-2015.md) 30 | * Menarini 31 | - [GlucoMen areo](menarini/glucomen-areo.md) 32 | * Sanofi 33 | - [BGStar and Mystar Extra](sanofi/bgstar-mystar.md) 34 | * SD Biosensor 35 | - [SD Codefree](sd-biosensor/codefree.md) 36 | * TaiDoc 37 | - [TD-42xx](taidoc/td42xx.md) 38 | 39 | See [reverse engineering contribution 40 | suggestions](contributing/reverse-engineered.md) for details on how to 41 | contribute new protocols. 42 | 43 | ## Manufacturer Supplied Documentation 44 | 45 | * [Ascensia Diabetes Care](http://protocols.ascensia.com/Programming-Guide.aspx) 46 | (_Contour_ brand, formerly under the Bayer name.) 47 | 48 | ## Standards and Common Protocols 49 | 50 | ### CLSI 51 | 52 | [CLSI](https://clsi.org/) (Clinical and Laboratory Standards Institute) develop 53 | and publish protocols that are used by some meter manufacturers. 54 | 55 | The two main relevant documents are: 56 | 57 | * [Specification for Low-Level Protocol to Transfer Messages Between Clinical 58 | Laboratory Instruments and Computer Systems, 2nd 59 | Edition](https://clsi.org/standards/products/automation-and-informatics/documents/lis01/) 60 | (LIS01-A2) 61 | * [Specification for Transferring Information Between Clinical Laboratory 62 | Instruments and Information Systems, 2nd 63 | Edition](https://clsi.org/standards/products/automation-and-informatics/documents/lis02/) 64 | (LIS02-A2) 65 | 66 | These are proprietary, not freely available standards. 67 | 68 | ### Bluetooth GATT 69 | 70 | Many Bluetooth glucometers implement [GATT 71 | Services](https://www.bluetooth.com/specifications/gatt/services/), which then 72 | reference the following specifications: 73 | 74 | * [Glucose Profile (GLP) 75 | 1.0](https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=248025). 76 | * [Glucose Service (GLS) 77 | 1.0](https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=248026). 78 | * [Continuous Glucose Monitoring Profile (CGMP) 79 | 1.0.1](https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=310501) 80 | * [Continuous Glucose Monitoring Service (CGMS) 81 | 1.0.1](https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=310502) 82 | 83 | ## License 84 | 85 | This work is licensed under a [Creative Commons Attribution 4.0 International 86 | License](https://creativecommons.org/licenses/by/4.0/). 87 | 88 | Use the information you'll find in this page for whatever purpose you see fit, 89 | but there is no warranty about the accuracy of this information. 90 | 91 | Most of the information has been reverse engineerd by individual contributors, 92 | see the individual page for details. 93 | -------------------------------------------------------------------------------- /src/lifescan/onetouch-ultra2.md: -------------------------------------------------------------------------------- 1 | 6 | 7 | # OneTouch Ultra 2 8 | 9 | The OneTouch Ultra 2 protocol specifications have been made available by 10 | LifeScan in the past, and as such require no reverse engineered protocol 11 | specification. 12 | 13 | This document is intended to only note similarities with other OneTouch devices. 14 | 15 | The communication protocol applies to the following models: 16 | 17 | * *OneTouch Ultra 2* 18 | 19 | ## Communication 20 | 21 | The device communicates over a TRS-connected serial port, compatible with 22 | the [OneTouch Ultra Easy](onetouch-ultraeasy.md) device. 23 | -------------------------------------------------------------------------------- /src/lifescan/onetouch-ultraeasy.md: -------------------------------------------------------------------------------- 1 | 6 | 7 | # OneTouch Ultra Easy 8 | 9 | The OneTouch Ultra Easy protocol specifications have been made available by 10 | LifeScan in the past, and as such require no reverse engineered protocol 11 | specification. 12 | 13 | This document is intended to only note similarities with other OneTouch devices. 14 | 15 | The communication protocol applies to the following models: 16 | 17 | * *OneTouch Ultra Easy* 18 | * *OneTouch Ultra Mini* 19 | 20 | ## Communication 21 | 22 | The device communicates over a TRS-connected serial port, compatible with 23 | the [OneTouch Ultra2](onetouch-ultra2.md) device. 24 | 25 | The packet structure of the protocol follows 26 | the [Shared Binary Protocol](shared-binary-protocol.md). 27 | 28 | Within the packet, the `link-control` byte is used; refer to the LifeScan 29 | provided specifications. 30 | 31 | The `command-prefix` byte is expected to be `0x05`. 32 | 33 | packet ; see shared-binary-protocol.md 34 | link-control = OCTET ; used by this device 35 | command-prefix = %x05 36 | -------------------------------------------------------------------------------- /src/lifescan/onetouch-verio-2015.md: -------------------------------------------------------------------------------- 1 | 6 | 7 | # OneTouch Verio 2015 8 | 9 | Reverse engineered by [Diego Elio Pettenò](mailto:flameeyes@flameeyes.com). 10 | 11 | The communication protocol as described in this document applies to 12 | the following models: 13 | 14 | * *OneTouch Verio 2015* (microUSB connector) 15 | * *OneTouch Select Plus* 16 | * *OneTouch Select Plus Flex* (USB connection only) 17 | 18 | ## Important device notes 19 | 20 | Not to be confused with the the previous generation of OneTouch Verio 21 | meters, the 2015 edition comes with a microUSB-A connector, rather 22 | than a TRS (stereo-jack.) 23 | 24 | ### USB IDs 25 | 26 | | Device | Vendor ID | Product ID | 27 | | --- | --- | --- | 28 | | OneTouch Verio 2015 | 2766 | 0000 | 29 | | OneTouch Select Plus | 2766 | 1000 | 30 | | OneTouch Select Plus Flex | 2766 | 1004 | 31 | 32 | ## Communication 33 | 34 | The device is identified by operating systems as a standard USB Mass 35 | Storage device of disk type. No custom drivers are required. 36 | 37 | The original software does not use any knocking sequence, no extra 38 | device or interface is available. 39 | 40 | Communication is apparently achieved through three 512-bytes 41 | [registers](https://en.wikipedia.org/wiki/Hardware_register), 42 | implemented as flash device sectors with 43 | [LBA](https://en.wikipedia.org/wiki/Logical_block_addressing) 3, 4 44 | and 5. These will be referenced as `lba3`, `lba4` and `lba5` in this 45 | text. 46 | 47 | The registers are accessed through SCSI commands **WRITE(10)** and 48 | **READ(10)**. Raw commands seem to be required, as the device rejects 49 | any CDB (Command Block) with non-default flags set. 50 | 51 | There does not appear to be any specific requirement of timing between 52 | the **WRITE(10)** command the subsequent **READ(10)**. The response 53 | for a given request is read from the same register it has been written 54 | to. Message are specific to one register and will not work if written 55 | to a different register. 56 | 57 | No knock sequence is needed to initiate communication. 58 | 59 | ## Identification 60 | 61 | Since the device communicates by what would otherwise be a destructive 62 | change to its storage, it is important that the commands are not 63 | issued to a non-compatible device, as they might damage the partition 64 | table of an external storage device. 65 | 66 | It is possible to identify the device by inspecting either the USB 67 | Device descriptor, or issuing a SCSI **INQUIRY** command. 68 | 69 | ### USB identification 70 | 71 | In the USB descriptor, the device will report an *Interface 72 | descriptor* as such: 73 | 74 | bInterfaceClass 8 Mass Storage 75 | bInterfaceSubClass 6 SCSI 76 | bInterfaceProtocol 80 Bulk-Only 77 | iInterface 7 LifeScan MSC 78 | 79 | The `LifeScan MSC` string identifies the mass-storage controller 80 | protocol as being non-standard. 81 | 82 | The USB `iProduct` and `iSerial` are also matching the information 83 | reported by the LifeScan communication protocol. 84 | 85 | ### SCSI identification 86 | 87 | At the SCSI level, the device will report a *Vendor identification* 88 | string of `LifeScan`: 89 | 90 | Vendor identification: LifeScan 91 | Product identification: 92 | Product revision level: 93 | Unit serial number: 94 | 95 | Note that while the USB protocol information (product, serial number) 96 | match the device's information, only the vendor identification is 97 | visible in response to the **INQUIRY** command. 98 | 99 | ## Packet Structure 100 | 101 | The registers are all 512 bytes in size (SCSI block size), and contain a padded 102 | packet as defined by the [Shared Binary Protocol](shared-binary-protocol.md). 103 | 104 | Within the packet, the `link-control` byte is unused and always left at 105 | `0x00`. 106 | 107 | The `command-prefix` byte may have one of accepted values as defined below, but 108 | for ease of implementation, `0x03` is suggested, as the **READ PARAMETER** 109 | command will not echo the chosen prefix, but always return `0x03`. 110 | 111 | packet ; see shared-binary-protocol.md 112 | link-control = %x00 ; not used by this device 113 | command-prefix = %x03 / ; suggested 114 | %x04 / %x05 115 | ## Timestamp Format 116 | 117 | Timestamps, both for the device's clock and for the reading records, are defined 118 | as a little-endian 32-bit number, representing the number of seconds since 119 | **2000-01-01 00:00:00**. 120 | 121 | It should not be mistaken for a UNIX timestamp, although the format is 122 | compatible. To convert to UNIX timestamp, you should add `946684800` to the 123 | value (the UNIX timestamp of the device's own epoch.) 124 | 125 | ## Messages 126 | 127 | Messages are binary, and only some are related to each other in any 128 | obvious way. 129 | 130 | The commands have been named after their function, in the style of 131 | SCSI commands: 132 | 133 | * **QUERY** to retrieve information on the device (serial number, 134 | device model, etc.) 135 | * **READ PARAMETER** to retrieve parameters set for the device (time 136 | and date format, glucose unit used.) 137 | * **READ RTC** to retrieve current RTC time of the device. 138 | * **WRITE RTC** to change the RTC time fo the device. 139 | * **READ RECORD COUNT** to retrieve the number of records in the 140 | device's memory. 141 | * **READ RECORD** to retrieve the content of one record. 142 | * **ERASE MEMORY** to clear the meter altogether. 143 | 144 | ### QUERY 145 | 146 | A single message with a byte specification provides information on the 147 | hardware device. The request is sent through, and the response read 148 | from, `lba3`. 149 | 150 | QUERY-request = STX %x0a %x00 ; message length = 10 bytes 151 | %x03 %xE6 %x02 query-selector 152 | ETX checksum 153 | 154 | query-selector = query-selector-serial / 155 | query-selector-model / 156 | query-selector-software / 157 | query-selector-unknown / 158 | query-selector-date-format / 159 | query-selector-time-format / 160 | query-selector-url / 161 | query-selector-languages 162 | query-selector-serial = %x00 163 | query-selector-model = %x01 164 | query-selector-software = %x02 165 | query-selector-unknown = %x03 166 | query-selector-date-format = %x04 167 | query-selector-time-format = %x05 168 | query-selector-url = %x07 ; http://www.lifescan.co.uk 169 | query-selector-languages = %x09 170 | 171 | The reply starts with what appears an arbitrary pair of bytes, and 172 | then follows with what appears to be a UTF-16-LE string, NULL 173 | terminated (except for the `query-selector-unknown` response.) 174 | 175 | QUERY-response = STX length 176 | %x03 %x06 *WCHAR-LE %x00 %x00 177 | ETX checksum 178 | 179 | #### Languages 180 | 181 | Devices sold on multilingual markets allow the selection of the 182 | language to use through settings. The **QUERY** selector `0x09` 183 | appears to provide the list of supported languages in the device. 184 | 185 | WALPHA-UPPER = %x41-5A %x00 186 | WALPHA-LOWER = %x61-7a %x00 187 | WDIGIT = %x30-39 %x00 188 | WIDESP = SP %x00 189 | WSEMICOLON = ";" %x00 190 | WDOT = "." %x00 191 | 192 | LANGUAGES = language *(WSEMICOLON WIDESP language) 193 | language = language-code country-specifier WIDESP language-version 194 | language-code = 2WALPHA-UPPER 195 | country-specifier = WALPHA-LOWER 196 | language-version = 2WDIGIT WDOT 2WDIGIT WDOT 2WDIGIT 197 | 198 | 199 | The languages are given as a list of wide-char (little endian) 200 | specifications of languages. Each language specification includes a 201 | main language code (which appears to match ISO language codes) and 202 | some country specification: `ENu` for *English (US)* and `ENe` for 203 | *English (UK)*. 204 | 205 | 206 | #### Date and time format 207 | 208 | The device appears to provide some information on the date and time 209 | format to use for displaying date and time, although this does not 210 | match the actual format displayed on the device. 211 | 212 | The format appears to be similar to `strftime`, but it is not 213 | compatible with the POSIX interface for it. 214 | 215 | | Specifier | Meaning | 216 | | --------- | ------------------------------------- | 217 | | %I | Hour as decimal number, 24-hour clock | 218 | | %h | Hour as decimal number, 12-hour clock | 219 | | %T | Minute as decimal number | 220 | | %p | Either "AM" or "PM" | 221 | | %D | Day of the month as decimal number | 222 | | %n | Abbreviated month name | 223 | | %y | Year as decimal number | 224 | 225 | ### READ PARAMETER 226 | 227 | The meter repors a number of parameters in a similar fashion to the 228 | **QUERY** command. The request is sent through, and the response read 229 | from, `lba4`. 230 | 231 | READ-PARAMETER-request = STX %x09 %x00 ; message length = 9 bytes 232 | %x03 parameter-selector OCTET 233 | ETX checksum 234 | 235 | parameter-selector = parameter-selector-timefmt / 236 | parameter-selector-datefmt / 237 | parameter-selector-unit 238 | 239 | parameter-selector-timefmt = %x00 240 | parameter-selector-datefmt = %x02 241 | parameter-selector-unit = %x04 242 | 243 | The `OCTET` following the selector appears to be completely ignored. 244 | 245 | The response is provided in different formats, depending on the 246 | parameter requested. 247 | 248 | READ-PARAMETER-response = STX length 249 | %x03 %x06 parameter-response 250 | ETX checksum 251 | 252 | parameter-response = parameter-response-timefmt / 253 | parameter-response-datefmt / 254 | parameter-response-unit 255 | 256 | parameter-response-timefmt = *WCHAR-LE %x00 %x00 257 | parameter-response-datefmt = *WCHAR-LE %x00 %x00 258 | 259 | parameter-response-unit = parameter-unit-mgdl / parameter-unit-mmol 260 | %x00 %x00 %x00 261 | parameter-unit-mgdl = %x00 262 | parameter-unit-mmoll = %x01 263 | 264 | Time and date formats match those returned by the **QUERY** command. 265 | 266 | ### READ RTC 267 | 268 | The request to query the device time is fairly simple, and is 269 | communicated through `lba3`: 270 | 271 | READ-RTC-request = STX %x09 %x00 ; message length = 9 bytes 272 | %x03 %x20 %x02 273 | ETX checksum 274 | 275 | READ-RTC-response = STX %x0c %x00 ; message length = 12 bytes 276 | %x03 %x06 timestamp 277 | ETX checksum 278 | 279 | timestamp = 4OCTET ; 32-bit little-endian value 280 | 281 | ### WRITE RTC 282 | 283 | The **WRITE RTC** command is also communicated through `lba3`. 284 | 285 | WRITE-RTC-request = STX %x0d %x00 ; message length = 13 bytes 286 | %x03 %x20 %x01 timestamp 287 | ETX checksum 288 | 289 | WRITE-RTC-response = STX %x08 %x00 ; message length = 8 bytes 290 | %x03 %x06 291 | ETX checksum 292 | 293 | ### READ RECORD COUNT 294 | 295 | The following messages correspond to request and response for the 296 | number of records in memory. The messages are transmitted over `lba3`. 297 | 298 | READ-RECORD-COUNT-request = STX %x09 %x00 ; message length = 9 bytes 299 | %x03 %x27 %x00 300 | ETX checksum 301 | 302 | READ-RECORD-COUNT-response = STX %x0a %x00 ; message length = 10 bytes 303 | %x03 %x06 message-count 304 | ETX checksum 305 | message-count = 2OCTET ; 16-bit little-endian value 306 | 307 | ### READ RECORD 308 | 309 | The records are then accessed through indexes between 0 and 310 | `message-count` (excluded) as reported by **READ RECORD COUNT**. 311 | 312 | READ-RECORD-request = STX %x0c %x00 ; message length = 12 bytes 313 | %x03 %x31 %x02 record-number %x00 314 | ETX checksum 315 | record-number = 2OCTET ; 16-bit little-endian value 316 | 317 | The record number is assumed to be a 16-bit little endian value, as the Verio 318 | 2015 is reported to store up to 500 results. It is also consistent with 319 | the [OneTouch UltraEasy](onetouch-ultraeasy.md) protocol. 320 | 321 | Records are stored in descending time order, which means record `0` is 322 | the latest reading. 323 | 324 | READ-RECORD-response = STX %x18 %x00 ; message length = 24 bytes 325 | %x03 %x06 inverse-record-number 326 | %x00 lifetime-counter 327 | timestamp glucose-value flag-meal %x00 328 | other-flags %x0b %x00 329 | ETX checksum 330 | 331 | inverse-record-number = 2OCTET ; 16-bit little-endian value 332 | liftime-counter = 2OCTET ; 16-bit little-endian value 333 | glucose-value = 2OCTET ; 16-bit little-endian value 334 | other-flags = OCTET 335 | 336 | flag-meal = meal-none / meal-before / meal-after 337 | meal-none = %x00 338 | meal-before = %x01 339 | meal-after = %x02 340 | 341 | The inverse record number seem to provide a sequence of readings, it 342 | would be interesting to compare its value for a reader that exceeded 343 | its storage memory. 344 | 345 | A lifetime counter is also present, that will keep increasing even 346 | though the device's memory is cleared with the **ERASE MEMORY** 347 | command. The original offset of the meter is likely related to the 348 | factory calibration. 349 | 350 | The glucose value is represented as a 16-bit little endian value. It represent 351 | the blood sugar in mg/dL. As most other meters, the eventual conversion to 352 | mmol/L happens only at display time. 353 | 354 | The meal flag is a single byte, representing a tristate of no information, 355 | before meal reading, and after meal reading. This meal information cannot be set 356 | on the Verio meter, but can be set on the Select Plus. 357 | 358 | The second set of flags are not currently well understood; Verio meters allow 359 | setting comments on the readings, but these responses are not visible from the 360 | interface of the device itself; a "speech bubble" appears, steady or blinking, 361 | on some of the readings instead. The original software does not seem to expose 362 | the data correctly either. These may be used by other models such as Select 363 | Plus. 364 | 365 | At least two information are likely to be found in these flags, or in the 366 | following constant `0x0b` byte: the type of measurement (plasma v whole blood) 367 | and the measurement site (fingertip), as those are visible in the original 368 | software's UI. 369 | 370 | *Caution:* at least one byte in the record will likely represent a control 371 | solution test, rather than an actual blood glucose reading; which value is that 372 | is still unknown. 373 | 374 | ### MEMORY ERASE 375 | 376 | The memory erase command deletes all the records in the device's 377 | memory. It is communicated over `lba3`. 378 | 379 | MEMORY-ERASE-request = STX %x08 %x00 ; message length = 8 bytes 380 | %x03 %x1a 381 | ETX checksum 382 | 383 | MEMORY-ERASE-response = STX %x08 %x00 ; message length = 8 bytes 384 | %x03 %x06 385 | ETX checksum 386 | 387 | Remember that this action is irreversible. 388 | -------------------------------------------------------------------------------- /src/lifescan/onetouch-verio-iq.md: -------------------------------------------------------------------------------- 1 | 6 | 7 | # OneTouch Verio IQ 8 | 9 | Reverse engineered by [Diego Elio Pettenò](mailto:flameeyes@flameeyes.com), based 10 | on 11 | [Tidepool](https://github.com/tidepool-org/chrome-uploader/blob/master/lib/drivers/onetouch/oneTouchVerioIQ.js). 12 | 13 | The communication protocol as described in this document applies to the 14 | following models: 15 | 16 | * *OneTouch Verio IQ* 17 | 18 | ## Important device notes 19 | 20 | The device has a miniUSB-A connector, and comes with an onboard USB-to-Serial 21 | adapter compatible with the cp210x driver. 22 | 23 | ### USB IDs 24 | 25 | | Device | Vendor ID | Product ID | 26 | | --- | --- | --- | 27 | | OneTouch Verio IQ | 10c4 | 85a7 | 28 | 29 | ### Serial port configuration 30 | 31 | The serial port should be configured as such: 32 | 33 | * 8 data bits; 34 | * no parity bits; 35 | * 1 stop bit; 36 | * 38400 baud rate. 37 | 38 | ## Packet Structure 39 | 40 | The device uses the same [Shared Binary Protocol](shared-binary-protocol.md) as 41 | other LifeScan devices. 42 | 43 | Within the packet, the `link-control` byte is unused and always left at 44 | `0x00`. 45 | 46 | The `command-prefix` byte may have one of accepted values as defined below, but 47 | for ease of implementation, `0x03` is suggested. This matches 48 | the [OneTouch Verio 2015](onetouch-verio-2015.md). 49 | 50 | packet ; see shared-binary-protocol.md 51 | link-control = %x00 ; not used by this device 52 | command-prefix = %x03 / ; suggested 53 | %x04 54 | ## Timestamp Format 55 | 56 | Timestamps, both for the device's clock and for the reading records, are defined 57 | as a little-endian 32-bit number, representing the number of seconds since 58 | **2000-01-01 00:00:00**. 59 | 60 | It should not be mistaken for a UNIX timestamp, although the format is 61 | compatible. To convert to UNIX timestamp, you should add `946684800` to the 62 | value (the UNIX timestamp of the device's own epoch.) 63 | 64 | ## Messages 65 | 66 | Messages are binary, and only some are related to each other in any obvious way. 67 | 68 | The commands have been named after their function, in the style of SCSI commands 69 | (as done for the [Verio 2015](onetouch-verio-2015.md): 70 | 71 | * **READ VERSION** to read the firmware version of the device. 72 | * **READ SERIAL** to read the device serial number. 73 | * **READ RTC** to retrieve current RTC time of the device. 74 | * **WRITE RTC** to change the RTC time fo the device. 75 | * **READ UNIT** to retrieve the device blood sugar display unit. 76 | * **READ RECORD COUNT** to retrieve the number of records in the device's 77 | memory. 78 | * **READ RECORD** to retrieve the content of one record. 79 | * **ERASE MEMORY** to clear the meter altogether. 80 | 81 | ### READ VERSION 82 | 83 | READ-VERSION-request = STX %x09 %x00 ; message length = 9 bytes 84 | %x03 %x0d %x01 ETX checksum 85 | 86 | READ-VERSION-response = STX length %x00 87 | %x03 %x06 version-length 88 | [version-length]VCHAR %x00 89 | ETX checksum 90 | 91 | The version string is encoded in ASCII and prefixed with its length but also 92 | appears NULL-terminated. This may be incorrect, and it may be that the string is 93 | only prefixed, and padded to 18 characters. 94 | 95 | ### READ SERIAL 96 | 97 | READ-SERIAL-request = STX %x0a %x00 ; message length = 10 bytes 98 | %x03 %x0b %x01 %x02 ETX checksum 99 | 100 | READ-SERIAL-response = STX length %x00 101 | %x03 %x06 serial-number 102 | ETX checksum 103 | serial-number = *VCHAR %x00 104 | 105 | The serial number is encoded in ASCII and NULL-terminated. 106 | 107 | ### READ RTC 108 | 109 | READ-RTC-request = STX %x09 %x00 ; message length = 9 bytes 110 | %x03 %x20 %x02 111 | ETX checksum 112 | 113 | READ-RTC-response = STX %x0c %x00 ; message length = 12 bytes 114 | %x03 %x06 timestamp 115 | ETX checksum 116 | 117 | timestamp = 4OCTET ; 32-bit little-endian value 118 | 119 | ### WRITE RTC 120 | 121 | WRITE-RTC-request = STX %x0d %x00 ; message length = 13 bytes 122 | %x03 %x20 %x01 timestamp 123 | ETX checksum 124 | 125 | WRITE-RTC-response = STX %x08 %x00 ; message length = 8 bytes 126 | %x03 %x06 127 | ETX checksum 128 | 129 | ### READ UNIT 130 | 131 | READ-UNIT-request = STX %0a %x00 ; message length = 10 bytes 132 | %x03 %09 %02 %02 133 | ETX checksum 134 | 135 | READ-UNIT-response = STX %x0c %x00 ; message length = 12 bytes 136 | %x03 parameter-unit-mgdl / parameter-unit-mmoll 137 | %x00 %x00 %x00 138 | ETX checksum 139 | 140 | parameter-unit-mgdl = %x00 141 | parameter-unit-mmoll = %x01 142 | 143 | ### READ RECORD COUNT 144 | 145 | READ-RECORD-COUNT-request = STX %x09 %x00 ; message length = 9 bytes 146 | %x03 %x27 %x00 147 | ETX checksum 148 | 149 | READ-RECORD-COUNT-response = STX %x0a %x00 ; message length = 10 bytes 150 | %x03 %x06 message-count 151 | ETX checksum 152 | message-count = 2OCTET ; 16-bit little-endian value 153 | 154 | ### READ RECORD 155 | 156 | The records are then accessed through indexes between 0 and `message-count` 157 | (excluded) as reported by **READ RECORD COUNT**. 158 | 159 | READ-RECORD-request = STX %x0a %x00 ; message length = 10 bytes 160 | %x03 %x21 record-number 161 | ETX checksum 162 | record-number = 2OCTET ; 16-bit little-endian value 163 | 164 | The record number is assumed to be a 16-bit little endian value, for consistency 165 | with other LifeScan devices. 166 | 167 | READ-RECORD-response = STX %x12 %x00 ; message length = 18 bytes 168 | %x03 %x06 timestamp glucose-value 169 | control-flag flag-meal 170 | %x00 %x00 171 | ETX checksum 172 | 173 | glucose-value = 2OCTET ; 16-bit little-endian value 174 | 175 | control-flag = not-control / control 176 | not-control = %x00 177 | control = %x01 178 | 179 | flag-meal = meal-none / meal-before / meal-after 180 | meal-none = %x00 181 | meal-before = %x01 182 | meal-after = %x02 183 | 184 | The `glucose-value` is represented as a 16-bit little endian value. It represent 185 | the blood sugar in mg/dL. As most other meters, the eventual conversion to 186 | mmol/L happens only at display time. 187 | 188 | The `control-flag` is a byte representation of a boolean. If true, the record 189 | refers to a control solution test, rather than a blood measurement. 190 | 191 | The `meal-flag` is a single byte, representing a tristate of no information, 192 | before meal reading, and after meal reading. This meal information cannot be set 193 | on the Verio meter, but can be set on the Select Plus. 194 | 195 | ### MEMORY ERASE 196 | 197 | The memory erase command deletes all the records in the device's 198 | memory. 199 | 200 | MEMORY-ERASE-request = STX %x08 %x00 ; message length = 8 bytes 201 | %x03 %x1a 202 | ETX checksum 203 | 204 | MEMORY-ERASE-response = STX %x08 %x00 ; message length = 8 bytes 205 | %x03 %x06 206 | ETX checksum 207 | 208 | Remember that this action is irreversible. 209 | -------------------------------------------------------------------------------- /src/lifescan/shared-binary-protocol.md: -------------------------------------------------------------------------------- 1 | 6 | 7 | # LifeScan Shared Binary Protocol 8 | 9 | Multiple LifeScan devices of the OneTouch family share a common packet framing 10 | protocol, clearly designed for serial communication but used over different 11 | transmission protocols as well. 12 | 13 | While commands within the protocol are specific to the model, the framing is 14 | vastly similar if not identical. 15 | 16 | packet = STX length link-control command_prefix message ETX checksum 17 | STX = %x02 18 | length = OCTET 19 | link-control = OCTET 20 | message = [length - 6]OCTET 21 | ETX = %x03 22 | checksum = 2OCTET ; 16-bit little-endian value 23 | 24 | The packets are variable length, with the length provided by the byte following 25 | the `STX` constant. This length is inclusive of the whole packet framing. The 26 | message itself is 6 bytes short of this value. 27 | 28 | The `STX` and `ETX` constants mark start and end of the message and correspond 29 | to the ASCII characters bearing the same names. 30 | 31 | The `link-control` byte is only used by some devices, and for others is 32 | maintained to a constant `0x00`. 33 | 34 | The `checksum` is a variant of CRC-16-CCITT, seeded at `0xFFFF`, and stored 35 | little-endian. 36 | 37 | ## Link Control 38 | 39 | The `link-control` byte is known used only in 40 | the [OneTouch Ultra Easy](onetouch-ultraeasy.md) protocol, which contains a 41 | description of the field. As no other meter uses this byte, its documentation is 42 | left to the LifeScan provided specifications. 43 | 44 | ## Command Prefix 45 | 46 | For packet that includes non-zero length messages, the message itself can be 47 | defined as 48 | 49 | message = command-prefix *OCTET 50 | command-prefix = OCTET 51 | 52 | The command prefix is device-specific, and is present both in the requests sent 53 | and the responses received. 54 | 55 | Some devices allow more than one prefix to be used, although not in the same 56 | session. If multiple prefixes are legal, the responses will echo back the 57 | command prefix of their request. 58 | 59 | Exceptions (likely bugs) exists where this guarantee is not maintained, check 60 | device-specific documentation. 61 | 62 | ## Command Success 63 | 64 | With the exception of a few device-specific control packets, all commands sent 65 | to the device receive a response in the same packet format. This extends the 66 | format a response to: 67 | 68 | response = command-prefix status *OCTET 69 | command-prefix = OCTET ; as provided in the request 70 | status = success / error 71 | success = %x06 72 | error = %x09 / OCTET ; only some errors are identified 73 | 74 | Whether data follows a non-success `status` is device specific. Data should not 75 | be considered a valid response if the `status` is not `success`. 76 | -------------------------------------------------------------------------------- /src/menarini/glucomen-areo.md: -------------------------------------------------------------------------------- 1 | 6 | 7 | # GlucoMen Areo 8 | 9 | Reverse engineered by [Diego Elio Pettenò](mailto:flameeyes@flameeyes.com). 10 | 11 | ## Cable 12 | 13 | The data cable provided for the device is an USB Serial adapter based on Silicon Laboratories CP210x chipset. 14 | 15 | It appears to be a fairly standard USB-to-TRS serial adapter, though the 16 | connector is a subminiature (2.5mm connector): 17 | 18 | | Connector | Meaning | 19 | | --- | --- | 20 | | Tip | Host-to-Device | 21 | | Ring | Device-to-Host | 22 | | Sleeve | GND | 23 | 24 | ### USB IDs 25 | 26 | | Device | Vendor ID | Product ID | 27 | | --- | --- | --- | 28 | | GlucoMen Areo Cable | 10c4 | ea60 | 29 | 30 | ## Protocol 31 | 32 | The communication happens over a serial protocol, mixing text-based and byte-based commands. 33 | 34 | ### Serial port configuration 35 | 36 | The serial port should be configured as such: 37 | 38 | * 8 data bits; 39 | * odd parity; 40 | * 1 stop bit; 41 | * 9600 baud rate. 42 | 43 | ### Request and Response Structure 44 | 45 | Commands are sent from the host to the device with either a single byte, or with two command bytes 46 | followed by text parameters. Responses from the device are either in text format, or a single byte 47 | response (if the request had text parameters). 48 | 49 | There are very few known commands that can be represented as such: 50 | 51 | request = get-info-command / get-readings-command / set-datetime-command 52 | response = text-parameters / no-readings / simple-response 53 | 54 | get-info-command = %xA2 55 | get-readings-command = %x80 56 | set-datetime-command = %xC2 %xA1 text-parameters 57 | 58 | simple-response = F / P 59 | no-readings = "[" CRLF %x90 %x3D CRLF "]" CRLF 60 | text-parameters = "[" CRLF *response-line checksum CRLF "]" CRLF 61 | 62 | response-line = 1*VCHAR CRLF 63 | checksum = 2HEXDIG 64 | 65 | ### Checksum 66 | 67 | The checksum is calculated according to the CRC-8/Maxim algorithm, applied on the text parameters 68 | starting from the opening square bracket (`[`) up until and including the `CRLF` preceding the checksum itself. 69 | 70 | It is represented as two **upper case** hexadecimal digits. The device will refuse a command sent 71 | with a lower-case checksum even if correct. 72 | 73 | ### `GET INFO` 74 | 75 | The `GET INFO` command receives a text response consisting of a single line, comma-separated: 76 | 77 | get-info-response = *DIGIT "," *DIGIT "," *DIGIT "," serial-number "," sw-version CRLF 78 | serial-number = *SP 1*VCHAR 79 | sw-version = *SP 1*VCHAR 80 | 81 | The first three values are unknown at the time of writing, while the serial number and software 82 | versions may have leading spaces, and are otherwise printable characters. 83 | 84 | ### Setting Date time 85 | 86 | To set the date and time of the device, a single command can be sent, followed by the text 87 | parameters in the same format as returned by the device. 88 | 89 | Note: the checksum has to be in upper case to be accepted by the device. 90 | 91 | set-datetime-command = %xC2 %xA1 "[" CRLF datetime checksum CRLF "]" CRLF 92 | datetime = year month day hour minute 93 | year = 2DIGIT 94 | month = 2DIGIT 95 | day = 2DIGIT 96 | hour = 2DIGIT 97 | minute = 2DIGIT 98 | 99 | ### Readings 100 | 101 | The `GET READING` command receives either a response informing that there are no readings on the 102 | device or one reading per line in the text format with comma-separated values. 103 | 104 | no-readings = "[" CRLF %x90 %x3D CRLF "]" CRLF 105 | 106 | reading-response-line = reading-type "," value "," unit "," markings "," date "," time CRLF 107 | reading-type = "Glu" / 1*VCHAR 108 | value = 1*DIGIT *1("." DIGIT) 109 | unit = "mmol/L" / 1*VCHAR 110 | markings = no-marking / check-mark / before-meal / after-meal / exercise 111 | date = year month day 112 | time = hour minute 113 | 114 | no-marking = "00" 115 | check-mark = "01" 116 | before-meal = "02" 117 | after-meal = "04" 118 | exercise = "08" 119 | 120 | year = 2DIGIT 121 | month = 2DIGIT 122 | day = 2DIGIT 123 | hour = 2DIGIT 124 | minute = 2DIGIT 125 | 126 | It's important to note that the readings are expressed in the native unite of the device and not, 127 | like in most other meters, in mg/dL even for mmol/L devices. This means you need to check the 128 | unit that is used in the same reading itself. 129 | 130 | The markings values appear to correspond to values in a bitmask but they cannot be applied 131 | simultaneously, so they should be considered as different enumeration values. 132 | -------------------------------------------------------------------------------- /src/sanofi/bgstar-mystar.md: -------------------------------------------------------------------------------- 1 | 6 | 7 | # Sanofi BGStar and Mystar Extra 8 | 9 | Reverse Engineered by Noury (@nbenm) 10 | 11 | ## Important device notes 12 | 13 | This protocol is used in the following devices: 14 | 15 | * BGStar 16 | * MyStar Extra 17 | * Other devices exist but have not been tested 18 | 19 | ## Cable 20 | 21 | These devices connect to a computer with a USB to RS232 cable. 22 | 23 | Sanofi provides for free this cable. 24 | It contains a CP210x component, and uses a VCP CP210x driver. 25 | This cable is known as Zero-click cable. 26 | 27 | With linux cp210x and usbserial modules are loaded. 28 | A device is created in /dev/ttyUSBx 29 | With MacOs it uses Mac VCP Driver (CP210x) from Silicon Labs. 30 | a device is created in /dev/cu.SLAB_USBtoUART 31 | I have asked them in 2016 to add the vendor id/product id, and they did it. 32 | 33 | ## Protocol 34 | 35 | ### Serial port configuration 36 | 37 | The serial port should be configured as such: 38 | 39 | * 8 data bits; 40 | * no parity bits; 41 | * 1 stop bit; 42 | * 115200 baud rate. 43 | 44 | ### Messages and commands 45 | 46 | All commands (requests) must end with a carriage return. 47 | 48 | In all results, leading zeros are removed. 49 | 50 | Message status is reported with HTTP-style status codes. 51 | 52 | continue = "100" 53 | ok = "200" 54 | 55 | ## Hello command 56 | 57 | first-command = "hello" CR 58 | 59 | first-response = ok SP "hello" SP name 60 | name = 4ALPHA "-" 2ALPHA 61 | 62 | ## Get Serial command 63 | 64 | get-serial-cmd = "get serial" CR 65 | get-serial-response = ok SP "serial" SP serial 66 | serial = 14( ALPHA / DIGIT ) 67 | 68 | ## Get date and time 69 | 70 | get-datetime-cmd = "get datetime" CR 71 | get-datetime-response = ok SP datetime 72 | 73 | datetime = year SP month SP day SP 74 | hour SP minutes SP seconds 75 | year = 4DIGIT 76 | day = 1*2DIGIT 77 | hour = 1*2DIGIT 78 | minute = 1*2DIGIT 79 | second = 1*2DIGIT 80 | 81 | ## Set date and time 82 | 83 | TODO: confirm the correct command. 84 | 85 | ## Get number of results 86 | 87 | get-glucount-cmd = "get glucount" CR 88 | get-glucount-response = ok SP "glucount" 1*4DIGIT 89 | 90 | ## Get single result 91 | 92 | Result ID is in reverse time order, 0 is most recent. 93 | 94 | get-glurec-cmd = "get glurec" SP glurec-id CR 95 | glurec-id = 1*4DIGIT 96 | 97 | get-glurec-response = ok SP "glurec" SP record 98 | record = 1DIGIT 1DIGIT value flag-meal datetime 99 | value = 1*3DIGIT 100 | 101 | flag-meal = no-meal / 102 | before-breakfast / after-breakfast / 103 | before-lunch / after-lunch / 104 | before-dinner / after-dinner 105 | no-meal = "0" 106 | before-breakfast = "1" 107 | after-breakfast = "2" 108 | before-lunch = "3" 109 | after-lunch = "4" 110 | before-dinner = "5" 111 | after-dinner = "6" 112 | 113 | If there was an error when the measure was taken, response begins with E. 114 | Unfortunately, I can't reproduce this to have the full error message. But it is 115 | sure that fifth field begins with an E (fields are separated by spaces) 116 | 117 | In the meter I have used, value is in mg/dL 118 | 119 | The maximum number of results is 1865. 120 | After that oldest result is replaced. 121 | 122 | To be checked: after that which number is used for a new result? 123 | 124 | ## Get System Info 125 | 126 | TODO: confirm whether lines end with CR or CRLF. 127 | 128 | get-sysinfo-cmd = "get sysinfo all" CR 129 | get-sysinfo-response = 1*sysinfo-line 130 | ok SP "sysinfo all" 131 | sysinfo-line = continue SP sysinfo-key SP sysinfo-value CR 132 | sysinfo-key = "model" / "product" / "comm" / "commaster" / 133 | "co" / "firmware" / "calcode" / "compiler" / 134 | "compiletime" / "deviceid" / "cpu" / 1*ALPHA 135 | sysinfo-value = 1*VCHAR 136 | 137 | ## Get Glucose Units: 138 | 139 | get-glucose-unit-cmd = "get gluunit" CR 140 | get-glucose-unit-response = ok SP "gluunit" SP unit 141 | unit = "mg/dL" / 1*VCHAR 142 | 143 | TODO: confirm the unit for mmol/L devices. 144 | -------------------------------------------------------------------------------- /src/sd-biosensor/codefree.md: -------------------------------------------------------------------------------- 1 | 6 | 7 | # SD Codefree 8 | 9 | Reverse engineered by [Diego Elio Pettenò](mailto:flameeyes@flameeyes.com). 10 | 11 | ## Cable 12 | 13 | The data cable that you can buy together with the device is an USB Serial 14 | adapter, based on Silicon Laboratories CP210x chipset. 15 | 16 | It appears to be a fairly standard USB-to-TRS serial adapter, though the 17 | connector is a subminiature (2.5mm connector): 18 | 19 | | Connector | Meaning | 20 | | --- | --- | 21 | | Tip | Device-to-Host | 22 | | Ring | Host-to-Device | 23 | | Sleeve | GND | 24 | 25 | ### USB IDs 26 | 27 | | Device | Vendor ID | Product ID | 28 | | --- | --- | --- | 29 | | SDCodefree Cable | 10c4 | ea60 | 30 | 31 | ## Protocol 32 | 33 | The communication happens over a serial binary protocol. The device initiates the 34 | connection once turned on, and the computer needs to respond to the opening 35 | challenge and follow up packets from the device with either commands or 36 | acknowledgments. 37 | 38 | If the device receives an invalid command, it reports `E-5` on the display and 39 | needs to be turned off. 40 | 41 | ### Serial port configuration 42 | 43 | The serial port should be configured as such: 44 | 45 | * 8 data bits; 46 | * no parity bits; 47 | * 1 stop bit; 48 | * 38400 baud rate. 49 | 50 | ### Packet structure 51 | 52 | Packets follow a simple format: 53 | 54 | packet = STX direction length message checksum ETX 55 | STX = %x53 56 | 57 | direction = direction-in / direction-out 58 | direction-in = %x20 59 | direction-out = %x10 60 | 61 | length = OCTET 62 | message = [length-3]OCTET 63 | checksum = OCTET 64 | ETX = %xAA 65 | 66 | The packets are variable length, with the following length provided in the third 67 | byte of the packets (length does not include the three bytes up to that point, 68 | but does include checksum and ETX). The second byte is a direction indication 69 | (device-to-host and host-to-device). 70 | 71 | The second to last byte is a checksum calculated as an 8-bit bitwise xor of the 72 | `message` bytes. 73 | 74 | ### Protocol initialization 75 | 76 | When the device is turned on it sends the following packet on the wire: 77 | 78 | challenge = STX direction-in %x04 %x10 %x30 checksum ETX 79 | 80 | Sometimes a leading null byte might be read from the message, unclear if this is 81 | due to the USB adapter, a bug in the driver or the device. 82 | 83 | If the device is not given a response within time, it ignores the cable. The 84 | expected response is: 85 | 86 | response = STX direction-out %x04 %x10 %x40 checksum ETX 87 | 88 | Following the response, the device will send a packet that is composed mostly of 89 | `0xAA` values, which include the count of readings in the device: 90 | 91 | count-packet = STX direction-in %x18 %x30 readings-count [19]%xAA checksum ETX 92 | 93 | readings-count = 2 OCTET ; 16-bit big-endian value 94 | 95 | The count of reading is assumed to be 16-bit because the manual references a 96 | memory of 1000 readings. 97 | 98 | ### Setting date and time 99 | 100 | The only parameter that can be tweaked on the device appears to be the date and 101 | time. 102 | 103 | This is done through what appears like a text command sent over the binary 104 | protocol. 105 | 106 | The packet need to be sent right after initialization and is acknowledge by the 107 | meter. 108 | 109 | set-time-packet = STX direction-out %x13 110 | 'ADATE' set-year set-month set-day 111 | set-hour set-minute checksum ETX 112 | set-year = 4DIGIT 113 | set-month = 2DIGIT 114 | set-day = 2DIGIT 115 | set-hour = 2DIGIT 116 | set-minute = 2DIGIT 117 | 118 | set-time-ack-packet = STX direction-in %x04 %x10 %x10 checksum ETX 119 | 120 | Note that while the date is set with a full four-digits year, the device will 121 | ignore the first two digits — 1999, 2099 and 2199 appear as exactly the same 122 | value internally. 123 | 124 | After receiving the acknwoeldgement, the device need to be told to disconnect, 125 | as otherwise it'll be stuck in PC connection mode. This can be done with the 126 | same packet used to fetch readings (see later in this document). 127 | 128 | disconnect-packet = STX direction-out %x04 %x10 %x60 checksum ETX 129 | disconnect-ack-packet = STX direction-in %x04 %x10 %x70 checksum ETX 130 | 131 | ### Dumping the readings history 132 | 133 | Alternatively from setting the date, it is possible to dump the records from the 134 | device. The readings will be returned in inverse order of them being taken, one 135 | for each fetch packet: 136 | 137 | fetch-packet = STX direction-out %x04 %x10 %x60 checksum ETX 138 | reading-packet = STX direction-in %x20 %x13 OCTET year month day 139 | hour minute value flag-meal 7OCTET checksum ETX 140 | year = OCTET 141 | month = OCTET 142 | day = OCTET 143 | hour = OCTET 144 | minute = OCTET 145 | value = 2OCTET ; 16-bit big-endian value 146 | 147 | flag-meal = no-meal / before-meal / after-meal 148 | no-meal = %x00 149 | before-meal = %x10 150 | after-meal = %x20 151 | 152 | The last seven bytes of the message are not understood yet, they seem to change 153 | independently from any settings on the device or on the reading itself, but they 154 | also don't change enough to look like a checksum of any kind. 155 | 156 | After the last reading is provided, a further fetch causes a disconnection. 157 | -------------------------------------------------------------------------------- /src/taidoc/td42xx.md: -------------------------------------------------------------------------------- 1 | 6 | 7 | # TaiDoc TD-42xx 8 | 9 | Reverse engineered by [Diego Elio Pettenò](mailto:flameeyes@flameeyes.com). With 10 | thanks to Gianni Ceccarelli for the time fields structure. 11 | 12 | The protocol is compatible with both TD-4277 and TD-4235B devices at least. 13 | 14 | These devices are marketed as: 15 | 16 | * GlucoRx Nexus 17 | * GlucoRx NexusQ 18 | * Menarini GlucoMen Nexus 19 | * Aktivmed GlucoCheck XL 20 | 21 | ## Important device notes 22 | 23 | The device has a miniUSB-A connector and comes with an onboard HID-to-Serial 24 | adapter, based on the Silicon Labs cp2110 interface. 25 | 26 | ### USB IDs 27 | 28 | | Device | Vendor ID | Product ID | 29 | | --- | --- | --- | 30 | | GlucoRx Nexus | 10c4 | ea80 | 31 | | GlucoRx NexusQ | 10c4 | ea80 | 32 | 33 | ### Serial port configuration 34 | 35 | The CP2110 bridge should be configured as follows: 36 | 37 | * 8 data bits; 38 | * no parity bits; 39 | * 1 stop bit; 40 | * 19200 baud rate. 41 | 42 | ### Supported Features 43 | 44 | The meter hardware supports: 45 | 46 | * Factory-fixed mg/dL or mmol/L *user* reported unit. Values are always 47 | returned by the protocol in mg/dL. 48 | * Meal flags (none, pre-meal, post-meal). 49 | * Sound and reminder alarms. 50 | 51 | ## Protocol 52 | 53 | ### Packet Structure 54 | 55 | The device uses a simple challenge and response serial protocol with fixed-size 56 | 8-bytes commands and responses. 57 | 58 | packet = STX command-id message direction checksum 59 | STX = %x51 60 | 61 | command-id = OCTET 62 | message = 4OCTET 63 | empty-message = %x00 %x00 %x00 %x00 64 | 65 | direction = direction-in / direction-out 66 | direction-in = %xA5 67 | direction-out = %xA3 68 | 69 | checksum = OCTET 70 | 71 | The checksum is calculated as a full sum of the first seven bytes of the packet, 72 | and then truncated to 8-bit. 73 | 74 | ### Connection 75 | 76 | Connection is established by sending a connection command, and receiving a 77 | response. 78 | 79 | message-connect = %x00 80 | command-connect = %x22 81 | response-connect = %x22 / %x24 / %x54 82 | 83 | In both the request and long response packets, the message is zero. 84 | 85 | ### Get Model 86 | 87 | To confirm the model of the device (probably to avoid confusing with other 88 | devices sharing a similar protocol), you can send command `0x24`. 89 | 90 | model-request = STX %x24 empty-message direction-out checksum 91 | model-response = STX %x24 model OCTET OCTET direction-in checksum 92 | 93 | model = OCTET %x42 ; 16-bit little-endian value 94 | 95 | The model will be reported as a 16-bit little-endian BCD value. 96 | 97 | ### Date and Time 98 | 99 | #### Format 100 | 101 | All representation of time for this protocol are idential, and they follow this 102 | format: 103 | 104 | datetime = day minute hour 105 | day = 2OCTET ; 16-bit little endian value. 106 | minute = OCTET 107 | hour = OCTET 108 | 109 | While minutes and hours are left unpacked, the `day` field packs the full year, 110 | month and day into a single 16-bit integer. 111 | 112 | Within the 16-bit `day` field, the first 7 bits represent the year, starting 113 | with 2000, followed by 4 bits for the month (range 1-12), and 5 bits for the day 114 | (range 1-31). 115 | 116 | #### Getting Time 117 | 118 | To retrieve the time of the device, you send the command `0x23` with a zero 119 | message, and parse the returned message as the date and time. 120 | 121 | gettime-request = STX %x23 empty-message direction-out checksum 122 | gettime-response = STX %x23 datetime direction-in checksum 123 | 124 | #### Setting Time 125 | 126 | To set the time of the device, you send the command `0x33` with the time as 127 | message. 128 | 129 | settime-request = STX %x33 datetime direction-out checksum 130 | gettime-response = STX %x33 datetime direction-in checksum 131 | 132 | ### Reading Records 133 | 134 | To retrieve the records from the device, you need to first request the number of 135 | records, and then retrieve the timestamp and the value and flags for each 136 | record. 137 | 138 | Record count and record index are 16-bit unsigned integers, little-endian, and 139 | are 0-indexed, with the most recent result first. 140 | 141 | record-id = 2OCTET ; 16-bit little-endian value 142 | 143 | #### Record Count 144 | 145 | To retrieve the record count, send command `0x2B`. 146 | 147 | recordcount-request = STX %x2B empty-message direction-out checksum 148 | recordcount-response STX %x2B record-count unknown-value direction-in checksum 149 | 150 | record-count = 2OCTET ; 16-bit little-endian value 151 | unknown-value = 2OCTET ; likely 16-bit little-endian value 152 | 153 | The `unknown-value` is unknown but appears to be bound to the record-count. For 154 | a new meter with a record count of 0 (or a cleared meter), the unknown value is 155 | always `0xFFFF`. 156 | 157 | #### Record Timestamp 158 | 159 | To retrieve each record timestamp, send command `0x25`. 160 | 161 | record-timestamp-request = STX %x25 162 | record-id %x00 %x00 direction-out checksum 163 | record-timestamp-response = STX %x25 datetime direction-in checksum 164 | 165 | #### Record Value 166 | 167 | To retrieve each record value, send command `0x26`. 168 | 169 | record-value-request = STX %x26 record-id %x00 %x00 direction-out checksum 170 | record-value-response = STX %x26 171 | glucose-value unknown meal-flag direction-in checksum 172 | 173 | glucose-value = 2OCTET ; 16-bit little-endian value 174 | unknown = OCTET 175 | meal-flag = meal-none / meal-before / meal-after 176 | meal-none = %x00 177 | meal-before = %x40 178 | meal-after = %x80 179 | 180 | ### Clearing Memory 181 | 182 | To completely clear the memory of the device, send command `0x52`. 183 | 184 | clear-memory = STX %x52 empty-message direction-out checksum 185 | --------------------------------------------------------------------------------