# IDU 0x31[11] — Working Notes

## Observed Values

| Value | Decimal | Captures |
|-------|---------|----------|
| `0x00` | 0 | Power-on initialization (1-2 frames, then jumps) |
| `0x17` | 23 | sleep_mode_cycle, start of sleep_cool_fan_cycle |
| `0x18` | 24 | sleep_cool_fan_cycle, sleep_heat_stdby, poweron_cool_1 |
| `0x19` | 25 | sleep_heat_stdby, poweron_cool_1 |
| `0x1A` | 26 | SCMI (constant, every capture) |
| `0x1D` | 29 | All IDU_* captures |
| `0x1E` | 30 | All IDU_* captures, cline_2 |
| `0x20` | 32 | IDU_stdby_cool_fan_cycle (latest capture) |
| `0x21` | 33 | IDU_stdby_cool_fan_cycle (latest capture) |

## What's Confirmed

1. **Not a temperature** — byte[7] is room temp, byte[9] is coil temp. byte[11] doesn't track either, and the gap is inconsistent across captures.

2. **Not a bitfield** — the 0x20/0x21 values broke the bits[3:2] structure theory. These are plain integers.

3. **Not a feature flag** (X-Fan, sleep comfort, quiet, turbo) — the residential IDU doesn't implement those features (they flash and turn off on the remote).

4. **Increases with uptime** — between cline_2 (`0x1E`=30) and IDU_stdby_cool_fan_cycle (`0x20`=32), the ONLY change was the system being powered for a long time. Value went up by 2.

5. **Starts at 0x00 at power-on** — poweron_cool_1 shows `0x00` for first 2 frames, then jumps to `0x18`.

6. **SCMI is constant `0x1A`** — never varies across 6+ SCMI captures. Zero overlap with any residential value.

7. **Oscillates between adjacent values within a capture** — period ~20-40 seconds. The oscillation is NOT correlated with byte[15:16] alternation or any user action.

## Coil-Threshold Gating (Validated, but May Be LSB Behavior Only)

The LSB responds to coil temperature thresholds during standby:

- **IDU_cool_long_cap standby**: `0x1D`→`0x1E` at exactly coil=17°C (afterblow done, coil dried)
- **IDU_heat_long_cap standby**: `0x1E`→`0x1D` at exactly coil=30°C (coil cooled down)
- **sleep_heat_stdby**: `0x18` only when b4=0x00 (fan inhibited), `0x19` when fan allowed
- **sleep_cool_fan_cycle**: `0x17`→`0x18` when fan control transitions from auto to manual

These are real and validated. But they may only explain the **+1/-1 toggling** (the LSB), not the base value.

## What's NOT Explained

- **Why different "bands"** across sessions: 23-25, 29-30, 32-33. Not room temp (disproven). Not feature settings (disproven). Not bus sleep/wake (cline_2 tested this). The only confirmed correlate is **cumulative uptime since last power cycle**.

- **The jump at boot**: poweron_cool_1 goes `0x00`→`0x18` (0→24) in 2 frames. That's not slow counting — it's loading an initial value from somewhere (EEPROM? calibration?).

- **Why the timestamped captures don't monotonically increase**: poweron_cool_1 (24) → sleep_cool (23) → sleep_heat (24). These were likely different power cycles, which would reset a volatile counter. But the initial value varies (23 vs 24), so something else seeds it.

- **SCMI constant 0x1A** — fits between the residential bands (24-25 and 29-30). Could be a fixed configuration value since SCMI has no indoor fan or coil management logic.

## New Information from ASD-60BI2 Documentation

Analysis of the Sinclair ASD-60BI2 user manual, engineering data book, installation manual, and service manual revealed several internal counters and timers that the IDU maintains:

### Candidate 1: Filter Clean Reminder Counter (EEPROM)

The IDU maintains a **cumulative operating hours counter** in non-volatile storage for the filter cleaning reminder feature. The wired controller allows setting "Cleaning Level" (range 00, 10–39) mapping to accumulated operating hours (100–10,000 hours). This proves:
- The IDU has persistent hour-counting infrastructure in EEPROM
- The counter survives power cycles
- The jump at boot (0x00→0x18) is consistent with loading from EEPROM

**Problem**: The filter timer counts in hundreds/thousands of hours, which doesn't directly match byte[11]'s 20-33 range. Unless byte[11] uses a different scale or is a different counter sharing the same EEPROM infrastructure.

### Candidate 2: DC Fan Driver Session Counter

The IDU has a **separate DC fan driver sub-board** with its own MCU and EEPROM (error code `qF` = "DC indoor fan driver memory chip error"). This sub-board could maintain its own cumulative runtime counter independent of the main IDU controller. byte[11] could relay the fan driver's internal counter.

### Candidate 3: Residual Heat Blowing Timer

Service manual documents two "blowing residual heating" modes (wired controller debug param 08):
- **Mode 1 (default)**: After heating reaches setpoint, fan runs 60s then stops. If restart conditions not met within **15 minutes**, fan runs 60s at low speed, then waits another 15 min — cycles this pattern.
- **Mode 2**: After reaching temp, fan stops with 10s delay.

