Building FingerScore Hardware 1 — System Design and Bill of Materials (BOM)

• Introduction
• Translating product requirements into hardware
• System block diagram
• Core block 1 — MCU + BLE SoC
• Core block 2 — Input method
• Core block 3 — Power
• BOM example — building the parts list
• From prototype to PCB — a roadmap
• Budget and difficulty
• Tools you need to learn
• About safety
• Common pitfalls
• Why BLE fits this device
• First wiring — reading the BOM on a dev board
• How to read a component datasheet
• Glossary
• Recording design decisions and a getting-started checklist
• Frequently asked questions
• Preview of the next part
• Closing
• References

Introduction

FingerScore is a platform that records the score of racket sports like table tennis, tennis, and badminton through finger gestures. A small ring-shaped device worn on the finger increments the score by one each time you win a point, and sends that result over BLE (Bluetooth Low Energy) to your phone or a Web Bluetooth screen in real time. On top of that sit tournaments, ELO ranking, and a live scoreboard, which together make up a full service.

This series aims to have you, the reader, build the lowest layer of that service yourself: the ring hardware you wear on your finger. It is a long journey of choosing electronic parts, drawing circuits, flashing firmware, and finally getting all the way to a PCB. As the first step, this post covers the work of translating "what are we building" into "with which parts and how do we build it", in other words system design and bill of materials (BOM).

It is fine if hardware is new to you. We explain each term as it comes up and draw the picture with comparison tables and block diagrams as we go. That said, we try not to lose accuracy. Rather than waving things away with vague analogies, we point concretely at what you actually need to look at when choosing parts.

Translating product requirements into hardware

Good hardware design always starts from requirements. If you pick a fancy chip first and then try to bend the product around it, you almost always regret it. Let us write down, one sentence at a time, what the FingerScore ring has to do, and examine which hardware decision each sentence forces.

• It receives input from finger gestures. The device has to detect the user flicking a finger or pressing a button. This forces an input element (button, touch, or inertial sensor).
• It increments the score by one. One input equals one point. This is not heavy computation but a single counter, so we do not need a powerful processor.
• It transmits over BLE. The result has to go wirelessly to the phone, so we need a chip with Bluetooth Low Energy radio built in.
• It lasts all day. It has to survive a whole match, and ideally several days without charging. This forces low-power design and an appropriate power source (battery).
• Ring form factor. It has to be small and light enough to wear on a finger. This puts a strong constraint on part size and battery capacity.

Lay these five lines side by side and the big picture of the hardware already appears. Computation is light (score +1), but the radio is essential (BLE), and power and size are tight (ring, all-day). In other words we are building a device that is "small, long-lasting, and wireless", which is the classic challenge of embedded low-power design.

Here is one important insight. Requirements often conflict with each other. Make it smaller and the battery shrinks, so lifetime drops; make the input flashier and power and bulk grow. Hardware design is the work of negotiating these trade-offs. So the next step is to split the system into blocks while staying conscious of that negotiation.

System block diagram

Even a complex device becomes simple once you break it into big chunks. The FingerScore ring is fully expressible with four blocks: input (sensor), brain (MCU), radio, and power. In fact, in many BLE devices the brain and the radio are combined into a single chip (SoC), which reduces the part count even further.

FingerScore Ring — System Block Diagram

   +-----------+        +------------------------+
   |  INPUT     |        |        MCU + BLE        |
   |  (sensor)  |  GPIO  |        SoC (U1)         |
   |  button/   +------->+  - read input          |
   |  touch/IMU |        |  - score counter       |
   +-----------+        |  - BLE radio (built-in) |
                        +-----------+------------+
                                    |  antenna
                                    v
                              (((  radio  )))  --> phone / Web Bluetooth
   +-----------+                    ^
   |  POWER     |   3.0~3.3V         |
   |  BAT +     +--------------------+
   |  regulator |
   +-----------+

In words, the diagram reads like this. When the user touches the input element, that signal enters the SoC through a GPIO (general-purpose input/output pin). The firmware inside the SoC interprets it as "one point", increments the counter, and sends it to the phone over the built-in BLE radio. All of this happens on top of the stable voltage supplied by the power block.

