WiFi Module Selection by Device Type: Smart Home, Camera, Drone, IoT & Embedded Terminal Guide

Key Overview

Picking the right WiFi module for your device is one of those engineering decisions that ripples through the entire product. It directly shapes wireless performance, power efficiency, protocol compatibility, and the end-user experience. This guide lays out a practical framework for matching your device requirements to the right module specs. The key dimensions covered include protocol version (WiFi 5 through WiFi 7), transmit power (+12 dBm to +21 dBm), power consumption (standby as low as 10 µA), interface type (SDIO 3.0, USB 2.0/3.0, SPI, UART), and Bluetooth Combo support. Real-world modules like the ME16WS03 (WiFi 6 + BLE 5.3 Combo for smart home) and the ASR595X series (WiFi 6 + BLE 5.2 for cameras and drones) are referenced throughout to anchor each principle in shipping hardware.

Introduction: Why Choosing the Right WiFi Module Matters for Your Device

The WiFi module is the wireless gateway for any connected device. It’s the single component that takes digital data from your device’s main processor and turns it into wireless frames that talk to access points, routers, and peer devices. Pick the wrong module, whether it’s a mismatched protocol version, insufficient transmit power, an incompatible interface, or overlooked power constraints, and you’re looking at field failures, a poor user experience, costly redesigns, and delayed time-to-market.

A smart plug that drops connection every hour. A security camera that buffers video at close range. A commercial display that can’t hold a stable stream. These are all symptoms of a fundamental mismatch between what the device needs and what the WiFi module delivers. And fixing that mismatch after production costs way more than getting the selection right during design.

Most WiFi module guides stop at generic spec lists. They’ll explain what MCS index means or how to read a link budget, but they won’t tell you how those specs actually trade off when you’re designing a smart plug versus a 4K security camera versus an industrial POS terminal. This article flips that framing entirely: instead of starting with the module, we start with the device. We walk through five real device categories, map out the hard WiFi requirements for each, and back every recommendation with production-proven module data sheets. Got a battery door sensor needing five years on a coin cell? An FPV drone streaming 4K back to a ground controller? A commercial display that can’t drop packets during peak retail traffic? We cover all five device categories with concrete module recommendations you can take straight to your BOM review.

Two modules appear repeatedly as reference cases. The ME16WS03, a WiFi 6 + BLE 5.3 Combo built on a low-power dual-core RISC-V chip, is what Zukaka engineers specify for most battery-powered smart home designs. The ASR595X series, dual-band 2×2 MIMO WiFi 6 + BLE 5.2 with USB 3.0 and SDIO 3.0 interfaces, is the go-to for camera and drone applications that need sustained high-throughput links. You don’t have to buy either, but the comparison points will help you evaluate whatever module you’re considering.

BLE Combo, Security, and Drivers — The Quiet Dealbreakers

Most engineers pick a WiFi module based on PHY rate, TX power, and form factor. That’s the obvious stuff. But every BOM review we’ve done has flagged issues in three areas that get missed on the first pass: whether the module ships as a WiFi-only chip or a combo, what security acceleration it actually has under the hood, and whether you’ll be maintaining the drivers yourself or relying on someone else. These aren’t sexy specs, but they kill schedules.

WiFi + BLE Combo Modules: Save Money by Not Buying Two Radios

A combo module integrates WiFi and Bluetooth LE on one die. It shares a single antenna through an internal RF switch, so you skip the separate BLE chip, crystal, matching network, and antenna trace. The savings are real: about $0.30–0.80 in BOM cost and 20 mm² of PCB area that could go to a larger battery or better sensor. The ME16WS03 comes as a BLE 5.3 combo with LE Audio and LE Coded PHY (400 m range for battery sensors that need reach beyond a wall). The ASR595X pairs WiFi 6 with BLE 5.2, which we use in camera designs to keep a low-power control channel open while the WiFi radio streams video. Separate radios mean higher current draw and more firmware complexity. Combo is the default choice now.

One more thing: don’t skimp on BLE version. BLE 5.2 brought LC3 audio codec and TX power control. BLE 5.3 added encrypted key size negotiation and LE channel classification. If your product might ship Matter support, needs over-the-air updates, or has any Bluetooth audio ambitions, get 5.2 or 5.3. BLE 5.0 is two generations old at this point.

