Importing Kismet captures into Google Maps

Having captured a few WiFi hot spots while driving around I wanted to export these hotspots to a KML file that I could then import into Google Maps. There are applications and scripts to do this but I decided to have a go a creating something myself. As I am currently learning Python and in my opinion the best way to learn a new language is by doing then Python was my first choice for this. I am by no means a Python expert and there will be better ways of doing this I am sure.

The first step is to open the Kismet XML file for parsing. The simplest way I found was to use an ElementTree.

import sys
import xml.etree.ElementTree as Etree

# Open the XML file
tree = Etree.parse("test.netxml")
root = tree.getroot()

Next we need to parse the child nodes looking specifically for the “wireless-network” tag. From there we can parse each sub element to extract the information we are interested in. Including the SSID, MAC address, location etc.

for child in root:
    # If new network entry
    if child.tag == "wireless-network":
        essid = ""
        bssid = ""
        encryption = []
        gpslat = ""
        gpslng = ""
        # Iterate through child elements
        for element in child:
            # SSID element
            if element.tag == "SSID":
                # Interate through each sub element
                for subelement in element:
                    # Found encryption type add it to the list
                    if subelement.tag == "encryption":
                        encryption.append(str(subelement.text))
                    # Found SSID save it
                    elif subelement.tag == "essid":
                        essid = str(subelement.text)
            # BSSID element contains MAC address save it
            if element.tag == "BSSID":
                bssid = str(element.text)
            # Location fix element
            if element.tag == "gps-info":
                for gps in element:
                    # Extract latitude
                    if gps.tag == "avg-lat":
                        gpslat = str(gps.text)
                    # Extract longitude
                    if gps.tag == "avg-lon":
                        gpslng = str(gps.text)
            # Sort encryption list
            encryption.sort()

With the input file parsed we move on to exporting the results to a KML file. For this I used the SimpleKML python library. SimpleKML makes working with KML files a breeze.

import simplekml

# Create an instance if simplekml
kml = simplekml.Kml()
# Add a new point
kml.newpoint(name=essid, description=bssid + " " + 
            ' '.join(encryption), coords=[(gpslng, gpslat)])
# Now save it
kml.save("output.kml")

That’s the basics covered. Time to add some features. One thing I wanted was to be able to filter hotspots found within a specific radius of a given point. For instance if you only wanted to save hotspots within a mile of your house you could enter you home location and set a search radius of one mile. The resulting KML file would then only contain hotspots that fell within that radius. For this we can use the Haversine formula. The Haversine formula determines the great-circle distance between two points on a sphere (in this case the earth) given their longitudes and latitudes. There is also happens to be a nice little Haversine python library.

from haversine import haversine

home = (45.7597, 4.8422)
dest = (48.8567, 2.3508)
distance = haversine(home, dest, unit='mi')
if distance > 1.0:
    print ("Greater than 1.0 miles!")

More features were then added including/excluding specific SSID’s, specifying certain authentication types, specifying the output file etc all of which are passed as arguments to the script.

My resulting netxml2kml script can be seen below:-

#!/usr/bin/env python3
import sys
import xml.etree.ElementTree as Etree
import os.path
import simplekml
import argparse
from haversine import haversine

# python netxml2kml.py test4.netxml output.kml -r 5.0 -x 45.7597 -y 4.8422 -s
# python netxml2kml.py test4.netxml output.kml -i Raspberry -s
# python netxml2kml.py test4.netxml output.kml -e Raspberry -s
# python netxml2kml.py test4.netxml output.kml -a WEP -s

def str2bool(v):
    if v.lower() in ('yes', 'true', 't', 'y', '1'):
        return True
    elif v.lower() in ('no', 'false', 'f', 'n', '0'):
        return False
    else:
        raise argparse.ArgumentTypeError('Boolean value expected.')