The reason we separate the four blocks is that each can be chosen and verified independently. Change the input method and the MCU choice stays nearly the same; change the battery and the radio behavior does not change. Separating concerns this way makes the design much easier to handle. Now let us look into each block in depth.

Core block 1 — MCU + BLE SoC

This is both the brain and the radio of the device. For modern BLE devices, the standard is to use an SoC (System on Chip) that combines a microcontroller (MCU) and the Bluetooth radio on one chip. It is smaller, cheaper, and easier to manage for power than using two separate parts. For a small ring like FingerScore, this integration is almost mandatory.

Let us compare the representative SoC families.

The selection criteria come down to this. First, low-power BLE performance. Since the ring has to last all day, a chip with very low sleep current is favorable. On this point the Nordic family has long been the reference for embedded low power. Second, learning material and ecosystem. If you are building for the first time, a side with abundant examples, tutorials, and community is far easier. Third, price and availability. The ESP32-C family is cheap and its dev boards are easy to obtain, which is great for getting started.

For learning FingerScore, I recommend two paths. If you want to chase low power all the way, start with the Nordic nRF52 family; if you want to get something running cheaply and quickly, start with the ESP32-C3. In this series we mention both, but when we talk about the power budget we will use the nRF52 as the reference example. Either way, remember that running a single score counter has more compute headroom than we will ever need. The resources we are short on are power and space, not computation.

Core block 2 — Input method

How will the device sense the user's finger gesture? This is the decision that most shapes the FingerScore user experience. Let us compare four methods.

Let us unpack each method a little more.

• The button is the simplest and most certain. One press per point is an intuitive action, and current flows only while pressed, which is ideal for power too. It is the most recommended for getting started.
• Capacitive touch responds to a light tap, so the action is light. However it needs tuning to prevent false triggers from sweat, water, and motion, which makes the firmware a bit more complex.
• The IMU (inertial measurement unit) can recognize the gesture of flicking a finger itself, giving the most "smart" feel. But leaving it always on uses a lot of power, and the algorithm that avoids misrecognizing gestures is far from trivial.
• The flex sensor reads finger bending directly as a resistance change, but its precision and durability are disappointing for fitting into a small ring form factor.

The recommendation for the learning stage is clear. In part one, start with a button and complete the whole system once, then extend to capacitive touch or an IMU in later parts. If you first get the entire chain of "input to count to BLE transmit" working with the simplest input, swapping only the input later becomes much easier. If you challenge IMU gesture recognition from the start, there are simply too many variables to debug.

Core block 3 — Power

Power is the trickiest block in the ring. It is where two head-on conflicting requirements meet: it must be small, yet it must last a long time. There are broadly two paths.

The coin cell is that coin-shaped battery that goes into a wristwatch. It is small and light, which suits a ring well, and is easy to replace. However its capacity is small, so it presupposes a low-power design where the device sits in deep sleep drawing almost no current and wakes only briefly when there is input. Fortunately, BLE and our light task (score +1) fit this pattern very well.

A small LiPo (lithium polymer) is attractive because it is rechargeable and you can scale up its capacity, but it always brings along a charging circuit and a protection circuit (against overcharge, overdischarge, and overheating). Lithium batteries are dangerous if mishandled, so the protection circuit is not optional but mandatory. It is also bulkier than a coin cell.

The learning recommendation is as follows. For the circuit-verification stage, the dev board's USB power or a coin cell is enough. Rechargeable LiPo and a protection circuit are safer to introduce later, at the final PCB stage, once you have built up more safety knowledge. Let us also note the supply voltage. A coin cell is about 3.0V, and many SoCs operate in the 1.8 to 3.6V range, so in simple designs the battery is sometimes connected directly without a separate regulator. However if the voltage fluctuates the radio can become unstable, so when stability is needed we add a low-dropout regulator (LDO).

