(05-10-2026, 11:54)Cafeole Wrote: Multumesc pentru raspuns! L-am comandat pe cel de pe emag. Sper sa reusesc sa il montez. Este complicat?

(05-10-2026, 13:04)Cafeole Wrote: De cateva ori am prajit via adaptorul vandut de Hibean pe aliexpress; am salvat cateva roasts cu acesta, insa din ce am citit un control mai bun il ofera adaptorul community, de aceea vreau sa il incerc. Am vazut o sumedenie de grafice si majoritatea ar fi obtinute cu community. La unele spuneau ca s-au obtinut roasts foarte bune, de aici dorinta de a incerca sa obtin rezultate cat de cat asemanatoare.

Quote:For technically savvy users, the Alpha may have the option to connect to a computer or Artisan roasting tracking software via its USB interface.
Such connection and modification may require special technical knowledge, therefore we cannot provide technical support for this.

(12-10-2026, 20:43)BennyLooterKing Wrote: Mai asteptam poate vede mesajul si rezolva, dar intrebare merita cel la 3000 de lei cu artisan chiar daca pentru inceput vreau sa prajesc de pe acel display? @renatoa

(01-10-2026, 19:15)renatoa Wrote: Nu stiu daca si l-a luat cineva, dar daca da, probabil nu are curaj sa se laude... prea l-am criticat eu de cate ori am avut ocazia

(13-10-2026, 15:03)renatoa Wrote: Pai nu am raportat in pagina anterioara ca noua placa nu se mai intelege cu vechiul controller ?
La momentul acela nici 3.4 nu se intelegea, 3.6 nu aparuse inca...

Quote:Fixed the issue of motherboard loss of control in v3.6 by Bear.
 
? Solved: Full Control of Skywalker Roaster v3.6 Mainboard with ESP32 (No Level Shifter Needed!)
? TL;DR / Executive Summary
If your ESP32-based controller on the new Skywalker v3.6 mainboard exhibits:
 
Relay clicking but heating elements staying completely dark/cold
 
Exhaust fan vibrating/stuttering at 60Hz or only running at a weak ~20% speed
 
Cooling fan running extremely weak
 
Communication dropping out or watchdog tripping
 
? It is NOT a 3.3V vs 5V logic level voltage problem! You DO NOT need a logic level shifter.
 
Native 3.3V GPIOs (including onboard USB-C D+/D- on ESP32-S3) drive the v3.6 board reliably.
 
The real culprit is a firmware timing starvation issue (inter-packet blackout), coupled with an AC Operation Mode lock byte and hardware safety interlocks.
 
? Detailed Root Cause Analysis
1. The Fatal Bug: Inter-Packet Blackout & TRIAC/PWM Starvation (The 20% Fan Bug)
How the v3.6 Board Works:
 
Unlike older revisions, the v3.6 mainboard’s onboard MCU requires a continuous, uninterrupted stream of valid control packets to maintain its internal zero-crossing TRIAC phase-angle triggers (exhaust fan and heater) and PWM timers (cooling fan).
 
The Stock Controller Behavior:
 
The OEM stock hand controller is a dedicated microcontroller that transmits a ~90ms packet, pauses for barely a few milliseconds, and immediately transmits the next preamble. There is virtually zero transmission downtime.
 
The Community Firmware Defect:
 
In previous firmware versions (e.g., v2.37 and earlier), TX packet transmission and RX temperature acquisition were coupled synchronously in the same thread. When calling receiveSerialBitsFromRoaster(), pulseIn() blocks execution for 150ms ~ 240ms waiting for temperature pulses.
 
The Result:
 
After sending a 90ms packet, the TX line goes completely silent for 70ms ~ 260ms. During this transmission gap, the roaster MCU’s TRIAC triggers and PWM refresh timers starve and drop out. This causes:
 
The AC exhaust fan to chatter/vibrate at 60Hz or spin at only ~20% duty cycle.
 
The heating element TRIAC never achieves sufficient conduction angle (the relay stays closed, but the tube never heats up).
 
Cooling fan PWM collapses to a crawl.
 
2. Byte 1: The AC Mode Lock (0x04 vs 0x00)
Byte 1 (Index [1], historically labeled FILTER_BYTE):
 
On the v3.6 firmware, Byte 1 acts as an AC Power/TRIAC Mode Lock:
 
During Roasting / Active Venting (VENT > 0 or HEAT > 0): Byte 1 MUST be set to 0x04. Setting it to 0x00 (or 0x01) places the roaster in Standby, locking out the heater TRIAC and corrupting the fan phase triggers.
 
In Standby / Shutdown: Byte 1 must be set back to 0x00.
 
3. Safety Interlock (Anti-Dry-Burn Protection)
The v3.6 firmware enforces strict safety rules:
 
Whenever HEAT > 0, DRUM must be running (100 / 0x64) and exhaust ventilation must be active (VENT >= 50).
 
If Heat is engaged while Drum is 0, the mainboard’s hardware safety trips the relay within hundreds of milliseconds (causing repetitive 1-second relay clicking).
 