parser = argparse.ArgumentParser(description='Convert Kismet Net XML to KML file.')
parser.add_argument("input_file", help="the Net XML file to be converted.")
parser.add_argument("output_file", help="the KML output file.")
parser.add_argument("-e", "--exclude", default="", help="exclude SSID string.")
parser.add_argument("-i", "--include", default="", help="include SSID string.")
parser.add_argument("-a", "--auth", default="", help="include search authentication string.")
parser.add_argument("-r", "--radius", type=float, default=0.0, help="include radius")
parser.add_argument("-x", "--lat", type=float, default=45.7597, help="start latitude")
parser.add_argument("-y", "--lon", type=float, default=4.8422, help="start longitude")
parser.add_argument("-s", "--show", type=str2bool, nargs='?', const=True, default=False, help="Show output entries.")
args = parser.parse_args()

def do_extraction(filename: str, output: str, exclude: str, include: str, auth: str, show: bool, radius: int,
                  lat: float, lon: float) -> int:
    if os.path.exists(filename) is False:
        print("Cannot find input file \"%s\"" % filename)
        sys.exit(1)
    print("Opening file \"%s\"" % filename)
    print("Saving to file \"%s\"" % output)
    tree = Etree.parse(filename)
    root = tree.getroot()
    kml = simplekml.Kml()
    print("Extracting entries...")
    found = 0
    for child in root:
        if child.tag == "wireless-network":
            essid = ""
            bssid = ""
            encryption = []
            gpslat = ""
            gpslng = ""
            for element in child:
                if element.tag == "SSID":
                    for subelement in element:
                        if subelement.tag == "encryption":
                            encryption.append(str(subelement.text))
                        elif subelement.tag == "essid":
                            essid = str(subelement.text)
                if element.tag == "BSSID":
                    bssid = str(element.text)
                if element.tag == "gps-info":
                    for gps in element:
                        if gps.tag == "avg-lat":
                            gpslat = str(gps.text)
                        if gps.tag == "avg-lon":
                            gpslng = str(gps.text)
                encryption.sort()
            valid = True
            if radius > 0.0:
                if gpslat and gpslng:
                    home = (lat, lon)
                    dest = (float(gpslat), float(gpslng))
                    dist = haversine(home, dest, unit='mi')
                    if dist > radius:
                        valid = False
            if include and essid.find(include) = 0:
                valid = False
            if auth and auth not in encryption:
                valid = False
            if valid:
                found += 1
                kml.newpoint(name=essid, description=bssid + " " + ' '.join(encryption), coords=[(gpslng, gpslat)])
                if show:
                    print(essid + "," + bssid + "," + ' '.join(encryption) + "," + gpslat + "," + gpslng)
    kml.save(output)
    print("Extracted %d entries." % found)
    return found

if __name__ == "__main__":
    ret = do_extraction(args.input_file, args.output_file, args.exclude, args.include, args.auth, args.show,
                        args.radius, args.lat, args.lon)

Advertisements

Mobile Wardriving Rig

I can’t quite believe it’s been over two years since I posted anything. So, apologies for that and with any luck hopefully I can improve on that and post a few more updates on recent escapades.

The last few months I have been experimenting with the Raspberry Pi for a whole host of applications. One thing I have wanted to do for some time is build a mobile Wardriving rig. For those that don’t know Wardriving is the art of scanning for Wi-Fi networks, usually from a car or other vehicle, and mapping out their locations. Basic setups would normally comprise a laptop, some means of determining your location and an external Wi-Fi adapter. I don’t fancy lumping around my laptop and figured it must be possible to achieve something similar using a Raspberry Pi. With a bit of free time on my hands I decided this would make an ideal weekend project.

My Wardriving rig running on the bench in the lab.

For anyone who wishes to build something similar this post will detail how I built mine. I’ll be honest I am not an expert on the Raspberry Pi or Linux and some of this is a learning curve for me.

All boxed up ready for deployment.

Shopping List

Before we get started on the build we are going to need a few bits of kit. The list below is what I used. I’ll be honest adding it all up it wouldn’t be cheap but fortunately I already had most of this stuff lying around. There will of course be suitable alternatives that will fit the bill, but I’ll leave that up to you.

Raspberry Pi 3 B+

If you going to build a mobile Wardriving rig using a Raspberry Pi it may as well be the latest version right.

Touch – HyperPixel 4.0

