A neat project for sure but as it stands this has major safety issues. The control logic is able to lock up and keep the boilers heating element in an forever "on" state till something snaps. I couldn't find a mention of safety in the manual nor see any mechanical safety failsafes in case of overheating.
> I couldn't [...] see any mechanical safety failsafes in case of overheating.
On the assembly instructions, page 39 shows the boiler assembly has a therm-o-disc thermostat fixed to the top. It's not labelled, you just have to recognise it. The schematic on page 44 shows it's wired in series with the boiler's heater. That provides redundancy for the main temperature control, which is presumably the microcontroller sensing from the PT1000
Page 32 also describes the installation of an overpressure valve (which appears to return water to the cold tank?)
The machine does lack hardware run-dry protection though; as far as I can tell, it relies on a load cell to detect if there's water in the tank. If you ran it without water to conduct heat from the heating element to the thermostat, the thermostat wouldn't function. So it's not entirely safe, as you say.
A thermal fuse isn't for overpressure control, it's intended to trip before a physical overpressure control vents superheated steam. Both provide failover redundancy independent of operational heater controls.
There isn't enough detail of the boiler to tell if there's an overpressure relief valve. The boiler can't be made safe without one. If they're cheap enough to be standard in cheap knockoff moka pots one should be here...
This machine's wiring diagram shows an unlabelled shape wired in series with what might possibly be the heating element and a shape with "ssr" in its label. Which places the first unlabelled shape in the right place to be a thermal fuse or switch. If they're cheap enough to be standard in Mr Coffee machines one should be here...
Safety discussion in this project is conspicuously absent. Knowledgable users shouldn't be making assumptions like this about safety features. Assumptions and safety aren't compatible. Average users should be informed in detail about the safety features they're tasked with assembling.
Are you speaking from experience or did you just study the f/w? I agree, gotta have those thermal switches, and they need to result in killing power on threshold breach.
I read the firmware, it's build with the Arduino IDE and PWM for the heater element is bitbanged and updated from the main loop. Meaning it can easily get stuck sending a MQTT message over wifi when it loses connection, causing the heater to possibly be left on indefinitely.
Lots of 3d printers used to have issues like this with the firmware controlling their hotends. They’d fail on and start a fire. Modern Klipper and Marlin firmware detect wild or unexpected temp swings and pull the “emergency stop” cord to shut it all down.
And speaking of safety, old FPV flight control software didn’t handle a very common mistake. It is very easy to put the wrong propeller on a motor. For example you might accidentally put on the counterclockwise propeller on the motor that spins clockwise. The result is when you arm the quad (as in turn on the motors), it flips its shit because the quad starts moving in a completely unexpected way. The flight control software is designed to “lock the angle (attitude) of the quad in and fight any uncommanded deviation”. Well, a backwards prop produces a hell of an uncommanded deviation!! So the controller tells the motor to spin faster to compensate but all that does is make things worse as the backwards prop pushes the thing in the exact wrong way. So it becomes an out of control quad that can and will cause property damage and injury (the propellers on a quad are large, very sharp and attached to very powerful motors. Coming into contact with a spinning propeller will send you to the hospital). This was a big problem in tight spaces like races and stuff.
A while ago somebody submitted a pull request that added a safety. When first arms, if the quad starts to behave “wrong” or “unexpected”, it immediately disarms. From what I recall it was actually fairly simple to detect too… if the “error” in the PID loop got too high it means something is very wrong mechanically and it’s best shut down. Countless fingers have no doubt been saved by this patch.
It’s probably very similar detection code to what is in 3d printer firmware or espresso machine firmware. If the PID error is “unexpected” something is mechanically wrong and it needs to shut down before Bad Things happen.
The drive to create thinner, lighter, and more energy efficient devices has resulted in modern SoCs being forced to balance a delicate tradeoff between power consumption, heat dissipation, and execution speed (i.e., frequency). While beneficial, these DVFS mechanisms have also resulted in software-visible hybrid side-channels, which use software to probe analog properties of computing devices. Such hybrid attacks are an emerging threat that can bypass countermeasures for traditional microarchitectural side-channel attacks.
Given the rise in popularity of both Arm SoCs and GPUs, in this paper we investigate the susceptibility of these devices to information leakage via power, temperature and frequency, as measured via internal sensors. We demonstrate that the sensor data observed correlates with both instructions executed and data processed, allowing us to mount software-visible hybrid side-channel attacks on these devices.
To demonstrate the real-world impact of this issue, we present JavaScript-based pixel stealing and history sniffing attacks on Chrome and Safari, with all side channel countermeasures enabled. Finally, we also show website fingerprinting attacks, without any elevated privileges.
Cool! I like tiny encoders. I teach assembly programming at a university where one of the final assignments in the course is making a decoder for something similar to LZ77 in Cortex M3 (thumb 2) assembly. Best I could do is 15 instructions / 40 bytes found here: https://gist.github.com/ManDeJan/fd1c625e3540faa41d03736eb94... .
No OP, but I used C and asm. Hi-Tech c compiler. I had no issues with it. Very simple and straightforward to code the PIC chips. I forget how much I paid for it.
Good old C. I am moderately sure it was the MPLAB software, I remember we had several of their ICD JTAG units (the round ones). But it might have been Hitech.
It's definitely the case that some of the ELF header fields can be repurposed to store additional data, the following articles all address that optimization:
There are also a few instructions in the article that are size-suboptimal (e.g. "movl $4, %eax" is 5 bytes (b804000000), while the equivalent "xor %eax, %eax; movb $4, %al" is only 4 bytes (31c0b004)).
I tried to do it as optimal as possible, but I think there is indeed more to be saved with putting code in the elf header, i'm not very familiar with the elf format. This is as small as I could get it without doing that, just using yasm, ld and strip.
I try every year to optimize for speed in zig: https://github.com/ManDeJan/advent-of-code