Power options — conceptual diagram

  [Coin cell path]
   BAT(3.0V) ----+----> SoC VDD
                 |
                (optional) LDO to stabilize voltage

  [LiPo path]
   USB ---> charge IC ---> protection ---> BAT(LiPo) ---> LDO ---> SoC VDD
            (charging)     (safety required)

BOM example — building the parts list

A BOM (Bill of Materials) is the list of all parts needed to build the device. It is the output of the design and the starting point for cost and procurement. Let us build an example BOM based on the simplest version of the FingerScore ring (button input + coin cell + nRF52 module).

Let us point out how to read this table. "Reference" is the name tag that calls each part in the schematic. By convention U is an integrated circuit, SW is a switch, BAT is a battery, C is a capacitor, R is a resistor, LED is a light-emitting diode, and ANT is an antenna. Thanks to these name tags you can connect and trace the schematic, the parts list, and the actual parts on the board to one another.

For the first time, I strongly recommend using a module. A module is a finished product that pre-bundles the SoC, antenna, and essential parts onto a small board. It means the module maker has already done the hardest parts, antenna design and radio certification, for you, so you can drop it in as if it were a single part. If you try to design the bare chip with the antenna yourself from the start, you easily fall into the trap of the radio never working.

One more thing: do not forget the decoupling capacitor (C1). This small capacitor placed right next to the chip's power pin absorbs momentary current swings and keeps the chip stable. It is the part beginners most often omit, and when missing it causes hard-to-find problems such as the radio dropping out at random.

From prototype to PCB — a roadmap

If you try to design a finger-sized PCB from the start, you will almost certainly become frustrated, because there are too many unverified variables. So we go in stages. From big to small, verifying loosely first and then locking it down hard.

Prototyping roadmap

  Stage 1: Dev board
     - Get firmware and BLE working first on a ready-made dev board
     - USB power and a built-in debugger make debugging easy

  Stage 2: Breadboard
     - Attach button, LED, and sensor with jumper wires to check the circuit
     - Swap freely with no soldering

  Stage 3: Prototype PCB (large size)
     - Move the circuit onto a board, but deliberately make it generously large
     - Add test points so measuring and fixing are easy

  Stage 4: Final PCB (ring form factor)
     - Optimize size, battery, and antenna
     - Do this last, only after everything is verified

The key to each stage is the principle of "handling only one unknown at a time". In stage 1 you look only at firmware and BLE. Since the board is verified, if something goes wrong the cause is your code. In stage 2 you look only at the circuit connections. The chip already works, so if it fails it is a wiring problem. Fixing one variable at a time this way makes debugging a traceable task. Conversely, if you change chip, circuit, size, and power all at once, you will never know what the problem is.

We deliberately push miniaturization into the ring form factor to the very end. The smaller it gets, the harder it is to measure and the more expensive it is to fix. Verifying everything on a large board first, and then moving the same circuit into a small one last, is the fastest path.

Budget and difficulty

For realistic expectations, let us lay out cost and difficulty. The exact amounts vary by parts, region, and quantity, so we only get a rough sense.

Overall, the initial cost to start learning is well within 100 to 200 dollars. A large share of that goes to tools (multimeter, soldering, logic analyzer), and those tools keep paying off long after this project ends. The parts themselves are surprisingly cheap.

The difficulty differs by stage. Stage 1, flashing firmware onto a dev board and sending the score over BLE, is easier than you might expect. The real challenge is the later part, moving the circuit onto a board and miniaturizing it. So enjoy the small early wins fully, and take the hard stages slowly. This series proceeds in that order too.

Tools you need to learn

Unlike software, hardware deals with electricity you cannot see, so measuring tools are your eyes. Debugging a circuit without tools is like searching for an object in a pitch-dark room. Let us lay out the minimum tools.

• Multimeter: the most basic tool for measuring voltage, resistance, and continuity. It checks whether the battery voltage is right, whether two points are connected, and whether there is a short. If you do hardware, it is the first tool to buy.
• Soldering tools: iron, solder, and a sucker or solder wick. Used to attach parts permanently to the board. Needed from the prototype stage.
• Logic analyzer: captures the 0s and 1s of digital signals along a time axis and shows them. It is decisive when you want to see with your eyes whether the button input is coming in correctly, whether the chip-to-chip communication (SPI/I2C) is flowing, and so on. Even a cheap entry-level one is enough.
• Breadboard and jumper wires: test circuits quickly with no soldering.
• (Nice to have) Oscilloscope: used when you need to see analog waveforms too, but you can do without it at the entry stage.