Most people would normally opt for a headless setup when building mobile wardriving rig. Then either SSH into the Pi using a laptop or mobile phone. My goal was to makes this as mobile as possible. I didn’t want to have to rely on any additional hardware. For this reason, I decided to use the HyperPixel 4.0. With a 4.0” IPS panel, 800×480 pixels, approx. 235 PPI, 18-bit colour and up to 60 FPS this is a truly excellent display. Did I mention there is also has a touch screen?

BT-708 USB GPS Receiver

To accurately determine your location we need a GPS receiver. The BT-708 USB GPS Receiver uses the UBX-G7020-KT chipset from U-Blox. I love the U-Blox range of receivers.

Alfa Network AWUS036NHA

The Alfa AWUS036NHA seems to be the pen testers adapter of choice. For one reason it works out of the box with Linux. For another it can operate in monitor mode. This allows the adapter to monitor (sniff) wireless traffic while not being associated with any networks access point. It also supports a whole host of other modes useful for pen testing, but we won’t go into those right now.

Anker PowerCore 20100 – Ultra High Capacity Power Bank

No preference here this the only power bank I own. It’s a beast. 20100 mA/h. Dual 2.4A outputs. With the display, external Wi-Fi adaptor and GPS receiver the kits going to draw a fair bit of power so you’re going to need something substantial if you want to run for any length of time.

Micro USB FAST Data Charger Cable Lead

Now this is important. I can’t tell you how many times I have had issues when powering my Raspberry Pi from anything other than the official power supply. The Pi is somewhat fickle when it comes to its supply voltage. Especially when powered from an external power bank. Using cheap cables just won’t cut. You’ll end up the lightning bolt appearing indicating under voltage conditions and in my case, you just won’t be able to get the external Wi-Fi adapter to work. I can only assume (and I didn’t investigate this) that lead resistance plays a part in this. With the current being drawn the volt drop caused by the lead resistance must be great enough to upset the Pi. So, for this reason, it’s important to use a high-quality charge cable.

A4 Tech KL-5 Mini Slim Compact Keyboard

At some point you will need access the Pi through the terminal. The display has a touch screen be a small USB keyboard makes things a lot easier.

Step 1 – Installing Raspbian

The first step is to install a fresh version of Raspbian onto your SD card. I am not going to go through this as there are loads of guides online to help including the Embedded Linux Wiki Wiki page.

Step 2 – Putting everything together

Start by plugging the HyperPixel display into the expansion port (the 40-pin header) on the Raspberry Pi. Pillars are included with the display to secure it to the Pi’s PCB. Be careful not to damage the display when pushing down on it. Next connect the GPS receiver and external Wi-Fi adapter. Be sure to connect your USB keyboard as well.

For the initial setup stage, using an external monitor or TV is the best option. We will leave setting up the HyperPixel until last. Place your new Raspbian SD card into the Raspberry Pi and apply power. Run though the generic setup for time zone, password, Wi-Fi settings etc.

Step 3 – Install and configure all the necessary tools

Open a terminal window by either clicking on the terminal icon in the title bar or pressing Ctrl+Shift+T.

Lets start by ensuring everything is up to date. Run the following commands through the terminal: –

sudo apt-get update
sudo apt-get upgrade -y 

Now install everything else with the following command:

sudo apt-get install -y screen gpsd libncurses5-dev libpcap-dev tcpdump libnl-dev gpsd-clients python-gps

We need to inform the GPS daemon which port the GPS receiver is connected. The easiest way to find out is by running a nice little script from a guy called Scott Helme.

Run the following command to download it: –

wget https://gist.githubusercontent.com/ScottHelme/e793516d2b322ed3a4c795a429eb5d04/raw/5829f33d29182aa92b79bcb7e76e71ab51c8fe1b/find.sh

Then make the new script executable: –

chmod +x find.sh

And then finally run it: –

./find.sh

You should get something similar to below: –

pi@raspberrypi:~ $ ./find.sh
/dev/ttyACM0 - u-blox_AG_-_www.u-blox.com_ublox_7_GPS_GNSS_Receiver

Open the GPS daemon configuration file for editing: –

sudo nano /etc/default/gpsd

Change the DEVICES value to the correct path found above: –

START_DAEMON="true"
GPSD_OPTIONS="-n"
DEVICES="/dev/ttyACM0 USBAUTO="true"
GPSD_SOCKET="/var/run/gpsd.sock"

