Reflow low v

GreenToaster

A reflow oven controller that turns an ordinary toaster oven into a reflow oven for soldering surface-mount boards. An RP2040 reads a platinum RTD probe in the oven, follows a solder profile on a 3.5" touchscreen, and switches the oven's mains through a solid-state relay, all inside a sealed 3D-printed enclosure that sits between the wall socket and the oven.

Preface

Reflowing a board properly means following a temperature profile: preheat, soak, a short peak above the solder's melting point, then cooling. A toaster oven gets hot enough, but its thermostat can't follow a curve. GreenToaster replaces the thermostat. Plug the oven into GreenToaster, put the probe in the oven, pick a profile, and the controller drives the heater to track it.

[!WARNING] This project switches mains voltage (230 V AC). The power board, the SSR and the wiring in the tower carry lethal voltages. Only build it if you are competent with mains wiring, keep the tower closed when powered, and fit an independent thermal cutoff (a bimetal snap-disc or a thermal fuse) in series with the oven's heater. The firmware's safety layers can't help if the microcontroller itself fails. Never leave the oven unattended.

Contents

1. How it fits together
2. Stage by stage
3. What you can configure
4. Building one
5. The case
6. Repository layout

1. How it fits together

The design is split along the line every mains project should be: a mains side, sealed in the rear "tower" of the case, and a low-voltage side in the front "wedge", separated by a solid firewall with a single low-voltage pass-through.

flowchart LR
    subgraph mains["Mains side: the tower"]
        IN["C14 inlet<br/>230 V AC"] --> PB["Power board<br/>fuse, MOV, X-cap, choke<br/>HLK-10M05"]
        IN --> SSR["SSR<br/>on heatsink"]
        SSR --> OUT["Outlet<br/>the oven plugs in here"]
        FAN["60 mm fan<br/>cools the SSR heatsink"]
    end
    subgraph lv["Low-voltage side: the wedge"]
        CB["Controller board<br/>RP2040"]
        LCD["3.5in touchscreen"]
        SW["SW1..SW5<br/>interlock chain"]
        RTD["MAX31865<br/>RTD amplifier"]
    end
    PB -- "5 V" --> CB
    CB -- "5 V" --> FAN
    CB <--> LCD
    PROBE["PT100 probe<br/>in the oven"] --> RTD --> CB
    CB -- "SSR drive" --> SW -- "only if all 5 closed" --> SSR

Every 250 ms during a run:

1. The RP2040 reads the oven temperature from the RTD.
2. It works out where the profile says the temperature should be.
3. It sets the heater power.

That power becomes on/off time within a two-second window on the SSR, which switches the oven's mains. The SSR drive passes through five physical switches on the front panel. If any one is open, the oven cannot heat, whatever the firmware is doing.

2. Stage by stage

Stage 1 — The power board (hardware/power-board)

A small single-purpose mains board, 116 × 55 mm, that turns the wall supply into the controller's 5 V. In signal order:

Mains comes in on J1 (pin 1 neutral, pin 2 line) and 5 V leaves on J2. Both are large 7.62 mm screw terminals. The board carries no logic at all: the SSR and the oven outlet are wired directly in the tower.

Stage 2 — The controller board (hardware/controller-board)

A 98 × 68.5 mm carrier with ground poured on both sides. It holds the microcontroller and connects it to everything else:

5 V from J6 feeds the Pico's VSYS. The WeAct module's own USB connector also feeds VSYS through its on-board diode, so USB alone powers the board for flashing. The display is write-only: its data-out pin isn't connected, so only the touch controller talks back on SPI1. The full pin map is in firmware/include/board_pins.h.

Stage 3 — Reading the temperature (firmware/src/sensor.cpp)

The probe is a platinum RTD read by a MAX31865 in continuous conversion mode. The chip converts on its own, and the firmware just collects a sample every 250 ms, so reading the oven never stalls the touchscreen. Resistance becomes temperature through the Callendar–Van Dusen equation for IEC 60751 platinum sensors.

Faults are decoded rather than hidden. NO SENSOR, RTD OPEN, RTD SHORT, RTD OV/UV or RTD RANGE replaces the reading on screen. Each detected fault is cleared and fault detection re-armed, so a passing glitch can't latch.

Stage 4 — The interlock chain (firmware/src/interlock.cpp)

The SSR is driven from GPIO 16 through all five panel switches in series:

GP16 → SW1 → SW2 → SW3 → SW4 → SW5 → J5 (SSR+)
          ↓      ↓      ↓      ↓      ↓
        GP28   GP27   GP26   GP22   GP21     (taps, read by the firmware)

Opening any switch physically cuts the SSR drive. The taps between the switches, held low by the RP2040's internal pull-downs, let the firmware see how far the chain is closed. It counts closed switches from SW1 onwards, so a floating input can never report more than are really closed.

Reading the taps needs GP16 high, and GP16 high with all five closed is the heater on. So while arming, the firmware senses with 50 µs pulses, at most 50 per second, which is far too little to heat anything. During a run it reads the taps for free during the SSR's on-time.

Stage 5 — The control loop (firmware/src/control.cpp)

The controller is feed-forward plus PID:

duty = feed_forward(setpoint) + PID(setpoint − measured)

• Feed-forward comes from a first-order model of your oven, measured by the dry run (stage 6). From the oven's gain (°C per % of power), time constant and ambient temperature, it works out the power the profile needs, so the oven tracks a ramp rather than lagging behind it. It's evaluated one oven dead-time ahead, so the power arrives when it's needed.
• PID only corrects what the model gets wrong. It uses derivative-on-measurement, so there's no kick when the profile changes slope. It uses conditional integration, so it doesn't wind up while the heater is saturated.
• Peak coast: on the final climb, the heater is cut 3 °C short of the peak and the elements' stored heat carries the rest. This is decided before the PID runs, so the integrator can't wind up during the coast.
• The run starts from the measured temperature, not an assumed ambient, so starting in a still-warm oven doesn't overshoot the first section.

