A deep-dive into Arduino, nRF24L01 radio modules, PWM motor control, and what this mini-project means for something much bigger

In collaboration with Karan Singh.

There's a specific kind of satisfaction that only comes from watching something you built actually workâ¦ not a simulation and not a diagram on a whiteboardâ¦ :) The real thing, a motor spinning faster and slower in direct response to a physical input, controlled wirelessly, all driven by code you wrote yourself. That was the moment Karan and I had in the UEA engineering lab, and it's the moment I want to walk you through in this post.

But before I get into the hardware and the code, let me give you the full picture of what this project actually is and why it matters.

The Bigger Picture: UEA Innovators and the Self-Driving RC Car

This isn't just a random weekend Arduino project. Karan Singh and I are part of UEA Innovators, a student-led engineering society at the University of East Anglia. Our flagship goal? the one we've been building towards, is designing and building a self-driving RC car from the ground up.

That's a significant undertaking. A fully autonomous vehicle, even at RC scale, involves computer vision, sensor fusion, motor control, mechanical design, embedded systems, and real-time decision making. You don't just jump straight into that. You build up to it.

This wireless motor control project is one of those building blocks. Specifically, it addresses two core subsystems of any RC car:

The transmission system , how mechanical power is generated and delivered to the wheels
The receiver system, how commands are wirelessly received and translated into physical action

Getting these two things to work reliably, cheaply, and in a way we actually understand at a low level is the entire point. If you don't understand how your receiver works, you can't debug it when it fails. If you don't understand how your motor responds to a control signal, you can't tune it. The self-driving car will only be as good as the foundations underneath it, and this is us laying those foundations.

What We Actually Built

At the highest level, we built a two-node wireless system. One Arduino reads a potentiometer (the input , a stand-in for what will eventually be steering and throttle controls) and broadcasts a speed value over a 2.4GHz radio link. A second Arduino receives that value and uses it to drive a DC motor via PWM (Pulse Width Modulation).

Turn the knob. The motor responds. Wirelessly. In real time.

It sounds simple when I say it like that, but there's a surprising amount of engineering packed into those two sentences. Let's break it down component by component.

Component Breakdown

1. Arduino Uno R3 (Ã2)

The Arduino Uno R3 is one of the most widely used microcontroller development boards in the world, and for good reason. It's built around the ATmega328P microcontroller, which runs at 16MHz with 32KB of flash memory, 2KB of SRAM, and 1KB of EEPROM. For a project like this, that's more than enough.

We used two Uno R3s, one as the transmitter node and one as the receiver node. They're identical in hardware; the difference is entirely in the firmware we flashed onto each one.

Key specs worth knowing:

Operating voltage: 5V
Digital I/O pins: 14 (of which 6 support PWM)
Analog input pins: 6
Clock speed: 16MHz
USB interface: ATmega16U2 for serial communication

The Uno's onboard USB-to-serial chip was crucial during developmentâ¦ it let us monitor the serial output of the receiver directly in the Arduino IDE's Serial Monitor, which is how we verified the system was working correctly (more on that later).

One thing worth noting architecturally: the Uno R3 operates at 5V logic, while the nRF24L01 operates at 3.3V. This is a common source of problems with this specific hardware combination, and it's something we had to be mindful of.

2. nRF24L01 Wireless Transceiver Module (Ã2)

This is the heart of the communication system, and honestly the most interesting component in the whole build.

The nRF24L01 is a single-chip 2.4GHz wireless transceiver manufactured by Nordic Semiconductor. It's a transceiver, meaning each module can both transmit and receive .,. but in our setup we configured one purely as a transmitter and one purely as a receiver, which simplifies the code significantly.

Key technical specifications:

Frequency band: 2.4â2.5GHz ISM band (the same band as WiFi and Bluetooth)
Data rate: 250kbps, 1Mbps, or 2Mbps (configurable)
Operating voltage: 1.9V to 3.6V (important, do not supply 5V directly)
Communication interface: SPI (Serial Peripheral Interface)
Range: Up to ~100 metres in open space at minimum power, further with the PA+LNA variant
Channels: 125 selectable RF channels
Maximum payload: 32 bytes per packet

That 3.3V operating voltage is critical. The nRF24L01 is not 5V tolerant on the power supply pin (VCC). Feed it 5V and you'll damage or destroy the module. In our setup, we took the 3.3V output from the Arduino Uno's onboard 3.3V regulator, which is rated at 50mA , just enough for the module at minimum power level.

