Rassberry Pi Remote Controlled Car- Step 2: Breadboarding

car_control_bb

 

Bread Board Prepping - 4 GPIO ports are used to control forward, backward, left, right

Bread Board Prepping – 4 GPIO ports are used to control forward, backward, left, right

 

Raspi Car Control with Pi Cobbler

Raspi Car Control with Pi direct connect
(I cut the hazardous GPOI pis from the circuit to ensure I didn’t short the Raspi)

See also:

Rassberry Pi Remote Controlled Car- Step 1. Reverse Engineering the Car

Rassberry Pi Remote Controlled Car- Step 3. Schematic and Stripboard

Rassberry Pi Remote Controlled Car- Step 4: PCBs

 

 

 

 

 

Rassberry Pi Remote Controlled Car- Step 1: Reverse Engineering the Car

I picked up a small RC car, about the size of a matchbox, today and have decided to reverse-engineer it in order to have my Raspi control the car remotely. The idea is to use Pygame or some other python library program to control the car via the GPIO pins.

The RC Car comes in a “coke can” packaging and is only 10€.

The car, with and without its plastic cover.

It’s a pretty simple controller. I choose the car for its simplicity since unlike most RC controllers; this one’s controls are simply on/off push buttons. Most of the time RC Car manufacturers use analog potentiometers in order to give the user speed control as well, but this 10€ model only allows the user to determine if it goes forward/backward, no control of how fast. That makes it much easier to control, since we can replace the pushbuttons with transistor logic.

After taking the controller apart, I establish that all 4 (left, right, forward, backward) pushbuttons result in voltage going from 0 to just over 3V, with very little current on closed position. This is great, since we can power the whole controller from the 3,3V pin on the Raspi (I decided the voltage was within tolerances so did not need to be stepped down.)

The bare PCB board of the controller.

See also:

Rassberry Pi Remote Controlled Car- Step 2. Breadboarding

Rassberry Pi Remote Controlled Car- Step 3. Schematic and Stripboard

Rassberry Pi Remote Controlled Car- Step 4: PCBs

 

Using FCC Filings to Find Hardware Tech Specs

Just about all hardware startups involve some kind of wireless communication.  Whether WiFi, Bluetooth, Cellular, or other protocols, wireless communication allows the user to interact with the product remotely and conveniently.

What most first time hardware founders don’t realize, however, is that any device which actively sends radio signals must be approved by the FCC. Specifically, a FCC approved lab must test the radio to ensure that it complies with FCC Part 15 rules pertaining to unlicensed devices (so that your users don’t need to be licenses to use the product). Outlining the steps for this approval is beyond the scope of this article, but this approval is always required for a product to be sold in the US.

This means your competitors have had to go through the process as well, and the FCC publishes publicly the results of the testing and certification online. So you can go to the FCC website and find out quickly information about any product with an FCC code.

By law the FCC Code is required to be on the radiating device. This is typically on the back and is comprised of the Grantee Code (the company doing the authorization) and the Product Code. The Grantee Code is assigned to the company but the company can choose the Product Code, so long as it is unique within their product list. (For the curious, the above codes corresponded to the Apple 4S).

To find information on a wireless product, go to the FCC’s OET (Office of Engineering and Technology) page for Original Equipment Authorizations:

https://apps.fcc.gov/oetcf/eas/reports/GenericSearch.cfm

and enter the necessary information. In my personal experience, the Product Code rarely matches exactly to what is in the FCC database, so you may need to simply enter other information like Grantee Code and date range, and try to find your target product manually. For example, entering Grantee Code BCG and limiting the list to the 1st six months of 2014, we find the following product (they all have the same date and code, so this is probably multiple authorizations on a single product).

You can tell from the frequencies that this product uses WiFi (802.11bg,n) as well as cellular signals (849.0 Mhz is a Cellular Phone frequency).

When we click on the 1st link “Detail”, we find additional information about the product.

A good place to start is confidentiality letter, since this will outline all the items that the Grantee (Apple, in this case) is requesting the FCC not to publish as trade secrets. These typically include bill of materials, diagrams, and schematics. Even without these documents however, we can still learn much about a product. For example, if you click on the document “Reg Label Location” (which shows where a final product’s FCC Code and Compliance Statement will be), you see that the product is a new version of the iPad.

Apple managed to keep all photos from being published for this product, but typically test setup photos for the tests will be included, as well as internal photos of the circuits. Both can be very useful in figuring out what chipsets a product uses.

For example, if you search for FCC Grantee Code Q87 (Linksys, the maker of WiFi Routers) with product Code WRT600NV11 , you find a nice list of photographs available for the public to view, including internal photographs, antenna photos, and test configuration photos . (This product is a 2007 version of the WiFi N Router).

By clicking on Internal Photographs, it looks like this Linksys Router is using a Broadcom wireless chipset, BCM5354KFBG. If we felt so inclined, we could go to Broadcom’s Product Brief for this chipset and find out its capabilities.