Tap into the button wiring in the control panel (if you’re qualified!). Maybe you’ll be able to type FF (hexadecimal) seconds, resulting in cooking time of 150+15=165 seconds!
Now seriously, a big portion of BCD (binary-counting-decimal) equipment is actually binary-to-hexadecimal but the counter is expected to reset before reaching A. Sometimes it doesn’t:
Another video, super compressed, by me, shot on a feature phone:
You also see it go to 3 st 14 lb, which should not be possible because it’s suppoded to show 4 st 0 lb at that point. (I use kilograms, I was just wondering what the switch in the battery compartment does.) I originally thought the ASIC inside would be a kind of microcontroller stripped down to what’s needed: CPU (8- or even 4-bit, likely von Neumann) with a few registers (hard to call that RAM), (EE?)PROM for the program and calibration data (there’s a pair of pins labeled “CAL” for a jumper or serial interface; I won’t mess with them), 1:4 multiplexed LCD driver, digital input (not even GPIO) pins for the unit switch and calibration interface, differential amplifier and A/D converter, plus some support circuitry like an RC oscillator for the CPU clock, charge pump for the LCD, low battery voltage detector and sleep/wake circuit for power saving. This could enable the same ASIC to be used in personal and kitchen scales, maybe even pressure gauges, thermometers or more, just with a different program, LCD and external components. However, now I see that there is likely no CPU because doing the math in software would make such errors impossible. So there’s most likely a hardwired logic system with hardware counters (just a little more complex than those cheap 3½-digit multimeters), binary-to-hex-7seg-digit converters and a flaky analog threshold system in the st:lb mode (the kg mode is a robust 1500-count decimal counter).
Tap into the button wiring in the control panel (if you’re qualified!). Maybe you’ll be able to type FF (hexadecimal) seconds, resulting in cooking time of 150+15=165 seconds!
Now seriously, a big portion of BCD (binary-counting-decimal) equipment is actually binary-to-hexadecimal but the counter is expected to reset before reaching A. Sometimes it doesn’t:
https://www.youtube.com/watch?v=MvZgfj0_hJU&t=86
Another video, super compressed, by me, shot on a feature phone:
You also see it go to 3 st 14 lb, which should not be possible because it’s suppoded to show 4 st 0 lb at that point. (I use kilograms, I was just wondering what the switch in the battery compartment does.) I originally thought the ASIC inside would be a kind of microcontroller stripped down to what’s needed: CPU (8- or even 4-bit, likely von Neumann) with a few registers (hard to call that RAM), (EE?)PROM for the program and calibration data (there’s a pair of pins labeled “CAL” for a jumper or serial interface; I won’t mess with them), 1:4 multiplexed LCD driver, digital input (not even GPIO) pins for the unit switch and calibration interface, differential amplifier and A/D converter, plus some support circuitry like an RC oscillator for the CPU clock, charge pump for the LCD, low battery voltage detector and sleep/wake circuit for power saving. This could enable the same ASIC to be used in personal and kitchen scales, maybe even pressure gauges, thermometers or more, just with a different program, LCD and external components. However, now I see that there is likely no CPU because doing the math in software would make such errors impossible. So there’s most likely a hardwired logic system with hardware counters (just a little more complex than those cheap 3½-digit multimeters), binary-to-hex-7seg-digit converters and a flaky analog threshold system in the st:lb mode (the kg mode is a robust 1500-count decimal counter).