The nRF24L01 communicates with the Arduino via SPI, which requires four signal lines: MOSI, MISO, SCK (clock), and CS (chip select). In addition, it needs two control pins: CE (Chip Enable) and CSN (Chip Select Not). In our code, we assigned these to digital pins 7 and 8 on the Arduino.

The RF24 library by TMRh20 abstracts a lot of the complexity , handling packet framing, CRC error checking, auto-acknowledgement, and retransmission. For this project we used basic one-way communication with auto-ack enabled (the default), which means the transmitter gets a hardware-level confirmation that each packet was received.

The address we used~>"00001" , is a 5-byte pipe address that identifies the communication channel between the two modules. Both the transmitter and receiver must use the same address on the same pipe, which is how they find each other in the 2.4GHz noise floor.

3. TT DC Gear Motor (Ã2)

The yellow TT motors (also known as "smart car motors" or "hobby gear motors") are the workhorses of budget robotics and RC builds everywhere. They're cheap, light, widely available, and crucially for our purposes , they respond well to PWM speed control.

These are brushed DC motors with an integrated plastic gearbox. The gearbox steps down the motor's high RPM to something more useful for actually moving a vehicle. The standard TT motor typically has a gear ratio of around 48:1, bringing a no-load speed of roughly 200â300 RPM at 5V.

Electrically, they're simple: two wires, positive and negative. Reverse the polarity and the motor spins the other direction. Apply a PWM signal and you control the speed. They draw somewhere between 70â250mA under load, which is important to know because the Arduino's digital I/O pins can only source around 40mA safely, hence the need for a motor driver in a complete system.

For the purposes of this proof-of-concept, we were validating the wireless control signal rather than driving a real vehicle load, so we connected the motor directly and kept current draw in the safe range by controlling speed via PWM rather than running at full throttle continuously.

4. The RF24 Library

The software backbone of the whole radio system is the RF24 library, originally written by J. Coliz and substantially extended by TMRh20. It's open source and available through the Arduino Library Manager.

The library handles all the low-level SPI transactions needed to configure and operate the nRF24L01. From a developer's perspective, you're working with a clean API: radio.begin(), radio.openWritingPipe(), radio.write(), radio.available(), radio.read(). The register-level configuration , setting the data rate, the PA level, the CRC configuration, enabling dynamic payloads, all happens under the hood.

We set RF24_PA_MIN (minimum power amplification) for this lab test, which is best practice when the two modules are sitting 30cm apart on a bench. Running PA at maximum over a short distance causes reflections and actually degrades link reliability.

System Architecture

Before diving into the code, it's worth understanding the full data flow from input to output:

[Potentiometer]
      |
   analogRead() â 0-1023
      |
    map() â 0-255 (PWM range)
      |
  radio.write() â nRF24L01 TX
      |
  2.4GHz RF link
      |
  nRF24L01 RX â radio.read()
      |
  analogWrite() â PWM signal â Motor
      |
  Serial.println() â Serial Monitor (debugging)

[Potentiometer]
      |
   analogRead() â 0-1023
      |
    map() â 0-255 (PWM range)
      |
  radio.write() â nRF24L01 TX
      |
  2.4GHz RF link
      |
  nRF24L01 RX â radio.read()
      |
  analogWrite() â PWM signal â Motor
      |
  Serial.println() â Serial Monitor (debugging)

Clean, linear, and deliberately simple. When you're building a proof of concept, the goal is to validate each link in the chain individually before adding complexity. The potentiometer is standing in for a proper joystick or encoder input. The direct PWM-to-motor connection is standing in for a proper H-bridge motor driver. But the wireless link in the middle â¦ the part that matters for this milestone â¦ is exactly what it will be in the final car.

The Transmitter: Code Deep Dive

Here's the full transmitter sketch:

cpp

#include <SPI.h>
#include <nRF24L01.h>
#include <RF24.h>
RF24 radio(7, 8); // CE, CSN
const byte address[6] = "00001";
const int potPin = A0; // Potentiometer connected to A0
void setup() {
  radio.begin();
  radio.openWritingPipe(address);
  radio.setPALevel(RF24_PA_MIN);
  radio.stopListening();
}
void loop() {
  // Read potentiometer (0-1023) and map to PWM range (0-255)
  int sensorValue = analogRead(potPin);
  int motorSpeed = map(sensorValue, 0, 1023, 0, 255);

  // Send the integer value
  radio.write(&motorSpeed, sizeof(motorSpeed));

  delay(10); // Small delay for stability
}

