Hacking the TP-Link TP-WR703N – Part 1: Brick it and then hack its serial port

I’m working on an embedded project that needs to be able to run node.js over WiFi. There aren’t too many cheap boards that can run linux. The $25 Raspberry Pi and the discontinued Pogoplug V2, which can be had for about $15 immediately came to mind. However, each of these boards had their shortcomings.  The Pogoplug is discontinued, so it may not be available in the future, and also, the PCB is rather big.  Neither of them has  built-in storage, and while both of them can take cheap <$10 USB WiFi adapters, the usable range is rather short.  Adding a power supply and a better USB WiFi adapter can easily drive the cost up by another $25. I recently discovered that the Arduino Yun, which has built-in WiFi, embeds an AR9331 processor.  The Arduino Yun is much too expensive, so I wondered if AR9331‘s could be bought separately. It turns out the answer is no, but then I discovered the vary hackable TP-Link TP-WR703N. A lot of hardware hackers are loading OpenWrt into this cute little WiFi router, and taking advantage of the many precompiled packages that are available. While node.js isn’t currently officially supported, I found that Giorgio Cefaro had gotten node.js running on an Arduino Yun. The Yun runs linio, which is based on OpenWrt, and since it uses the AR9331, I’m hoping that I can use his precompiled packages on my TP-WR703N.

I put “TP-WR703N” in to Amazon.com, and found it for $19.99 – what a steal, I thought. When it arrived, I found out that I’d ordered a TP-WR702N by mistake (grr.. Amazon for returning the wrong model in my search), which uses the same processor, but has much too little flash memory to load OpenWrt, and doesn’t have a USB port. Oh well, it works very well as a low-power WiFi client. I took it out to my garage, which is very far away from my AP, and was amazed that it worked as well as my Linksys WRT54G, which has dual external antennas! Furthermore, the TP-WR702N is has very flexible firmware, which allows it to act as a portable AP, repeater, etc. A great little device to carry around on trips. But I digress …

