How to Use Your Dev Kit's Reference Design to Shortcut Your Custom PCB Layout

Using your dev kit's reference schematic to speed up custom PCB design

You have a working BLE prototype on an nRF52840 DK. Investors want a real product in 6 months. You open KiCad to start the custom PCB, and the cursor blinks at you for an hour.

Here’s the question you should actually be asking: of the 200-odd components on that dev kit, which ones do you copy verbatim, which do you adapt, and which do you delete entirely?

Get the answer wrong on the RF side and you’ll find out 4 months in, during pre-scan testing, when your radiated power is 6 dB low and nobody can tell you why. Get it right and you save roughly 3 months of engineering time that Nordic (or Espressif) already paid for.

This article walks through the practical mechanics: what to lift straight from the dev kit reference design, what’s safe to customize, and where the BOM and certification traps hide.

Why the Reference Design Exists (And Why You Should Trust It)

Chip vendors spend 6 to 12 months and serious money validating their reference designs. RF tuning, regulatory pre-scans, thermal characterization, power integrity simulation. Every reference schematic you download is the survivor of that process.

Nordic publishes the full nRF52840 DK hardware package: schematic, layout files, Gerbers, BOM. Espressif does the same for ESP32 modules and bare SoCs in its Hardware Design Guidelines. These aren’t marketing artifacts. They’re the exact files Nordic and Espressif used to pass their own FCC and CE testing.

Skip the reference and you’re paying that engineering cost yourself. A junior RF engineer doing matching network tuning from scratch is a 4 to 8 week task, and that’s if they have a vector network analyzer in the lab. Most early-stage hardware teams don’t.

What to Copy Verbatim

Bookmark this section. Here’s what gets copied from the nrf52840 reference schematic (or its ESP32 equivalent) without modification:

The RF front end, non-negotiable:

  • Pi-matching network: component values, package size (0402 typically), and physical placement
  • Antenna feedline: 50Ω controlled impedance, exact trace length and width
  • Antenna choice: chip antenna, PCB trace antenna, or external. Don’t swap types.
  • Ground pour and keepout zones around the antenna (this is where most copies fail)
  • 32 MHz crystal: load capacitor values, trace lengths, and ground guarding

Decoupling capacitor network: values, packages, and the order in which they sit relative to each supply pin. The reference puts the smallest cap closest to the pin for a reason.

Power topology: if the reference uses the internal DC/DC with the spec’d inductor, copy it. If it uses LDO mode, copy that. Don’t mix and match without reading the product spec carefully.

   [SoC] --[C1]--[L1]--[C2]-- ANTENNA
            |          |
           GND        GND
   ^ Copy values, packages, AND placement.
   ^ Do not "optimize" or substitute.

The esp32 reference design follows the same logic. Espressif’s hardware guidelines are explicit about the antenna keepout area (typically 15mm clearance from any ground or trace) and the matching network topology. Anything between the SoC’s RF pin and the antenna belongs to the vendor, not to you.

One specific trap: the matching network values are tuned to a specific antenna and a specific PCB stackup. Change either and the values change too. Copy the antenna, the stackup (4-layer, FR-4, specific dielectric thickness), and the matching network. All three together.

What You Can Safely Customize

Past the matching network, customize freely:

  • Power input stage: battery holder, USB-C, barrel jack, whatever fits your enclosure. The dev kit’s USB-to-UART bridge and onboard SEGGER J-Link are dead weight in production.
  • Sensor and peripheral interfaces: I2C, SPI, GPIOs broken out to whatever your application needs.
  • Debug interface: keep SWD pads (you’ll need them for production programming and field debug), but drop the onboard J-Link IC. A 4-pin Tag-Connect footprint saves space.
  • LEDs, buttons, connectors: size for your production volume and enclosure, not for a benchtop demo.
  • Mechanical outline and mounting holes: entirely yours.
+--------------------------------------------------+
|  [USB-C]  [LDO]  [SoC] --RF--> [ANT]             |
|  CUSTOM   CUSTOM  COPY  COPY    COPY             |
|                                                  |
|  [Sensors] [GPIO header]  [Debug pads]           |
|  CUSTOM    CUSTOM         COPY pinout, drop JLink|
+--------------------------------------------------+

One subtle point on layout: even when you customize the digital side, keep the SoC’s ground pour generous and uninterrupted under the chip. A split ground plane under a BLE SoC will ruin your day in ways that are hard to debug.

The Module vs. Discrete Decision

You don’t actually have to copy the discrete reference design. The other path is using a pre-certified BLE module reference circuit: Fanstel, Raytac, or u-blox for nRF52840; ESP32-WROOM-32 or ESP32-MINI for Espressif. The module already contains the SoC, crystal, matching network, and antenna, all on a tiny PCB that’s passed FCC, CE, IC, and Bluetooth SIG qualification.