Now we need to download and install Kismet. Kismet is a wireless network and device detector, sniffer, wardriving tool. Kismet is available for various platforms including Linux. At the time of writing the newest stable version on the Kismet code repository appears to be “kismet-2016-07-R1.tar.xz”. There are some newer BETA versions, but this version which worked fine me. We are building from source so this is going to take some time to complete.

Run the following commands (one at a time) in the terminal to download, extract, build and install Kismet.

wget http://www.kismetwireless.net/code/kismet-2016-07-R1.tar.xz
tar -xvf kismet-2016-07-R1.tar.xz cd kismet-2016-07-R1/
./configure
make dep
make
sudo make install

Assuming everything went to plan you should now have successfully installed Kismet. To avoid Kismet asking which Wi-Fi adapter we want to use every time we can specify this in the Kismet configuration file. It’s safe to assume the Pi’s internal Wi-Fi will be “wlan0” and the external adapter should be “wlan1” but you can confirm this by running “ifconfig”: –

ifconfig

Which should show all your network interfaces.

Edit the Kismet config file: –

sudo nano /usr/local/etc/kismet.conf

And change the network card setting “ncsource”. Remove any leading # that comments out the setting: –

ncsource=wlan1

Its worth changing the output file formats generated by Kismet. We are only interested in the log xml files so change the “logtypes” to: –

logtypes=gpsxml,netxml

Step 4 – Testing everything works

Start by checking the GPS receiver is working by running “gpsmon” from the terminal: –

gpsmon
gps

If you have the GPS daemon setup correctly you should see something similar to the screen above. Now depending on whether you have a fix or not you should see your location, speed, altitude, number of satellites etc. Even if you don’t have a fix you should see NMEA messages ($GPGLL etc) appearing at the bottom of the window. Press CTRL + C to exit back to the terminal.

Next let’s fire up Kismet and start logging. First we need to create a directory for Kismet to dump all its captured output.

mkdir ~/test
cd ~/test

Then run kismet using the following: –

sudo kismet

When kismet starts you will be asked if you wish to automatically start the kismet server. Select “Yes”.

kismet1

On the next screen, be sure to unselect “Show console” and then select “Start”.

kismet2

You may then get another prompt with a source warning. Select “OK” to acknowledge it.

kismet3

After a few seconds you should starting seeing detected networks appearing in the list at the top of the window. The elapsed time, number of networks, packets etc can be seen on the right-hand side. In the middle you should see you location as well as a visual representation of any captured packets.

kismet4

After a few minutes and having detected a suitable number of networks quit Kismet by clicking on the “Kismet” menu and selecting “Quit”.

kismet5

Kismet will ask you if you want to kill the Kismet server before quitting. Select “Yes” to do so.

kismet6

Your test directory should now have at least two capture files a “.gpsxml” file and a “.netxml” file.

pi@raspberrypi:~/test $ ls -l
total 844
-rw-r--r-- 1 root root 550346 Feb 10 16:31 Kismet-20190210-16-30-47-1.gpsxml
-rw-r--r-- 1 root root 309786 Feb 10 16:31 Kismet-20190210-16-30-47-1.netxml

Step 5 – Going mobile

With everything working all that remains now is to install the HyperPixel display drivers.

Start by cloning the HyperPixel repository using the following command: –

cd ~
git clone https://github.com/pimoroni/hyperpixel4 

Then run the following to begin the installation process: –

cd hyperpixel4
sudo ./install.sh

Once the installation has completed power down the Raspberry Pi and remove the HDMI cable. Re-apply the power and the display should spring into life. Eventually you should see the Raspbian desktop appear.

That’s it. You now have a completely mobile setup that can not only be used for wireless network surveillance but also forms the basis for building a complete mobile penetration testing kit.

In the next post we will play around with the captured data. Import it into
Google Maps and maybe even some data manipulation using Python as well.

Atmel ICE, JTAG and the ATmega32U4

