telemetry documentation

Telemetry DocumentationRelease 0

Michael Bryan

January 08, 2016

Contents

1 CMT_Telemetry 31.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Building Documentation and Running Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Project Development Methodology 52.1 What Is Agile? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Project Specification 73.1 v0.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4 Software - Hardware Interface 11

5 Testing and Code Coverage 135.1 Running tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135.2 Code Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145.3 My .coveragerc File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

6 Build Process 176.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176.2 The Build Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

7 telemetry package 217.1 Submodules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217.2 Main Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

8 To-Do List 238.1 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238.2 Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

9 Contributing 259.1 Package Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259.2 Version Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259.3 Doing Stuff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

10 License 31

11 Indices and tables 33

Python Module Index 35

i

Telemetry Documentation, Release 0

Contents:

Contents 1


2 Contents

CHAPTER 1

CMT_Telemetry

1.1 Description

A telemetry project for the Curtin Motorsport Team.

This project aims to create a system that will send live data from the racecar to an engineer in the pits. Allowing themto monitor the car in real time, helping to diagnose and predict issues much faster and with much more accuracy thanthe current system..

[Car drives past billowing smoke]Person 1: [sniff sniff] Do you smell that?Person 2: Mmm, smells funny. If only there was a way we could find out what's

going on...

For more information on how to use the project or how it works, consult the accompanying documentation in./docs/ or at ReadTheDocs.

1.2 Building Documentation and Running Tests

You should be able to run build all the documentation and run all unit tests, as well as coverage.py by using a simplehelper script in the project root directory:

./test_and_build_docs.sh

Coverage reports are at ./coverage_html_report/index.html

1.3 Requirements

alabaster==0.7.7Babel==2.1.1docutils==0.12Jinja2==2.8MarkupSafe==0.23Pygments==2.0.2pyserial==2.7pytz==2015.7six==1.10.0snowballstemmer==1.2.1Sphinx==1.3.3

3

http://telemetry.readthedocs.org/en/latest/


sphinx-rtd-theme==0.1.9wheel==0.24.0

4 Chapter 1. CMT_Telemetry

CHAPTER 2

Project Development Methodology

This project will be done using the Agile development methodology, because it is a quick, lightweight developmentmethodology which gets you to constantly re-evaluate your functional requirements and your product on a regularbasis.

As a small, one-man project where there’s a good chance that the desired features will change several times during theproduction cycle, Agile is a much more sensible design methodology than the usual PP-CD-DD-Manufacture designcycle that CMT employs.

Note: For any non-trivial project, it’s impossible to imagine the perfect design for something, see every detail, andforesee and account for every technical challenge or situation that might occur along the way.

2.1 What Is Agile?

Agile development methodology provides opportunities to assess the direction of a project throughout the developmentlifecycle. This is achieved through regular cadences of work, known as sprints or iterations, at the end of which teamsmust present a potentially shippable product increment. By focusing on the repetition of abbreviated work cycles aswell as the functional product they yield, agile methodology is described as “iterative” and “incremental.” In waterfall,development teams only have one chance to get each aspect of a project right. In an agile paradigm, every aspect ofdevelopment — requirements, design, etc. — is continually revisited throughout the lifecycle. When a team stops andre-evaluates the direction of a project every couple weeks, there’s always time to steer it in another direction.

Basically it’s a bunch of work cycles, where a work cycle will consist of:

1. Do some work and present a potentially shippable product

2. Re-evaluate the direction of the project and it’s requirements

3. Go back to step 1

2.1.1 Principles of Agile

The Agile Manifesto is based on twelve principles:

1. Customer satisfaction by early and continuous delivery of valuable software

2. Welcome changing requirements, even in late development

3. Working software is delivered frequently (weeks rather than months)

4. Close, daily cooperation between business people and developers

5

http://agilemethodology.org/


5. Projects are built around motivated individuals, who should be trusted

6. Face-to-face conversation is the best form of communication (co-location)

7. Working software is the principal measure of progress

8. Sustainable development, able to maintain a constant pace

9. Continuous attention to technical excellence and good design

10. Simplicity—the art of maximizing the amount of work not done—is essential

11. Self-organizing teams

12. Regular adaptation to changing circumstance

6 Chapter 2. Project Development Methodology

CHAPTER 3

Project Specification

Okay, now that people have an overview of how Agile works, here’s an initial specification of what we want from thisproject.

Important: Avoid wank! Write dot points, be very specific about what you do or don’t want. Because this page willbe edited often make sure everything is as concise as possible.

