We discovered this after the first prototypes/consoles were sent to early reviewers. They kept seeing weird in-game behavior no one could replicate, even when affected reviewers tried to demonstrate. Turns out they were gripping hard enough to minutely bend the PCB during intense moments in games, which created voltage spikes the software mistook for button presses. You needed to be angry to replicate.
How did you end up debugging/reproducing? I conjured a picture in my head of an engineer comically exasperated and squeezing the controller followed by an “Aha!”
A story I have heard several times in different instances is some light sensitivity, I think this happened to the Raspberry Pi team (PMIC transient induced by camera flash).
Yes. It’s the Raspberry Pi 2: https://hackaday.com/2015/02/08/photonic-reset-of-the-raspbe...
I had an interesting case around fifteen years ago. I had designed a real time image/video processor using a large Xilinx FPGA at the center of it. The system worked very well, except that it would have problems when flown on a helicopter. Actually, only certain kinds of helicopters, with certain types of cameras.
I scratched my head for months trying to solve this riddle.
Months later, while working on a completely unrelated problem, I touched the FPGA and burned my finger. It was surprisingly hot. This thing ran cool as can be, even without a heatsink.
What happened? At first I thought I had a bad board, so I swapped it out. Sure enough, it got very hot, very quickly.
Huh?
That's when I realized I was using footage from one of the helo's. For some reason my brain made the connection. I instantly knew why we were having problems with helicopter-mounted cameras and why I burned my finger: Vibration.
CMOS consumes power on state transitions, not so much once you reached the final state (low or high). More transitions per unit of time means more power. If the transitions are high speed edges (which is the case for real-time image processing) even worse.
The helicopters in question did not have motion-stabilized cameras. They were hard-mounted to the verticals of the skids and that was that. Which means that every bit of vibration from the helo made it onto the camera. Add that to the helo travelling and you have a perfect storm: Every pixel was changing on every frame at 120 frames per second. The translation was a massive increase in power consumption and heat dissipation. Hence my burned index finger and the problems we had with helo-mounted systems.
So, yeah, the power consumed by an imaging system is a direct function of the rate of change per unit of time of pixel data. A still frame consumes nothing when compared to a busy sequence where every pixel is changing. Logical, yet not obvious when you are not thinking in those terms.
You have to burn your finger (or knock stuff off your desk) to learn this kind of thing.
These days I almost always have a FLIR camera pointed at any new design I am working on. All it takes is getting burned (literally) once.
Keeping with the "unconventional" theme, lips are more sensitive to temperature than fingers, but make sure you don't burn your fingers before you try kissing the chip. With practice, your lips can tell which 0402 passive is getting hotter than others.
Or you can buy a thermal camera.
In the last project I worked on with an FPGA (Xilinx Zynq) and cameras, the embedded system that had fairly strict power budget and IIRC the whole design could dissipate something like 45W, which led to a rather impressive looking enclosure that functioned as a heatsink. There was of course a margin, but the thermal design was driven by how much power could be run through the system.
Tools have gotten better, of course. However, I think the fundamentals haven't really changed in the sense that accurate modelling is impossible outside of certain domains. The risk is that you can under or over-design thermal management. This is where experience with a design can be invaluable. As the design goes through iterations one notes performance, compares to assumptions and estimates and makes adjustments.
We tend to work on projects that are highly constrained in terms of such things as allowable mass. And so, I can't just liberally apply a multiplier to estimates and call it good. We need to know. With time you develop test suites that stress things enough to achieve pretty decent test-based thermal data.
I was part of a team commissioning all of the process analyzers in a new chemical plant. We had an oxygen analyzer (measures oxygen content in a process stream) that kept giving off problematic readings. Every single flange and tubing fitting upstream of the analyzer, as well as the analyzer itself, was leak checked repeatedly to no avail.
One of the chemical engineers recommended we start leak checking downstream. Problem solved. Ambient oxygen was getting into the system downstream, diffusing upstream against the process flow, and was being detected by the analyzer. All the non-chem e's were mindblown.