Security: WPA3-Enterprise Isn’t Optional Anymore

Five years ago, WPA2-Enterprise was fine. Today? Depends on your device. WPA3-SAE replaces the PSK handshake with something offline attacks can’t crack. That matters for any device on a customer’s home network. For anything handling card data (POS terminals, kiosks), WPA3-Enterprise with AES-GCMP-256 hardware acceleration is mandatory under PCI DSS 4.0. Software crypto on the host CPU kills throughput and drains battery. Make sure the module spec sheet says “hardware AES-GCMP acceleration” not just “supports WPA3.” Some cheaper modules advertise WPA3 in firmware but compute it on the main CPU. That’s a trap.

Driver Support: The Hidden Cost of Every Module

Ask this question before you spec: “when the kernel gets upgraded next year, will I need to recompile the WiFi driver?” If the answer is yes, and you picked a module without mainline kernel support, you just committed to maintaining an out-of-tree module for the life of your product. That’s months of work you didn’t budget for.

• Linux (mainline kernel): Qualcomm (ath11k, ath12k), MediaTek (mt76), and Realtek (rtw88, rtw89) all have in-kernel drivers. They ship with every Ubuntu and Debian release, maintained by kernel developers, zero SDK or binary blobs. This is a hard cutoff for anything running Ubuntu Core or a distro that updates regularly.
• FreeRTOS / RT-Thread: These need vendor SDKs. What matters is documentation quality and whether the SDK gets updated when the OS does. The ME16WS03 FreeRTOS SDK includes WiFi manager, DHCP client, TLS stack, and a GATT server; we’ve used it in production without patching. Some vendor SDKs are abandoned six months after launch. Check before you commit.
• Huawei HarmonyOS: Every six months we field requests for devices targeting the Chinese market that need HarmonyOS certification. It’s getting harder to avoid. Before spec’ing, ask if the vendor has completed HarmonyOS compatibility testing and will provide reference ports.

Device-Specific Selection Guides: Smart Home, Embedded & Commercial

Now we get to the core of this guide, the stuff generic guides skip. Five device categories, each with hard WiFi requirements that don’t compromise. For each one we lay out the design constraints, the module specs you must hit, real-world failure modes to avoid, and production-proven module recommendations you can take straight to your BOM review.

Category 1: Battery-Powered Smart Home Sensors

Door/window contact sensors, temperature/humidity nodes, PIR motion detectors, and water leak probes fall into this category. They spend 99.9% of their life in deep sleep, wake up for milliseconds to report a reading or event, and must run 3–5 years on a single CR2032 coin cell or pair of AAA batteries.

Hard limits you can’t fudge:

• Deep-sleep current ≤ 10 µA. Anything higher and you’re looking at battery life below two years, a non-starter for consumer smart home where users expect multi-year operation without maintenance.
• TWT hardware support. IEEE 802.11ax Target Wake Time lets the sensor negotiate a deterministic wake schedule with the AP, cutting average power by 3–4× compared to legacy DTIM listen intervals. WiFi 4 modules can’t do this.
• BLE combo mandatory. Users provision the sensor through their phone over BLE (Bluetooth Network Transition Service), then the sensor switches to WiFi for cloud reporting. Two separate radios = higher BOM, larger PCB, more sleep current.
• Package footprint ≤ 180 mm². A CR2032 is only 20 mm in diameter. Your module, SoC, battery connector, and sensor die all have to fit in that enclosure.

Module comparison:

Our call here: ME16WS03. Not even close. The TWT support alone doubles effective battery life over the MT7697, and the integrated BLE 5.3 with LE Coded PHY gives you phone provisioning plus long-range BLE backup if the WiFi link drops. We’ve shipped this in over 200,000 sensor nodes with zero field returns related to WiFi module power consumption.

Here’s the trap we catch in BOM reviews: Spec’ing a WiFi 4 module because “the bandwidth is more than enough.” Bandwidth isn’t the constraint here, average power is. A WiFi 4 module at 10 µA deep sleep with no TWT will consume 10× more energy per day than a WiFi 6 module with TWT at 5 µA, because every beacon listen cycle forces a full radio wake-up.

Category 2: Smart Plugs & Wall Switches

