iPhone Cellular Tracking – Redux. Can it be turned off, at all?

If you managed to catch my previous post on the iPhone Cellular Location Tracking Controversy, you saw that I did a little more research into the issue than most of the other articles. Or, at least I showed my work. So why post today? I’m going to walk through a check to see if turning of ‘Location Services’ and *not* approving any of the services to use it for a week, stopped or at least reduced the amount of data recorded.

Here is what I did…. and at the end of the article, we’ll both know the results.

Syncing the iPhone to laptop

Connected my phone to the laptop at 08:49, and specifically told iTune to sync. Once that was done, I changed to the iPhone backup directory:

Looking for updated files
:Backup me$ cd /Users/me/Library/Application\ Support/MobileSync/Backup

Next, I checked to see which directories had been most recently updated:

:Backup me$ ls -ltr
total 0
drwxr-xr-x  1929 me  staff  65586 Mar 16  2010 21562bef54882a56a05f4047db0dd1ea95783af1
drwxr-xr-x  1323 me  staff  44982 Apr  2 08:16 d56742670a5e045f4a76ebb7fd93c728054c0ebe-20110402-081551
drwxr-xr-x   719 me  staff  24446 Apr 25 16:33 669ed5e78e2afe06caad469294edd80d4b3261b9
drwxr-xr-x  1371 me  staff  46614 Apr 26 08:49 d56742670a5e045f4a76ebb7fd93c728054c0ebe

Locating the Manifest files that contain filename for the consolidated.db data file. This netted 4 database files. The one I am most interested in is the one created during the sync at 08:49 this morning.

:Backup me$ find . -name 'Manifest.mbdb*' -exec ls -l {} \; 
-rw-r--r--  1 me  staff  226086 Apr  2 08:16 ./d56742670a5e045f4a76ebb7fd93c728054c0ebe-20110402-081551/Manifest.mbdb
-rw-r--r--  1 me  staff  167152 Apr  2 12:21 ./669ed5e78e2afe06caad469294edd80d4b3261b9/Manifest.mbdb
-rw-r--r--  1 me  staff  167022 Apr 25 16:33 ./669ed5e78e2afe06caad469294edd80d4b3261b9/Snapshot/Manifest.mbdb
-rw-r--r--  1 me  staff  232090 Apr 26 08:49 ./d56742670a5e045f4a76ebb7fd93c728054c0ebe/Manifest.mbdb

Changing to the directory, I ran the python script that lists contents of the db, and it’s data files, looking for the true name of the consolidated.db. There are over 1300 data files in that directory. It looks like the data file name remains unchanged (4096c9ec676f2847dc283405900e284a7c815836).

:Backup me$ cd ./d56742670a5e045f4a76ebb7fd93c728054c0ebe

:d56742670a5e045f4a76ebb7fd93c728054c0ebe me$ ls -1 | wc -l
    1369

:d56742670a5e045f4a76ebb7fd93c728054c0ebe me$ ~/phonedb2.py | grep consolidated
-rw-r--r-- 00000000 00000000 19128320 1303587917 1303587917 1301716372 (4096c9ec676f2847dc283405900e284a7c815836)RootDomain::Library/Caches/locationd/consolidated.db
File located, copy and compare to previous

Now that I know where the file is, I’m going to copy it to my home directory, and compare it to the other DB files I’ve saved off over the last week. Looking at the list, you can see that the size of the file has not changed, since I started to track this last week. Now, that does not necessarily mean there are no new records in the table, but, it’s a pretty decent indication that it does not. But, an examination of the table, and comparison to the data from the last extract will quickly tell the tail!

:d56742670a5e045f4a76ebb7fd93c728054c0ebe me$ cp 4096c9ec676f2847dc283405900e284a7c815836 ~/iPhoneTracking.3.db