Having spent a lot of time working with AVR microcontrollers I decided a number of years ago to invest in a dedicated In Circuit Emulator (ICE). At the time Atmel had just released their new Atmel ICE device. This seemed to fit the bill perfectly. atmel-ice_angle1024Not only did it support  traditional JTAG debugging but also debugWIRE. Atmels own propriety debug protocol aimed at low resource devices such as the ATMega88/168/328 family. I purchased the Atmel ICE basic kit. The kit consists of the Atmel ICE and a 10 pin ribbon cable to 10 to pin JTAG (0.05″ pitch) and 6 pin (0.1″ pitch) SPI connector. The full kit available at a much greater cost shipped with a number of different cables and adaptors. As debugWIRE uses the RESET line for debugging I deemed the 6 pin SPI cable would be all I needed. Or so I thought.

Moving on a few years I find myself now working with the ATmega32U4 again (I needed USB functionality) and to my surprise this device does not support debugWIRE only JTAG. What!!! How can this be?

I was wondering if Atmel sold those additional debug cables separately? Turns out they do but they are almost £50. After shelling out just shy of £100 in the first place I wasn’t prepared to spend another £50 on cables.
adaptor
So I set about building my own adaptor. The main problem I faced was the Atmel have used 0.05″ (1.27mm) pitch connectors rather than the more readily available standard 0.1″ (2.54mm) pitch connectors. What I needed was some form of breakout board or even something to convert from the 0.05″ pitch connector to something more manageable. After trawling the net it turns out Adafruit have a Cortex SWD adaptor which in essence is a 0.05″ pitch to 0.1″ breakout board. The pin mapping is one to one so assuming you ignore the silk screen it should be easy to interface to the ATmega32U4. The best thing about this solution is the price, I managed to get two of these boards from a local supplier for just £3.

The development board I am currently using is an OLIMEXINO-32U4 an Arduino Leonardo type design from Olimex. The table below shows the Cortex SWD to AVR JTAG pin mapping. Also shown is the JTAG connections of the 32U4 (or Arduino Leonardo if you prefer) development board.

# SWD Pin JTAG Pin Olimex 32u4 Pin
1 Vin TCK A3 (PF4)
2 SWIO GND GND
3 GND TDO A1 (PF6)
4 CLK VCC VCC
5 GND TMS A2 (PF5)
6 SWO RESET RESET
7 KEY N/C N/C
8 N/C N/C N/C
9 GND TDI A0 (PF7)
10 /RST GND GND

Below you can see a picture of my setup. I am not sure if they are needed but I did add 10K pull ups to all of the control lines TCK, TDO, TMS and TDI.

board1

One thing that had not dawned on me was the fact JTAG is not enabled by default. The pins designated to the JTAG interface PF4-PF7 are used as analog inputs. So in order for JTAG to work you need to ensure the JTAGEN fuse is programmed. This can be done through the ISP interface in the normal manner. Once I had that programmed I could successfully download and debug my code on target. Result.

Raspberry Pi Internet Radio

I am a big fan of internet radio stations but it can be a bit restricting listening to my favourite stations on my laptop or phone. So over the last couple of weeks I have been building my own internet radio. A lot of people have converted old routers into radios but the best example I found was Bob Rathbones amazing Raspberry PI Radio. I had an old Raspberry Pi 2 lying around not doing much so I decided why not give it a try. Bob provides on his website an extremely comprehensive guide that takes you through the process of building an internet radio which if you’re interested you can download here.

At the heart of this radio is Music Player Daemon (MPD) running on Raspian Jessie. MPD is a flexible, powerful, server-side application for playing music. Through plugins and libraries it can play a variety of sound files while being controlled by its network protocol. Bobs manual provides a detailed overview of construction and software. It contains instructions for building the radio using either the HDD44780 LCD directly wired to the Raspberry PI GPIO pins or alternatively using an either an Adafruit RGB-backlit LCD plate or the PiFace Control and Display (CAD) . An I2C backpack is also now supported. It can be constructed using either push buttons or rotary encoders. An optional infra-red remote control can also be used. Along with the construction guidelines Bob also provides software to drive the LCD, read the switch states and interface with the MPD server.