Unlike sensors, smart plugs and switches are AC-powered, so power efficiency isn’t the primary constraint. But they sit inside electrical boxes with tight clearance, behind metal faceplates that attenuate RF, and must hold connections 24/7 without rebooting or dropping packets.

What we spec for, no exceptions:

• 2.4 GHz mandatory. Most smart home hubs (Zigbee, Z-Wave, Matter) use 2.4 GHz. More importantly, WiFi 5 GHz signals struggle to penetrate electrical boxes and wall cavities. Your customers will have dead zones otherwise.
• BLE combo for Matter support. The Matter protocol uses BLE for commissioning. Even if you’re not shipping a Matter-certified device today, the BLE radio is needed for OTA updates and local control fallback.
• PCB antenna with 3 dBi gain minimum. The electrical box enclosure attenuates signals by 6–10 dB. A chip antenna with 2 dBi gain won’t cut it.
• Industrial operating temp −40 °C to +85 °C. Electrical boxes in attics and garages hit 70 °C+ in summer. Consumer-grade modules rated to +70 °C will reset in thermal protection.

Here’s what we ship: ME16WS03 in single-band 2.4 GHz configuration, with the module’s internal PCB trace antenna tuned for 3 dBi gain. For wall switches where the enclosure is particularly cramped (behind a double-gang faceplate), we use the ASR595X with an IPEX connector and an external ceramic chip antenna placed on the edge of the PCB.

We learned this one the hard way: Forgetting to de-rate TX power inside a metal enclosure. A module rated for +20 dBm free-space will couple less than +14 dBm out of a metal electrical box. If your link budget was calculated for free-space, you’ll have 6 dB less margin than you planned, and intermittent drops on the fringe of WiFi coverage.

Category 3: 4K Security Cameras & Video Doorbells

Security cameras are the bandwidth hogs of the smart home. A 4K H.265 stream at 25 fps needs 8–12 Mbps sustained throughput with zero packet loss, or you get dropped frames and motion detection gaps. Video doorbells add battery constraints into the mix.

Hard requirements we don’t budge on:

• 2×2 MIMO on 5 GHz. A 1×1 5 GHz link at HT80 delivers about 80 Mbps TCP throughput in clean conditions, barely enough for 4K with headroom. 2×2 doubles that to ~160 Mbps, giving you room for dual streams (main 4K + sub 1080p).
• Hardware-accelerated TCP/IP offload. The camera SoC is already busy encoding 4K video in real time. If the WiFi module forces the host CPU to handle TCP segmentation and reassembly, you’ll see encoding frame drops. The ASR595X has built-in TSO (TCP Segmentation Offload) and checksum offload.
• BLE for low-power wake-up. Video doorbells wake the WiFi radio only when motion is detected, a BLE advertisement from the PIR sensor triggers the WiFi radio to wake, connect, and start streaming. Without BLE, you’d have to keep the WiFi radio in DTIM listen mode 24/7, killing battery life.
• IP67-rated antenna connector. Outdoor cameras need IPEX 7 GHz or U.FL-K connectors rated for moisture. Standard IPEX won’t hold up through a year of rain and temperature cycling.

What we ship: ASR595X series (dual-band WiFi 6 + BLE 5.2, 2×2 MIMO, USB 3.0 interface). We pair it with the Ambarella S5LM camera SoC, the USB 3.0 link keeps video data off the SDIO bus entirely, avoiding contention with the SD card write path. For cost-sensitive 1080p cameras, a 1×1 WiFi 6 module like the Realtek RTL8852BE (in 1×1 mode) is sufficient, but we still insist on dual-band support for 5 GHz interference avoidance.

Don’t make this mistake: Routing video over SDIO 3.0 while the SoC also writes to an SD card. SDIO arbitration on most camera SoCs (Ambarella, HiSilicon) causes microsecond-level bus contention that translates directly to video frame jitter. Use USB 3.0 for the WiFi module and keep SDIO dedicated to storage.

Category 4: FPV Drones & Remote Control Aircraft

FPV (First-Person View) drones stream HD or 4K video from an onboard camera to a ground controller, often 1–5 km away. Latency is the killer. Pilots need 30 ms or lower one-way delay, or they crash. The module also has to handle extreme vibration, temperature swings, and weight constraints (every gram matters on a racing drone).

What matters most here:

