Receiver PCB

nrf24-rc-car-controller

A two-board wireless RC car electronics design, built as a solo project: a compact ATtiny85-based handheld remote transmitting over an NRF24L01+ 2.4GHz radio link, and an ATmega328P-based receiver board that decodes commands and drives two DC motors through a DRV8833 dual H-bridge. Designed end-to-end in KiCad — schematics, PCB layout, and manufacturing (gerber) files for both boards.

Table of contents

• Overview
• System architecture
• Transmitter (TX) board
• Receiver (RX) board
• Bill of materials
• Design decisions and reasoning
• PCB layout considerations
• Repository structure
• Tools and how to open the project
• Deliverables checklist
• Possible future improvements
• License

Overview

The goal of this project was to design the complete electronics for a simple, battery-operated RC toy car: a handheld remote that a user holds and presses buttons on, and a receiver board mounted inside the car that reads those commands wirelessly and moves the car accordingly.

The car supports four commands — forward, reverse, left, right — sent over a 2.4GHz wireless link and translated into motor driver signals on the receiving end.

Transmitter → Wireless communication → Receiver → Motor driver → Motors

System architecture

At the top level, the remote (TX) is a battery-powered handheld device with four buttons. Pressing a button causes the TX's microcontroller to send a corresponding command byte over SPI to its NRF24L01+ radio module, which transmits it over 2.4GHz.

The car's receiver (RX) board listens continuously with its own NRF24L01+ module. When a command arrives, its microcontroller decodes which button was pressed and sets the appropriate control lines on the DRV8833 motor driver, which in turn drives the two onboard DC motors — one motor handles forward/reverse, the other handles left/right steering.

Both boards use the same RF module and the same SPI pin mapping convention, which kept firmware and sourcing simpler — one driver, one part number, two boards.

Transmitter (TX) board

Purpose: a small, battery-powered handheld remote with four buttons.

The pin-count constraint. The ATtiny85 has only 5 usable GPIOs (PB0–PB4). Between 4 buttons and a 5-signal SPI bus (MOSI, MISO, SCK, CSN, CE) to the NRF24L01+, that's 9 signals competing for 5 pins. Two things were done to make it fit:

1. CE tied permanently to VCC. Since the remote doesn't need to dynamically enable/disable the radio, CE is hardwired high, freeing up one pin.
2. All 4 buttons read through a single ADC pin. Instead of one GPIO per button, the buttons are wired into a resistor voltage-divider network: a pull-up resistor from VCC to a shared node (also tied to the ADC pin), and each button connects that node to GND through its own distinctly-valued resistor (or directly to GND, for one of the four). Each button press produces a different, distinguishable voltage on the ADC pin, which the firmware reads and maps back to a specific button.

This kept the whole design on a single small, cheap 8-pin MCU rather than moving to a larger chip just for pin count.

Receiver (RX) board

Purpose: the board that lives inside the car, decodes commands, and drives the motors.

Two separate power rails. The receiver needs more current and a different voltage than the transmitter, so the board runs two rails off the same battery:

• VBAT — the raw Li-ion voltage (~3.7–4.2V), feeding the DRV8833's motor supply pin directly, since motors want the higher voltage and the extra current headroom.
• 3V3 — a regulated, clean rail from the AMS1117, feeding the ATmega328P and NRF24L01+, which are more sensitive to supply noise than a brushed DC motor.

