Bluetooth vs WiFi vs USB for Sensor Streaming | SensorCast — SensorCast

SensorCast can stream your phone's sensor data over three different transports: Bluetooth, WiFi, and USB. Each has real trade-offs in range, latency, and setup effort, and picking the right one can make the difference between a smooth project and a frustrating one. Here's how to decide.

Bluetooth: the simple wireless option

Bluetooth is the easiest way to connect to a classic Arduino paired with an HC-05 or HC-06 module. It's reliable for short-range, moderate-rate streaming and doesn't depend on any network infrastructure. The trade-off is bandwidth: for very high sample rates across many sensors at once, Bluetooth can become a bottleneck. Reach is typically around ten meters.

WiFi: range and throughput

WiFi is the best choice for ESP32 and Raspberry Pi projects that need higher throughput or longer range. As long as both devices share a network, you can stream many sensors at high rates with room to spare, and your robot can roam across a whole room or building. The catch is that you depend on a network being available and both devices getting on it.

USB: lowest latency, most reliable

A wired USB connection gives you the most consistent, lowest-latency link with no radio interference. It's ideal for benchtop development, data logging, and any application where a cable isn't a problem. You give up mobility, but you gain rock-solid reliability.

A quick rule of thumb

Reach for USB while developing and debugging on the bench, switch to WiFi when you need range and high data rates on an ESP32, and use Bluetooth for simple, self-contained Arduino builds where no network is available. Because SensorCast supports all three, you can start with whichever is convenient and switch later without changing your sensor setup.

The code side of each transport

The transport only changes how you open the connection — once data is flowing, your parsing code stays the same. Here's the receiving setup for each option.

Bluetooth on an Arduino (HC-05 on a hardware/soft serial port):

#include <SoftwareSerial.h>
SoftwareSerial bt(10, 11);   // RX, TX to the HC-05

void setup() {
  Serial.begin(115200);
  bt.begin(9600);            // match the module's baud rate
}

void loop() {
  if (bt.available()) {
    String line = bt.readStringUntil('\n');
    Serial.println(line);    // one JSON reading per line
  }
}

WiFi on an ESP32 (UDP listener):

#include <WiFi.h>
#include <WiFiUdp.h>
WiFiUDP udp;

void setup() {
  Serial.begin(115200);
  WiFi.begin("SSID", "PASSWORD");
  while (WiFi.status() != WL_CONNECTED) delay(300);
  udp.begin(5000);           // match the port shown in SensorCast
}

void loop() {
  char buf[512];
  if (udp.parsePacket()) {
    int n = udp.read(buf, sizeof(buf) - 1);
    buf[n] = '\0';
    Serial.println(buf);
  }
}

USB (serial) on any board:

void setup() {
  Serial.begin(115200);      // SensorCast streams over the USB serial link
}

void loop() {
  if (Serial.available()) {
    String line = Serial.readStringUntil('\n');
    // parse `line` here
  }
}

Notice the loop body is nearly identical in all three — read a line or packet, then parse it. That's what makes switching transports painless: prototype over USB, then move to WiFi or Bluetooth without touching your parsing logic.

Bluetooth vs WiFi vs USB: Choosing the Right Connection for Your Sensor Stream