Note: A quote to remember when people want massive spec documents from you...I found the people insisting on extensive requirements documents before starting any design were really ‘blockers‘Just trying to slow the process down (and usually peopie with nothing to contribute on design or innovative thinking).

All our best work was done with a few concepts in our heads about improving a site, doing a quick prototype (static),changing the design a bit and then building a live prototype with real data. After kicking the tires on this prototype,we usually had a real project in motion and good results.

- Mark Gallagher, Corporate intranet developer (from Signal vs. Noise)

At the end of each work cycle, the design requirements will be re-evaluated and each version appended to the top ofthe list below (versions are incremented).

Use the following template (raw rst) to write your specs. Anything in square brackets is a directive to the writer.

Version Number==============Cycle start date: [insert here]Cycle end date: [insert here]

Overall Project---------------

[A quick 1-2 line description of the project]

Must Include------------

[broken up according to some logical sectioning]

* [feature 1]

* [feature 2]

* etc

Nice to Have but not Essential------------------------------

7


(in order of preference)

* [feature 1]

* [feature 2]

* etc

3.1 v0.0

Cycle start date: N/A (initial specifications) Cycle end date: N/A initial specifications)

3.1.1 Overall Project

A telemetry system that receives data via a serial port and will display it in a GUI for a user to monitor the CMT carwhile it is driving.

3.1.2 Must Include

Back-End

• Receive data via a user defined serial connection.

• Read the data packet and parse it according to a pre-defined format, returning the parsed data.

• The parsed data must specify:

– CAN node ID

– Values delivered

– Timecode for when the data packet was received

• Must be able to read data from multiple CAN nodes (without mixing them up).

• Specify a name that corresponds to a particular CAN node in an external file.

Front-End

• Display continually updating graphs of the received data.

• Let the user know if packets are being received.

• GUI should look and react fairly similarly to the current data logger GUI.

3.1.3 Nice to Have but not Essential

Back-End

• A configuration file for custom setup of the overall program.

– INI format using configparser

• Save parsed data to a database. (should be trivial)

8 Chapter 3. Project Specification

https://docs.python.org/3.5/library/configparser.html#supported-ini-file-structure


Front-End

• Export as CSV.

• Tell the user how many packets were received in the last (for example) 10 seconds.

• Alerts for when something if wrong.

• A settings menu.

• Adjustable refresh rate.

• Hosting on a web server. (big feature!)

3.1. v0.0 9


10 Chapter 3. Project Specification

CHAPTER 4

Software - Hardware Interface

The software side of the telemetry project only has to worry about receiving data packets via a serial port, and thenpresenting the data to the user in a logical way.

The data packets will be composed of the following:

Section Description Size (bytes)

HeaderStart Bytes (“CMT”) 3CAN node ID 2Data length (bytes) 1

Payload Data values for that sensor variable (around 1-8)Tail End of message (<CR>) 1

We have chosen not to add a checksum byte because you’ve already got the data length byte, but it would be trivial toinsert it as part of the tail or header sections.

11


12 Chapter 4. Software - Hardware Interface

CHAPTER 5

Testing and Code Coverage

“Code without tests is broken by design.” - Jacob (core contributor at Django)

Providing automated tests for your code is a way to repeatedly ensure, with minimal developer effort, that the codeyou wrote to handle a task works as advertised. Think of tests as your insurance policy. They generally keep you frombreaking existing code & looking foolish to other people. They’re also concrete proof that the code works correctly.Without that proof, what you have is a pile of code that worked right once on your machine & that you’ll either haveto hand-test again & again in the future or will break without you knowing any wiser.

Use the following guidlines:

• Write something then immediately run the tests. If something is broken, fix it before moving on.

• Don’t get lazy with writing tests. You’ll regret it later on.

• Make small methods, the bigger it is the harder it is to write tests for.

• A good way to construct tests is like this:

1. Make some dummy input and the the expected output (i.e. a should_be variable).

2. Run your code with the dummy input.

3. Check that it raises an error, gives you the expected output or whatever else the test is meant to test.

• Give the test a detailed docstring specifying exactly what it should do.

• Informative method names are good. If it’s a bit long then that’s fine.

• Test method names should start with “test_”.

• Only test one thing per test.

• One test file per source file.

• All test files should start with “test_”.

• All tests should be in the telemetry/tests directory.

• Use the output from coverage.py to tell you whether you are missing sections of code or code branches whenrunning your tests.

5.1 Running tests

To run all tests use the command

13


python manage.py test

To run a particular app, use the command

python manage.py test [app_name]