Drop the module on your board, route power and digital signals, and you inherit the certifications.

                  | <10k/yr | 10-100k | >100k/yr
------------------|---------|---------|----------
Pre-cert Module   |   ✓✓✓   |   ✓✓    |    ✓
Discrete SoC      |    ✗    |   ✓     |   ✓✓✓
Tight cert window |   ✓✓✓   |  ✓✓✓    |   ✓✓

Per-unit cost: a Raytac MDBT50Q runs around $5-7 in low quantities; a discrete nRF52840 with surrounding components is $3-4 in BOM cost at similar volumes. The module premium pays for itself anywhere under about 10k units/year, especially when you factor in the $15-40k of certification testing you skip.

If you’re shipping a 50k unit consumer product where a $2 BOM delta means $100k/year, the discrete path starts paying off. If you’re shipping under 10k, the module almost always wins. If you have a tight regulatory timeline (a trade show, a key customer pilot), use a module regardless of volume.

Important catch: substituting any RF-path component on a discrete design, even a “compatible” capacitor, invalidates the chip vendor’s pre-scan data. You’re now responsible for full intentional radiator testing.

BOM and Sourcing Pitfalls

Reference designs sometimes spec parts that are EOL, allocated, or single-sourced. Before you commit to the schematic, validate every RF-critical part has a stocked second source with identical specs. Not “close enough.”

Specifically:

  • Crystals: load capacitance and ppm tolerance must match exactly. A 12 pF crystal is not interchangeable with an 8 pF one without recalculating the load caps.
  • Matching network inductors: Q factor matters as much as inductance. A 2.7 nH 0402 with Q=20 doesn’t behave like a 2.7 nH 0402 with Q=8 at 2.4 GHz.
  • RF path capacitors: NP0/C0G dielectric only. Substitute X7R in the matching network and your tuning shifts across temperature and voltage; you’ll fail intermittent testing in ways that look like ghosts.
  • Antennas: chip antennas are tuned to a specific ground plane geometry. Swapping a Johanson part for a Yageo “equivalent” can cost you 3 dB.

Buy the reference parts. Spend the extra dime.

Certification Implications

Three certifications matter for a BLE product:

  1. Regulatory: FCC (US), CE/RED (EU), IC (Canada), and others by region. Tests intentional radiator emissions.
  2. Bluetooth SIG: required for any product using the Bluetooth trademark. You need a QDID.
  3. Carrier or platform-specific: Apple MFi, network operator approvals if applicable.

Module path: a pre-certified module gives you modular FCC/CE/IC and a transferable QDID. You still need your own FCC grant as a “limited modular approval” host, but the testing is minimal, usually unintentional radiator scans only, around $3-5k.

Discrete path: full intentional radiator testing. Roughly $15-40k depending on the lab and regions, 6 to 12 weeks of calendar time including retests. You also need your own Bluetooth SIG QDID, which is another $4k-$8k depending on your SIG membership tier.

Even if your discrete board is a perfect copy of the Nordic reference, you still need your own FCC ID. The reference design helps you pass; it doesn’t transfer the grant.

Once Your Board Is Ready, The Connectivity Problem

You ship the PCB. The radio works. How does the device actually reach the internet?

The traditional answer is grim. Deploy BLE gateways at every customer site, or build a phone app and beg users to keep Bluetooth on, or partner with a hub maker and hope they don’t EOL the product. Each path adds months of work and recurring infrastructure cost.

Hubble runs a global BLE network that picks up advertising packets from your device directly, with no gateway and no phone app in the loop. The same BLE radio you just laid out can talk to satellites and a terrestrial network of receivers. If you want to see what changes on the firmware side, the Hubble Device SDK on GitHub and the terrestrial network overview are the right starting points.

For most early-stage hardware teams, this turns connectivity from a fleet-of-gateways problem into a send-a-packet problem.

Your Monday Morning Checklist

Three steps, in order:

  1. Download the Nordic nRF52840 DK hardware files (or the Espressif ESP32 hardware design guide). Open the schematic next to your blank canvas.
  2. Decide module vs. discrete this week, before you start layout. The decision changes everything downstream.
  3. Copy the RF section verbatim. Customize the power, debug, and peripheral sections. Validate every RF-critical BOM line has a stocked second source.

Once the board is back from the fab and blinking, the asset tracking integration guide covers what your firmware needs to do to start sending data over Hubble’s network, no gateway required.

Hubble Network lets your custom PCB reach the cloud directly from a standard BLE radio, no gateways or cellular modem required. See how it works →