When I started I had a pretty good idea of what I wanted to achieve with this radio. I wanted a 4×20 HDD44780 based LCD display, push buttons for control (rather than rotary encoders) and a pair of 4″ coaxial speakers. I wanted it to sound as good as possible so decided early on to use a Digital to Analogue Converter (DAC) rather than relying on the line level audio output on the Pi. A network connection would be via WiFi rather than a LAN connection. It would also have the ability to play music from an external USB device. Possible even the ability to control it with an old infra-red remote control.

The enclosure was constructed from 9mm MDF sheet. The dimensions of which were based around the two coaxial 4″ speakers and the LCD display. I didn’t want anything too big but I also didn’t want it so cramped inside that everything wasn’t going to fit.

enclosure2.Using Front Panel Designer I drew up a template to aid with the drilling of the holes for the speakers, the switches and the panel cut out for the display. The whole thing was then glued and joined with furniture blocks before being painted.

While in my local Maplin store I managed to bag a pair of 4″ Vible Slick Coaxial speakers from their clearance section for a good price. They fitted the bill perfectly. The speakers are driven via a 2x30W audio power amplifier kit from Velleman. The amplifier has an RMS output of 15W into 4 ohms and is protected against overheating and short circuits. The LCD display is driven directly by the GPIO lines of the Raspberry Pi. As are the switch inputs. inside3aIn order to minimise the wiring somewhat I built a little interface board between the display, the switches and the header on the Raspberry Pi. I added a small potentiometer to the interface board to allow the overall volume to be configured.

Power for the Raspberry Pi is provided by the official mains power supply while the amplifier is powered via a 12V 50VA toroidal transformer. As I have already mentioned I wanted the radio to sound the best it possibly could so I opted to use the HifiBerry DAC+, a little expensive costing nearly as much as the Pi itself but it was definitely worth it. I am no audiophile but when driven hard those 4″ speakers sound great. With the addition of a panel mount USB socket music can also be played from a USB device.

Total spend is probably approaching well over £100, even already having the Raspberry Pi, but I am really pleased with the result. I have now have a fully up-gradable internet radio with around 600 stations configured that I can control remotely and sounds and looks amazing.

LG 32LC56 Power Supply Repair

I recently inherited a completely dead LG 32″ LCD TV from my parents. Apparently this TV set was working fine one day and completely dead the next. So I thought I would have a look and see if I could get it back up and running. Upon receiving the set the first thing I did was try and power it up. Nothing completely dead. No standby light nothing. Checked the fuse in the plug (obviously) and that was fine. Time to dig a bit deeper.

With the current symptoms the obvious suspect is going to be the power supply. The internet is strewn with examples of power supplies going bad in these TVs and people on eBay are even selling repair kits for anyone wanting to repair them.

After carefully removing the back panel I had managed to expose the power supply board. I must say a bit of a beast by all accounts. But if you think about the job it has this is to be expected. Fortunately most of the connectors were labelled with the expected output voltages. Probing around on these pins showed no voltage on any of them. Checking the mains into the board gave a reading of around 230V AC. Checking the voltage after the 5A fuse on mains input read nothing. Turns out this fuse had blown. Question is why?

On closer inspection smoke damage can be seen on the large heat sink holding the power transistor, bridge rectifier and rectifier diode on the input stage. My first thoughts were one of these may have been damaged but on closer inspection it turns out the smoke was caused by a 220 pF 2Kv ceramic disc capacitor just in front of the heat sink (shown in the image above directly between the transformer and the heat sink) exploding. Which explains why the fuse may have blown. Probing around the remainder of the input stage the other components appeared to be fine as far as I could tell. Turning my attention to the electrolytic capacitors (shown above) on the output stage I could immediately see a number of these were starting to show the tell tale signs of failure with at least three of them having significant bulging. So I decided I would replace all of them just as a matter of course along with the ceramic disc capacitor that had blown.

Once all of the new components had arrived and been fitted along with a new fuse I powered up the board on the bench and now had a 5V standby voltage present. After fitting the board back into the TV and a quick press the power button on the side and the TV sprung back into action. Result. So a nice easy fix this one. Total spend was about £3 whereas a refurbished power supply board runs to around £30. And for a TV only worth probably that in the first place it hardly seems worth it.

Build a Performance Quadcopter for under £150 – Part 2