Among these, the multimeter and the logic analyzer get used especially often when building a BLE device. You check power and current draw with the multimeter, and look into input signals and chip-to-chip communication with the logic analyzer. We will gradually cover how to use the tools themselves in this series as well.

About safety

Electronics work is generally safe, but a few things must be observed, especially when handling batteries and the soldering iron.

• Do not handle lithium batteries (LiPo) without a protection circuit. Overcharge, overdischarge, and short circuits can lead to heat and fire. Use a coin cell or USB power for early learning, and introduce lithium only after you are well practiced, together with a protection circuit.
• Beware of shorts. If power and ground touch directly, a large current flows and parts can burn or the battery can become dangerous. Build the habit of checking for shorts with a multimeter before applying power.
• The iron is hot. It reaches several hundred degrees, so beware of burns and fire, work in a ventilated place, and always turn it off after use.
• Mind static (ESD). Sensitive chips can be damaged by static electricity. Discharge by touching metal, or use an ESD wrist strap if you can.

Safety rules may look cumbersome, but their value is clear once you remember that a single accident can burn up both your parts and your motivation. Above all, never treat lithium batteries lightly.

Common pitfalls

Let us lay out, in advance, the pitfalls people often fall into when building hardware for the first time.

• Trying to design the antenna yourself on a bare chip. Radio design is hard. At the entry stage, use a certified module to skip this whole challenge.
• Omitting the decoupling capacitor. As emphasized earlier, leaving out the small capacitor next to the chip's power pin leaves you suffering from unexplained instability.
• Deferring the power budget. If you postpone with "get it working first, power later", it becomes hard to make a ring that lasts all day. Be conscious of sleep current from the start.
• Changing everything at once. Changing chip, circuit, size, and power simultaneously makes debugging impossible. Fix one variable at a time.
• Guessing without measuring tools. Going forward on "it is probably connected" without a multimeter loses the most time. Always measure and confirm the electricity you cannot see.

What these pitfalls share is "impatience". When you rush to see the small ring, skipping stages only makes you take the long way around. Going slowly, one stage at a time, confirming with measurement, is in the end the fastest.

Why BLE fits this device

There are several wireless options, so why BLE (Bluetooth Low Energy) in particular? Hold the candidates up against the requirements of the FingerScore ring and the answer becomes clear.

The data FingerScore sends is a tiny piece of information: "someone just scored a point." It needs no large bandwidth at all. Conversely, since it has to last all day, power is decisive. And it has to attach straight to the user's phone with no extra hardware. The one thing that satisfies all three of these conditions at once (small data, low power, direct to phone) is BLE.

The core behavior of BLE can be summed up in a paragraph. Normally the device scatters advertising packets occasionally and stays mostly asleep. When the phone sees that advertising and forms a connection, from then on it briefly wakes up every short connection interval to exchange data and goes back to sleep. This "mostly asleep, briefly awake" rhythm is the secret to BLE's low power, and it matches FingerScore's usage pattern -- where scoring happens only occasionally -- perfectly.

Learning a few terms in advance makes the later posts easier. GATT is the structure for exchanging data in BLE: a service contains characteristics inside it. For FingerScore, you would place a "current score characteristic" inside a "score service," and design it so that each time the score changes a notify is sent to the phone. We cover this structural design in depth later in the wireless post. For now it is enough to remember that "BLE is specialized for sending small data to a phone with very little power."

First wiring — reading the BOM on a dev board

Let us draw the simplest version of how an abstract parts list actually connects. If we distill the earlier BOM down to its essentials, we have the SoC (U1), the button (SW1), the pull-up resistor (R1), the decoupling capacitor (C1), and the status LED (LED1). Here is what they look like placed on a dev board.