?️ The Solution: Decoupled Continuous TX on Core 0
To eliminate the transmission gaps, TX must be decoupled from temperature reading (pulseIn) and moved to a dedicated FreeRTOS task pinned to Core 0 that streams packets continuously.
 
1. Continuous Non-Stop TX Function & Task (Pinned to Core 0)
C++
// Buffer definitions
static rmt_symbol_word_t tx_symbols[1 + CONTROLLER_LENGTH * 8];
 
void sendRoasterMessageContinuous() {
    uint8_t snapshot[CONTROLLER_LENGTH];
    memcpy(snapshot, sendBuffer, CONTROLLER_LENGTH);
 
    // ? v3.6 Safety & Mode Lock Enforcement
    if (snapshot[VENT_BYTE] > 0 || snapshot[HEAT_BYTE] > 0) {
        snapshot[FILTER_BYTE] = 4; // Byte 1 MUST be 0x04 to unlock AC TRIACs
        if (snapshot[HEAT_BYTE] > 0) {
            snapshot[DRUM_BYTE] = 100; // Mandatory drum rotation during heat
            if (snapshot[VENT_BYTE] < 50) {
                snapshot[VENT_BYTE] = 50; // Maintain base exhaust airflow
            }
        }
    } else {
        snapshot[FILTER_BYTE] = 0; // Standby / Cooling mode: 0x00
    }
 
    // Standard 8-bit checksum: Sum(Byte 0..4) & 0xFF
    uint8_t sum = 0;
    for (int i = 0; i < (CONTROLLER_LENGTH - 1); i++) {
        sum += snapshot[i];
    }
    snapshot[CHECK_BYTE] = sum;
 
    // Encode RMT symbols (Preamble: Low 7500us, High 3800us)
    int idx = 0;
    tx_symbols[idx].val = 0;
    tx_symbols[idx].val |= (START_PULSE & 0x7FFF);
    tx_symbols[idx].val |= (0 << 15);
    tx_symbols[idx].val |= ((START_DELAY & 0x7FFF) << 16);
    tx_symbols[idx].val |= (1U << 31);
    idx++;
 
    // Data Bits (LSB first: 1 = Low 1500us / 0 = Low 650us, Gap = High 750us)
    for (int i = 0; i < CONTROLLER_LENGTH; i++) {
        for (int j = 0; j < 8; j++) {
            int low_dur = (bitRead(snapshot[i], j) == 1) ? 1500 : PULSE_ZERO;
            tx_symbols[idx].val = 0;
            tx_symbols[idx].val |= (low_dur & 0x7FFF);
            tx_symbols[idx].val |= (0 << 15);
            tx_symbols[idx].val |= ((POST_PULSE_DELAY & 0x7FFF) << 16);
            tx_symbols[idx].val |= (1U << 31);
            idx++;
        }
    }
 
    rmt_transmit_config_t tx_conf = {
        .loop_count = 0,
        .flags = { .eot_level = 1 }
    };
 
    if (rmt_transmit(tx_channel, copy_encoder, tx_symbols,
                     idx * sizeof(rmt_symbol_word_t), &tx_conf) == ESP_OK) {
        rmt_tx_wait_all_done(tx_channel, 200); // Wait for the ~90ms packet to complete
    }
}
 
// ? Dedicated Background TX Task: Eliminates the 100ms+ blackout window
void roasterTxTask(void *pvParameters) {
    vTaskDelay(pdMS_TO_TICKS(1000)); // Boot stabilization delay
    for (;;) {
        sendRoasterMessageContinuous();
        vTaskDelay(pdMS_TO_TICKS(2)); // Immediately send next packet (2ms yield for WDT)
    }
}
2. Setup Initialization
In setup():
 
C++
    setupRMT_TX();
    pinMode(RX_PIN, INPUT);
 
    // Launch background TX task on Core 0 with priority 5
    xTaskCreatePinnedToCore(roasterTxTask, "RoasterTX", 4096, NULL, 5, NULL, 0);
3. Main Loop (loop()) Cleanup
Remove any calls to sendRoasterMessage() inside loop() or receiveSerialBitsFromRoaster(). Let receiveSerialBitsFromRoaster() strictly handle reading incoming 56-bit temperature data without blocking the TX queue.
 
? Verification & Results
Once this firmware structure is applied:
 
Exhaust Fan: Runs smoothly and whisper-quiet across all power levels (0–100%) without any 60Hz magnetic shuddering.
 
Heater: The element starts glowing red within 3–5 seconds of engaging heat.
 
Hardware: Fully verified using a direct USB cable connection (ESP32-S3 Zero / DevKitC-1 straight into the roaster port) without any level shifter hardware.

Quote:No ESP32-S3 pin is 5V tolerant, so you must connect the VBUS to ESP32-S3 via a comparator with voltage thresholds as described above, or use a simple resistor voltage divider that will output (0.75 x Vdd) if VBUS is 4.4V (see figure below).

Quote:The ESP32-S3 GPIO pins are 3.3V tolerant only, with an absolute max around 3.6V.
Sending 5V logic straight into a pin risks permanent damage,
so you need a voltage divider or level shifter for 5V sensors or signals.