:~ me$ ls -ltr iPhone*  
-rw-r--r--  1 me  staff  19128320 Apr 21 10:19 iPhoneLocation.1.db
-rw-r--r--  1 me  staff    225280 Apr 21 10:21 iPhoneLocation.2.db
-rw-r--r--  1 me  staff  19128320 Apr 21 13:23 iPhoneLocation.4.db
-rw-r--r--  1 me  staff  19128320 Apr 21 15:13 iPhoneTracking.1.db
-rw-r--r--  1 me  staff  19128320 Apr 22 14:24 iPhoneTracking.2.db
-rw-r--r--  1 me  staff  19128320 Apr 26 09:16 iPhoneLocation.3.db
Comparing the data. 22-APRIL vs. 26-APRIL.

I simply turned off Location Services on my phone last week, after storing the snapshot on 22-APRIL. During that time I used several apps that use some sort of location information, and in the cases where I was prompted to provide location services, I declined.

But first things first. I think it’s important to show that there is more than just the controversial CellLocation data in this database file. Here is the full list of tables included in consolidated.db

:~ me$ sqlite3 iPhoneTracking.2.db  (this is the file from 22-APRIL)
SQLite version 3.6.12
sqlite> .tables
CdmaCellLocation                   CellLocationCounts               
CdmaCellLocationBoxes              CellLocationHarvest              
CdmaCellLocationBoxes_node         CellLocationHarvestCounts        
CdmaCellLocationBoxes_parent       CellLocationLocal                
CdmaCellLocationBoxes_rowid        CellLocationLocalBoxes           
CdmaCellLocationCounts             CellLocationLocalBoxes_node      
CdmaCellLocationHarvest            CellLocationLocalBoxes_parent    
CdmaCellLocationHarvestCounts      CellLocationLocalBoxes_rowid     
CdmaCellLocationLocal              CellLocationLocalCounts          
CdmaCellLocationLocalBoxes         CompassCalibration               
CdmaCellLocationLocalBoxes_node    Fences                           
CdmaCellLocationLocalBoxes_parent  Location                         
CdmaCellLocationLocalBoxes_rowid   LocationHarvest                  
CdmaCellLocationLocalCounts        LocationHarvestCounts            
Cell                               TableInfo                        
CellLocation                       Wifi                             
CellLocationBoxes                  WifiLocation                     
CellLocationBoxes_node             WifiLocationCounts               
CellLocationBoxes_parent           WifiLocationHarvest              
CellLocationBoxes_rowid            WifiLocationHarvestCounts        

The table that is supposed to contain the data, is CellLocation. Lets show what is in the last 5 records entered in that table. Here are the fields, then the last 5 records:

sqlite> .header ON
sqlite> select * from CellLocation limit 1;
MCC  MNC  LAC  CI  Timestamp  Latitude  Longitude  HorizontalAccuracy  Altitude  VerticalAccuracy  Speed  Course  Confidence

22-APRIL
sqlite> select Timestamp,Latitude,Longitude,HorizontalAccuracy,Speed,Confidence from CellLocation order by Timestamp desc limit 5; Timestamp|Latitude|Longitude|HorizontalAccuracy|Speed|Confidence 325110108.640637|47.24654626|-122.43737727|2164.0|-1.0|70 325110108.640637|47.24717628|-122.43819308|500.0|-1.0|50 325110108.640637|47.24570667|-122.43808859|2138.0|-1.0|50 325110108.640637|47.2472279|-122.43625974|1550.0|-1.0|70 325110108.640637|47.24575543|-122.43641382|500.0|-1.0|50
26-APRIL
:~ me$ sqlite3 iPhoneTracking.3.db SQLite version 3.6.12 sqlite> .header ON sqlite> select Timestamp,Latitude,Longitude,HorizontalAccuracy,Speed,Confidence from CellLocation order by Timestamp desc limit 5; Timestamp|Latitude|Longitude|HorizontalAccuracy|Speed|Confidence 325110108.640637|47.24654626|-122.43737727|2164.0|-1.0|70 325110108.640637|47.24717628|-122.43819308|500.0|-1.0|50 325110108.640637|47.24570667|-122.43808859|2138.0|-1.0|50 325110108.640637|47.2472279|-122.43625974|1550.0|-1.0|70 325110108.640637|47.24575543|-122.43641382|500.0|-1.0|50

