EMI Lessons from a Battery-Powered CPR Device 

The many small decisions that taught us a hard lesson about noise in integration projects.  

The problem we were asked to solve  

Consistent, high-quality CPR is incredibly difficult for a person to maintain. As fatigue sets in your compressions become too shallow or too slow, and this can drastically reduce or completely negate the effectiveness of the CPR being done. Our client asked us for a portable CPR device that could be strapped to a patient and maintain up to two hours of precisely calibrated CPR compressions.

They had already begun work with other contractors on the motor drive and main circuits, so it fell on us at Embedded Engineering Solutions to integrate the system together. We had to make sure that the device was able to operate with the same consistency regardless of location; it needed to do compressions just as well in an ambulance or medivac helicopter as on a stretcher on the ground. Because of this, we knew the project would need extensive EMI mitigation for battery-powered medical devices. 

Where the project stood when we joined  

When we joined the project, our client had a working engine, complete with a motorized plunger, a power system, and the control firmware needed for the drive. However, with a UI that consisted of a few dev-board switches and some status LEDs, and a product that was just a board and cables strewn everywhere, they had not built a device ready to face the brutal reality of a real-life emergency.

The packaging and certification weren’t finalized either, which is why we were brought in. The client needed us to come in and close the gaps without tearing open any new holes in the work that had already been done. This simplified our focus on the project, narrowing our priority to minimizing changes while delivering a safe and certifiable product.  

Design constraints  

• Duty cycles powered by batteries: To maximize the battery life of our unit, and therefore provide consistent compressions for the two-hour timeline required, we made sure to hoard every milliwatt of power for the motor, and leave the background process off unless absolutely necessary.  

• Harsh operating environments: Ambulances and helicopters are extremely noisy, with lots of intense vibrations, and tons of RF interference. This meant our device had to be able to operate under those conditions without complications, as well as be able to survive hospital cleaning procedures and quick turnaround times between emergencies. 

• Simple controls in stressful situations: Because of the use case we were designing for, our UI had to be easy to read and obvious. We had to design for the tired paramedic responding to a 3 a.m. call. We had to make sure they could push the right buttons, even with gloves on.  This meant we had to design large buttons to be easy targets, make sure our device was giving clear feedback to the user, and skip out on any hidden modes or other confusing details.  

• Regulatory path: our design process was heavily influenced by the need to design a device capable of passing the FCC and aircraft safety approvals. This meant we had to choose our enclosure materials, shielding, and even labels, carefully, especially those involving EMI mitigation for battery-powered medical devices. 

What we built and why it worked  

A purpose-built enclosure and wiring strategy 

Because of the constraints we were operating under, we decided to repackage the circuits into a custom plastic housing that was specifically sized for the Plunger and battery pack that we had been given. While it may sound like a cosmetic change, it was decidedly more than that.

Those decisions meant the enclosure had become our heat path, as well as our EMI plan and our seal. We had to move sensitive traces away from the panel edges, while adding copper where needed and routing noisy drive lines in such a way as to shrink our loop area. This created a cleaner RF plot, with fewer pre-scan surprises, and all that work helped set up EMI mitigation for battery-powered medical devices in portable gear. 

On the wiring side of things, we condensed the tangle of wire harnesses into a set of keyed connectors and short flex runs, which used less wiring, and therefore less failure points. By keeping a neat wire harness, we kept it quiet, and needed less wiring during assembly, which also helps with EMI. To read more on our approach, click here: electrical design and embedded firmware integration. 

Real world ergonomics in a membrane panel 

Our design utilized a sealed membrane front panel with only a few clearly labeled buttons, and bright LEDs for indicating device statuses. The firmware we installed handled any debouncing or long-press behavior, and kept clear LED patterns to match the clinical state of the patient and device. We also built our LED patterns specifically for field training.  Checking the battery state and compression activity needed to take no more than one glance. Medical gear REQUIRES good UI, it’s not just for looks. UI clarity in emergency situations is paramount. 

Quiet housekeeping firmware 

Because the motor control code was owned and designed by another team, we left it alone. Our work focused mainly on the edges of the project, with things such as panel scanning, LED drivers, fault alerts, and power control. We also helped design processes to ensure that we weren’t wasting battery life with unnecessary things, such as supporting logic, or sleep and wake states.   

EMI mitigation for battery-powered medical devices: what finally worked ️ 

High switching currents in the motor drive caused us some major issues, specifically by creating excess wideband noise.  These issues were further compounded by the restrictions placed upon us by the RF limits for air transport, which are much stricter than for typical portable gear. Our early pre-scans showed peaks at the switching base tone and its overtones, because the harnesses we were using were acting like antennas. We also found leaks in the plastic enclosure, which did not help the problem.             