#include <SPI.h>
#include <nRF24L01.h>
#include <RF24.h>
RF24 radio(7, 8); // CE, CSN
const byte address[6] = "00001";
const int potPin = A0; // Potentiometer connected to A0
void setup() {
  radio.begin();
  radio.openWritingPipe(address);
  radio.setPALevel(RF24_PA_MIN);
  radio.stopListening();
}
void loop() {
  // Read potentiometer (0-1023) and map to PWM range (0-255)
  int sensorValue = analogRead(potPin);
  int motorSpeed = map(sensorValue, 0, 1023, 0, 255);

  // Send the integer value
  radio.write(&motorSpeed, sizeof(motorSpeed));

  delay(10); // Small delay for stability
}

Let's walk through this line by line.

Includes and Object Instantiation

cpp

#include <SPI.h>
#include <nRF24L01.h>
#include <RF24.h>
RF24 radio(7, 8);

#include <SPI.h>
#include <nRF24L01.h>
#include <RF24.h>
RF24 radio(7, 8);

The three includes pull in the SPI library (Arduino's built-in hardware SPI driver), the nRF24L01 register definitions, and the RF24 high-level library. The RF24 radio(7, 8) line instantiates the radio object with CE on pin 7 and CSN on pin 8. The MOSI, MISO, and SCK pins are handled automatically by the SPI library using the Arduino's dedicated hardware SPI pins (11, 12, 13 on the Uno).

Address Configuration

cpp

const byte address[6] = "00001";

const byte address[6] = "00001";

This defines the 5-byte pipe address. The string literal "00001" is 5 characters plus a null terminator, which is why the array is declared as 6 bytes. Both the transmitter and receiver must use the same address for the link to be established.

Setup Function

cpp

radio.begin();
radio.openWritingPipe(address);
radio.setPALevel(RF24_PA_MIN);
radio.stopListening();

radio.begin();
radio.openWritingPipe(address);
radio.setPALevel(RF24_PA_MIN);
radio.stopListening();

radio.begin() initialises the module via SPI. openWritingPipe() tells the module which address to transmit to. setPALevel(RF24_PA_MIN) sets the power amplifier to minimum â fine for bench testing and reduces noise at close range. stopListening() is the key line that puts the module into transmit mode. An nRF24L01 can't transmit while it's in listening mode, so this is mandatory on the transmitter.

The Main Loop

cpp

int sensorValue = analogRead(potPin);
int motorSpeed = map(sensorValue, 0, 1023, 0, 255);
radio.write(&motorSpeed, sizeof(motorSpeed));
delay(10);

int sensorValue = analogRead(potPin);
int motorSpeed = map(sensorValue, 0, 1023, 0, 255);
radio.write(&motorSpeed, sizeof(motorSpeed));
delay(10);

analogRead() returns a 10-bit value (0â1023) corresponding to the voltage on pin A0. The potentiometer creates a voltage divider between 0V and 5V, so rotating the pot from one end to the other sweeps the ADC value across the full range.

map() rescales that range to 0â255, which matches the 8-bit PWM resolution of analogWrite() on the receiver side. This is important: you're translating between two different numeric domains, the ADC's 10-bit resolution and the PWM timer's 8-bit resolution.

radio.write(&motorSpeed, sizeof(motorSpeed)) transmits the integer. Note the address-of operator & , you're passing a pointer to the variable, not the variable itself. sizeof(motorSpeed) gives the size in bytes (2 bytes for an int on AVR). The library packages this into an RF24 payload and handles framing, CRC, and auto-acknowledgement automatically.

The delay(10) gives a 10ms gap between transmissions, yielding a maximum update rate of 100 packets per second. In practice, for motor speed control, 50â100Hz is more than adequate for smooth operation.

The Receiver: Code Deep Dive

cpp

#include <SPI.h>
#include <nRF24L01.h>
#include <RF24.h>
RF24 radio(7, 8); // CE, CSN
const byte address[6] = "00001";
const int motorPin = 3; // PWM pin for motor speed control
void setup() {
  Serial.begin(9600);
  pinMode(motorPin, OUTPUT);

  radio.begin();
  radio.openReadingPipe(0, address);
  radio.setPALevel(RF24_PA_MIN);
  radio.startListening();
}
void loop() {
  if (radio.available()) {
    int receivedSpeed = 0;
    radio.read(&receivedSpeed, sizeof(receivedSpeed));
    analogWrite(motorPin, receivedSpeed);

    Serial.print("Received Speed: ");
    Serial.println(receivedSpeed);
  }
}

#include <SPI.h>
#include <nRF24L01.h>
#include <RF24.h>
RF24 radio(7, 8); // CE, CSN
const byte address[6] = "00001";
const int motorPin = 3; // PWM pin for motor speed control
void setup() {
  Serial.begin(9600);
  pinMode(motorPin, OUTPUT);

  radio.begin();
  radio.openReadingPipe(0, address);
  radio.setPALevel(RF24_PA_MIN);
  radio.startListening();
}
void loop() {
  if (radio.available()) {
    int receivedSpeed = 0;
    radio.read(&receivedSpeed, sizeof(receivedSpeed));
    analogWrite(motorPin, receivedSpeed);

    Serial.print("Received Speed: ");
    Serial.println(receivedSpeed);
  }
}

The Key Differences from the Transmitter

The receiver sketch is, architecturally, a mirror of the transmitter. But the differences are meaningful.

openReadingPipe(0, address) vs openWritingPipe(address) , the nRF24L01 supports up to 6 reading pipes simultaneously (pipes 0â5), each with its own address. For our single-transmitter setup, we only need pipe 0. The address must match the transmitter's writing pipe address exactly.

radio.startListening() vs radio.stopListening() , this is the most fundamental difference. In listen mode, the module continuously monitors the configured pipe addresses and buffers any received packets in its internal 3-level FIFO queue.

The Loop Logic

cpp

if (radio.available()) {
  int receivedSpeed = 0;
  radio.read(&receivedSpeed, sizeof(receivedSpeed));
  analogWrite(motorPin, receivedSpeed);
  Serial.print("Received Speed: ");
  Serial.println(receivedSpeed);
}

if (radio.available()) {
  int receivedSpeed = 0;
  radio.read(&receivedSpeed, sizeof(receivedSpeed));
  analogWrite(motorPin, receivedSpeed);
  Serial.print("Received Speed: ");
  Serial.println(receivedSpeed);
}

radio.available() returns true if there's at least one unread payload in the receive FIFO. This is a non-blocking check â if nothing has been received, the loop just continues. This is the right pattern for a real-time system.

analogWrite(motorPin, receivedSpeed) outputs the PWM signal on pin 3. On the Arduino Uno, pin 3 is one of six hardware PWM outputs driven by Timer 2. The analogWrite() function sets the duty cycle of that timer's output, giving you 256 discrete speed levels (0 = fully off, 255 = fully on).

The Serial.print() lines are the debugging output â this is what we watched scrolling in the Serial Monitor to confirm the system was working. Seeing Received Speed: 127, then Received Speed: 200, then Received Speed: 80 as we twisted the potentiometer, with the motor audibly respondingâ¦ that was the validation moment.

The Wireless Link: How nRF24L01 Actually Works

The nRF24L01 operates in the 2.4GHz ISM (Industrial, Scientific, Medical) band. This is the same spectrum used by WiFi (802.11b/g/n), Bluetooth, microwave ovens, and a range of other devices. It's unlicensed, globally available, and crowded.

Nordic's approach to dealing with this crowded environment is called Enhanced ShockBurstâ¢ (ESB)â¦ their proprietary packet protocol. ESB provides:

Automatic packet assembly and parsing â¦the library handles framing, you just pass data
Automatic CRC checking â¦ the receiver validates packet integrity using a 1 or 2-byte CRC
Auto-acknowledgement â¦ the receiver automatically sends an ACK packet back when a payload is received
Automatic retransmission â¦ if the transmitter doesn't receive an ACK within a timeout, it retransmits (up to 15 times)

This is why radio.write() is a relatively robust operation. There's a handshake happening at the hardware level â¦ the receiver sends an ACK, the transmitter gets it, and only then does write() return true. You get link-layer reliability without writing a single line of error-correction code.

Challenges We Hit

1. The 3.3V / 5V Power Issue

The nRF24L01 VCC pin is rated for a maximum of 3.6V. The classic symptom of getting this wrong is code that compiles and uploads fine, the radio initialises without errors, but no data is ever received. This is a power issue masquerading as a software issue, and it burns hours of debugging time.

The robust solution is to add a 10ÂµF decoupling capacitor across the nRF24L01's VCC and GND pins. For a bench prototype without the capacitor, keeping the modules physically close and at minimum PA level (as we did) reduces peak current demand.

2. SPI Pin Conflicts

The nRF24L01 uses the Arduino's hardware SPI bus on pins 10, 11, 12, and 13. If you have anything else connected to these pins, you'll get interference. Keep those lines clean.

3. Floating Analog Pin

In early testing, the motor occasionally twitched even when the potentiometer was at zero â¦ a floating analog pin picking up noise. Fix: add a pull-down resistor (10kÎ© to GND) on the analog input, or implement a software deadband: if motorSpeed < 10, set it to 0.

4. Serial Monitor Baud Rate

Serial.begin(9600) must match the baud rate set in the Serial Monitor dropdown in the Arduino IDE. Mismatched baud rates give garbled output. Match them. Always.

Results: The Serial Monitor Tells All

The validation moment for this project was watching the Serial Monitor. As I turned the potentiometer from one end to the other, the receiver's output scrolled:

Received Speed: 0
Received Speed: 45
Received Speed: 112
Received Speed: 178
Received Speed: 230
Received Speed: 255

Received Speed: 0
Received Speed: 45
Received Speed: 112
Received Speed: 178
Received Speed: 230
Received Speed: 255

And simultaneously, the motor was audibly and visibly responding , spinning faster as the values climbed, slowing as they dropped, stopping at 0. The wireless link was working. The PWM control was working. The delay between turning the knob and the motor responding was imperceptible, well under 50ms.

Why This Connects to My Year 1 Project

This wasn't my first time working with wireless communication and embedded systems. In Year 1, I built a home security system as a lab projectâ¦ sensors, triggers, alerts. The same fundamentals applied here: GPIO, serial communication, power management, systematic debugging. But at a higher level of complexity.

I'll be writing a dedicated blog on that Year 1 security system soon. It's a great entry point if you're newer to embedded systems. Consider this a teaser.

What's Next: The Self-Driving RC Car

This wireless motor control system is one tile in a much larger mosaic. Here's how it feeds into the full self-driving car build:

Transmission system, L298N or L293D H-bridge motor drivers for bidirectional control with higher current handling. The PWM speed control logic is identical.

Receiver system , the nRF24L01 link carries all control signals. As we add channels (throttle, steering, braking), we'll move from a single integer payload to a structured data packet.

Steering, servo control (50Hz PWM with variable pulse width) over the same nRF24L01 link.

Autonomy layer, a camera feeding image data into a neural network on an onboard Raspberry Pi. The Pi generates steering and throttle commands, passed to the Arduino for execution.

Sensor fusion , ultrasonic sensors (HC-SR04), IR sensors, potentially a 9-DOF IMU for orientation tracking.

There's a lot of road between here and there. But this build proves the critical link in the chain: the control signal gets from A to B reliably, in real time, over a robust wireless link. That's the foundation everything else sits on.

Technical Summary

ComponentSpecificationMicrocontrollerArduino Uno R3 (ATmega328P, 16MHz)Radio modulenRF24L01, 2.4GHz, SPI interfaceFrequency2.4â2.5GHz ISM bandPA levelRF24_PA_MIN (-18dBm)Pipe address"00001" (5 bytes)Data payload2-byte integer (motor speed, 0â255)Transmit rate~100 packets/second (10ms delay loop)MotorTT DC gear motor, 3â6V, ~48:1 ratioSpeed control8-bit PWM, pin 3 (Timer 2)InputPotentiometer, A0, 10-bit ADC (0â1023)DebuggingSerial monitor, 9600 baud

Closing Thoughts

Building this with Karan was a good experience in the way that properly collaborative engineering projects always are. You debug faster with two people. You catch mistakes you'd miss alone. You explain your reasoning out loud and in doing so realise it's wrong.

The reference we worked from was the HowToMechatronics nRF24L01 tutorial,, an excellent starting point. But we didn't just copy the code. We read it, understood it, stripped out what we didn't need, and adapted it for our specific use case. The final code is meaningfully different from the tutorial, and more importantly, we can explain every line of it.

That's the standard I try to hold myself to. Not just "does it work" but "do I understand why it works." Because if you only understand it when it works, you're helpless when it doesn't.

More soon.

Next up: A look back at my Year 1 home security system build â¦ the project that started it all. Stay tuned ;)

Follow my journey building the self-driving RC car with UEA Innovators :0