• 5 GHz band, 20 MHz channel only. 2.4 GHz is congested with Bluetooth, garage door openers, and microwave ovens. You get 1–2 Mbps of usable throughput on a good day. 5 GHz with 20 MHz channels (not 40/80/160) gives you 8 non-overlapping channels and less multipath fading at distance.
• Long-range mode with +23 dBm TX power. Most drone regs allow up to +23 dBm EIRP in the 5.8 GHz ISM band. Modules that cap at +18 dBm cut your range by 60% (each 3 dB gain doubles range).
• Copper-clad steel PCB antenna or external whip. A chip antenna at 5.8 GHz has 2 dBi gain. A copper-clad steel PCB trace antenna gives 5–6 dBi. An external whip antenna mounted on the drone’s tail gives 8–9 dBi and clears the carbon-fiber body that attenuates signals by 3–4 dB.
• Operating temp −10 °C to +60 °C. Racing drones hit 60 °C after 10 minutes of full-throttle flight. Consumer modules rated to +50 °C will thermal-throttle mid-flight.

What you want here: ASR595X series configured for 5 GHz-only operation with +21 dBm TX power (we de-rate from the module’s +23 dBm spec for regulatory compliance in most regions). Pair it with a 5 dBi copper-clad steel PCB antenna on the drone and a 9 dBi directional patch antenna on the ground controller. This setup gives 3–5 km range with 25–30 ms latency on 1080p60 streams.

We’ve seen this crash drones: Using an 802.11ac module in 80 MHz channel mode at 5.8 GHz. Wide channels sound like more throughput, but they use more of the crowded 5.8 GHz band. You’ll get more interference from nearby drones and RC transmitters. 20 MHz channels give you 30–40 Mbps PHY rate, which is exactly what 1080p60 needs with zero contention.

Category 5: Commercial POS Terminals & Digital Signage

Point-of-sale systems, self-service kiosks, and digital signage panels live in dense RF environments, retail stores with 50+ competing WiFi networks, convention centers, airports. They’re almost always AC-powered, so power efficiency is irrelevant, but they need rock-solid throughput, enterprise-grade security, and easy field replacement.

Check these boxes before you spec:

• WiFi 6E or WiFi 7 mandatory. The 6 GHz band has 1200 MHz of spectrum (versus 500 MHz on 5 GHz and 80 MHz on 2.4 GHz) and zero overlap with legacy devices. In a retail environment, 2.4 GHz and 5 GHz are both saturated. 6 GHz is your only path to clean spectrum.
• WPA3-Enterprise with 192-bit security. PCI DSS 4.0 (payment card industry) now requires WPA3-Enterprise for POS systems handling card data. WPA2 is no longer sufficient.
• M.2 2230 Key E form factor. Field replaceability matters. M.2 modules plug into a standard socket. You can swap a failed module in 30 seconds without desoldering. Mini-PCIe is also acceptable but has shorter lifecycle.
• Linux mainline driver support. Commercial POS runs on Ubuntu Core or a custom embedded Linux. Out-of-tree drivers break on every kernel upgrade and are a maintenance nightmare. Use modules with in-kernel driver support (ath11k for Qualcomm, mt76 for MediaTek).

Our pick: Qualcomm QCNCM865-based M.2 module (WiFi 6E, tri-band 2.4/5/6 GHz, 2×2 MIMO per band). The ath11k driver is upstream in Linux 5.15+, so it just works with no SDK or binary blob needed. For a digital signage panel pushing 4K video across a store network, this module gives you 1.2 Gbps PHY rate on 6 GHz with OFDMA and BSS Color for interference mitigation.

What trips engineers up: Buying a consumer-grade WiFi 6 module and expecting it to handle enterprise WPA3-Enterprise. Most consumer modules support WPA3-Personal (SAE) but not WPA3-Enterprise (802.1X with GCMP-256). Check the chipset datasheet for “Enterprise WPA3” or “WPA3-Enterprise Suite B” before specifying.

Conclusion: Start With the Device, Not the Spec Sheet

The core question isn’t “what WiFi module is best?” It’s “what does my device actually need to get out of bed in the morning?” A battery door sensor can’t run 2×2 MIMO and doesn’t need to. It needs to sleep so deeply the battery outlasts your next apartment move. An FPV drone? 6 GHz with 802.11ax would be great, except no one’s racing through 6 GHz yet. Latency and range are everything. And that POS terminal behind the register, the one handling 400 transactions a day? It’ll sit on a dusty shelf for five years running Ubuntu Core updates. You need a chipset with mainline Linux support or you’ll be maintaining out-of-tree drivers until retirement.

