# IDU 0x31[4:5] — Revised Hypothesis & Test Plan

## Background

The ASD-60BI2 ducted IDU uses a **DC brushless indoor fan motor** driven by a **separate DC fan driver sub-board** with its own MCU, EEPROM, and serial link to the IDU main controller (error code `qC` = master/fan-driver comm failure).

The fan system uses **13 internal speed steps (S01–S13)**. The 4 user-facing speeds (Low / Medium / High / Super High) map to different S-levels depending on the **ESP (External Static Pressure) setting** configured via wired controller parameter P30 (default P05, range P01–P09 for high-ESP duct units):

| P30 | Super High | High | Medium | Low |
|-----|-----------|------|--------|-----|
| P01 | S05 | S03 | S02 | S01 |
| P02 | S06 | S04 | S03 | S02 |
| P03 | S07 | S05 | S04 | S03 |
| P04 | S08 | S06 | S05 | S04 |
| **P05 (default)** | **S09** | **S07** | **S06** | **S05** |
| P06 | S10 | S08 | S07 | S06 |
| P07 | S11 | S09 | S08 | S07 |
| P08 | S12 | S10 | S09 | S08 |
| P09 | S13 | S11 | S10 | S09 |

The wired controller has **5 fan settings**: Low, Medium, High, Super High, and Auto.

Source: Sinclair engineering data book (uni-split 2 series), service manual, user manual, installation manual for the ASD-xxBI2 range.

## Hypothesis: byte[5] is a bitfield

Analysis of the `IDU_stdby_cool_fan_cycle` capture (249 IDU 0x31 frames) shows byte[5] decomposes into independent sub-fields:

### byte[5] bit layout

```
  bit7  bit6  bit5  bit4  bit3  bit2  bit1  bit0
 [---- 7:6 ----]   0     0   [---- 3:2 ----]  strobe  0
  fan driver fb                fan speed step   chg
```

| Sub-field | Values | Behavior |
|-----------|--------|----------|
| **bits[7:6]** | 0, 1, 2 | Cycles autonomously every 2–6 frames. Independent of user actions and byte[4] changes. Does NOT correlate with byte[15:16] alternation. |
| **bits[3:2]** | 0, 1, 2, 3 | Steps discretely — holds for 5–18 frames per value. Candidate for fan speed encoding. |
| **bit1** | 0 or 1 | Strobes HIGH for ~5 frames during temperature setpoint changes. Observed at frames 185–189, exactly when byte[6] transitions. |
| **bit0** | always 0 | Unused in current captures. |
| **bits[5:4]** | always 0 | Unused in current captures. |

### bits[3:2] stepping in the byte[4]=0x01 region

In the `IDU_stdby_cool_fan_cycle` capture, during byte[4]=0x01 (frames 1–53):

| Frames | bits[3:2] | Candidate speed |
|--------|-----------|-----------------|
| 1–4 | 3 | Prior state (Super High?) |
| 5–16 | 0 | Low |
| 17–21 | 1 | Medium |
| 22–29 | 2 | High |
| 30–47 | 3 | Super High |
| 48–53 | 0 | Reset before Auto transition |

This gives **4 discrete steps (0→1→2→3)** matching the 4 manual fan speeds, with a 5th action (Auto) triggering byte[4] to change from 0x01 to 0x02.

**NOT YET CONFIRMED** — the capture lacks timestamps and the user's exact button-press timing is uncertain. Dedicated tests needed (see Test Plan below).

### bits[7:6] — fan driver feedback

This field cycles 0→1→2→0 at its own pace (~4–12 frames per cycle), regardless of user actions, byte[4] value, or operating mode. It is **always 0 when byte[5] is 0x00** (i.e., during heating/anti-cold-wind when the fan is off).

Hypothesis: this is a **motor state feedback** signal relayed from the DC fan driver sub-board — possibly commutation sector, phase current quadrant, or a driver heartbeat counter. The sub-board has its own MCU and communicates with the IDU main controller.

### bit1 — settings change strobe

Observed exactly once in the capture set: frames 185–189 of `IDU_stdby_cool_fan_cycle`, during the temperature setpoint change (byte[6] transitions 0x3E→0x3F→0x40). Fires for 5 consecutive frames then clears. Likely signals "wired controller parameter change in progress" to the ODU.

## Hypothesis: byte[4] is fan mode / demand level

| byte[4] | Meaning | Context |
|---------|---------|---------|
| `0x00` | Transitional / init | First frame of some captures |
| `0x01` | Manual fan mode | All 4 user-selected speeds (L/M/H/SH); actual speed in byte[5] bits[3:2] |
| `0x02` | Auto fan — lower demand | IDU auto-algorithm selected; speed still in bits[3:2] |
| `0x03` | Auto fan — higher demand | IDU auto-algorithm selected; speed still in bits[3:2] |
| `0x80` | Standby / fan off | Compressor off, fan stopped |
| `0x81` | Afterblow / wind-down | Transitional state between active and standby |

In auto mode (byte[4]=0x02/0x03), the IDU controller internally selects a fan speed and reports it via bits[3:2]. byte[4] may encode the demand band or thermal load estimate rather than a direct speed.

### Heating behavior

In `IDU_heat_long_cap`, byte[5] is **always 0x00** — all sub-fields zero. This matches anti-cold-wind behavior: the indoor fan is suppressed during heating until the coil warms up. When the fan is off, there is no motor feedback and no speed to report.