Motor control signals. The ATmega328P drives the DRV8833's four logic inputs (AIN1, AIN2, BIN1, BIN2) directly from four GPIO pins, letting firmware set each motor's direction and (with PWM-capable pins) speed. AISEN and BISEN (the DRV8833's current-sense pins) are tied to GND, disabling active current limiting — an acceptable simplification for small hobby motors, though a production design would typically use these for over-current protection.

A firmware-availability tradeoff worth noting. Early in wiring, the motor control lines were placed on PD0/PD1 (the ATmega328P's hardware UART pins). Since those pins are also needed to reprogram or serial-debug the chip later, they were moved to PC1–PC4 instead, keeping UART free for firmware development and debugging.

Bill of materials

TX — handheld remote

RX — car board

Approximate total per unit (TX + RX, excluding one-time PCB fab batch cost): ₹1,000–₹1,300 in components.

Design decisions and reasoning

Why NRF24L01+ over a simpler 433MHz ASK/OOK pair? The NRF24L01+ gives a digital SPI interface with built-in auto-acknowledgement, which is significantly more reliable in noisy environments than basic OOK modulation. Using the identical module on both ends also meant writing one SPI driver and reusing it on both boards, rather than maintaining two different RF stacks.

Why ATtiny85 on TX but ATmega328P on RX? The transmitter's job is simple — read buttons, push bytes over SPI — so a small, cheap, low-power 8-pin MCU is sufficient. The receiver has to decode incoming packets, drive four motor-control lines, and manage two power rails and a battery charger, which needs more I/O and headroom than the ATtiny85 offers.

Why DRV8833 for motor driving? A single small IC contains two independent H-bridges, so one part drives both the forward/reverse motor and the steering motor, rather than needing two separate driver chips. It also includes internal current limiting and thermal shutdown, covering basic motor protection without extra components.

Why TP4056 + AMS1117 instead of designing charging from scratch? The TP4056 is a purpose-built, inexpensive Li-ion charge/protection IC — reinventing that circuit from discrete parts adds risk (over-charge, over-discharge protection is safety-critical) for no real benefit at this scale. The AMS1117 then steps the raw battery voltage down to a clean 3.3V for the digital logic, kept on a separate rail from the higher-voltage, higher-noise motor supply.

Why 2xAAA on TX but rechargeable Li-ion on RX? The remote is handled constantly and benefits from simple, swappable batteries. The car's board benefits more from rechargeability and a compact single-cell form factor that fits inside a small chassis.

PCB layout considerations

• RF and motor sections kept apart. On the RX board, the NRF24L01+ module and the DRV8833 + motor connectors are placed in diagonally opposite corners of the board, to reduce the chance of motor-switching noise coupling into the radio's signal path.
• Wider traces for motor current. Power traces feeding the motors and the DRV8833's VM pin are routed noticeably wider than the thin signal traces used for SPI and control lines.
• Ground pour. Both boards use a solid copper ground pour on the bottom layer rather than individually routed ground wires, which lowers ground impedance and simplifies routing around dense areas.
• Decoupling placed close to each IC's supply pin, not routed in from a shared point several millimetres away.
• Antenna keep-out. No copper pour or trace passes directly under the NRF24L01+ module's antenna trace, on either board.

Repository structure

/tx-remote/     KiCad project for the transmitter board (schematic, PCB, gerbers)
/rx-car/        KiCad project for the receiver board (schematic, PCB, gerbers)
/docs/          BOM + design write-up document, exported schematic PDFs

Tools and how to open the project

Designed in KiCad 9.0.5. To open either board:

1. Install KiCad (free, cross-platform).
2. Open the .kicad_pro file inside tx-remote/ or rx-car/.
3. The schematic (.kicad_sch) and PCB (.kicad_pcb) files are both included and editable.

Deliverables checklist

• System block diagram
• Component selection and BOM, with reasoning for main components
• Full schematics for both boards (power, switches, RF, motor driver, motors, battery, decoupling, protection)
• PCB layout for both boards
• Gerber and drill files for both boards

Possible future improvements

• Add active current limiting on the DRV8833 by using its AISEN/BISEN pins instead of tying them to GND.
• Add a status LED (charge/low-battery) on the RX board using TP4056's CHRG output, currently left unconnected.
• Move to PWM-capable pins for motor speed control rather than simple on/off direction control.

License

This project is shared openly for reference and reuse — feel free to fork or adapt for your own RC or wireless-control projects.