I ended up buying a TP-WR703N on eBay for $23. It came with Chinese firmware, but I was able to load OpenWrt following the instructions on the wiki page.  Much to my chagrin, after rebooting into OpenWrt, I was not able to ping or connect to it. The unit is now bricked. The only way to bring it back from the dead is to load new firmware via a serial connection.  [UPDATE: I found a way to unbrick it without any hardware hacking, if it is able to go into OpenWrt failsafe mode. See Method #1] Luckily, the TP-WR703N has a built-in UART for this purpose, but the PCB only has tiny pads for connecting to it. There are lots of instructions on other sites describing how to do this, but I’ll document my experiences here. Here’s what the case looks like with the top lid removed:


It’s held on by 3 clips. I first tried to use a guitar pick, and several plastic tools to open it up without marring the surface, but the case was just too tight. Finally, I wedged a small screwdriver in the location pictured below:


Once the first clip popped loose, I was able to just carefully pry the lid up and off from that edge, popping the other two clips open in the process. To hook up the UART, 3 pins are needed: Tx, Rx, and GND. Most writeups say to solder onto the round gold pads labeled TP IN  (Rx) and TP OUT (Tx). However, from Squonk’s reverse engineering of the PCB, I noticed that C57 connects between TP_IN and GND, and C55 connects between TP_OUT and GND:


It turns out that C57 and C55 are unpopulated on the board. I decided that it would be easier to solder to the pre-tinned pads instead of trying to scrape the solder mask off of the round pads:


It turns out that I was wrong. I managed to solder my 40AWG wire-wrap wire onto one of C55‘s pads, but the rest of them were too tricky due to their small size. So I scraped off the solder mask on TP IN, and soldered there, and I found a relatively large capacitor, C37 to use for my GND connection:


TIP: Modern machine-assembled PCB’s are typically coated with a solder mask, which is an insulator. Before attempting to solder to one of the copper pads, scrape off the solder mask where you want the solder to stick with an x-acto knife, exposing the bright copper below.  Try not to scrape off the solder mask in adjacent areas, to reduce the chance of creating solder bridges (shorts).

Next, I applied a liberal amount of hot melt glue to secure the connections:


To connect the UART to a PC, the easiest way is to use a USB to 3.3V UART adapter. Unfortunately, the only one I have is 5V, which would fry the AR9331. I ordered this CP2102-based one which I found on eBay:

CP2102_0Connecting the USB UART adapter to the TP-WR703N is easy:


To access the serial console from your PC, you must first install the appropriate drivers for your USB UART adapter. Then, use a serial terminal client program (I like to use PuTTY), and connect to the virtual serial port with parameters: 115200,N,8,1.

To be continued after I receive my USB -> TTL adapter …

Next: Hacking the TP-Link TP-WR703N – Part 2: Bring it back from the dead

How to Access a Hotmail Account via IMAP

Previously, if you wanted to use an e-mail client for accessing a Hotmail account, you were stuck with the POP3 protocol, which doesn’t allow you to access all of your mail subfolders. IMAP support was available, but cost extra. So, if you wanted to access your Hotmail folders, you were stuck with using Microsoft products, such as Windows Live Mail client or Microsoft Outlook.

Well, with the recent folding of Hotmail users into Outlook.com, Microsoft has quietly enabled IMAP access to Hotmail accounts for free. Now, you can use any IMAP compatible e-mail client, such as Mozilla Thunderbird.

Here are the settings for accessing a Hotmail account via IMAP:

Incoming server:

  • Server address: “imap-mail.outlook.com”
  • Server port: “993″
  • Encryption type: “SSL”

Outgoing server:

  • Server address: “smtp-mail.outlook.com”
  • Server port: “587″
  • Encryption type: “TLS” (“SSL” can be used if TLS is not an option)

Accuracy of Pyle PSWGP405BK vs RunKeeper Revisited

This morning, I repeated my Eaton Canyon loop with the Pyle PSWGP405BK and RunKeeper on the iPhone 4S.  This time, both of them were quite a bit more accurate than on the last hike.



This time round, the Pyle tracks the shapes of the switchbacks fairly accurately, albeit with an offset.  There is a fair amount of overshoot, however, in the last switchback.

RunKeeper on iPhone 4S


RunKeeper on the iPhone 4S again does much worse than the Pyle, but still much better than in my previous recording.  Out of the various iPhone tracking apps I’ve tried, I still find RunKeeper to be the most accurate.  I would like to try this route with an Android phone sometime, to see if it does a better job with outputting accurate location data. Here’s the tabular data:

Distance (mi) Calories
RunKeeper 3.47 491
Pyle PSWGP405BK 3.31 593
Pyle PSWGP405BK track on RunKeeper.com 3.43 475

Interestingly, the disparity between RunKeeper’s distance calculation of its own track vs its calculation of the Pyle’s track was much smaller today, but this can be explained by the fact that RunKeeper didn’t meander as badly today, so the tracks lined up more closely.

On the other hand, disparity between the results I got today and my previous post show how GPS accuracy can vary, even in similar weather conditions, at a similar timeof day on the same route.  I would conjecture that the increased accuracy today has to do with a more optimal geometry of the satellites in the sky. Unfortunately, since the devices I used don’t output detailed satellite signal and skyview data, there is no way to verify for sure.

This evening, I again pitted RunKeeper against the Pyle, walking on a very flat route, composed mostly of straight lines. Here are the surprising results:


Distance (mi) Calories
RunKeeper 3.38 381
Pyle PSWGP405BK 3.22 355
Pyle PSWGP405BK track on RunKeeper.com 3.27 354

Like this morning, the RunKeeper and Pyle tracks were a lot more similar than on previous days. RunKeeper’s distance was .11mi longer than its calculation of Pyle’s track, which makes sense, because its track was more wiggly, as usual, which adds distance.  But what’s inexplicable is that on this track, the difference between the Pyle’s own distance calculation versus RunKeeper’s calculation of its track is only .05mi, only 1.5%.  Contrast that to this morning’s hike, where the difference was .12mi or 3.6%.

Previous Related Post:  Accuracy of Strava vs RunKeeper vs Pyle PSWGP405BK vs Garmin Forerunner 10


Accuracy of Strava vs RunKeeper vs Pyle PSWGP405BK vs Garmin Forerunner 10

I went out for a hike today, with Strava and RunKeeper simultaneously running on my iPhone 4S, and the Pyle PSWGP405BK on my wrist.  Unfortunately, my wife had the Garmin Forerunner 10, so I have to use an old track, recorded last week, at approximately the same time of day. I know that it’s not an ideal comparison, but it will have to suffice for this article.  The route was in mountainous terrain, through a canyon … a much more challenging for a GPS than the flat route that I used in my last comparison.  Here’s RunKeeper’s take on the track: rk2 Strava’s take, running simultaneously on the iPhone with RunKeeper: strava Strava’s exported GPX file, imported to RunKeeper.com: stravaonrk What’s revealing is that given the same data, RunKeeper.com and Strava calculate essential identical distances. This becomes important when we compare them to the Pyle. Strangely, RunKeeper.com shows a 13 second shorter duration, but identical average pace. The data downloaded from the Pyle and displayed in GPS Master are identical to what displayed on the watch: gpsmaster I used the Pyle’s included wireless heart rate monitor on this hike, and its connectivity was flawless during the entire recording.  I didn’t have to moisten the contacts in order to get a good reading, which was also nice. GPS Master shows my average heart rate was 121, and the max was 155.  The plots above are speed, altitude, and heart rate. The GPX file exported from GPS Master and uploaded to RunKeeper.com: pylerk A comparison table gleaned from the above data:

Distance (mi) Calories
Strava 3.7 N/A
Strava track on RunKeeper.com 3.71 600
RunKeeper 3.53 422
Pyle PSWGP405BK 3.27 526
Pyle PSWGP405BK track on RunKeeper.com 3.40 555

Once again, the Pyle PSWGP405BK and GPS Master displayed identical data, and the calculated distance was shorter than RunKeeper’s calculation using the Pyle’s exported GPX data.  I am convinced that the Pyle’s distance calculation is too conservative… 3.27mi vs 3.40mi calculated by RunKeeper.com on the same data.  Strava calculated 3.7 mi, which is too long, due to its poor filtering of the iPhone’s noisy data stream.  The Google Earth plots below will reveal more information.  Here is a Google Earth plot of Strava (green), RunKeeper (red), Pyle (blue), and Garmin FR10 (yellow) in the most challenging part of the track: all Strava (green) vs RunKeeper (red) stravark Viewing the track reveals why Strava calculated the longest distance.  Strava’s filtering algorithm is clearly inferior to RunKeeper’s in handling the iPhone’s poor quality location data stream. Pyle (blue) vs Garmin (yellow) fr10pyle Again, not an entirely valid comparison, since the Garmin track was recorded on a different outing, but it’s quite obvious that the Garmin outperforms the Pyle in accuracy.  The Garmin is the only device that was able to trace all of the switchbacks on the trail. Even in the less challenging parts of the track, the Pyle wanders a bit.  Still, the Pyle’s accuracy far exceeds that of the apps running on the iPhone. I am very disappointed that several reviewers said that the Pyle is very accurate.  Clearly, they didn’t do their homework.  The Pyle PSWGP405BK consistently calculates distances too short.  The Forerunner 10 kicks Pyle’s ass.  But the Pyle has a compass, navigation, and heart rate monitor for about the same price, and is not that bad, as long as you don’t mind the fact that it miscalculates distance, and have to use other software in order to extract the correct distances from its track. If you want to play with my data, you can download the tracks an view them in Google Earth yourself: eckml.zip Strava doesn’t export KML, so but Google Earth can easily import its KML file.  I have also included full size image files of the screen shots I showed above.  In case you decide to compare the gory details of the tracks, when I got to the top of the winding trail above, I took a little break to fix my socks in a tree-covered area.  The FR10 track doesn’t show me deviating from the trail, because I didn’t take the detour during that outing.

Previous Related Post: Garmin Forerunner 10 vs Pyle PSWGP405BK

Next Related Post:  Accuracy of Pyle PSWGP405BK vs RunKeeper Revisited

Garmin Forerunner 10 vs Pyle PSWGP405BK

While I like my wife’s Garmin Forerunner 10 GPS watch, it’s irritating to me that it is a GPS device which is not capable of displaying GPS coordinates (latitude/longitude). This makes it essentially useless to use as a navigation device. After browsing around the web, I happened upon the Pyle PSWGP405BK.


What struck me immediately was that for a list price of $150, it has a GPS, wireless heart rate monitor, digital compass, navigation functions, and is waterproof to 30m. Though there were few reviews of this GPS watch, they were generally favorable, and I was able to purchase a “used – good condition” unit from Amazon.com for $27 after getting a $50 credit for applying for their credit card, and got free 2-day shipping with a trial subscription to Amazon Prime.  When I received the unit, I was delighted to find that it was actually a never used, open box item.  The Pyle PSWGP405BK is essentially the same device as the Runtastic GPS watch, in slightly different packaging.  It is also available from several other companies with various names. As far as I can tell, the manufacturer is Latitude Limited, from Hong Kong.  It’s called the Nav Master II on their website.

This article is not meant to be a detailed comparison between the Garmin FR10 and the Pyle PSWGP405BK, but here are some of the differences:

  • Battery life with GPS on: Pyle – 8hr, Garmin – 5hr
  • Pyle has digital compass,navigation functions, tual time, and 5 alarms
  • Pyle is bigger and heavier
  • Pyle comes with clunky PC software.  Garmin interfaces to their Garmin Connect online service.
  • Pyle is much more customizable, and displays more types of data
  • Pyle has wireless HRM, Garmin doesn’t support HRM
  • Garmin is simpler, easier to use, at the expense of less functionality
  • Pyle takes a bit longer to get a GPS fix
  • Pyle outputs GPS track points at selectable interval in seconds, Garmin uses an adaptive approach, outputting GPS points at varying intervals depending on terrain

For me, the clunky PC software and lack of online service is a non-issue, because the included GPS Master software easily exports to various formats, such as GPX, TCX, KML, and even NMEA. Many of the phone softwares have online services which allow uploading of externally gathered GPS data, so I upload my Pyle tracks to RunKeeper.com. Today, I had a chance to wear both watches and simultaneously track a workout.

One minor inconvenience of the Pyle vs Garmin is that when you press the start button on the Garmin, it automatically waits for a GPS fix before it lets you start the workout. On the other hand, the Pyle will happily start the workout clock even when it doesn’t yet have a fix, so you must first start the GPS, wait for a fix, and then start the workout. Also, I found that the Pyle took a bit longer than the Garmin to get an initial GPS fix. Minor irritants, but how about GPS performance? The overlaid tracks below tell a big part of the story, Garmin in red, Pyle in blue:


The Garmin FR10′s track is noticeably more accurate, especially at the bottom of the plot. However, the Pyle PSWGP405BK is no slouch, it is still significantly more accurate than anything running on an iPhone. However, there is a significant bug in both the PSWGP405BK and the accompanying GPS Master software’s distance calculation. Here is a synopsis of the above route:

Distance (mi) Calories
Garmin Forerunner 10 2.43 153
Pyle PSWGP405BK 2.37 242
Pyle PSWGP405BK track on RunKeeper.com 2.44 247
Garmin Forerunner 10 track on RunKeeper.com 2.43 232

Notice how the Pyle came up short on its distance calculation: 2.37mi vs Garmin’s 2.43mi, a difference of .06mi.  However, the Pyle’s GPS track uploaded to RunKeeper.com comes up .01mi longer than the Garmin track.

Though the Pyle’s GPS accuracy is not as good as the Forerunner 10, and there is a glaring bug in its distance calculations, for the $27 I paid, it’s a keeper.  I like its extensive customizability and functionality, and I don’t mind the distance calculation bug, because I always upload the tracks to an online site for analysis. Please take my results with a grain of salt for now… I have only used the Pyle for one workout so far.  I have not seen any reviews which complain about the inaccuracy of its distance calculations, so maybe today’s track was just an aberration. I will post updates to this article if my results change.

Previous Related Post: Accuracy of Garmin FR10 vs RunKeeper vs MapMyRun

Next Related Post: Accuracy of Strava vs RunKeeper vs Pyle PSWGP405BK vs Garmin Forerunner 10

Accuracy of Garmin Forerunner 10 vs RunKeeper vs MapMyRun

Even though I’m the engineer in the family, my wife is more of a gadget freak than me. This year, she beceame interested in tracking her workouts.  She started out with a FitBit, and found that to be rather useless, so we returned that. Lately, she’s been into training for a half marathon, so we started using GPS workout tracking apps on an iPhone 5 and iPhone 4S.

We played with several different apps:  Kaiser EB Walk, Nike+, MapMyRun, NeoTreks, and Runkeeper. It’s interesting how you can run several apps simultaneously on an iPhone, and get wildly varying metrics from them.  The distance and pace vary quite a bit between apps, and I think the main reason is that the realtime geodata coming out of the iPhone is crap. Therefore, the app developers implement different filtering strategies on the data, leading to the different calculated metrics.

I find it amazing that the iPhone has an onboard GPS, accelerometer, and compass, and still manages to output such bad location data. Granted, the GPS antenna is quite small, but GPS watches are pretty small these days, and work much better. My guess is that Apple needs to do some work in iOS’ sensor data processing code. If only they would give us access to raw GPS data, rather than forcing us to use their garbage location API’s…

Following the recommendations of friends, my wife recently bought a Garmin Forerunner 10 (FR10) GPS watch.  I was skeptical that it was worth the $130, price tag, and was very interested in finding out how much better it would perform than the iPhone.  After using it for only a few days, I must say that I am very impressed.  Unlike my 10 year old Garmin eTrex GPS, the FR10 gets a fix very quickly, and manages to keep the fix even under moderate tree cover and in canyons.

Below, I will compare the simultaneously recorded outputs of RunKeeper, MapMyRun, and the FR10.  I chose RunKeeper and MapMyRun as the iPhone apps, because they offer easy access to the logged track data in the form of GPX files, and both websites allow you to upload/edit track data.  Note that the MapMyRun and RunKeeper data were recorded simultaneously on my iPhone, so they share the same sensor data.

Route plotted on Google Maps:


Calculated distance: 1.3mi



Despite the fact that the route is largely in a flat area, with very little tree cover, notice how the track wiggles and meanders.



The MapMyRun track, as expected, also wiggles quite a bit.

MapMyRun Track on RunKeeper.com


The above plot is taken from a GPX file exported from MapMyRun.com of the workout, as recorded by MapMyRun. Notice how RunKeeper.com, using the same track data, calculates the distance/pace/calories differently. I have found that MapMyRun consistently calculates the longest distances, and highest calorie count of the bunch.

Garmin FR10 on Garmin Connect



Note how the Garmin track is very clean and smooth, and tracks the roads reasonably closely.

Garmin FR10 Track on RunKeeper.com


The above plot is of GPX data exported from Garmin Connect, and then uploaded to RunKeeper.com. The FR10 stores the track data in a proprietary FIT format, but luckily, their website is able to output GPX. Again, notice that RunKeeper.com used the same data, and yet, calculated different results.


Distance (mi) Calories
RunKeeper 1.40 153
MapMyRun 1.51 178
FR10 (Garmin Connect) 1.28 81
MapMyRun Track on RunKeeper.com 1.44 147
Garmin FR10 Track on RunKeeper.com 1.29 121
Google Maps 1.3 N/A

Below are some data from a couple of other routes that I tested:

Euston Loop

Distance (mi) Calories
RunKeeper 2.53 279
MapMyRun 2.71 306
FR10 (Garmin Connect) 2.44 156
MapMyRun Track on RunKeeper.com 1.44 147
Google Maps 1.3 N/A
Manual Plot on RunKeeper.com 2.55 N/A

Winston Loop

Distance (mi) Calories
RunKeeper 1.79 186
MapMyRun 1.83 205
FR10 (Garmin Connect) 1.66 103
Manual Plot on RunKeeper.com 1.73 N/A



While my sample size is small, some trends emerge.  The Garmin FR10 consistently calculates the shortest distances and calories.  MapMyRun consistently calculates the longest distances and highest calorie counts.  There is a difference between the calculation methodology between RunKeeper.com and MapMyRun.com, because given the same GPS track, MapMyRun calculates a longer distance (1.51 vs 1.44mi) and a higher calorie burn (147 vs 178cal) than RunKeeper.com.  On the other hand, Garmin Connect calculates shorter distances and calorie burns than RunKeeper.com, given the same track.

I have tested several other times, and the above trends hold.  Furthermore, the Garmin FR10 gives the smoothest, most accurate GPS track, especially when in a canyon, or under heavy tree cover. Below is a canyon track, Garmin FR10 in red, RunKeeper in blue:


Notice the vastly improved accuracy of the Garmin FR10 track vs RunKeeper running on the iPhone.

Finally, a canyon track which was recorded on my iPhone 4S, running RunKeeper and MapMyRun simultaneously. RunKeeper is in red, MapMyRun in blue:

The image above shows the vast differences which sometimes occur between the way that RunKeeper and MapMyRun interpret the same location data stream.  Neither track closely follows the actual path.  It’s pretty obvious that the Garmin FR10 is a worthwhile upgrade from using the iPhone as a sensor.

Next Related Post: Garmin Forerunner 10 vs Pyle PSWGP405BK

LeafCAN v2 Firmware in Alpha Test

I have been working on v2 of the LeafCAN firmware, which adds a whole slew of new screens, selectable via a rotary encoder.  The rotary encoder is connected to the AD0/1/2 pins on the expansion header of the LeafCAN V2 hardware.  The code is currently in alpha testing, and is available in the development branch of the LeafCAN github repository.  Be aware that the development branch is for my bleeding edge code, and at any time, the code there may be broken, as I continually checkpoint my code.  I will move it to the master branch when it’s ready to be released.

While I was developing the LeafCAN v2 firmware, I received a pleasant surprise in the mail from Barbouri (GregC) of the MyNissanLeaf forum.  He designed a PCB with 16×2 OLED display + RGB Led Rotary Encoder support,


and sent me a completely assembled and tested rig.  I immediately added support for this new hardware variant into my working LeafCAN v2 firmware code.  The RGB knob is cool:


but I am still pondering how best to use it. Currently, I have it blue when the car is idle, red when it’s consuming power, and green during regen.
Below is an overview of LeafCAN v2Alpha3. The various screens are selected by rotating the encoder knob. Some of the screens have different modes, selected via a press of the encoder knob. The first screen is the familiar info screen from LeafCAN v1.3:


The top line from left to right is: kWh remaining/gids/fixed fuel bars, and the bottom line is: pack voltage/SOC%/instantaneous kW. The next screen is an idea lifted from Turbo3′s WattsLeft, the DTE (distance to event) screen:


The top line shows various miles/kWh values, 2.0/3.0/4.0/5.0/6.0, and bottom line shows the distance in miles to the event, in this case, Low Battery.  Pressing the encoder button switches it to miles until Very Low Battery:


and pressing the button a third time shows miles until Turtle:


Thanks to a breakthrough in active can sampling, spearheaded by GregH and TickTock, I was able to implement the following new screens. The first one has on the top line, High Precision State of Charge (SOC)%.  The bottom line shows State of Charge (Ah), and possibly a Battery Health %.


The next screen shows the 4 battery pack temperature sensors:


The units are selectable between Celcius and Fahrenheit with a press of the button. Finally, the last screen shows the minimum and maximum cell-pair voltages in mV, as well as their difference:


When an OLED is installed, the display now blanks after 5 sec of inactivity on the CAN bus. Pressing and holding the knob for a second wakes the display up for 5 sec.  When an LCD is installed, the press/hold turns on the backlight for 5 sec, instead.

I will be working towards finishing LeafCAN v2.0 in the coming weeks, and will announce its release here.

Barbouri and I are also collaborating on a dual-CAN bus version of the LeafCAN hardware, which will be able to monitor the Car-CAN as well as the EV-CAN on the Nissan Leaf. This will open up access to various information which is accessible only via the Car-CAN, such as friction brake actuation, steering angle, etc.

I would also like to point out that GregH has yet another cool Leaf CAN bus dash display in the works (only $80) that is worth checking out. Also, TickTock and garygid are working on the very fancy dual-touchscreen open-source CANary Project. Turbo3 has also figured out how to extract data from the Leaf Car-CAN using a cheap ELM-327 clone dongle and an Android phone. There is currently a flurry of CAN bus hacking on the Leaf.

How to Clean Rancid Oil

I have a Misto Olive Oil sprayer that sat unused for a few years while it was loaded with oil.  The oil became rancid, and left this smelly, sticky residue that was not only impossible to wash off the sprayer, but also off your fingers after touching it.  First, I tried hot water and soap with intense brushing.  That didn’t work well.  There was still yellow residue all over it, and it still felt sticky, and stank.  Even leaving it in soapy water for a few days didn’t help.  I searched the Internet, and found a recommendation for vinegar, but that didn’t work.  Then I read that boiling soapy water would work, so I tried soaking it in boiled soapy water.  The yellow residue finally washed off, but it still stank, and was still slightly sticky after a few tries.

At this point, I’d already wasted so much time and effort that I was ready to just throw it out.  Then, I remembered that I had some OxiClean that I bought from Costco years ago.  I wasn’t sure if it was safe for food, so I read the label, which recommended it for cleaning teapots.  I mixed one scoop of OxiClean with 32oz of very hot (not boiling) water, and left it to soak for 3 hours. The results were pretty amazing. The residue is completely gone … no more stickiness .. and the stinky smell is also completely abolished.  Amazing! Not only that, the stainless steel bits are all shiny, and look new again.  I wish I’d thought of the OxiClean before wasting a few days with the other ideas.

* I have absolutely no financial ties to OxiClean or Costco. *

UCTronics 3.2″ TFT LCD Arduino Shield with Touchscreen

Updated 2014-03-14

I’ve been looking for a way to add a touchscreen UI to my projects.  To this end, I purchased a UCTronics 3.2″ TFT LCD Arduino Shield.  Most of the cheap TFT touchscreens that I found need about 38 pins, and therefore, need to interface with an Arduino Mega.  What makes this UCTronics shield unique is that it uses an onboard latch to convert the onboard SSD1289 TFT driver data bus from 16-bits to 8-bits.  This allows it to connect to an Arduino Duemilanove or UNO.  The board I received is a RevB board, and it looks somewhat different from the board pictured in the UCTronics product description.  The resistive touch panel on top of the TFT very similar to the touch panel used in the Nintendo DS.  Below is the board running UTFT’s demo (UTFT_Demo_320x240):


When I purchased this display, I had to use a specially modified version of UTFT downloaded from UCTronics: 3inch2_RevB.zip. This is because at the time, UTFT only supported the SSD1289 in 16-bit mode. However, as of 2014/14/03, the shield now works with the official UTFT distribution. The key is to supply the correct parameters to the UTFT constructor:

UTFT myGLCD(SSD1289_8,A1,A2,A0,A3);

SSD1289_8 specifies that we’re using an SSD1289 controller in 8-bit mode. The rest of the parameters are the pin assignments.

When compiling for an Arduino Duemilanove or UNO, the IDE will complain that the sketch is too big, unless you comment out all of the #define DISABLE_xxx except for #define DISABLE_SSD1289 in UTFT’s memorysaver.h.

While UCTronics’ version of UTFT comes preconfigured, it is based on an older version of UTFT, which is slower. On my Duemilanove, the UTFT_Demo_320x240 sketch takes 57.7 sec to execute with UCTronics’ UTFT, and 48.6 sec with the official UTFT library.  This is mainly because the latest UTFT has a new function called _fast_fill_8(), which speeds up certain fills. However, the sketches built with the newer UTFT library are bigger. With UCTronics’ UTFT, UTFT_Demo_320x240 compiles to 27248 bytes, and 30092 bytes with official UTFT.

Here is a bottom view of the shield:


At right is the integrated micro SD card reader, which is handy for storing bitmap data to load into the screen.

UCTronics supplies ArduCAM_Touch to support the touchscreen. However, I decided to just use UTouch, instead. Below is the UTouch_ButtonTest example sketch:


To use UTouch, you must configure the following lines in the sketch:

UTFT        myGLCD(SSD1289_8,A1,A2,A0,A3);
UTouch      myTouch(13,10,11,12,9);

I was able to operate the buttons by pressing firmly with my fingers. Note that the touchscreen is resistive, not capacitive, so it works by pressure. A stylus gives you considerably more control. The touchscreen is very similar to the one found in a Nintendo DS.

At first, I was disappointed by the bitmap display.  This is the output of the UTFT_Read_BMP demo sketch supplied by UCTronics:


There is severe quantization of the colors. This is the way due to the way that UCTronics implemented the UTFT::dispBitmap() function in their modified UTFT library. I wrote my own function, dispRaw(), to instead display .raw files generated by UTFT’s ImageConverter 565:

// UTFT_dispraw
// display a raw bitmap that was processed with ImageConverter565


#define SD_CS 8

//UTFT(byte model, int RS, int WR,int CS,int RD)
UTFT myGLCD(SSD1289_8,A1,A2,A0,A3);

void dispRaw(UTFT *utft,File inFile)
  char VH,VL;
  int i,j = 0;
  cbi(utft->P_CS, utft->B_CS);
  for(i = 0; i < 320; i++)
    for(j = 0; j < 240; j++)       { 	VL = inFile.read(); 	VH = inFile.read(); 	utft->LCD_Write_DATA(VL,VH);
  sbi(utft->P_CS, utft->B_CS);

void setup()
  if (SD.begin(SD_CS))
      char VH,VL;
      File inFile;
      inFile = SD.open("ade.raw",FILE_READ);
      if (! inFile)
	  while (1);  //if file does not exist, stop here.

void loop(){}

The output looks a lot better:


The display is actually much higher quality than the photo above.  The photo contains screening and moire patterns that you don’t see with the naked eye.  To create a RAW file, first create a 240×320 pixel jpg,png, or GIF file.  Run it through either imageconverter565.exe or the online ImageConverter 565 make sure to select Convert to .raw file and Target Platform Arduino (AVR). Copy it to a FAT-formatted uSD card, and insert it into the uSD slot.

It takes about 6 seconds to load a fullscreen RAW file. I’m think the bottleneck is the reading of the data from the SD card. Clearing the screen takes almost 1 second. The speed is acceptable when running UTFT_Demo_240x320.  This is board is no speed demon, but the speed seems adequate for implementing a graphic touchscreen control panel. If you need a fast display, look elsewhere.


User Guide
UCTronics Customized UTFT library


EKitsZone UNO Rev.3 First Look

I recently decided to buy an Arduino UNO R3, to test compatibility with my sketches, which I have been testing w/ a Deumilanove.  The UNO R3 contains an ATmega16U2  instead of an FTDI chip to do the serial to USB conversion, as well as 3 extra pins on the digital side of the board: SCL/SDA/AREF.  One thing I don’t like about the Arduino UNO is that while it uses a 16MHz crystal for the 16U2, the main 328P MCU runs on a resonator, which is not as accurate.  I found the EKitsZone UNO Rev.3 on eBay for $14.99, and decided to give it a try.

unor3The notable differences in the EKitsZone Rev.3 versus the Arduino UNO R3 are:

  1. the ATmega328P uses a 16MHz crystal oscillator instead of a resonator, so its timing is just as accurate as a Deumilanove
  2. the reset button is mounted at a right angle, so it’s easily accessible even when a shield is attached on top
  3. it uses a mini-USB connector instead of a full-sized one
  4. the JP2 pins aren’t filled with solder, so it’s easier to solder in headers, should you want to connect something the PB4..PB7 pins on the 16U2
  5. the programming header for the 16U2 isn’t installed, but it’s easy to solder one in

I see 1-4 as advantages.  Plus, the board is a cool looking red color.