The SSR is time-proportional over a 2 s window, which is 100 mains half-cycles at 50 Hz, so the duty resolution is 1 %.

Stage 6 — Calibrating to your oven: the dry run

Instead of hand-tuning, the controller measures your oven in an automatic dry run, with the oven empty and cold (it refuses to start above 50 °C):

Phase 3 is the Åström–Hägglund relay method, which characterises the oven at reflow temperature. The PID gains use the no-overshoot rule (Kp = 0.2·Ku, Ti = 0.5·Pu, Td = 0.33·Pu), because overshoot on a reflow profile is what damages boards. Each phase has a timeout, so a fault can't leave it running.

At the end, the screen shows an Oven characterised card: the oven's gain, heating and cooling rates, Ku/Pu, and the resulting PID gains. The model is saved to flash (/oven.bin) and survives reflashing. Start Reflow is refused until a dry run has succeeded.

Stage 7 — The touchscreen UI (firmware/src/screens_*.cpp)

Home ──┬── Profiles ─── Profile view ──── Arming ──── Run (live graph)
       │                 (graph, Start Reflow / Dry Run)
       └── New Profile ─── Section editor

• Home: the live temperature, plus Profiles and New Profile.
• Profiles: the built-ins and your saved profiles, five per page. Saved ones have a delete button; the built-ins can't be deleted.
• Profile view: the profile as a temperature-against-time graph, with Start Reflow and Dry Run.
• Arming: five bars that fill in as you close SW1 to SW5. The run starts the moment the fifth one closes.
• Run: the target curve in orange and the measured temperature in cyan on one graph, with target, elapsed time, the heater duty and STOP. When the profile's temperature starts falling, it tells you to open the oven door, since cooling is done by the door.
• New Profile / Section editor: build a profile from sections, each a target temperature and the time to reach it. New profiles are named Profile 1, Profile 2, and so on.

A four-button rail down the right edge (UP, DOWN, SAVE, BACK) keeps the same meaning on every screen. Held buttons auto-repeat after 450 ms, so stepping a temperature up doesn't take dozens of taps. The case's bezel covers the panel's left edge, so every screen is laid out clear of it.

Safety layers

1. The hardware interlock: the SSR cannot be driven unless all five switches are closed.

2. The independent thermal cutoff you fit in series with the heater (see the warning above).

3. Software aborts:

   • temperature above 280 °C;
   • the sensor unreadable for 3 s;
   • the interlock opening while the heater is on;
   • over 95 % power for 3 minutes with less than a 3 °C rise. This catches a dead element, a dead SSR, or a probe that isn't in the oven.

   A run also won't start if the sensor is faulty, the oven is already over 280 °C, or another run is in progress.

4. A hardware watchdog (8 s), armed as soon as any run is armed and kept until the next reboot. If the firmware hangs, the reset drops every pin to high impedance, which the SSR reads as off.

3. What you can configure

The RTD module — firmware/platformio.ini

Profiles

Built in, and can't be deleted:

Your own: up to 12 profiles of up to 16 sections, built on the touchscreen. A section is a ramp: a target temperature (up to 300 °C, in 5 °C steps) and the time to reach it from the previous section (up to 900 s, in 5 s steps). A hold is a section that repeats the previous temperature. Profiles are stored in flash, written through a temporary file so a power cut can't corrupt them.

The serial console (115200 baud)

While the oven is being driven, the board also prints one CSV telemetry line per second (R,t_s,mode,phase,temp_c,set_c,duty_pct,armed), which firmware/scripts/log_run.py captures to a log file.

Other settings

4. Building one

The boards

Both are 2-layer boards made with KiCad 10. Open the .kicad_pro in each folder under hardware/ and plot gerbers and drill files. Each project carries copies of every symbol and footprint it uses, so the boards open and plot without any extra libraries. Schematic PDFs are in docs/.

Also needed: an SSR with a heatsink, a 60 mm 5 V fan, a C14 inlet, an outlet for the oven, a PT100 probe (3-wire to match the default build), mains-rated wire, and the thermal cutoff.

The firmware

cd firmware
pio run                 # build
pio run -t upload       # flash
pio device monitor      # serial console, 115200 baud

Uploading needs no driver. scripts/upload_uf2.py resets the board into its bootloader and copies the firmware onto the RPI-RP2 drive, so you don't need picotool, Zadig or the BOOT button.

First use

1. Power up and check the banner on the serial console. It reports the storage, the RTD settings and whether the oven is calibrated.
2. Check the probe with t at room temperature. If it's off, fix the RTD build flags.
3. Check the interlock with i, closing the switches one at a time.
4. Optionally test the SSR with T.
5. Run a Dry Run once from a cold, empty oven: open any profile and tap Dry Run.
6. Reflow: pick a profile, tap Start Reflow, close the five switches, and open the door when the screen says so.

5. The case

Five printable parts, in case/:

The mains side and the low-voltage side never share an open space. The only link between them is a single low-voltage pass-through in the firewall.

6. Repository layout

hardware/
  power-board/          KiCad project: the 230 V AC to 5 V board
  controller-board/     KiCad project: the RP2040 controller board
firmware/               PlatformIO project
  platformio.ini          build settings, display and RTD configuration
  include/, src/          the firmware (pin map in include/board_pins.h)
  scripts/                UF2 uploader, run logger, interlock watcher, layout check
case/                   STL files for the five printed parts
docs/
  power-board-schematic.pdf
  controller-board-schematic.pdf
  images/               renders used in this README