That’s why the device-type approach matters. You skip the irrelevant specs and zero in on what will actually bite you. The ME16WS03 shows up in every sensor design we touch because TWT support and that 5 µA sleep current are dealbreakers if missing. If a prospect asks us to spec a WiFi 4 module on battery power, we explain why the customer will hate them in 18 months. For cameras and drones we reach for the ASR595X. That USB 3.0 offload alone has saved us from more frame jitter complaints than any other single feature. Commercial POS is a different universe entirely: we don’t even quote modules that can’t do WPA3-Enterprise with Linux mainline drivers. The QCNCM865 isn’t the cheapest, or the smallest, but it boots up on Ubuntu Core with zero configuration and that’s all that matters when you’re deploying 300 terminals across a retail chain.

The most expensive module is the one that doesn’t work in your device. Spending an extra $2 on a module with TWT support can save you a $2 million battery recall. Spending $3 more for USB 3.0 instead of SDIO can eliminate video frame jitter that would otherwise cost you your Amazon reviews. Your module vendor should be a partner who understands your device’s real-world constraints, not just a catalogue of datasheets.

For the complete WiFi module selection framework covering all generations, form factors, chipsets, and enterprise requirements, see the WiFi Module Complete Guide. If you are weighing whether to buy a finished module or build on a discrete chipset/SoM instead, see the Module-vs-Chipset Build-vs-Buy Guide.

Frequently Asked Questions: WiFi Module Selection by Device Type

These are the questions our hardware engineering team answers most often when consulting on WiFi module selection for production designs.

1. I have a battery sensor that needs 5-year life. Can a WiFi 4 module work, or do I really need WiFi 6 with TWT?

You really need WiFi 6 with TWT. Let’s run the numbers: A WiFi 4 module in DTIM listen mode wakes up roughly every 100 ms to check for beacons. At 10 µA sleep current and 40 mA peak during beacon decode, that averages out to about 200 µA continuously. A WiFi 6 module with TWT negotiates a 30-second wake interval with the AP, averaging under 2 µA. Over five years, that’s 876 mAh versus 8.8 mAh of battery consumption for the same reporting interval. A CR2032 holds about 220 mAh. With WiFi 4 you’d need three CR2032s in parallel to hit five years. With WiFi 6 TWT you’d barely drain a single one.

2. My security camera spec sheet says “supports 5 GHz.” Do I need 2×2 MIMO, or is 1×1 enough?

For 1080p30 streaming, 1×1 at HT80 (40 MHz channel bonding) delivers about 80 Mbps TCP throughput, enough with comfortable headroom. For 4K25 or 1080p60 with motion-triggered recording, you need 2×2 MIMO, which doubles your link budget and gives you ~160 Mbps. The difference isn’t just throughput — 2×2 MIMO with spatial multiplexing dramatically reduces packet loss in noisy RF environments, and that’s where camera systems fail. If you’re in any environment with more than 10 WiFi networks visible on 5 GHz, use 2×2. That $3 difference saves you from blown cloud storage re-record fees on missed motion events.

3. For my FPV drone, should I use 20 MHz or 40 MHz channels on 5.8 GHz?

20 MHz, always. The 5.8 GHz ISM band (5745–5825 MHz) has only 8 non-overlapping 20 MHz channels. A 40 MHz channel takes two of those channels, leaving only 6 usable channels. At any drone field day with 3+ pilots, you’ll get interference on 40 MHz. With 20 MHz channels you still get ~40 Mbps PHY rate (enough for 1080p60 H.265 encoding at 10 Mbps) and you keep all 8 channels available. The only time 40 MHz makes sense is for a single-pilot setup in a completely isolated RF environment, which never happens in real racing.

4. My POS vendor said WPA2-Enterprise is “fine for now.” Is that true?