I would like to start off by saying thank you to HobbyKing for their extremely prompt service. I now have in my possession a cardboard box full of quadcopter parts. I wasn’t going to waste any time getting started.

The first task was to assemble the frame. The frame consists of two glass fibre plates, an upper and lower plate, as well as four coloured plastic arms, two red and two white. How you configure of these arms is entirely up to you. I decided I would have the two white arms pointing forwards while the red arms pointed backwards. Attaching the arms is simply a case of screwing them to each plate with the screws provided. I found it easier to attached the arms to the lower plate first before adding the upper plate. If your following along with your own build be careful not to over tighten these screws and I would suggest investing in a decent set of hex drivers before starting.

With the frame assembled I then moved on to attaching the motors. This was simply a case of lining the up the holes on the motor with the holes at the end of each arm and using the screws provided with the frame to secure them in place.

Keeping this post short because I have run out of time for now. Next up I will be preparing the speed controllers and flashing them with Simon K’s modified firmware. So stay tuned.

Build a Performance Quadcopter for under £150 – Part 1

With summer fast approaching I decided it was high time I started a new project. I have been toying with the idea of building a quadcopter for a while now. The internet is littered with websites and videos detailing other people’s builds so I decided to give it a go. What will follow hopefully is a number of successive posts detailing my build process. Which should provide enough instruction for other people to build their own.

From the outset I had a fairly rough idea of what I wanted to achieve but for a little more inspiration I started reading a other peoples builds. One if the best builds I found was from a chap named Daniel J. Gonzalez. He based his quadcopter around a 330 mm frame which seemed like a good compromise to me. Click on the picture below to jump directly to the build on his blog.

Daniel J. Gonzalez My First Quadrotor

Daniel J. Gonzalez’s My First Quadrotor.

Like Daniel I opted to use the Hobby King F330 glass fibre frame. For the flight controller I decided on the Hobby King KK2.1.5 based purely on the customer reviews. Apparently the KK is easy to set-up and flies exceptionally well. It may well do with a competent pilot but time will tell how it copes with me in control. The speed controls I chose were the Hobby King blue series controllers. These are a fairly standard controllers however they can be flashed with Simon K’s high performance firmware optimized for quadcopter use. More on this later. The motors were Turnigy 1100kV outrunners which I am hoping should produce more than enough thrust to get the quadcopter off the ground and maybe even enough to carry a GoPro in the future.

The complete shopping list is shown below:-

Part Quantity Cost ($)
Glass Fiber Mini Quadcopter Frame 330mm 1 11.75
D2822/17 Brushless Outrunner 1100kv 4 20.00
Hobbyking KK2.1.5 Multi-rotor LCD Flight Control Board 1 19.99
HobbyKing 20A BlueSeries Brushless Speed Controller 4 39.40
GWS Style Slowfly Propeller 8×4.5 Black (CW) (4pcs) 1 2.63
GWS Style Slowfly Propeller 8×4.5 Black (CW) (4pcs) 1 2.62
Turnigy High Quality 14AWG Silicone Wire 1m (Red) 1 1.56
Turnigy High Quality 14AWG Silicone Wire 1m (Black) 1 1.56
Turnigy High Quality 18AWG Silicone Wire 1m (Red) 1 0.60
Turnigy High Quality 18AWG Silicone Wire 1m (Black) 1 0.80
10CM Servo Lead (JR) 32AWG Ultra Light 1 2.46
PolyMax 3.5mm Gold Connectors 10 PAIRS 2 4.20
Turnigy 4mm Heat Shrink Tube 1M (Red) 1 0.85
Turnigy 4mm Heat Shrink Tube 1M (Black) 1 0.73
Turnigy 5mm Heat Shrink Tube 1M (Red) 1 0.77
Turnigy 5mm Heat Shrink Tube 1M (Black) 1 0.68
Nylon XT60 Connectors Male/Female 1 3.92

Total spend = $114.52 + $8.09 (shipping) = $122.61 which was approximately £89.42 GBP at the time of purchase. All that was required to complete the build would then be a suitable 3S LiPo battery pack and radio system. I hadn’t decided on which radio system to use so opted to leave that until the initial build was complete.

Parts on order so the next post I shall start the build process.