prettier: re-format
Prettier is enabled in openbmc-build-scripts on Markdown, JSON, and YAML
files to have consistent formatting for these file types. Re-run the
formatter on the whole repository.
Change-Id: I834909dc663e8762217517eab4a4294174d3bcf2
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
diff --git a/README.md b/README.md
index e34fbef..26ff923 100644
--- a/README.md
+++ b/README.md
@@ -115,22 +115,22 @@
The code is broken out into modules as follows:
-* `dbus` - Any read or write interface that uses dbus primarily.
-* `experiments` - Small execution paths that allow for fan examination
- including how quickly fans respond to changes.
-* `ipmi` - Manual control for any zone is handled by receiving an IPMI
- message. This holds the ipmid provider for receiving those messages and
- sending them onto swampd.
-* `notimpl` - These are read-only and write-only interface implementations
- that can be dropped into a pluggable sensor to make it complete.
-* `pid` - This contains all the PID associated code, including the zone
- definition, controller definition, and the PID computational code.
-* `scripts` - This contains the scripts that convert YAML into C++.
-* `sensors` - This contains a couple of sensor types including the pluggable
- sensor's definition. It also holds the sensor manager.
-* `sysfs` - This contains code that reads from or writes to sysfs.
-* `threads` - Most of swampd's threads run in this method where there's just a
- dbus bus that we manage.
+- `dbus` - Any read or write interface that uses dbus primarily.
+- `experiments` - Small execution paths that allow for fan examination including
+ how quickly fans respond to changes.
+- `ipmi` - Manual control for any zone is handled by receiving an IPMI message.
+ This holds the ipmid provider for receiving those messages and sending them
+ onto swampd.
+- `notimpl` - These are read-only and write-only interface implementations that
+ can be dropped into a pluggable sensor to make it complete.
+- `pid` - This contains all the PID associated code, including the zone
+ definition, controller definition, and the PID computational code.
+- `scripts` - This contains the scripts that convert YAML into C++.
+- `sensors` - This contains a couple of sensor types including the pluggable
+ sensor's definition. It also holds the sensor manager.
+- `sysfs` - This contains code that reads from or writes to sysfs.
+- `threads` - Most of swampd's threads run in this method where there's just a
+ dbus bus that we manage.
## Example System Configurations
diff --git a/configure.md b/configure.md
index 44fd6ff..164e2e3 100644
--- a/configure.md
+++ b/configure.md
@@ -2,8 +2,8 @@
A system needs two groups of configurations: zones and sensors.
-They can come either from a dedicated config file or via D-Bus from
-e.g. `entity-manager`.
+They can come either from a dedicated config file or via D-Bus from e.g.
+`entity-manager`.
## D-Bus Configuration
@@ -18,10 +18,10 @@
### --strict-failsafe-pwm
-This build flag is used to set the fans strictly at the failsafe percent when
-in failsafe mode, even when the calculated PWM is higher than failsafe PWM.
-Without this enabled, the PWM is calculated and set to the calculated PWM
-**or** the failsafe PWM, whichever is higher.
+This build flag is used to set the fans strictly at the failsafe percent when in
+failsafe mode, even when the calculated PWM is higher than failsafe PWM. Without
+this enabled, the PWM is calculated and set to the calculated PWM **or** the
+failsafe PWM, whichever is higher.
## JSON Configuration
@@ -59,7 +59,8 @@
```
A sensor has a `name`, a `type`, a `readPath`, a `writePath`, a `minimum` value,
-a `maximum` value, a `timeout`, a `ignoreDbusMinMax` and a `unavailableAsFailed` value.
+a `maximum` value, a `timeout`, a `ignoreDbusMinMax` and a `unavailableAsFailed`
+value.
The `name` is used to reference the sensor in the zone portion of the
configuration.
@@ -84,9 +85,8 @@
If the `readPath` value contains: `/sys/` this is treated as a directly read
sysfs path. There are two supported paths:
-* `/sys/class/hwmon/hwmon0/pwm1`
-* `/sys/devices/platform/ahb/1e786000.pwm-tacho-controller/hwmon/<asterisk
- asterisk>/pwm1`
+- `/sys/class/hwmon/hwmon0/pwm1`
+- `/sys/devices/platform/ahb/1e786000.pwm-tacho-controller/hwmon/<asterisk asterisk>/pwm1`
The `writePath` is the path to set the value for the sensor. This is only valid
for a sensor of type `fan`. The path is optional. If can be empty or `None`. It
@@ -95,14 +95,13 @@
If the `writePath` value contains: `/sys/` this is treated as a directory
written sysfs path. There are two support paths:
-* `/sys/class/hwmon/hwmon0/pwm1`
-* `/sys/devices/platform/ahb/1e786000.pwm-tacho-controller/hwmon/<asterisk
- asterisk>/pwm1`
+- `/sys/class/hwmon/hwmon0/pwm1`
+- `/sys/devices/platform/ahb/1e786000.pwm-tacho-controller/hwmon/<asterisk asterisk>/pwm1`
-If the `writePath` value contains: `/xyz/openbmc_project/sensors/fan_tach/fan{N}` it
-sets of a sensor object that writes over dbus to the
-`xyz.openbmc_project.Control.FanPwm` interface. The `writePath` should be the
-full object path.
+If the `writePath` value contains:
+`/xyz/openbmc_project/sensors/fan_tach/fan{N}` it sets of a sensor object that
+writes over dbus to the `xyz.openbmc_project.Control.FanPwm` interface. The
+`writePath` should be the full object path.
```
busctl introspect xyz.openbmc_project.Hwmon-1644477290.Hwmon1 /xyz/openbmc_project/sensors/fan_tach/fan1 --no-pager
@@ -138,17 +137,17 @@
to handle the case where it doesn't know what to do -- as it doesn't have all
its inputs.
-The `ignoreDbusMinMax` value is optional and defaults to false. The dbus
-passive sensors check for a `MinValue` and `MaxValue` and scale the incoming
-values via these. Setting this property to true will ignore `MinValue` and
-`MaxValue` from dbus and therefore won't call any passive value scaling.
+The `ignoreDbusMinMax` value is optional and defaults to false. The dbus passive
+sensors check for a `MinValue` and `MaxValue` and scale the incoming values via
+these. Setting this property to true will ignore `MinValue` and `MaxValue` from
+dbus and therefore won't call any passive value scaling.
-The `unavailableAsFailed` value is optional and defaults to true. However,
-some specific thermal sensors should not be treated as Failed when they are
-unavailable. For example, when a system is powered-off, its CPU/DIMM Temp sensors
-are unavailable, in such state these sensors should not be treated as Failed and
-trigger FailSafe. This is important for systems whose Fans are always on.
-For these specific sensors set this property to false.
+The `unavailableAsFailed` value is optional and defaults to true. However, some
+specific thermal sensors should not be treated as Failed when they are
+unavailable. For example, when a system is powered-off, its CPU/DIMM Temp
+sensors are unavailable, in such state these sensors should not be treated as
+Failed and trigger FailSafe. This is important for systems whose Fans are always
+on. For these specific sensors set this property to false.
### Zones
@@ -164,75 +163,74 @@
Each zone has its own fields, and a list of controllers.
-| field | type | meaning |
-| ------------------ | --------- | ----------------------------------------- |
-| `id` | `int64_t` | This is a unique identifier for the zone. |
-| `minThermalOutput` | `double` | This is the minimum value that should be considered from the thermal outputs. Commonly used as the minimum fan RPM.|
-| `failsafePercent` | `double` | If there is a fan PID, it will use this value if the zone goes into fail-safe as the output value written to the fan's sensors.|
-| `pids` | `list of strings` | Fan and thermal controllers used by the zone.|
+| field | type | meaning |
+| ------------------ | ----------------- | ------------------------------------------------------------------------------------------------------------------------------- |
+| `id` | `int64_t` | This is a unique identifier for the zone. |
+| `minThermalOutput` | `double` | This is the minimum value that should be considered from the thermal outputs. Commonly used as the minimum fan RPM. |
+| `failsafePercent` | `double` | If there is a fan PID, it will use this value if the zone goes into fail-safe as the output value written to the fan's sensors. |
+| `pids` | `list of strings` | Fan and thermal controllers used by the zone. |
The `id` field here is used in the d-bus path to talk to the
`xyz.openbmc_project.Control.Mode` interface.
-***TODO:*** Examine how the fan controller always treating its output as a
+**_TODO:_** Examine how the fan controller always treating its output as a
percentage works for future cases.
-A zone collects all the setpoints and ceilings from the thermal
-controllers attached to it, selects the maximum setpoint, clamps it by
-the minimum ceiling and `minThermalOutput`; the result is used to
-control fans.
+A zone collects all the setpoints and ceilings from the thermal controllers
+attached to it, selects the maximum setpoint, clamps it by the minimum ceiling
+and `minThermalOutput`; the result is used to control fans.
### Controllers
There are `fan`, `temp`, `margin` (PID), and `stepwise` (discrete steps)
controllers.
-The `fan` PID is meant to drive fans or other cooling devices. It's
-expecting to get the setpoint value from the owning zone and then
-drive the fans to that value.
+The `fan` PID is meant to drive fans or other cooling devices. It's expecting to
+get the setpoint value from the owning zone and then drive the fans to that
+value.
-A `temp` PID is meant to drive the setpoint given an absolute
-temperature value (higher value indicates warmer temperature).
+A `temp` PID is meant to drive the setpoint given an absolute temperature value
+(higher value indicates warmer temperature).
-A `margin` PID is meant to drive the setpoint given a margin value
-(lower value indicates warmer temperature, in other words, it's the
-safety margin remaining expressed in degrees Celsius).
+A `margin` PID is meant to drive the setpoint given a margin value (lower value
+indicates warmer temperature, in other words, it's the safety margin remaining
+expressed in degrees Celsius).
The setpoint output from the thermal controllers is called `RPMSetpoint()`
However, it doesn't need to be an RPM value.
-***TODO:*** Rename this method and others to not say necessarily RPM.
+**_TODO:_** Rename this method and others to not say necessarily RPM.
Some PID configurations have fields in common, but may be interpreted
differently.
When using D-Bus, each configuration can have a list of strings called
-`Profiles`. In this case the controller will be loaded only if at
-least one of them is returned as `Current` from an object implementing
-`xyz.openbmc_project.Control.ThermalMode` interface (which can be
-anywhere on D-Bus). `swampd` will automatically reload full
-configuration whenever `Current` is changed.
+`Profiles`. In this case the controller will be loaded only if at least one of
+them is returned as `Current` from an object implementing
+`xyz.openbmc_project.Control.ThermalMode` interface (which can be anywhere on
+D-Bus). `swampd` will automatically reload full configuration whenever `Current`
+is changed.
-D-Bus `Name` attribute is used for indexing in certain cases so should
-be unique for all defined configurations.
+D-Bus `Name` attribute is used for indexing in certain cases so should be unique
+for all defined configurations.
#### PID Field
If the PID `type` is not `stepwise` then the PID field is defined as follows:
-| field | type | meaning |
-| -------------------- | -------- | ----------------------------------------- |
-| `samplePeriod` | `double` | How frequently the value is sampled. 0.1 for fans, 1.0 for temperatures.|
-| `proportionalCoeff` | `double` | The proportional coefficient. |
-| `integralCoeff` | `double` | The integral coefficient. |
-| `feedFwdOffsetCoeff` | `double` | The feed forward offset coefficient. |
-| `feedFwdGainCoeff` | `double` | The feed forward gain coefficient. |
-| `integralLimit_min` | `double` | The integral minimum clamp value. |
-| `integralLimit_max` | `double` | The integral maximum clamp value. |
-| `outLim_min` | `double` | The output minimum clamp value. |
-| `outLim_max` | `double` | The output maximum clamp value. |
-| `slewNeg` | `double` | Negative slew value to dampen output. |
-| `slewPos` | `double` | Positive slew value to accelerate output. |
+| field | type | meaning |
+| -------------------- | -------- | ------------------------------------------------------------------------ |
+| `samplePeriod` | `double` | How frequently the value is sampled. 0.1 for fans, 1.0 for temperatures. |
+| `proportionalCoeff` | `double` | The proportional coefficient. |
+| `integralCoeff` | `double` | The integral coefficient. |
+| `feedFwdOffsetCoeff` | `double` | The feed forward offset coefficient. |
+| `feedFwdGainCoeff` | `double` | The feed forward gain coefficient. |
+| `integralLimit_min` | `double` | The integral minimum clamp value. |
+| `integralLimit_max` | `double` | The integral maximum clamp value. |
+| `outLim_min` | `double` | The output minimum clamp value. |
+| `outLim_max` | `double` | The output maximum clamp value. |
+| `slewNeg` | `double` | Negative slew value to dampen output. |
+| `slewPos` | `double` | Positive slew value to accelerate output. |
The units for the coefficients depend on the configuration of the PIDs.
@@ -243,7 +241,7 @@
If the PID is a fan controller whose output is pwm: proportionalCoeff is %/RPM
and integralCoeff is %/RPM sec.
-***NOTE:*** The sample periods are specified in the configuration as they are
+**_NOTE:_** The sample periods are specified in the configuration as they are
used in the PID computations, however, they are not truly configurable as they
are used for the update periods for the fan and thermal sensors.
@@ -261,13 +259,13 @@
The type `fan` builds a `FanController` PID.
-| field | type | meaning |
-| ---------- | ----------------- | ------------------------------------------- |
-| `name` | `string` | The name of the PID. This is just for humans and logging.|
-| `type` | `string` | `fan` |
-| `inputs` | `list of strings` | The names of the sensor(s) that are used as input and output for the PID loop.|
-| `setpoint` | `double` | Presently UNUSED |
-| `pid` | `dictionary` | A PID dictionary detailed above. |
+| field | type | meaning |
+| ---------- | ----------------- | ------------------------------------------------------------------------------ |
+| `name` | `string` | The name of the PID. This is just for humans and logging. |
+| `type` | `string` | `fan` |
+| `inputs` | `list of strings` | The names of the sensor(s) that are used as input and output for the PID loop. |
+| `setpoint` | `double` | Presently UNUSED |
+| `pid` | `dictionary` | A PID dictionary detailed above. |
#### type == "margin"
@@ -283,22 +281,21 @@
The type `margin` builds a `ThermalController` PID.
-| field | type | meaning |
-| ---------- | ----------------- | ------------------------------------------- |
-| `name` | `string` | The name of the PID. This is just for humans and logging.|
-| `type` | `string` | `margin` |
-| `inputs` | `list of strings` | The names of the sensor(s) that are used as input for the PID loop.|
-| `setpoint` | `double` | The setpoint value for the thermal PID. The setpoint for the margin sensors.|
-| `pid` | `dictionary` | A PID dictionary detailed above. |
+| field | type | meaning |
+| ---------- | ----------------- | ---------------------------------------------------------------------------- |
+| `name` | `string` | The name of the PID. This is just for humans and logging. |
+| `type` | `string` | `margin` |
+| `inputs` | `list of strings` | The names of the sensor(s) that are used as input for the PID loop. |
+| `setpoint` | `double` | The setpoint value for the thermal PID. The setpoint for the margin sensors. |
+| `pid` | `dictionary` | A PID dictionary detailed above. |
-Each input is normally a temperature difference between some hardware
-threshold and the current state. E.g. a CPU sensor can be reporting
-that it's 20 degrees below the point when it starts thermal
-throttling. So the lower the margin temperature, the higher the
-corresponding absolute value.
+Each input is normally a temperature difference between some hardware threshold
+and the current state. E.g. a CPU sensor can be reporting that it's 20 degrees
+below the point when it starts thermal throttling. So the lower the margin
+temperature, the higher the corresponding absolute value.
-Out of all the `inputs` the minimal value is selected and used as an
-input for the PID loop.
+Out of all the `inputs` the minimal value is selected and used as an input for
+the PID loop.
The output of a `margin` PID loop is that it sets the setpoint value for the
zone. It does this by adding the value to a list of values. The value chosen by
@@ -306,11 +303,11 @@
#### type == "temp"
-Exactly the same as `margin` but all the inputs are supposed to be
-absolute temperatures and so the maximal value is used to feed the PID
-loop.
+Exactly the same as `margin` but all the inputs are supposed to be absolute
+temperatures and so the maximal value is used to feed the PID loop.
#### type == "stepwise"
+
```
"name": "temp1",
"type": "stepwise",
@@ -336,17 +333,17 @@
The type `stepwise` builds a `StepwiseController`.
-| field | type | meaning |
-| ---------- | ----------------- | ------------------------------------------- |
-| `name` | `string` | The name of the controller. This is just for humans and logging. |
-| `type` | `string` | `stepwise` |
-| `inputs` | `list of strings` | The names of the sensor(s) that are used as input and output for the controller. |
-| `pid` | `dictionary` | A controller settings dictionary detailed below. |
+| field | type | meaning |
+| -------- | ----------------- | -------------------------------------------------------------------------------- |
+| `name` | `string` | The name of the controller. This is just for humans and logging. |
+| `type` | `string` | `stepwise` |
+| `inputs` | `list of strings` | The names of the sensor(s) that are used as input and output for the controller. |
+| `pid` | `dictionary` | A controller settings dictionary detailed below. |
The `pid` dictionary (confusingly named) is defined as follows:
| field | type | meaning |
-| -------------------- | -------- | ----------------------------------------- |
+| -------------------- | ------------ | ---------------------------------------------------------------------------------------------------- |
| `samplePeriod` | `double` | Presently UNUSED. |
| `reading` | `dictionary` | Enumerated list of input values, indexed from 0, must be monotonically increasing, maximum 20 items. |
| `output` | `dictionary` | Enumerated list of output values, indexed from 0, must match the amount of `reading` items. |
@@ -355,14 +352,13 @@
| `isCeiling` | `bool` | Whether this controller provides a setpoint or a ceiling for the zone |
| `setpoint` | `double` | Presently UNUSED. |
-***NOTE:*** `reading` and `output` are normal arrays and not embedded
-in the dictionary in Entity Manager.
+**_NOTE:_** `reading` and `output` are normal arrays and not embedded in the
+dictionary in Entity Manager.
-Each measurement cycle out of all the `inputs` the maximum value is
-selected. Then it's compared to the list of `reading` values finding
-the largest that's still lower or equal the input (the very first item
-is used even if it's larger than the input). The corresponding
-`output` value is selected if hysteresis allows the switch (the
-current input value is compared with the input present at the moment
-of the previous switch). The result is added to the list of setpoints
+Each measurement cycle out of all the `inputs` the maximum value is selected.
+Then it's compared to the list of `reading` values finding the largest that's
+still lower or equal the input (the very first item is used even if it's larger
+than the input). The corresponding `output` value is selected if hysteresis
+allows the switch (the current input value is compared with the input present at
+the moment of the previous switch). The result is added to the list of setpoints
or ceilings for the zone depending on `isCeiling` setting.
diff --git a/examples/fan-info.json b/examples/fan-info.json
index f1676cb..77e5cf9 100644
--- a/examples/fan-info.json
+++ b/examples/fan-info.json
@@ -1,5 +1,5 @@
{
- "sensors" : [
+ "sensors": [
{
"name": "fan1",
"type": "fan",
@@ -59,7 +59,7 @@
"timeout": 4
}
],
- "zones" : [
+ "zones": [
{
"id": 1,
"minThermalOutput": 3000.0,
@@ -75,7 +75,7 @@
"proportionalCoeff": 0.0,
"integralCoeff": 0.0,
"feedFwdOffsetCoeff": 0.0,
- "feedFwdGainCoeff": 0.010,
+ "feedFwdGainCoeff": 0.01,
"integralLimit_min": 0.0,
"integralLimit_max": 0.0,
"outLim_min": 30.0,
@@ -94,7 +94,7 @@
"proportionalCoeff": 0.0,
"integralCoeff": 0.0,
"feedFwdOffsetCoeff": 0.0,
- "feedFwdGainCoeff": 0.010,
+ "feedFwdGainCoeff": 0.01,
"integralLimit_min": 0.0,
"integralLimit_max": 0.0,
"outLim_min": 30.0,
@@ -113,7 +113,7 @@
"proportionalCoeff": 0.0,
"integralCoeff": 0.0,
"feedFwdOffsetCoeff": 0.0,
- "feedFwdGainCoeff": 0.010,
+ "feedFwdGainCoeff": 0.01,
"integralLimit_min": 0.0,
"integralLimit_max": 0.0,
"outLim_min": 30.0,
@@ -132,7 +132,7 @@
"proportionalCoeff": 0.0,
"integralCoeff": 0.0,
"feedFwdOffsetCoeff": 0.0,
- "feedFwdGainCoeff": 0.010,
+ "feedFwdGainCoeff": 0.01,
"integralLimit_min": 0.0,
"integralLimit_max": 0.0,
"outLim_min": 30.0,
diff --git a/ipmi.md b/ipmi.md
index 65139c8..fb3d181 100644
--- a/ipmi.md
+++ b/ipmi.md
@@ -2,20 +2,20 @@
## Sensor Data Pushing Advice
-For temperature sensors not reachable by the BMC, sensor readings can be
-pushed to the BMC from the host, by using the IPMI SDR as shared storage.
+For temperature sensors not reachable by the BMC, sensor readings can be pushed
+to the BMC from the host, by using the IPMI SDR as shared storage.
To do this, it is recommended that
[ExternalSensor](https://github.com/openbmc/docs/blob/master/designs/external-sensor.md)
-be used. ExternalSensor can add virtual sensors to the IPMI SDR. The host
-can then write values to these virtual sensors, to keep them up to date. Thus,
-these sensors will become visible on the BMC, and can be used normally,
-similar to other temperature sensors already on the BMC.
+be used. ExternalSensor can add virtual sensors to the IPMI SDR. The host can
+then write values to these virtual sensors, to keep them up to date. Thus, these
+sensors will become visible on the BMC, and can be used normally, similar to
+other temperature sensors already on the BMC.
-For temperature sensors on the BMC, including those added with
-ExternalSensor as mentioned above, these can be manipulated through
-normal IPMI commands, and are already supported. The same applies to fan RPM
-and PWM sensors. No additional OEM commands are required to use these.
+For temperature sensors on the BMC, including those added with ExternalSensor as
+mentioned above, these can be manipulated through normal IPMI commands, and are
+already supported. The same applies to fan RPM and PWM sensors. No additional
+OEM commands are required to use these.
## IPMI OEM Command Specification
@@ -30,25 +30,25 @@
#### Request
-Byte | Purpose | Value
----- | ------------ | -----------------------------------------------------
-`00` | `netfn` | `0x2e`
-`01` | `command` | `0x04 (also using manual command)`
-`02` | `oem1` | `0xcf`
-`03` | `oem2` | `0xc2`
-`04` | `padding` | `0x00`
-`05` | `SubCommand` | `Get or Set. Get == 0, Set == 1`
-`06` | `ZoneId` |
-`07` | `Mode` | `If Set, Value 1 == Manual Mode, 0 == Automatic Mode`
+| Byte | Purpose | Value |
+| ---- | ------------ | ----------------------------------------------------- |
+| `00` | `netfn` | `0x2e` |
+| `01` | `command` | `0x04 (also using manual command)` |
+| `02` | `oem1` | `0xcf` |
+| `03` | `oem2` | `0xc2` |
+| `04` | `padding` | `0x00` |
+| `05` | `SubCommand` | `Get or Set. Get == 0, Set == 1` |
+| `06` | `ZoneId` |
+| `07` | `Mode` | `If Set, Value 1 == Manual Mode, 0 == Automatic Mode` |
#### Response
-Byte | Purpose | Value
----- | --------- | -----------------------------------------------------
-`02` | `oem1` | `0xcf`
-`03` | `oem2` | `0xc2`
-`04` | `padding` | `0x00`
-`07` | `Mode` | `If Set, Value 1 == Manual Mode, 0 == Automatic Mode`
+| Byte | Purpose | Value |
+| ---- | --------- | ----------------------------------------------------- |
+| `02` | `oem1` | `0xcf` |
+| `03` | `oem2` | `0xc2` |
+| `04` | `padding` | `0x00` |
+| `07` | `Mode` | `If Set, Value 1 == Manual Mode, 0 == Automatic Mode` |
### OEM Get Failsafe Mode
@@ -56,21 +56,21 @@
This setting is read-only because it's dynamically determined within
phosphor-pid-control per zone.
-Byte | Purpose | Value
----- | ------------ | ----------------------------------
-`00` | `netfn` | `0x2e`
-`01` | `command` | `0x04 (also using manual command)`
-`02` | `oem1` | `0xcf`
-`03` | `oem2` | `0xc2`
-`04` | `padding` | `0x00`
-`05` | `SubCommand` | `Get == 2`
-`06` | `ZoneId` |
+| Byte | Purpose | Value |
+| ---- | ------------ | ---------------------------------- |
+| `00` | `netfn` | `0x2e` |
+| `01` | `command` | `0x04 (also using manual command)` |
+| `02` | `oem1` | `0xcf` |
+| `03` | `oem2` | `0xc2` |
+| `04` | `padding` | `0x00` |
+| `05` | `SubCommand` | `Get == 2` |
+| `06` | `ZoneId` |
#### Response
-Byte | Purpose | Value
----- | ---------- | -----------------------------------------------
-`02` | `oem1` | `0xcf`
-`03` | `oem2` | `0xc2`
-`04` | `padding` | `0x00`
-`07` | `failsafe` | `1 == in Failsafe Mode, 0 not in failsafe mode`
+| Byte | Purpose | Value |
+| ---- | ---------- | ----------------------------------------------- |
+| `02` | `oem1` | `0xcf` |
+| `03` | `oem2` | `0xc2` |
+| `04` | `padding` | `0x00` |
+| `07` | `failsafe` | `1 == in Failsafe Mode, 0 not in failsafe mode` |
diff --git a/tuning.md b/tuning.md
index ef9ff40..1fa8f08 100644
--- a/tuning.md
+++ b/tuning.md
@@ -4,7 +4,8 @@
to specify the sensors and PID coefficients. Determining good coefficients is
beyond the scope of this document.
-**NOTE** The steps below may not be applicable if you are using D-Bus based configuration.
+**NOTE** The steps below may not be applicable if you are using D-Bus based
+configuration.
## Tuning Fan PID Using a Fixed RPM Setpoint
@@ -37,26 +38,24 @@
## Core Logging
-For even more detailed logging, flag `"-g"` can be specified
-to enable the daemon to log the computations made during the core
-of the PID loop.
+For even more detailed logging, flag `"-g"` can be specified to enable the
+daemon to log the computations made during the core of the PID loop.
-The log output is in CSV format, in the same directory as specified with
-the `"-l"` option. Default is the system temporary directory,
-typically `/tmp`.
+The log output is in CSV format, in the same directory as specified with the
+`"-l"` option. Default is the system temporary directory, typically `/tmp`.
-Two files will be created, for each PID loop configured. The
-`pidcoeffs.*` file will show the PID coefficients that are in use
-for the PID loop. The `pidcore.*` file will show the computations
-that take place, to transform the input into the output. The configured
-name of the PID loop is used as the suffix, for both of these files.
+Two files will be created, for each PID loop configured. The `pidcoeffs.*` file
+will show the PID coefficients that are in use for the PID loop. The `pidcore.*`
+file will show the computations that take place, to transform the input into the
+output. The configured name of the PID loop is used as the suffix, for both of
+these files.
-The `pidcoeffs.*` file will grow slowly, updated only when new
-coefficients are set using D-Bus without restarting the program. The
-`pidcore.*` file, on the other hand, will grow rapidly, as it will
-be updated during each PID loop pass in which there were changes. To
-prevent needless log file growth, identical logging lines are
-throttled, unless it has been at least 60 seconds since the last line.
+The `pidcoeffs.*` file will grow slowly, updated only when new coefficients are
+set using D-Bus without restarting the program. The `pidcore.*` file, on the
+other hand, will grow rapidly, as it will be updated during each PID loop pass
+in which there were changes. To prevent needless log file growth, identical
+logging lines are throttled, unless it has been at least 60 seconds since the
+last line.
## Fan RPM Tuning Helper script
@@ -68,10 +67,10 @@
1. Create initial `/usr/share/swampd/config.json` used for PID control
2. (Option 1) If using a fixed setpoint, write the value to
- `/etc/thermal.d/setpoint`, run swampd manually with `swampd -l ${LOG_PATH}&`, and kill the
- process after desired duration.
-3. (Option 2) If sweeping fan setpoint, using the tuning helper script `fan_rpm_loop_test.sh` to
- configure fan setpoint in steps and collect logs
+ `/etc/thermal.d/setpoint`, run swampd manually with
+ `swampd -l ${LOG_PATH}&`, and kill the process after desired duration.
+3. (Option 2) If sweeping fan setpoint, using the tuning helper script
+ `fan_rpm_loop_test.sh` to configure fan setpoint in steps and collect logs
4. Parse logs from `${LOG_PATH}/zone_*.log` and analyze response data
-6. Modify `/usr/share/swampd/config.json` as needed
-7. Repeat from step 2 or step 3
+5. Modify `/usr/share/swampd/config.json` as needed
+6. Repeat from step 2 or step 3