First wiring — button input and status LED (conceptual)

   3V3 ----+-------------------+
           |                   |
          R1 (10k pull-up)     C1 (0.1uF decoupling)
           |                   |
   GPIO2 --+---- SW1 ----+     +---- next to U1 VDD pin
                         |
                        GND

   GPIO3 ---- R2(220) ---- LED1 ---- GND

Let us walk through how to read this picture. One side of button SW1 connects to the GPIO2 pin, the other to ground (GND). Normally the pull-up resistor R1 holds GPIO2 up at 3.3V (HIGH); when you press the button, GPIO2 connects directly to ground and drops to 0V (LOW). The firmware reads this moment of falling from HIGH to LOW as "one point." Without the pull-up resistor, while the button is not pressed the pin would be left "floating," attached to nothing, and would swing between 0 and 1 at the whim of surrounding noise. We cover the principle of this pull-up at the circuit level more deeply in the next post.

C1 sits right next to U1's power pin. When the chip momentarily pulls a lot of current -- such as when it turns the radio on -- the supply voltage swings, and C1 acts like a small reservoir that absorbs that swing and steadies the chip. LED1 is for status indication: setting GPIO3 HIGH lights it through the current-limiting resistor R2. Even this single LED lets you see states like "the button was pressed" or "BLE connected" with your eyes, which makes debugging far easier.

The important point here is that this wiring is not yet a finger ring but a loose experiment on a dev board. The pin names (GPIO2, GPIO3) differ from board to board, so you must check your own board's datasheet. But the structure itself -- "pull-up + button to GPIO input," "GPIO output to resistor to LED," "decoupling next to VDD" -- is a universal pattern that holds on any board. Once you fully understand this one small circuit, you will see that the skeleton stays the same even when you later swap the input for touch or an IMU.

How to read a component datasheet

Do hardware long enough and you eventually have to get friendly with datasheets. A datasheet is the official document in which the part's maker writes down everything about that part. At first the dozens of pages of tables and graphs feel overwhelming, but at the beginner stage there are only a few items you absolutely must look at.

• Operating voltage range. Between what voltage and what voltage does this part work? The very first thing to check is whether a coin cell (about 3.0V) falls within that range.
• Current consumption. How much it draws at rest (sleep) and in action (active). In an all-day ring the sleep current is especially important.
• Pinout. Which pin is power, ground, GPIO, or a communication line. This is the starting point of wiring.
• Absolute maximum ratings. The limit values beyond which the part breaks. You design the circuit so as never to cross this line.
• Communication interface. If it is a sensor, whether it is I2C or SPI, and what the address or speed is.

You do not need to read a datasheet from cover to cover. Like a dictionary, you look up only the items you need. Just the five items above are enough for part selection and wiring at the beginner stage. In this series too, each time a new part appears we will point out which line of the datasheet to look at, right then and there.

One practical piece of advice. When choosing a part, weigh "is it easy to obtain" and "is there a lot of material on it" as heavily as the operating specs. No matter how good the specs are, a part that is hard to get or has no examples at all becomes a trap for beginners. A widely used part has correspondingly more tutorials, libraries, and question-and-answer threads piled up around it, so when you get stuck there are many ways out.

Glossary

Here we gather the key terms that appeared in this post in one place. If you get stuck while reading later posts, come back here.

Rather than trying to memorize terms, it is better to pick them up naturally as you read. Use this table like a dictionary, keeping it nearby and flipping to it when needed. As the same terms appear again and again in later posts, they eventually become second nature without your having to look them up.

Recording design decisions and a getting-started checklist

A good hardware project leaves a record of "why we decided things this way." As time passes you tend to forget even the reasons behind your own decisions, and then you either repeat the same deliberations or fail to undo a wrong choice. It does not have to be a grand document. One line per decision is enough.

You can write down the first round of decisions for the FingerScore ring like this.

• Start the input with a button (tact switch). Reason: it is the simplest and ultra-low power, so it is good for completing the whole chain first.
• Use an nRF52 module for the MCU. Reason: it is the standard for low-power BLE and has abundant learning material.
• For power, use a coin cell or USB during the learning stage. Reason: it pushes the safety burden of lithium batteries to later.
• For the radio, use the module's built-in antenna. Reason: it skips the hardest parts, antenna design and certification.

