Electronic – How to build a cheap device to determine where Wi-Fi interference is coming from

Developing a workable RF communications protocol is apt to be a tricky but educational exercise. A few additional points to consider beyond what's been said:

1. On some radio hardware, it takes a lot of power to listen for a signal. With many if not most small radios, listening for a second is going to take more energy than transmitting for a millisecond; on some radios, listening for a millisecond may take more energy than transmitting for a millisecond. If current consumption is not an issue, listening continuously is a lot simpler than listening intermittently; if current consumption is an issue, however, it may be necessary to listen intermittently. Probably not a good idea until you've managed to get something going with a continuous-listen protocol.
2. Listen-before-transmit may be "polite", but it's nowhere near as useful with RF as with e.g. an Ethernet cable. Ethernet signalling is designed so that not only is it likely that a device which listens before transmitting will usually avoid a collision, but it's also designed so that a device whose transmission collides with that of another device is virtually guaranteed to notice. RF transmission offers no such promise. It's entirely possible that when P wants to transmit to Q, some other device X which is closer to Q than to P will be transmitting loud enough to prevent Q from hearing P's transmission, but not loud enough for P to notice. The only way P will know that Q might not have received his transmission is by the fact that P won't hear a response from Q.
3. It's important to beware the consensus problem--much moreso with RF than with wire signalling. If a P sends to Q, it's possible that Q will hear P's transmission and send an acknowledgment, but P will for various reasons not hear that acknowledgment. It's thus necessary to be very careful to distinguish retransmissions from "new" transmissions.

   The consensus problem can be especially vexing if one is trying to save energy by powering down receivers when they're not needed. Suppose two P and Q are supposed to communicate once every 10 seconds, so they power up and P sends Q a packet. Q receives the packet, sends his acknowledgment, and--knowing that P won't be sending anything for almost ten seconds, powers down. If P doesn't get Q's acknowledgment, he'll retransmit; since Q is asleep, however, he won't hear P's retransmission. From Q's perspective, that wouldn't matter (he's already received his data), but it means no matter how many times P retries, he'll have no way of knowing Q got his packet (at least not until the next rendezvous in about ten seconds).

4. It's entirely possible to have a situation in which node Q will be able to receive transmissions from P, but P will not be able to receive transmissions from Q. It may not be possible to usefully communicate in such scenarios, but one should at least endeavor to avoid doing anything obnoxious (like having P endlessly retry a transmission hundreds of retries per second)

As said, a workable RF communications protocol is apt to be a tricky exercise. Still, I'd expect you'll probably learn a lot from the experience.

If the bulk of interference is coming from circuit connections (a schematic would help), you can either add inductance to the connections to filter out high-frequency feedback or attempt to isolate the discharge circuit and control & monitoring circuit. Adding inductance can be as simple as wrapping wire around a ferrite bead. Care must be taken to ensure the feedback is sufficiently attenuated while not impeding circuit operation (ie: slower rise times). Optical and physical isolation are common methods of separating high and low voltage circuits. Safely separating grounds may be too much trouble, but you can still keep the return paths of each circuit apart for most of their journey. The spiking voltage return path should be unimpeded (least inductance). If isolation efforts don't do the trick, one can lower the input impedance of the troublesome digital inputs using pull-up or pull-down resistors and capacitors. The resistor value should be high enough such that the line's regular operation is not impeded -- that is, the driver can support this lower resistance; the capacitor shorts high-frequency content to ground -- start with 100nF ceramic and work up to 10uF if needed (try it first with nothing, of course!). If voltage at any point is exceeding a part's maximum, one can clamp it to below a chosen value using something as simple as a zener diode, though other (superior and more expensive) TVS systems/parts are available. This just protects from damage, though.

If the bulk of interference is radiating from the capacitor discharge connections, one approach would be to reduce the radiation at the source. I'm guessing that slowing or otherwise modifying the cap discharge rate (TVS) is not an option, as it would affect measurements. The next best thing is to reduce the propagation properties of the wires and traces powering the capacitor(s): minimize all connection lengths including ground, and minimize ground loop areas (keep the return as close as possible to signal/power). Of course, physical distance between the controller and DUT will help.

I have no experience with EMI shielding layers (mu-metal, etc.).

A strategy to skip all this is to temporarily shut down the controller during the discharge, a few hundred milliseconds, saving state in the meantime.