The IDU must maintain a timer for the 15-minute cycling. However, this is a short-term operational timer, not a persistent counter — unlikely to explain the cross-session base value drift.

### Candidate 4: Compressor Protection Timer (3 min)

Confirmed in both cooling and heating flowcharts. Once the compressor stops, a 3-minute delay timer runs before restart is allowed. This is a short operational timer.

### Candidate 5: Defrost Participation Timer

The IDU participates in defrost by stopping its indoor fan and running anti-cold-wind logic afterward. Two defrost algorithms exist (debug param 06). The IDU needs internal state tracking for this.

### What the documentation rules OUT

- **No DIP switches** documented for the IDU — all configuration is via wired controller and stored in EEPROM/flash.
- **No sleep mode** for the duct type (that's a wall-unit/cassette feature). The sleep_* captures may be from a period when a different controller was attached, or the wired controller timer function.
- **No turbo/quiet mode** documented for the ducted unit.

## Updated Theory

byte[11] is a **composite value**:

- **Base value (bits[7:1])**: A volatile counter loaded from EEPROM at boot, incrementing slowly with cumulative powered-on time. Possibly a coarse runtime counter (hours?) used by the ODU for IDU session tracking or the filter-clean infrastructure. The different "bands" (23-25, 29-30, 32-33) represent different total runtime accumulated across the unit's lifetime.

- **LSB (bit0)**: A **coil-condition gate flag** that toggles at temperature thresholds:
  - After cooling: 0→1 when coil rises above ~17°C (post-run dryout complete)
  - After heating: 1→0 when coil drops below ~30°C (residual heat dissipated)
  - During active operation: locked to a fixed value

- **SCMI constant `0x1A`**: The SCMI controller module has no fan/coil to manage and no EEPROM runtime counter to load — sends a fixed hardware ID or "not applicable" value.

## Confidence: Low-Medium

The EEPROM-loaded runtime counter theory is the strongest available, but the exact counting mechanism (rate, reset conditions, seeding) is unproven. See test plan below.

---

## Test Plan

### Test 6: Runtime counter validation (CRITICAL)

**Goal**: Determine if byte[11] base value increments with cumulative powered-on time.

**Procedure**:
1. **Hard power-cycle** the IDU (breaker off, wait 30 seconds, breaker on).
2. Start capture immediately. Record byte[11] value once it jumps from 0x00 (should happen in first 2-3 frames). Note the value as `V_start`. Note the exact time.
3. Leave the IDU powered on (any mode — standby is fine) for **exactly 4 hours**.
4. Record byte[11] at the end of 4 hours. Note value as `V_4h`.
5. **Hard power-cycle** again. Capture byte[11] at boot. Note value as `V_reboot`.

**Analysis**:
- If `V_4h > V_start` and `V_reboot ≈ V_4h`: it's a persistent EEPROM counter that increments with uptime.
- If `V_4h > V_start` but `V_reboot ≈ V_start`: it's volatile (RAM-only) and resets each boot — the initial seed comes from elsewhere.
- If `V_4h = V_start` throughout: the increment period is longer than 4 hours, or it's not a runtime counter.

### Test 7: Counting rate measurement

**Goal**: Measure how fast byte[11] base value increments.

**Procedure**:
1. After power-on, note byte[11] and the time.
2. Check byte[11] every 30 minutes for 8 hours (or leave capture running).
3. Record every transition of the base value (ignoring the LSB toggle).

**Expected**: If the base value (byte[11] >> 1) increments by 1 every N hours, this gives the counting rate. Compare to the filter-clean timer thresholds (100–10,000 hours) to see if they share a common base.

### Test 8: Boot seed investigation

**Goal**: Determine what seeds the initial byte[11] value at boot.

**Procedure**:
1. Power-cycle and record boot value (e.g., 0x1E = 30).
2. Via the wired controller, **reset the filter clean reminder** (if accessible).
3. Power-cycle again and record boot value.
4. If unchanged, change the **ESP setting** (P30) and power-cycle. Record boot value.
5. If unchanged, change the **defrost mode** (debug param 06) and power-cycle. Record boot value.

**Analysis**: If any wired controller parameter change shifts byte[11]'s boot value, that parameter is the seed (or part of it).

### Test 9: LSB toggle threshold precision

**Goal**: Confirm the exact coil temperature thresholds for LSB toggling.

**Procedure**:
1. Run cooling for 10+ minutes (coil cold). Stop compressor (set to standby or fan-only).
2. Capture continuously. Monitor byte[9] (coil temp, C+40) and byte[11].
3. Record the exact byte[9] value when byte[11] LSB transitions.
4. Repeat for heating: run heating, stop, watch coil cool down.

**Expected**: LSB toggles at a consistent coil threshold (~17°C after cooling, ~30°C after heating based on existing captures). These thresholds likely correspond to the anti-cold-wind release temperature and the post-run dryout completion temperature documented in the service manual.