That was a really interesting read, and almost amazing the lengths that Jeff was willing to go to debug the problem. But it's also worth considering, how much work was possibly wasted during this arduous debug process? I say that not to knock the work Jeff did, but really to appreciate the creative process which is "debugging" and this is a great example of where a different strategy could save a lot of time.

Anytime you debug a problem, you create in your mind a list of likely candidates for the problem, and sort them based on a combination of how likely the problem is being caused by 'X' multiplied by how hard it is to prove the problem is not caused by 'X'.

I may have missed something, but from the story it seems like testing with one AirBud versus the other AirBud active would have isolated the problem immediately to the left pod. If you see different performance on left vs. right pod, you know immediately the problem almost certainly has nothing to do with your RF environment. So before going to extreme lengths to modify the RF environment, you absolutely must ask yourself; how can I prove the problem is not RF?

Well, you have one shared RF environment. So naturally you need two or more DUTs (device under test) to run the test against and see if the problem is consistent across different DUTs.

What's so neat about this particular case is that Jeff already had two DUTs, since the pods can apparently operate completely independently. Having two DUTs, it was a massive missed opportunity to test them independently before going down the RF rat hole.

Please don't read this as a critique of Jeff, his write-up is a great place for learning to happen!