## What's NOT explained

1. **byte[4] = 0x02 vs 0x03 boundary**: What determines when auto mode switches between these two demand levels? Temperature delta? Compressor state?

2. **bits[3:2] behavior in auto mode**: In byte[4]=0x02, bits[3:2] cycles through 0→1→2→3→0 (one full revolution over ~74 frames). In byte[4]=0x03, bits[3:2] stays at 0 for ~60 frames then jumps to 3. If bits[3:2] is speed, the auto algorithm appears to sweep speeds differently at different demand levels.

3. **bits[7:6] physical meaning**: Motor phase, current feedback, or just a driver heartbeat? Cannot be determined from protocol captures alone — would need oscilloscope on the fan driver communication link.

4. **Fan speed during heating**: byte[5]=0x00 even after anti-cold-wind releases and the fan is confirmed running. Either the fan speed is communicated differently during heating, or the IDU only reports fan speed during cooling/fan modes.

5. **bits[3:2] as counter vs speed**: An alternative interpretation is that bits[3:2] is an autonomous slow counter (not user-controlled), cycling 0→1→2→3 every ~90–120 seconds regardless of user input. The timing in the capture is ambiguous without timestamps. The test plan below is designed to distinguish between these two interpretations.

## Confidence: Low-Medium

The bitfield decomposition is solid (independent cycling rates, bit1 strobe correlation). The speed-step interpretation of bits[3:2] is plausible but unconfirmed — it relies on the assumption that user button presses happened at ~15–30 second intervals matching the observed transitions.

---

## Test Plan

### Test 1: Fan speed isolation (CRITICAL)

**Goal**: Determine whether byte[5] bits[3:2] encodes the user-selected fan speed.

**Procedure**:
1. Set cooling mode, any setpoint. Wait for steady-state (compressor running, stable bus traffic).
2. Set fan to **Low**. Wait **2 full minutes** without touching anything. Note the capture line number.
3. Press fan speed UP once (to **Medium**). Wait **2 full minutes**. Note the line number.
4. Press fan speed UP once (to **High**). Wait **2 full minutes**. Note the line number.
5. Press fan speed UP once (to **Super High**). Wait **2 full minutes**. Note the line number.
6. Press fan speed UP once (to **Auto**). Wait **2 full minutes**. Note the line number.
7. Press fan speed DOWN back through each step with 2-minute waits.

**Expected if bits[3:2] = fan speed**: bits[3:2] will jump discretely at each noted line number and hold steady between presses. The value will be constant during each 2-minute wait, only bits[7:6] will cycle.

**Expected if bits[3:2] = autonomous counter**: bits[3:2] will continue cycling 0→1→2→3 regardless of button presses, with no correlation to the noted line numbers.

**Marker technique**: Change the temperature setpoint by +1 then -1 at each fan speed change point. The bit1 strobe in byte[5] will mark the exact frame in the capture where each action happened, making post-hoc correlation trivial even without timestamps.

### Test 2: byte[4] vs fan mode

**Goal**: Confirm byte[4] encodes manual-vs-auto fan mode.

**Procedure**:
1. In cooling mode, set fan to **Low**. Wait 1 minute. Record byte[4].
2. Switch to **Auto**. Wait 1 minute. Record byte[4].
3. Switch back to **Low**. Wait 1 minute. Record byte[4].

**Expected**: byte[4] = 0x01 during manual speeds, byte[4] = 0x02 or 0x03 during auto. The transition should be immediate (within 1–2 frames of the button press).

### Test 3: Heating fan behavior

**Goal**: Determine why byte[5] is always 0x00 in heating.

**Procedure**:
1. Set heating mode. Start capture.
2. Wait for anti-cold-wind to release (byte[12] bit3 clears, fan starts blowing warm air).
3. Continue capturing for 5+ minutes after fan starts.
4. Cycle through all 5 fan speed steps with 1-minute waits between each.

**Expected if byte[5] reports speed in heating**: bits[3:2] should become non-zero after anti-cold-wind release and respond to fan speed changes.

**Expected if heating fan is encoded differently**: byte[5] stays 0x00 even with fan running. In that case, check byte[4] — it may carry the speed during heating.

### Test 4: ESP setting effect

**Goal**: Determine if the ESP (P30) setting appears on the bus.

**Procedure**:
1. Record current P30 value (likely P05 default).
2. In cooling at a fixed fan speed (e.g., High), capture 1 minute of steady traffic.
3. Change P30 to P03 via wired controller. Capture 1 minute at the same fan speed.
4. Change P30 to P07. Capture 1 minute at the same fan speed.
5. Restore P30 to P05.

**Watch**: byte[4], byte[5], and any other IDU 0x31 byte that changes. If the S-level is encoded, different ESP settings at the same user speed should produce different bus values. If only the user speed abstraction is sent, the bytes won't change.

### Test 5: bit1 strobe reproducibility

**Goal**: Confirm bit1 is a settings-change indicator.

**Procedure**:
1. In steady cooling, change temperature setpoint up by 1°C. Wait 30 seconds.
2. Change setpoint down by 1°C. Wait 30 seconds.
3. Change fan speed. Wait 30 seconds.
4. Toggle mode (cool → fan → cool). Wait 30 seconds.

**Watch**: Does bit1 strobe (byte[5] & 0x02) fire after each change? Is it specific to setpoint changes only, or all wired controller actions?