CONCLUSION

Based on the evidence collected from my phone, it indicates that turning LOCATION SERVICES OFF DOES STOP CellLocation LOGGING!. So.. there you have it.. My research. I’ve shown my work. Explained my methodology. You can trust me or not, but if you have some evidence, beyond some huckster’s article, that indicates I’m wrong, PLEASE let me know! If I missed something, I want to correct my research and conclusion.

As always, you cell phone may vary.

The Great iPhone Location File Controversy

The Great iPhone Location File Controversy – is it really a problem?

Unless you have been living under a rock, or use a Windows Mobile Device (no difference), you no-doubt have heard about the reports floating around in the last day or so about the infamous consolidated.db location history file that is maintained on each 3G enabled iOS4 devices such as the iPhone and 3G iPad.

In fact, the number of articles discussing this issue (and now this one is also joining the fray) is extensive.

Regardless, it’s an issue of one sort or another, so I decided to delve into this a little bit. My research starts with this site on ReadWriteWeb: Your iPhone Is Tracking Your Every Move.

The article references this page [iPhoneTracker], where you can download and app, or the source code to compile a program to read your consolidated.db file. However, first you must find it! The instructions for finding the file were not completely accurate, there are some references with path misspellings etc. So, I’m going to re-do those pages, show you how I did it, include the Python script I ran to read the database file, and finally the steps I went about to move the file, compare snapshots of the file, and see if turning off location services, as it purported, solves this problem

First order of business is to get the App. Since I’m smart and use a MAC (and LINUX, but I don’t sync my phone to LINUX, so that’s not going to be discussed any further) I grabbed this zip file, extracted the app inside, and dropped it in my Applications pane.

Running the program, I see this:

iPhone Tracker Data File Heat Map

As you can see, I don’t do much wandering around. Zoomed in you can see some of the places along the West Coast I have wandered since I purchased the current device. The App will display ALL data, or you can have it just display a specific weeks’ full of data, form any time frame in the device. Here is a shot of some travel I did during Thanksgiving 2010.

A winter vacation to California, during Thanksgiving

To say the dataset is full of inaccuracy’s is an understatement. Just look at this map of the last two days of travel. I can assure you, I was not in Sumner, nor in Olympia or any of those other places on the eastern side of the sound in a long time, much less that last two days:

A day in the life, covering the last few days. However, there are a lot of errors!

And yet another, from the middle of last year. You can see a lot of ‘hits’ on Vancouver island. However, I have NEVER been there. Ever!

This map is full of errors, I've never been to Vancouver Island!

OK, so, I hope you can see that, the use of the data has it’s limitations. It’s not very accurate. In face it’s pretty inaccurate in enough cases to make it’s utility, dubious.

But, I wanted to know more, so I delved deeper into the files and went in search of the nefarious SQLite file itself. First stop was this page, where I grabbed a script, applied some mentioned patches, located the backups directory and find my consolidated location files (I found 4).

Here is the patched Python script:

#!/usr/bin/env python
import sys

def getint(data, offset, intsize):
    """Retrieve an integer (big-endian) and new offset from the current offset"""
    value = 0
    while intsize > 0:
        value = (value<<8) + ord(data[offset])
        offset = offset + 1
        intsize = intsize - 1
    return value, offset

def getstring(data, offset):
    """Retrieve a string and new offset from the current offset into the data"""
    if data[offset] == chr(0xFF) and data[offset+1] == chr(0xFF):
        return '', offset+2 # Blank string
    length, offset = getint(data, offset, 2) # 2-byte length
    value = data[offset:offset+length]
    return value, (offset + length)