5.2 Code Coverage

It’s important to test all your code. Code coverage is frequently used as a measuring stick for a developer’s success increating quality tests. The basic rule of thumb is comprehensive tests should execute every line of code.

Coverage , a tool that measures code coverage for Python code, will be used to check what percentage of the tutorialcode is being tested.

Note: Install coverage with pip install coverage

To use coverage, run it from the command line

coverage run --include='./*' manage.py test

To ensure that each code branch is taken (if statements etc) then you can add the --branch switch

coverage run --include='./*' --branch manage.py test

To review the results you can either look at a brief report with

coverage report

Or coverage can make pretty html files for you so you can see exactly what lines need to be tested in each python file

coverage html

Coverage allows us to specify a configuration file (.coveragerc files) to specify default coverage attributes. The docu-mentation explains how .coveragerc works.

Let’s add a .coveragerc file to our project that looks like this:

[run]include = ./*branch = True

Now we can run coverage without any extra arguments:

coverage run manage.py test

Important: Run tests and check coverage often to make sure something you’ve done hasn’t broken the site!

Note: A useful command to run all tests and check coverage in one hit is:

coverage run manage.py test && coverage html

Although with the ./test_and_build_docs.sh script, doing this manually is no longer necessary :)

14 Chapter 5. Testing and Code Coverage

http://coverage.readthedocs.org/en/latest/

http://nedbatchelder.com/code/coverage/config.html


5.3 My .coveragerc File

# .coveragerc file to control coverage.py[run]branch = Trueomit = ./tests/*

[html]directory = coverage_html_report

5.3. My .coveragerc File 15


16 Chapter 5. Testing and Code Coverage

CHAPTER 6

Build Process

A build script was created to facilitate doing all the monotonous, yet important tasks required to update the project.This includes:

• Running all unit tests

• Checking code coverage and generating a report

• Building the documentation

• Optionally opening the coverage report or documentation up in your browser

6.1 Usage

Usage is as follows:

Usage: ./build.sh [-c] [-d]

-h|--help Display this help message-c|--coverage Open up the coverage report after doing the build-d|--docs Open up the docs home page after doing the build

This means you can run the script without any arguments, in which case it will just run tests, build docs and do codecoverage. However if you add the -d switch, it will open the documentation up in your browser. Adding the -c switchwill open the coverage report up in your browser. You can use the switch’s long version if you wish.

6.2 The Build Script

The script itself is fairly easy to understand. Even if you don’t understand bash very well, by reading the comments(lines that start with a “#”) and echo statements you should be able to get a good idea of what’s going on.

The script itself is included below:

1 #!/bin/bash2 # A build script for the telemetry project.3 #4 # Use this to run unittests, code coverage, and build the documentation5 # in one hit.6

7 BASEDIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"8

17


9 # Define the usage10 usage(){11 echo "Usage: $0 [-c] [-d]"12 echo13 echo "-h|--help Display this help message"14 echo "-c|--coverage Open up the coverage report after doing the build"15 echo "-d|--docs Open up the docs home page after doing the build"16 exit 117 }18

19 # Read command line arguments20 while [ "$1" != "" ]; do21 case $1 in22 -d | --docs )23 # Open the documentation at the end24 DOCS=125 shift26 ;;27 -c | --coverage )28 # Open the coverage report at the end29 COVERAGE=130 shift31 ;;32 -h | --help )33 # Show the usage34 usage35 ;;36 * )37 # Invalid option38 usage39 exit 040 ;;41 esac42 done43

44 # Generate our docs45 echo46 echo "Generating Documentation"47 echo "========================"48 echo49 cd $BASEDIR/docs/50 make clean51 make html52

53 # Run coverage and our test suite54 echo55 echo "Running Tests"56 echo "============="57 echo58 cd $BASEDIR59 coverage run -m unittest60 coverage html61

62 # Open the coverage report63 if [[ $COVERAGE ]]; then64 xdg-open $BASEDIR/coverage_html_report/index.html65 fi66

18 Chapter 6. Build Process


67 # Open up the docs68 if [[ $DOCS ]]; then69 xdg-open $BASEDIR/docs/_build/html/index.html70 fi

6.2. The Build Script 19


20 Chapter 6. Build Process

CHAPTER 7

telemetry package

7.1 Submodules

7.1.1 telemetry.reader module

class telemetry.reader.Reader(serial_connection)Bases: object

read()A function that will read a line from the serial device and interpret the packet received.

The packets look something like

|CMT|ID(2)|BLK|D1|D2|D3..D8|<CR>

The function will also do all necessary error checking to make sure the packet wasn’t mangled on the way.

Returns A named tuple of the CAN ID and values received.

start()

7.2 Main Module

21


22 Chapter 7. telemetry package

CHAPTER 8

To-Do List

8.1 Documentation

• Write an API usage guide with examples.

8.2 Project

• Write (and test) something that will read from serial, process the message, and write it to a database.

• Write the GUI

23


24 Chapter 8. To-Do List

CHAPTER 9

Contributing

9.1 Package Contributors

• Michael Bryan <[email protected]>

9.2 Version Control

This project uses a Version Control System (VCS) called Git to manage versions of the project when being used bymultiple people, as well as for things like rolling back, branching etc.

The repository is currently hosted on GitHub and may be accessed here. To get your own copy of the project so youcan work with it, use the clone command.

git clone [email protected]:AnonRandom/lapsim.git

Note: When wanting to contribute towards this project it is recommended that you use either a linux or maccomputer as the command line is used heavily in both Git and for running the automated tests. PyCharm is a reallygood IDE to use for a large project like this as it offers a lot of support for working on multiple files, using both .pyand .rst files as well as syntax highlighting and autocomplete.

9.2.1 How to use Git

Git for beginners: The definitive practical guide is an excellent article on StackOverflow for learning the basics of Git.Read it before trying to do anything on the project.

Another very useful resource is the Pro Git book

9.2.2 Git Best Practices

Read the article, Visualized Git practices for team: branch, merge, rebase for a quick intro on how to use Git in a teamscenario. Read it. Also, make sure to read the comments, there’s a lot of useful stuff written in there regarding goodhabits to get into.

25

mailto:[email protected]

https://git-scm.com/

https://github.com/AnonRandom/lapsim

https://www.jetbrains.com/pycharm/download/

http://stackoverflow.com/questions/315911/git-for-beginners-the-definitive-practical-guide

http://git-scm.com/book/en/v2

http://kentnguyen.com/development/visualized-git-practices-for-team/


Note: Before merging a branch back into master, it is your responsibility to make sure your branch is up to date andthere won’t be any conflicts.

9.2.3 About Branching Models

A successful Git branching model is a good resource to help you get your head around the structure of this git repositoryand possible ways you can structure a project, for both small or large applications.

9.2.4 Branching Workflow for this Project

In this project we will be using the following guidelines to manage the workflow:

• “master” is the good (stable) copy of the project, use it as the main branch that most other branches are generatedfrom. At the end of a work cycle, the “develop” branch will be merged back into the “master”.

• “develop” is the working copy of the project, it may not necessarily be stable but is used while building theproject.

• Merge the master into your current branch fairly often so the number of conflicts will be minimal.

9.3 Doing Stuff

9.3.1 Documentation

Do it. You’ll make your life a million times easier if you write this as you’re working. That way everything will befresh in your mind. The documentation is automatically generated from .rst files and using sphinx. To generate a newversion of the documentation, cd into the telemetry/docs/ directory and run the make file.

make clean && make html

The generated html will be in telemetry/docs/_build/html/, to look at it open the index.html file inyour browser (just double click).

Make sure that at the top of the file you put a link anchor. That way it makes it easy to link to a specific page. The taglooks like this:

.. _some_random_page:

26 Chapter 9. Contributing

http://nvie.com/posts/a-successful-git-branching-model/


9.3.2 Testing

This project uses the Test Driven Development (TDD) software development process. To quote Wikipedia.

> Test-driven development (TDD) is a software development process that relies > on the repetition of avery short development cycle: first the developer > writes an (initially failing) automated test case thatdefines a desired > improvement or new function, then produces the minimum amount of code to pass >that test, and finally refactors the new code to acceptable standards.

Put simply, for pretty much every class, method or function you write, there should be an associated unit test (or tests)that can be run to make sure it works as advertised. If writing a test for a function is too difficult then chances are yourfunction is too complex/convoluted and you need to break it up into smaller chunks.

Use the following guidlines:

• Write something then immediately run the tests. If something is broken, fix it before moving on.

• Don’t get lazy with writing tests. You’ll regret it later on.

• Make small methods, the bigger it is the harder it is to write tests for.

• A good way to construct tests is like this:

1. Make some dummy input and the the expected output (i.e. a should_be variable).

2. Run your code with the dummy input.

3. Check that it raises an error, gives you the expected output or whatever else the test is meant to test.

• Give the test a detailed docstring specifying exactly what it should do.

• Informative method names are good. If it’s a bit long then that’s fine.

• Test method names should start with “test_”.

• Only test one thing per test.

• One test file per source file.

• All test files should start with “test_”.

• All tests should be in the telemetry/tests directory.

To run all unit tests enter the following command from the main telemetry directory:

python3 -m unittest discover tests

9.3.3 Writing Code

When writing code, try to use the language’s in-built mechanisms and structure as possible. The language is practicallypseudocode in itself, try to use its inbuilt stuff as much as possible. For example, use:

with open(filename, 'w') as fp:fp.write(stuff)

when opening or working with files, or:

if empty_list:# Do stuff to the list if it isn't empty

to check if a list/dictionary is empty. PEP8 is a good resource. Likewise the talks Beyond PEP 8 – Best practices forbeautiful intelligible code - PyCon 2015 by Raymond Hettinger, and Stop writing classes by Jack Diederich are veryinformative and teach you how to write very “Pythonic” code.

9.3. Doing Stuff 27

https://www.python.org/dev/peps/pep-0008

https://www.youtube.com/watch?v=wf-BqAjZb8M

https://www.youtube.com/watch?v=wf-BqAjZb8M

https://www.youtube.com/watch?v=o9pEzgHorH0

http://blog.startifact.com/posts/older/what-is-pythonic.html


Context Managers

If you find that you are having to copy and paste entire blocks of code then consider refactoring it out and giving itit’s own function. Likewise if you find there are a lot of times where there’s a setup, do stuff, tear down pattern thenconsider writing a custom context manager. A basic context manager looks like this:

from contextlib import ContextDecorator

@ContextDecoratordef my_custom_context_manager(args):

"""A quick summary of the context manager.

A more in-depth paragraph describing the context manager and how it works.

:param args: description of args.:return: A description of the thing returned in the "with my_custom_context_manager()"

statement."""

do_something_to_setup()

# Now yield so we can run whatever is in the with block.yield return_object # (optional)

tear_down()

Naming Conventions

Names that are visible to the user as public parts of the API should follow conventions that reflect usage rather thanimplementation.

The naming conventions are as follows:

Packages and Modules Modules should have short, all-lowercase names. Underscores canbe used in the module name if it improves readability. Python packages should also haveshort, all-lowercase names, although the use of underscores is discouraged.

Classes Class names should normally use the CapWords convention. The naming conventionfor functions may be used instead in cases where the interface is documented and usedprimarily as a callable.

Exceptions Because exceptions should be classes, the class naming convention applies here.However, you should use the suffix “Error” on your exception names (if the exceptionactually is an error).

Functions Function names should be lowercase, with words separated by underscores as nec-essary to improve readability.

Function and method arguments

• Always use self for the first argument to instance methods.

• Always use cls for the first argument to class methods.

Method Names and Instance Variables

• Use the function naming rules: lowercase with words separated by underscores asnecessary to improve readability.



• Use one leading underscore only for non-public methods and instance variables.

• To avoid name clashes with subclasses, use two leading underscores to invokePython’s name mangling rules.

9.3.4 And Finally...

A few words from the Zen of Python:

Beautiful is better than ugly.Explicit is better than implicit.Simple is better than complex.Complex is better than complicated.Flat is better than nested.Sparse is better than dense.Readability counts.Special cases aren't special enough to break the rules.Although practicality beats purity.Errors should never pass silently.Unless explicitly silenced.In the face of ambiguity, refuse the temptation to guess.There should be one-- and preferably only one --obvious way to do it.Although that way may not be obvious at first unless you're Dutch.Now is better than never.Although never is often better than *right* now.If the implementation is hard to explain, it's a bad idea.If the implementation is easy to explain, it may be a good idea.Namespaces are one honking great idea -- let's do more of those!

9.3. Doing Stuff 29

CHAPTER 10

License

The MIT License (MIT)

Copyright (c) 2015 Michael Bryan

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documen-tation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use,copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whomthe Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of theSoftware.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PAR-TICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHTHOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTIONOF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFT-WARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

31


32 Chapter 10. License

CHAPTER 11

Indices and tables

• genindex

• modindex

• search

33


34 Chapter 11. Indices and tables

Python Module Index

ttelemetry, 21telemetry.reader, 21

35


36 Python Module Index

Index

Rread() (telemetry.reader.Reader method), 21Reader (class in telemetry.reader), 21

Sstart() (telemetry.reader.Reader method), 21

Ttelemetry (module), 21telemetry.reader (module), 21

37

telemetry documentation

Documents