Updates to docs
This commit is contained in:
@ -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
|
||||
|
Reference in New Issue
Block a user