def process_mbdb_file(filename):
    mbdb = {} # Map offset of info in this file => file info
    data = open(filename).read()
    if data[0:4] != "mbdb": raise Exception("This does not look like an MBDB file")
    offset = 4
    offset = offset + 2 # value x05 x00, not sure what this is
    while offset < len(data):
        fileinfo = {}
        fileinfo['start_offset'] = offset
        fileinfo['domain'], offset = getstring(data, offset)
        fileinfo['filename'], offset = getstring(data, offset)
        fileinfo['linktarget'], offset = getstring(data, offset)
        fileinfo['datahash'], offset = getstring(data, offset)
        fileinfo['unknown1'], offset = getstring(data, offset)
        fileinfo['mode'], offset = getint(data, offset, 2)
        fileinfo['unknown2'], offset = getint(data, offset, 4)
        fileinfo['unknown3'], offset = getint(data, offset, 4)
        fileinfo['userid'], offset = getint(data, offset, 4)
        fileinfo['groupid'], offset = getint(data, offset, 4)
        fileinfo['mtime'], offset = getint(data, offset, 4)
        fileinfo['atime'], offset = getint(data, offset, 4)
        fileinfo['ctime'], offset = getint(data, offset, 4)
        fileinfo['filelen'], offset = getint(data, offset, 8)
        fileinfo['flag'], offset = getint(data, offset, 1)
        fileinfo['numprops'], offset = getint(data, offset, 1)
        fileinfo['properties'] = {}
        for ii in range(fileinfo['numprops']):
            propname, offset = getstring(data, offset)
            propval, offset = getstring(data, offset)
            fileinfo['properties'][propname] = propval
        mbdb[fileinfo['start_offset']] = fileinfo
    return mbdb

def process_mbdx_file(filename):
    mbdx = {} # Map offset of info in the MBDB file => fileID string
    data = open(filename).read()
    if data[0:4] != "mbdx": raise Exception("This does not look like an MBDX file")
    offset = 4
    offset = offset + 2 # value 0x02 0x00, not sure what this is
    filecount, offset = getint(data, offset, 4) # 4-byte count of records 
    while offset < len(data):
        # 26 byte record, made up of ...
        fileID = data[offset:offset+20] # 20 bytes of fileID
        fileID_string = ''.join(['%02x' % ord(b) for b in fileID])
        offset = offset + 20
        mbdb_offset, offset = getint(data, offset, 4) # 4-byte offset field
        mbdb_offset = mbdb_offset + 6 # Add 6 to get past prolog
        mode, offset = getint(data, offset, 2) # 2-byte mode field
        mbdx[mbdb_offset] = fileID_string
    return mbdx

def modestr(val):
    def mode(val):
        if (val & 0x4): r = 'r'
        else: r = '-'
        if (val & 0x2): w = 'w'
        else: w = '-'
        if (val & 0x1): x = 'x'
        else: x = '-'
        return r+w+x
    return mode(val>>6) + mode((val>>3)) + mode(val)

def fileinfo_str(f, verbose=False):
    if not verbose: return "(%s)%s::%s" % (f['fileID'], f['domain'], f['filename'])
    if (f['mode'] & 0xE000) == 0xA000: type = 'l' # symlink
    elif (f['mode'] & 0xE000) == 0x8000: type = '-' # file
    elif (f['mode'] & 0xE000) == 0x4000: type = 'd' # dir
    else: 
        print >> sys.stderr, "Unknown file type %04x for %s" % (f['mode'], fileinfo_str(f, False))
        type = '?' # unknown
    info = ("%s%s %08x %08x %7d %10d %10d %10d (%s)%s::%s" % 
            (type, modestr(f['mode']&0x0FFF) , f['userid'], f['groupid'], f['filelen'], 
             f['mtime'], f['atime'], f['ctime'], f['fileID'], f['domain'], f['filename']))
    if type == 'l': info = info + ' -> ' + f['linktarget'] # symlink destination
    for name, value in f['properties'].items(): # extra properties
        info = info + ' ' + name + '=' + repr(value)
    return info