We could not fall back on the usual solution of shunting to ground, since this was a battery powered system without a true earth for us to ground to. Common mode noise was spreading across the harness through the hard ties and large bypass network, which was raising the RF levels. Unfortunately, we could not sink that noise, so we had to contain it, and that meant we prioritized EMI mitigation for battery-powered medical devices over comfort-zone fixes. 

Our solutions: 

• Shielded cables on noisy paths. By moving the motor phases and other high di/dt lines into shielded cable assemblies, we were able to keep shields continuous through bulkheads and strain reliefs. This prevented any gaps that might act like slot antennas. 

• Placing clamp-on ferrites with intent. To block the current that was trying to ride out on the harness, we placed ferrites at strategic point along the motor leads. This raised the common-mode impedance and cut the current. Even a small shift could change the pre-scan plot.  

• Using a metallic coating inside the plastic enclosure. To form a simple Faraday cage, we coated the inside of the enclosure in a metallic coating.

• Installing floating shields rather than a hard ground. Because we had no real ground, we just amplified and radiated the noise when we tied our shielding into the battery negatives like we normally would. While leaving the metalized coating and cable shields floating felt odd, in our battery only system it managed to cut the RF peaks enough to clear the regulations. Making a choice like that is often the difference between a pass and a failure in EMI mitigation for battery-powered medical devices. 

• Shorter, quieter loops. To shrink the source of the noise before it hit our shielding, we reduced the loop area of our highest di/dt paths and rerouted them to avoid any long parallel runs.  

All of these changes that we made worked together to turn a failing pre-scan into a passing report. We learned that in a portable, battery powered system, floating shields and ferrites beat big bypass networks, which we summarized in our process overview. 

Integration work you do not see, but you do feel  

System integration is many small choices that compound into the final product. Some examples from this program include: 

• Serviceability: We wanted all of the parts in our device to be easily replaceable, and we kept that in mind when placing our connectors and fasteners, to prevent any hard-to-reach parts during repairs.  

• Manufacturing flow: We made sure our board stack-ups, panel subassemblies, and test points would match how a contract manufacturer would actually build the product, which streamlines production  

• Cleaning and durability: We made sure to make design choices about panel materials and adhesives that took into account the disinfectants already in use by paramedics, and only used materials we knew would not react poorly to those chemicals.  

• Helpful documentation: our detailed assembly drawings, torque specs, and labeled harness maps helped remove confusion on the production line. 

For another field-hard build story, see A Solar-Native VFD for Remote Water Pumping. 

Crossing the finish line 

With the final touches placed on the UI, and the hardware integrated, we made sure to harden the power and EMI paths, then finalized the project by fully supporting our client through their field and aircraft use certifications. After all those steps were completed, we were able to ship a completed product that provided first responders with a new tool to save lives, using consistent, reliable CPR compressions through a simple UI. We accomplished our goals. Without any new features or clever tricks, with had delivered simple reliability for emergency situations. EMI mitigation for battery-powered medical devices in practice.  

Lessons we carried forward  

• Design the UI for gloves, sweat, and noise. You are not building for a quiet lab. Big buttons, unambiguous lights, and predictable behavior always win, every time. 

• Give the motor all the glory. Stick to your battery budget, and don’t overuse it.  Let your housekeeping logic measure and trim your runtime.  

• Do not assume a ground you do not have. In battery-only systems, noise radiates through hard bonds and big bypass networks. Careful placement of ferrites, adding shielding to harnesses, carefully rerouting your paths, and sometimes even adding floating shields can put you on the path to a pass in EMI mitigation for battery-powered medical devices. 

• Treat the enclosure like a circuit element. Find unique uses for your enclosure; you can use it as a heat spreader, a shield, or even a gasket.  

• Start certification work early. Don’t wait for the final product before you begin testing. Pre-scan, fix, and pre-scan again. When you can make changes to your design, finding flaws isn’t as big of a deal. Fix the flaws before you file your paperwork, and it will hopefully move much quicker through the process.  

If you are looking for a partner who can help you land the plane, our teams that handle hardware design, embedded firmware, and system integration can work with your existing stack and keep momentum without a full rewrite. 

If your prototype needs to become a product  

We help teams finish projects. If you have a partially built device that must ship, reach out, and we can assess the current design, map the fastest path to test and certification, and own the gritty integration work that gets you there. If your challenge involves EMI mitigation for battery-powered medical devices, even better, we are happy to bring the ferrites.  

Ready to move from bench to field? Get in touch: Contact EES.