ECE497 Project GPS Tracker

Revision as of 18:06, 4 November 2013 by Fendrirj (Talk | contribs)

Jump to: navigation, search

thumb‎ Embedded Linux Class by Mark A. Yoder

Team members: Robert Fendricks, Chris Hopwood

Grading Template

I'm using the following template to grade. Each slot is 10 points. 0 = Missing, 5=OK, 10=Wow!

00 Executive Summary
00 Installation Instructions 
00 User Instructions
00 Highlights
00 Theory of Operation
00 Work Breakdown
00 Future Work
00 Conclusions
00 Demo
00 Late
Comments: I'm looking forward to seeing this.

Score:  10/100

(Inline Comment)

Executive Summary

Chris Hopwood and Robert Fendricks will be working on a way to interface the Beaglebone Black with a GPS tracker using UART. We plan on using this data to track the Bone's location on a map via a web interface.


If you have hardware, consider Small Build, Big Execuition for ideas on the final packaging.

Installation Instructions

Give step by step instructions on how to install your project.

  • Include your github path as a link like this to the read-only git site:
  • Be sure your is includes an up-to-date and clear description of your project so that someone who comes across you git repository can quickly learn what you did and how they can reproduce it.
  • Include a Makefile for you code.
  • Include any additional packages installed via opkg.
  • Include kernel mods.
  • If there is extra hardware needed, include links to where it can be obtained.

User Instructions

Once everything is installed, how do you use the program? Give details here, so if you have a long user manual, link to it here.


Here is where you brag about what your project can do.

Include a YouTube demo.

Theory of Operation

Give a high level overview of the structure of your software. Are you using GStreamer? Show a diagram of the pipeline. Are you running multiple tasks? Show what they do and how they interact.

Work Breakdown

We first attempted to connect to the Beaglebone via the included FTDI cable. Here is a link to the FTDI cable's ref. sheet: To connect the

List the major tasks in your project and who did what.

Also list here what doesn't work yet and when you think it will be finished and who is finishing it.


The GPS we are using is MTK3339

To load the device tree overlay on the beaglebone:

root@beaglebone# echo BB-UART4 > /sys/devices/bone_capemgr.*/slots

This will connect UART4-rx onto P9_11.

To find which tty the UART is exposed as, run:

root@beaglebone# dmesg | tail

On our beagle it outputted:

[   50.991396] bone-capemgr bone_capemgr.8: slot #8: 'Override Board Name,00A0,Override Manuf,BB-UART4'
[   50.991495] bone-capemgr bone_capemgr.8: slot #8: Requesting part number/version based 'BB-UART4-00A0.dtbo
[   50.991514] bone-capemgr bone_capemgr.8: slot #8: Requesting firmware 'BB-UART4-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
[   50.991542] bone-capemgr bone_capemgr.8: slot #8: dtbo 'BB-UART4-00A0.dtbo' loaded; converting to live tree
[   50.991860] bone-capemgr bone_capemgr.8: slot #8: #2 overlays
[   50.995484] 481a8000.serial: ttyO4 at MMIO 0x481a8000 (irq = 61) is a OMAP UART4
[   50.996082] bone-capemgr bone_capemgr.8: slot #8: Applied #2 overlays.
[   51.171271] [drm:output_poll_execute], [CONNECTOR:5:HDMI-A-1] status updated from 2 to 2
[   61.202485] [drm:output_poll_execute], [CONNECTOR:5:HDMI-A-1] status updated from 2 to 2
[   71.233751] [drm:output_poll_execute], [CONNECTOR:5:HDMI-A-1] status updated from 2 to 2

According to [ 50.995484] 481a8000.serial: ttyO4 at MMIO 0x481a8000 (irq = 61) is a OMAP UART4 our port is mapped to ttyO4.

To test if the GPS is connected correctly, run:

root@beaglebone# screen /dev/ttyO4 9200

replacing ttyO4 with whatever device dmesg reported earlier.

To disconnect from the screen session correctly, press <ctrl>+<shift>+<:>, then type ":quit"

Google Maps Webpage

We used Google Maps in Javascript to interface with the Beaglebone Black and display our GPS information.

Robert started work on this, first using Dr. Yoder's Boneserver script to create a simple server. A new webpage was added that just had map on it. Google provides free documentation for their API, and it turns out it's fairly straight forward to use. One of the many features that Google offers with this API is the ability to draw on the map, such as placing markers and drawing lines. By using the marker class in conjunction with actionlisteners, I was able to create a button that would place a marker on coordinates specified by the user. The next step will be to have a script that will read from a file and place markers or lines on the map given a time range.

Connecting to the Bone

For this project, we felt that being able to connect to the Beaglebone directly to access the web interface would be beneficial. To do this, we looked into setting up an ad-hoc wireless network.

To do this, first make sure that you have a wireless interface installed an configured on the Bone. We used Adafruit's RTL8192CU wireless adapter on our bone.

Once your wireless adapter has been configured, you are now ready to set up the Ad Hoc network. The following commands must be run on both the Beaglebone and the computer you want to connect to the Beaglebone. Note that this will utilize the wireless adapter on your computer, so you won't be able to use it for connecting to the internet. These commands are:

ip link set <interface> down #This will bring your wireless interface down
iw <interface> set type ibss #This sets your interface to act as an Ad Hoc Network
ip link set <interface> up #Bring your interface back up
iw <interface> ibss join <SSID> <frequency> #This sets up an SSID for your ad hoc network.
#<SSID> and <frequency> must be the same on both machines

Once these commands have been run on both machines, you now want to assign an IP address to both. The most straight forward way is to use a static IP for both, making sure they are on the same subnetwork. Running the following command on each will accomplish this:

ip addr add <IP address>/<subnet mask> dev <interface>
#e.g.: ip addr add dev wlan0
#This should go without saying, but make sure the IP address is different on the two machines

Now you should be able to ping the IP of the opposite machine and get a response. If you get it, you're done! In our experience, it can take a while of pinging before we get a response back. We will have to look into what the cause of this is.

Future Work

Suggest addition things that could be done with this project.


Give some concluding thoughts about the project. Suggest some future additions that could make it even more interesting.

Useful Links

Server Side Events info:

GPS Ref. Sheet:

GPS NMEA Sentences:

thumb‎ Embedded Linux Class by Mark A. Yoder