verbose = True
if __name__ == '__main__':
    mbdb = process_mbdb_file("Manifest.mbdb")
    mbdx = process_mbdx_file("Manifest.mbdx")
    sizes = {}
    for offset, fileinfo in mbdb.items():
        if offset in mbdx:
            fileinfo['fileID'] = mbdx[offset]
        else:
            fileinfo['fileID'] = ""
            print >> sys.stderr, "No fileID found for %s" % fileinfo_str(fileinfo)
        print fileinfo_str(fileinfo, verbose)
        if (fileinfo['mode'] & 0xE000) == 0x8000:
            sizes[fileinfo['domain']]= sizes.get(fileinfo['domain'],0) + fileinfo['filelen']
    for domain in sorted(sizes, key=sizes.get):
        print "%-60s %11d (%dMB)" % (domain, sizes[domain], int(sizes[domain]/1024/1024))

I placed the script in my home directory for now. Later I’ll move it off to the Applications directory. Setting the script to executable, I then set out to locate the manifest db files. To do this, I leveraged the find utility (don’t worry Windoze users… you’re not missing this utility, you never had it in the first place). I thus located these 3 manifest db files. The one I’m most interested in is dated today:

Now it’s time to run the python script, and grep for the filename I need.

Locating the physical backup filename for the database file

Filename in hand, I check and verify it’s existence. The important part of the data returned is this:

(4096c9ec676f2847dc283405900e284a7c815836)RootDomain::Library/Caches/locationd/consolidated.db:

That number is the real filename. Checking that I see that the file is there. Making a copy of that file available in my home directory (using cp to copy it… that means ‘copy’ for you Windoze users reading from your bunkers).

Making a copy of the file. One never wants to hack on a 'production' data file.

Word on the street, is that this is a SQLite database file. I should be able to confirm that with a simple strings test, and the rumor is confirmed:

Checking to see if the file is an SQLite database file.

I opened the database file, and selected the first 5 records, and last 30 records from the CellLocation table (rumored to contain the data of interest).

The last 5 records recorded are:

MCC|MNC|LAC|CI|Timestamp|Latitude|Longitude|HorizontalAccuracy|Altitude|VerticalAccuracy|Speed|Course|Confidence
310|410|42979|9468182|325110108.640637|47.24654626|-122.43737727|2164.0|0.0|-1.0|-1.0|-1.0|70
310|410|42997|9468176|325110108.640637|47.24717628|-122.43819308|500.0|0.0|-1.0|-1.0|-1.0|50
310|410|42997|6781206|325110108.640637|47.24570667|-122.43808859|2138.0|0.0|-1.0|-1.0|-1.0|50
310|410|42997|7895312|325110108.640637|47.2472279|-122.43625974|1550.0|0.0|-1.0|-1.0|-1.0|70
310|410|42985|6781206|325110108.640637|47.24575543|-122.43641382|500.0|0.0|-1.0|-1.0|-1.0|50

Now, the time stamping get’s a little tricky.. it’s seconds since January 01, 2001 (I really don’t want to do the GMT / epoch offsets right now), but I don’t need to worry about that, all I really care about is that LAST location the phone recorded for me. If it did, in fact, honor my demand to turn OFF location services, my last point of origin should be in or north of Purdy.

Checking this Latitude and Longitute with Lougle Maps (OK, so it’s a corny movie reference, move on with your big bad selves)… I see….

Well, this does not bode well for the Apple ‘researchers’ that say turning off Location Services solves this problem. As far as I can tell it DOES NOT. I’ll be doing a little more research on this myself later, when I have time to verify the timestamps. But for now, it looks like, regardless if you like it or not.. Big Brother Steve Jobs is WATCHING!!!!

Just a few articles culled from a Google query on iOS4 devices


iOS 4 devices quietly track, store users’ locations | iLounge News

Apr 20, 2011 iLounge news discussing the iOS 4 devices quietly track, store users’ locations. Find more iPad news from leading independent iPod, iPhone,
www.ilounge.com/…/ios4devices-quietly-track-store-users-locations/Cached

