Updates to docs

This commit is contained in:
Magnus Persson
2022-01-09 09:23:40 +01:00
parent 2662f38bf7
commit e234d6f908
9 changed files with 179 additions and 59 deletions

View File

@ -1,3 +1,5 @@
.. _functionallity:
Functionallity
==============
@ -6,21 +8,21 @@ The main differences
* **Operates in two modes gravity monitoring and configuration mode**
In ``gravity monitoring`` mode it behaves just like the iSpindle, it wakes up at regular intervals, measure angle/tile, temperature, calculates gravity and pushes the data to defined endpoints.
In ``gravity monitoring`` mode it behaves just like the iSpindle, it wakes up at regular intervals, measures angle/tile, temperature, calculates gravity and pushes the data to defined endpoints.
In ``configuration mode`` the device is always active and the webserver is active. Here you can view the angle/tilt values, change configuration options and more. When in this mode you can also interact with the device
via an REST API so data can be pushed to the device via scripts (see API section for more information)
via an REST API so data can be pushed to the device via scripts (see API section for more information).
You can force the device into ``configuration mode`` while measuring gravity. This is useful when calibrating the device so you dont needs to wait for the device to wake up and push the data. The entire calibration
You can force the device into ``configuration mode`` while measuring gravity. This is useful when calibrating the device so you don't needs to wait for the device to wake up and push the data. The entire calibration
sequence can be handled via the web interface without need for additional software tools.
*See the configuration section for more information on how to trigger the configuration mode.*
See the :ref:`setting-up-device` section for more information on how to trigger the configuration mode.
* **Can send data to multiple endpoints at once**
The original iSpindle can only have one destination, this software will push data to all defined endpoints so in theory you can use them all. However this will consume a lot of battery power so use only as many as needed.
Currently the device supports the following endpoints: http (2 differnt), influxdb2 and Brewfather
Currently the device supports the following endpoints: http (2 different), influxdb2 and Brewfather
If you want additional targets please raise a feature request in the github repo.
@ -60,21 +62,20 @@ Other features
Experimental features
---------------------
.. tip::
These are not enabled by default. To enable them you need to recompile the code and enable the correct defines.
* Use the temperature sensor in the gyro instead of DS18B20
This works fine when the device has time to cool down between measurements and it saves a few milliseconds (reduced battery consumption). My testing shows that this is quite accurate.
There is lots of battery power to save, reading the temp sensor takes almost as long as the gyro. This could reduce the run time by 40-50% and probly extend battery life with the same.
However more testing is required. Might add this as an option in the UI.
.. note::
This is not enabled by default.
* Performance measurements
I've also create a small library to measure execution code in some areas of the code that i know is time consuming. This way I can find a good balance between performace and quality.
*See the compile section for more information.*
See the :ref:`compiling-the-software` for more information.
Battery life