It depends on when your device goes to market. PCI DSS 4.0 (effective March 2024) already requires WPA3-Enterprise or WPA2-Enterprise with AES-GCM-256 for card-accepting POS systems. WPA2-Enterprise with TKIP is explicitly prohibited. Most major card networks (Visa, Mastercard) will begin requiring WPA3-Enterprise for new device certifications starting Q1 2026. If you’re shipping before then and WPA2-Enterprise with CCMP-256 works for your deployment, it’s acceptable, but specify a module with hardware AES-GCM acceleration so you can enable WPA3-Enterprise later via firmware update. Don’t ship a module that can’t do WPA3 at all.

5. I’m designing a smart plug. Why can’t I just use a cheap WiFi 4 module? Everyone says 2.4 GHz is enough?

2.4 GHz is the right band, but WiFi 4 is the wrong generation. Here’s why. Smart plugs sit behind electrical boxes and metal faceplates that attenuate RF signals by 6–10 dB. WiFi 4 uses a single spatial stream and typically tops out at ~18 dBm TX power. WiFi 6 modules with OFDMA and target wake time give you better link margin and better coexistence with other 2.4 GHz devices in the home (Zigbee thermostats, BLE sensors, microwave ovens). But the real reason is Matter, the industry connectivity standard launched in 2022 uses BLE for commissioning and WiFi for connectivity. A WiFi 6 + BLE 5.3 combo module lets you support Matter with a single chip, versus needing a separate BLE chip alongside a WiFi 4 module. The WiFi 4 route saves you $1.50 on the module but costs you $3.00 in extra BOM (BLE chip, crystal, matching network) and kills Matter compatibility.

6. What about range, should I just pick the module with the highest dBm output power?

TX power matters, but it’s only half of the link budget equation. RX sensitivity on your device is at least equally important; a module with −75 dBm RX sensitivity at MCS0 can hear a signal that a module with −71 dBm sensitivity can’t. That 4 dB difference translates to roughly 50% more range with identical TX power. And antenna gain on both ends of the link matters even more. A 9 dBi directional antenna on the ground controller of your drone gives you 9 dB of free link gain. That’s equivalent to cranking TX power from +18 dBm to +27 dBm, which would violate FCC limits. The highest TX power module on the market is useless if your antenna design only gives you 1 dBi gain. Calculate your link budget first, then pick the module.

References & Further Reading

1. IEEE 802.11ax-2021, IEEE Standard for Information Technology; Telecommunications and Information Exchange between Systems Local and Metropolitan Area Networks; Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 1: Enhancements for High-Efficiency WLAN (WiFi 6). IEEE, November 2021.
2. IEEE 802.11be-2024, IEEE Standard for Information Technology; Specific Requirements Part 11: Wireless LAN MAC and PHY Specifications Amendment 7: Enhancements for Extremely High Throughput (WiFi 7). IEEE, June 2024.
3. WiFi Alliance. WiFi CERTIFIED 6: Technical Overview. WiFi Alliance Technical White Paper, 2023. Available at: https://www.wi-fi.org/wi-fi-certified-6
4. WiFi Alliance. 6 GHz Spectrum for WiFi: A Global Status Update. WiFi Alliance Industry Briefing, 2024. Available at: https://www.wi-fi.org/6ghz
5. Bluetooth SIG. Bluetooth Core Specification Version 5.3 Feature Overview. Bluetooth SIG Technical Overview, 2022. Available at: https://www.bluetooth.com/specifications/specs/core-specification-5-3/
6. Connectivity Standards Alliance (CSA). Matter 1.0 Specification Overview. CSA Technical White Paper, 2022. Available at: https://csa-iot.org/our-work/matter/
7. Zukaka Engineering. ME16WS03 WiFi 6 + BLE 5.3 Combo Module Datasheet (v2.3). Zukaka Product Documentation, 2025. Available at: https://www.zukaka.com/product/me16ws03/
8. Zukaka Engineering. ASR595X Series Dual-Band WiFi 6 + BLE 5.2 Module Datasheet (v1.8). Zukaka Product Documentation, 2025. Available at: https://www.zukaka.com/product/asr595x/
9. PCI Security Standards Council. PCI DSS 4.0 Requirements and Security Assessment Procedures. PCI SSC, March 2024. Available at: https://www.pcisecuritystandards.org/document_library/
10. FCC. Part 15 Radio Frequency Devices; Subpart C: Intentional Radiators. Federal Communications Commission, 2024. Available at: https://www.ecfr.gov/current/title-47/chapter-I/subchapter-C/part-15/