2
\$\begingroup\$

Short version (TL;DR): I need help troubleshooting the radio communication of an RC car that I made. Every 5s or so, the connection drops out and the car spends about 1s without receiving instructions from the controller.


The Whole Story

I've removed all electronics (except the motors) from an old RC car (and its controller) from the 1980's and rebuilt it from scratch, mostly just to have fun and learn something from it. Here's a picture of a similar car:

Picture of my RC car

Inside my RC car

Detail of where the RF receiver is

The car works just fine, except for the radio reception. Every 5s or so the connection drops for about 1s. Then, reception is back again and it runs fine for some more time. Then it all repeats. The end result is that the car runs in surges and sometimes it's difficult to avoid obstacles and such. I wanted to fix that, hopefully with your help.

The Design

Car

The car has the following components:

  • One DC motor is responsible for forward and backward motion. That's controlled by one H-bridge. This motor has a stall current of about 1.5A.
  • Another much smaller DC motor controls steering. This one has stall current of about 400mA and had its own H-bridge as well. Direction is captured by a pot attached to the steering mechanisms.
  • Both H-bridges are based on the ones I presented in this question of mine: BJH H-bridge going in reverse but not forward, LL transistor overheating. The larger motor actually uses a beefier version.
  • A 434MHz Receiver Module (Datasheet).
  • An ATmega328P-PU receiving input from the RF module, controlling the H-bridges and lights (just bright LEDs for headlights, turn signals, brakes and reverse).
  • Two separate battery sets with grounds connected, for powering the motors and the controller board:
    • 4x NiMH AA for the controller board (powering the MCU, RF receiver and LEDs)
    • 6x NiMH AA for the motors (ground connected to the other battery set).

Below are the board schematics and design.

Car electronics schematics

Car electronics board

Controller

The controller has these components:

  • A 434MHz Transmitter Module (Datasheet).
  • An ATmega328P-PU receiving input from two pots that represent forward/backward motion and steering and sending the coded commands to the car using the TX module.
  • 4x NiMH AA for the controller board (powering the MCU and RF transmitter)

The controller schematics and board design are below.

Controller schematic

Controller board

Protocol

I made up a simple transmission protocol to send the commands from the controller to the car, which consists of sending 4 bytes:

| Car address | Forward/Reverse position | Left/Right position | Headlights On/Off |

The meaning of each byte is the following:

  • Car address is just to avoid conflict with other RF receivers I have around the house (all other transmitters are off when I'm doing this troubleshoot)
  • Forward/Reverse position is a number from 0 to 100 representing whether the car should go backward (0), forward (100), remain stopped (50) or anything in between.
  • Left/Right position is similar to above: 50 is center, 0 is full left, 100 is full right, intermediate values make the car turn less sharply.
  • Headlights On/Off 1 means headlight on, 0 means it's off.

Some of the packets would look like these:

| 100 | 50  | 50 | 1 | Stopped, steering wheel centered, headlights on        |
| 100 | 100 | 75 | 1 | Full throttle forward, 50% to the right, headlights on |
| 100 | 25  |  0 | 0 | 50% in reverse, 100% to the left, headlights off       |

The controller sends this 4 byte package every 50ms using VirtualWire library at 2400 bps.

Troubleshooting

Besides the dropout problem, the car runs fine. I can control it within the area I have available (about 10m). I programmed it so that it will flash its reverse lights whenever it looses signal, so I can tell when that happens.

Here are a few things I tried and a few symptoms:

  1. The dropout is negligible when the car is stopped throughout the whole range.
  2. The dropout seems to happen when the car is moving, usually at full speed forward.
  3. It also seems to be some dropout when lights are blinking.
  4. Battery charge doesn't seem to affect the issue
  5. Transmission speed doesn't affect the dropout either. I started using 2400 bps and tested it with 1200 and now I'm at 1000 bps. No change to the symptoms.

From items 1 and 2 above I can tell that the problem has something to do with the main motor interfering with the receptor module. Maybe some shielding would help. From item 3 above, it seems that the LED wiring is also interfering with the communication. But that's all I can tell.

Questions

  1. What can I do to troubleshoot and fix my car communication problems? I have a DMM, a 70MHz oscilloscope. What signals can I probe to find the problem?

  2. What can I do to improve my car in revision 2? Better shielding between motor and receiver? Changes in the protocol? Replace the RF modules for something better?

  3. What other important information did I omit that I should add to my question?

\$\endgroup\$
  • 1
    \$\begingroup\$ Is your power supply up to snuff? \$\endgroup\$ – Passerby Sep 7 '14 at 23:12
  • \$\begingroup\$ @Passerby - What do you mean? Which of the 3 power supplies? What is snuff? \$\endgroup\$ – Ricardo Sep 7 '14 at 23:19
  • 2
    \$\begingroup\$ I'm surmising a little, here, but your question's title says this happens at full speed, and you say you've connected the "grounds" of all three power supplies. "Ground" isn't really ground, it's just the negative side of all the power supplies. Could your "drive" power supply be "pulling up" the ground when it's being fully taxed? Do you have any way to measure the effective voltage of the power supply while the motor is fully taxed? (On a bench.) Just a thought. \$\endgroup\$ – Wesley Long Sep 8 '14 at 0:01
  • 1
    \$\begingroup\$ I'd not use the scope. I'd use a DMM (Digital Multi-Meter). The ground on your scope's probe is (likely) connected to the AC ground from the wall, and would invalidate the tests's conditions. A DMM (battery-powered) would not. \$\endgroup\$ – Wesley Long Sep 8 '14 at 1:42
  • 1
    \$\begingroup\$ Up to snuff means up to the job/task. @wesleyLong explained what I meant. If the battery supplies, at full motor load, is changing the available voltage (or creating a lot of ripple), it can affect the receiver. Check the voltage rails under load. A scope is better than a multimeter imho, but check with both anyway. \$\endgroup\$ – Passerby Sep 8 '14 at 16:42
2
\$\begingroup\$

The RX and TX modules are very crude and do not feature an automatic CRC handling, so you should do it in software, along with some error correction coding.

The receiver requires \$5\,\mathrm{V}\pm 0.1\, \mathrm{V}\$, so with 4 AAs you probably need a boost (or perhaps buck/boost) converter.

Brushed motors generate EMI by arcing at commutator, so shielding and placing it farther from the receiver should help. Or get a brushless motor.

\$\endgroup\$
  • \$\begingroup\$ I think that VirtualWire adds some sync preamble, but not CRC, I suppose. I though I would get away with 4x 1.25V NiMH AAs, but was assuming that the receiver would accept a little less than 5V. Truth is I was paying more attention to the MCU power supply limits... Good stuff, thanks! +1 \$\endgroup\$ – Ricardo Sep 7 '14 at 23:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.