Writing it down like this lets you answer, in one second, a later question such as "why didn't we start with an IMU again." When you want to change a decision too, you just look at the original reason and check whether its premise still holds.

Now, before you actually move your hands, let us confirm your readiness with a getting-started checklist.

• Have you secured one dev board (nRF52 or ESP32-C3 family)?
• Do you have a multimeter (for checking voltage and continuity)?
• Do you have a breadboard, jumper wires, and a few buttons, LEDs, and resistors?
• Have you checked the GPIO pin numbers and power pins in the board's datasheet?
• Have you installed the firmware development environment (SDK and toolchain), and does an empty project build?
• Have you installed a BLE scanner app on your phone (for checking advertising packets)?

Once all six items are checked, you are ready to follow the circuits and firmware of the next parts. If some items are still missing, getting those in place first, before diving into the main content, ends up saving time.

Frequently asked questions

Here we gather the questions that people new to this series often ask.

Q. I know nothing about electronics at all. Can I follow along? Yes. The next part is electronics basics itself, explaining everything from Ohm's law to digital signals from the ground up. This series assumes no prior knowledge.

Q. Do I really have to go all the way to a PCB? No. With just a dev board and a breadboard, you can complete the whole "button to score to BLE transmit" behavior and check it on your phone. PCBs and miniaturization come after that, a stage only those who want it need to go to.

Q. Should I start with the nRF52 or the ESP32-C3? If you want to chase low power all the way, I recommend the nRF52; if you want to get one cheaply and quickly and start tinkering, I recommend the ESP32-C3. Either way, the concepts of this series apply as they are.

Q. Can it really be made as small as a ring? That is exactly the goal of the final PCB stage. However, miniaturization is the hardest, last step, so it is safer to take it on only after you have verified everything on a large board.

Q. How much does it cost? Including tools, you can start with an initial 100 to 200 dollars. Once you buy the tools, they keep getting used in other projects afterward.

Preview of the next part

In this post we drew the big picture for building the FingerScore ring. We translated requirements into hardware, split the system into four blocks (input, MCU, radio, power), compared candidates for each block, and touched on an example BOM, tools, budget, and safety. We have not yet covered circuit details or firmware, because there is a foundation we need first.

The next part covers the fundamentals of electronic circuits. We will explain what voltage, current, and resistance are and how Ohm's law governs a circuit, why pull-up and pull-down resistors are needed, and how the 0s and 1s of digital signals are represented electrically, all using the FingerScore input circuit as an example. With that foundation, the schematics and firmware that follow start to read not as vague incantations but as understandable sentences.

Closing

Building hardware is not one giant leap but a chain of small decisions. Today we wove the first links of that chain. We defined what we are building, split it into blocks, compared what to choose in each block, and wrote those choices down into a list called a BOM. There was no flashy technology, but this calm design is the foundation of every stage that follows.

If you are touching hardware for the first time, set aside for a moment the urge to build the perfect ring in one shot. It is enough to first taste the small win of one score appearing on your phone on top of a dev board. Inside that small action, every block of this post already lives: input, computation, radio, and power. From there, one step at a time, we will arrive at the small ring on a finger.

References

• Nordic Semiconductor — nRF52 series product page: https://www.nordicsemi.com/Products/nRF52-Series
• Espressif — ESP32-C3 product page: https://www.espressif.com/en/products/socs/esp32-c3
• SparkFun — electronics learning tutorials: https://www.sparkfun.com/tutorials
• Adafruit Learn — electronics and embedded guides: https://learn.adafruit.com
• Texas Instruments — LDO regulator overview: https://www.ti.com/power-management/linear-regulators-ldo/overview.html
• Bluetooth SIG — Bluetooth Low Energy technology: https://www.bluetooth.com/learn-about-bluetooth/tech-overview/
• Nordic — nRF Connect SDK documentation: https://docs.nordicsemi.com