Apple tracking location of iOS4 device users, researchers say
Apr 20, 2011 A team of researchers have discovered that iOS4 is secretly obtaining your location and recording it to a hidden file, raising obvious
www.betanews.com/article/Apple-tracking…iOS4device…/1303319892

Got an iPhone or 3G iPad? Apple is recording your moves – O’Reilly
Apr 20, 2011 Ever since iOS 4 arrived, your device has been storing a long list of ….. Why not just visit http://oo.apple.come from any IOS4 device and
radar.oreilly.com/2011/04/apple-location-tracking.html


  • Apple tracks your location in iOS 4 without your permission
    2 hours ago 

    From the moment you switched to iOS 4,your device has been storing a long list of coordinates(latitude – longitude) and timestamps.

    Top Buzz News2846 related articles

  • Passing of a friend. Memories of Allie Daneman

    Today I have a very, VERY heavy heart. Yesterday I learned of the passing of a friend. Allie Daneman (aka Drainfade) left us yesterday at the age of 38. I miss him already.

    I first met Allie 10 years ago, via the Pacific Northwest VFR list.

    Having both grown up the S.F. Bay Area, we immediately hit it off. Allie was always a joy to ride with, we met up for rides often. He had and energy and passion for motorcycles that was infectious.

    It was with great sorrow, we’d learned of his cancer diagnosis, just a short couple of years later. It was a grave prognosis. Melanoma. Skin cancer. And it was in an advanced stage. But he forged forward with the therapy. He told me about the horrendous descriptions of what the Chemotherapy would and could do to his body. But he had a great passion for life and his family, and he persevered.

    He bravely fought the battle for 8 years. Far surpassing expectations of survival. He was, a fighter!

    Recently he’d asked me a question about Short Course R/C truck (he has and SC10, similar to mine). Sadly, I didn’t find the answer to his question before he passed. Not that it matters any more, but I hate not having had the chance to be a friend to him, just one more time, and send some help his way.

    Sadly, I didn’t know how badly things had recently being going for Allie. For those strong enough to read it, his blog tells the frank and sobering story of a man preparing for the end. It was difficult to read, but I felt important to do so.

    I’m having a hard time getting my thoughts together today. I’m been in shock since I found out around 5:00PM yesterday. We had some great times, and when I started this entry… my intent was to focus on those good time, sharing a few stories… but.. I just can’t do it right now. Instead I’m including the obituary from his own website.

    Allie George Daneman age 38 passed away on April 5, 2011, after a courageous 8-year-plus battle with melanoma. He is survived by his wife Jennifer of almost 13 years, their three children Ben (10), twins Toby and Jessi (8), brother (Jake), parents , Stepmother, Grandmother, Uncles, in-laws, brother-in-law, Stepfather. A native Californian, Allie was born on November 28, 1972 and grew up in San Francisco. He graduated from The Athenian High School, a Bay Area private college prep. school, in 1991. Allie holds a BS Degree in Business and Public Administration from U. of the Pacific, Stockton, CA. At UOP, he belonged to the Omega Phi Alpha Fraternity and played on the Lacrosse team. Allie worked as a Network Engineer for Alcatel-Lucent, T-Mobile USA Integrations Lab in Bellevue, WA. He loved to snow ski and snowboard. Allie was an avid motorcyclist and maintained a blog of his motorcycling exploits, culminating in his annual ride from Seattle, WA to the Laguna Seca MotoGp races in Monterey, CA. Motorcycling was more than a hobby for Allie–it was his passion. His family and friends will miss him immensely as his undying spirit freewheels in eternity. In lieu of flowers, memorial donations may be made to the Daneman Family Fund at US Bank. Memorial Service will be held on Friday, April 8, 2011

    The silver lining in this, is that he’s at peace now. No longer in pain, and free to ride the skies at will.

    Godspeed Allie. We’ll all miss you my friend. We’ll miss you a lot.

    It’s here! The TLR22. And it’s built!

    Ah.. YES! Months of waiting. Reading the press releases. Seeing the sneak-peek spy photos, hearing the team drivers talk about this amazing new car. This (r)evolution in 2wd 1/10th scale RC Racing. Innovation, engineering, a radical remake.

    The Hype surrounding this new (model / toy) car was intense! Just read this little blurb from Team Losi Racing (TLR) about the brand new TLR22!

    The Team Losi Racing 1/10-scale 22 2WD Electric Race Buggy Kit is an entirely new racing platform. Without a doubt, it will reignite 1/10-scale electric racing throughout the world. The TLR 22s innovative design takes full advantage of envelope-pushing Li-Po and brushless power. It is the only platform of its kind to offer all the hardware needed in a single kit to build a rear- or mid-motor configured chassis. The 22 is about to change all the rules.

    So.. I, of course, had to order one. And on April 1st, it arrived at the local Hobby shop (along with 11 others) for a bunch of the local racers. Mine, was #7 (at our shop, 1533 worldwide, based on it’s serial number), so the body of the car carries that number.

    Without further reading, here are some pictures of the new TLR22, along with the older Associated Factory Team B4 I’ve been racing for about a month now. As you will see, the 8 year old AE design is really showing it’s age.

    AE FT b4 (left), TLR 22 (right). The difference in body is astounding.

    The side view of the car exemplifies it’s sleek new design.

    TLR22 In Profile

    Compare it to the ‘current’ B4 class buggy from Associated. It’s a bit like comparing a runner, to a bowler.

    Current offering from Team Associated (AE), the B4 (and B4.1)

    Here they are with their bodies off. Both are fitted with Stock Club Racing 17.5T brushless power systems, SAVOX high-speed servos, and the new 96mm compact 60C LiPo, which was designed specifically for the TLR22 by Losi’s battery division.

    AE B4 is on the left. You can see that positioning of the electronics is a lot further off the center line, increasing the tendency for the vehicle to roll over in turns. Compare that to the compact, down the middle design of the TLR22. But the differences go far beyond that. If you notice, the older B4 is a rear engine design. By contrast the new TLR22 can be built either rear motor, OR, as I have done here, mid-motor! I’m aware of only one other off-road 2wd mid-motor buggy currently available. But this is the only kit that was designed to be built either way, and comes with all the parts to do it right in the box.

    The guts, that bring the glory. (B4 left, TLR22 right)

    In mid-motor configuration, the power controller (ESC) is located on a bracket right above the motor and transmission. Space is VERY limited so wiring must be compact and tidy. No room for sloppy just wire it up work (which I never do anyway). It was a challenge to get it even this tidy. Others have produced even cleaner looking installations by using all the same color wire. I decided to stick with the stock multi-color wiring supplied with the ESC, and power leads from the battery manufacture. You can’t hardly go wrong doing that.

    Speed controller and battery wiring.

    Here you can see the motor, it’s wiring, transmission (to the left of the motor) and receiver antenna. Even with the smallest 2s battery in the RC off-road industry, space is at a premium!

    Motor wiring and installation.

    Servo and receiver location was no picnic either. Here I’m running a 3/4 length Titanium geared .07 ms high-torque servo (yes, yes.. it’s as expensive as it sounds, and without a servo-saver in the design, it’s also in a fair degree of peril!). Just behind the SAVOX SH-1257TG servo, is the Futaba sport 3-channel 2.4GHz FHSS receiver. The control center for all that is fun and right in the buggy. One of the many advantages of the 2.4GHz system (aside from eliminating the need for crystals and frequency pins or flags) is the very show length antenna. Running an old 75 or 27 MHz antenna (about 11″ long) would just ruin the look of this car. And I’m sure you understand how important it is to look good!.

    Just behind (to the right) of that is the 7.4V 3800mAh 2S2P 60C 96mm LiPo. It’s the battery that makes all of this possible.

    Finally, one last photo of just the TLR22, wired and ready for racing:

    TLR22