Thursday, September 30, 2010

Upgrading the RAM in a WRT54Gv2

This project is specific to the rev 2 hardware, due to Linksys converting the routers from SDRAM to DDR RAM at some point (Probably the G/GL split?).  It is certainly possible with newer versions, but requires different chips and nvram parameters.  Obviously, this means that with the addition of a new flash chip (which you'd need a JTAG cable to debrick), you could probably convert a WRT54Gv8 into a WRT54GL...
In any case, I would generally NOT recommend trying this.  On my previous attempt, I managed to lift solder pads like hookers in Reno, which if you're lucky, you can recover from with jumper wires, but one of the pads I lost went under the chip to a via to the other side, and routing a data line on RAM the long way around doesn't really work...

What I did was to first replace the two 64Mbit RAM chips in my Wifi router with chips twice as big, and then very carefully modified the settings in the nvram to configure the router to try and use the extra 16MB of RAM, giving me way more than the 16MB the firmware is expecting, giving me quite a bit more extra space to do as I please with.  SDRAM inherently requires the same number of address lines regardless of the density, so getting 64MB of RAM on here may be theoretically possible as well...

This unfortunately doesn't upgrade the 4MB of FLASH storage this router comes with, but in addition to being able to wire an SD card to the GPIO lines on the controller, I am exploring the option of upgrading the FLASH chip on-board, and will let you know how that goes in the future. As it stands, it leaves me with 1MB of JFFS2 storage to play with, which is enough for pretty much anything I'm personally going to write in C or SH, and maybe even an NFS driver, but it's the challenge, right?

First thing first is to find a suitable pair of 128Mbit SDRAM chips in 54-TSOP-II packages.  The most common source for these are old RAM sticks, but I didn't have any around, and felt that that was fighting a little too far uphill.  By luck, I got a call from an Arrow sales rep last week, and decided to look through their catalog to see if I could find the parts I needed for a few of these more obscure projects.  It turns out they did have some parts in stock, that they'd sell to me for less than $6 a piece or lots of 1,500.  As for the rest of their selection, they certainly won't replace Digikey, clearly being focused more on production run type stuff, and not the random gizmos I generally order from Digikey.

The part I ordered was the IS42S16800D-7TL (datasheet) (No deep links in Arrow's catalog?), at $2.90 a piece, plus a $0.99 "energy fee."  This fee made more sense when I got it in the mail, and they had been so kind as to load my pair of chips in a full TSOP tray, and triple wrap it in bubble wrap and perf paper...
Once I had replacement chips in hand, the hard part was afoot.  To remove the old chips, and solder on the new chips, all while not damaging the motherboard to a state beyond repair.

Removing the old chips is the challenging part, but once I figured out to use my mini-blowtorch as a pseudo-hot air gun, it was as simple as use a dental pick to apply slight pressure, and just keep brushing the pins lightly with flame until it all just instantly melted and came off.
I used aluminum foil to protect the coax running to the second antenna while using the torch, having had a bad experience trying to solder coax onto 3/4" copper pipe in the past...
Once the old chips were off, clean up the pads a little and apply flux liberally (like, use a lot.  If you think you're using enough, add more; you're not).  This picture is before I cleaned the pads, having just removed the old chips:
Soldering on the new chips is pretty standard surface mount technique.  Flux, line up the chip, tack two opposite corners, check alignment, flux, drag solder along the pins, flux, solder wick / reflow until the bridges are all gone, use a multimeter and 30x loop to check all of the pins to try and find shorts and opens before the smoke test.
Ain't that solderin' perdy?  This was before cleaning up the chips and board a little bit with a Q-tip to remove the flux.  The second from bottom pad on the far right column did lift, but I managed to caress it back in place enough to work.  GENTLE! You must be GENTLE with pads on commercial PCBs!  These things weren't made by LadyAda.

Having finished the hardware problem, it's just software from here on out.  Power it up and check to make sure that it still works.  If not, hope that you can go back in and fix it, and that you haven't damaged anything.  Once that's checked, it's time to change the memory controller settings.  Of course, I'm already running Tomato on it, so this is as simple as opening an SSH session with the router, and running the following commands [NOTE: These are different depending on hardware revision!]:

nvram set sdram_init=0x008
nvram set sdram_ncdl=0x000
nvram commit
reboot

  • The first line tells the brcm controller to use a 9-bit column width instead of an 8-bit column, to address the extra 16MB of RAM.  
  • The second line clears the ncdl tuning information, forcing the CFE bootloader to calibrate new timing values for the new RAM the next time it runs.  
  • The third line actually writes these values to the nvram.  
  • Now, the forth line is a little confusing, but if you read the man page and --help carefully enough, you might be able to figure out what that command does. 
  • Useful links: [DD-WRT forum post] [BCM3302 memory controller config registers tables]


Once the router comes back up (hopefully), you'll be the proud owner of a router with plenty of extra RAM, and the pride that you upgraded it yourself (but really, I wouldn't recommend trying this, unless you really aren't that big of a fan of your WRT to begin with.).
Yay! 22.36MB of free RAM! So much potential!


On a related topic, I'm developing quite a WRT54G problem...  Luckily I only bought one of them retail, having gotten the rest for decent prices on eBay, and RIDICULOUSLY good prices ($20) at swap meets.
Anyone want to send me a free WRT54Gv8 to see if I can convert it to a GL?

Wednesday, September 29, 2010

Cue CAT - The Cheap Barcode Scanner

I was picking through the electronics bin with Robert at the SPCA Thrift Store today (as I do...) and Robert handed me a ziplock bag with a :CueCAT in it.
I had never heard of a CueCAT before, but apparently it's a PS/2 barcode reader that was given away like candy in the 2000-2001 time frame (The servers apparently went dead in 2002).  The SPCA was asking $1 for it, so I figured it'd be an interesting way to spend the afternoon.  It's clever in that it has both a male and female PS/2 connector, so it goes inline between the keyboard and the computer.

Apparently, the company that originally made it threw a hissy fit when people started hacking the device.  Using their software, the concept was barcoded URLs, but every time it resolved a barcode, it uploaded it plus the devices serial number to their website, which is a big privacy no-no.

Digging through the Internet Wayback Machine, I found lots of information on how to disable the serial number (being stored on a standard 93C46), but that didn't interest me as much as decoding the faux-encrypted barcodes it spit out over the PS/2 connection:

.C3nZC3nZC3nXCNPXE3zWChnY.cGf2.ENr7C3n0C3rXDNDXChPZC3nZ.
(Yeah, that has my unique serial number in it; I trust you enough to give you that)

In digging around for decrypting this encoding that looks kind of like base64, but isn't, I found mention of being able to place the device in a debug mode where it would spit out the raw barcode, which is what I really want anyways, so a-diggin' I go.
[Javascript decoder][The decryption algorithm (isn't much of an encryption protocol...)]
Useful links for the hardware: [1] [2].
(Catalog number 68-1965)

My particular model seems to be one of the early models, since they hadn't yet moved to the epoxy die-on-PCB process used by most of the documented cases, but oddly didn't match any of those early models I found online either.  Reading the second link very carefully, I noticed that they point out that it's the 10th pin on the Hyundai 8051 core that you cut to get it into debug mode, and although mine doesn't have a Hyundai 8051 on it, it was pretty obvious which chip is the CPU on this thing, so I tried cutting the 10th pin on that, and it worked!
Front view: The silkscreen says K023A016 REV:C
Back view: The larger chip is a 74 series chip for interrupting the PS/2 clock to the daughter keyboard for injecting keypresses.
Closeup of the controller (presumably a generic 8051 substitution for the Hyundai found in most other :CATs; understandable due to the general components shortage at the time) : SyncMOS 0022 SM2958 C160

Note that I cut the trace from the 10th pin to the ground plane, which is the second from right pin on the bottom row (The white bar indicates it to the right of "C1 U2").  I haven't extensively tested this from a failure point of view, so you might want to additionally pull it up to 5V, but it's hot here in Davis and that would require turning on a soldering iron in my bedroom...

Putting it back together and firing it up gives the following result for the same barcode as before:

9780070725423 90000

Sweet!  Now I have a raw UPC and ISBN barcode reader.  I started testing it on other barcodes I had laying around, and it triggered on one in my Mark's Handbook and printed the name "matthews" (pg 10-77 fig 10.7.14).  Unfortunately, the book made no comment as to what encoding that specific barcode is, and I couldn't get it to trigger on anything else in the section other than the UPC.  This does indicate that it can read at least primitive barcodes with some sort of alphanumeric encoding, which is a little more interesting than just numeric codes.

[UPDATE 9/30/2010: I have confirmed that it does in fact read 2 of 5, 3 of 9, and most Code 39 bar codes I've thrown at it.  It just takes a finesse to get it to read, and the initial samples I was using didn't want to register...] 

The possibilities as to what to do with it now are pretty appealing.  In addition to the obvious cataloging of my book collection, PS/2 is relatively easy to decode with microcontrollers, so working this into some kind of embedded project wouldn't be that difficult.

I didn't bother trying to dump the 93C46 chip due to a lack of interest, but if anyone out there is dying to know (unlikely), I'll see what I can do.

Saturday, September 25, 2010

MSP430 Low Power Experiment

One of the primary reasons why I got so excited when Texas Instruments announced the Launchpad was because I've been looking at getting into low power embedded systems, which is exactly what the MSP430 architecture is designed for.  After my initial hello world blink programs, I set one of the controllers up with 20F worth of super capacitors and a raw LCD screen to see how long it could run on so little storage.
This was supposed to be a quick little experiment to see exactly how low power these controllers are, but it's been running for more than three weeks already, and there's still another 0.15V left on the capacitors down to the rated minimum voltage...

NOTE: I have built on the progress I made on this project by building the LCD into a full 4 digit low power display, which I am currently using as a clock.  See the write-up for more information.

Video:


So, it turns out these little buggers are VERY low power.  Clearly, with the addition of some sort of energy harvesting system, be it solar or otherwise, this controller could clearly run indefinitely.

Parts list:
  • MSP430G2231
  • 2x 10F 2.7V super capacitors
  • 1x 12.5pF 32kHz quartz crystal
  • 1x 4.7kΩ resistor
  • 1x raw liquid crystal display (sourced locally at Halted) (Good possible replacement on Digikey)



How I did it

The key steps I took to get the power consumption so low for this experiment were two-fold.

First, I extensively used the sleep-mode on the controller.  I have it setup to only wake 32 times per second, which means that the rest of the time is spent with only the crystal oscillator running, which consumes VERY little power.

The second trick I used was using a raw liquid crystal display.  LCDs are typically seen sold in large modules with 14-16 pins and their own HD44780ish driver chip.  This is much preferred, because driving the raw LCD is a friggin pain in the ass.  LCDs contain an ionic fluid, which in the precess of a voltage potential will rotate to polarize light in one direction or the other.  With the addition of filters on the front of a screen, rotating the light will cause the screen to appear dark or light.

This voltage potential rotating molecules is great because it draws little current, since the display is based on a voltage, instead of a current like in LEDs.  Unfortunately, this voltage will also start separating the fluid into its positive and negative parts.  Left on for too long (typically on the order of seconds), the LCD fades back to its natural state.  To prevent this, the driver must alternately bias each cell first positively, then negatively.  This is done by alternating the voltage on the back-plane of the LCD, with unlit cells following the back-plane bias to prevent them from being enabled.  This is particularly visible on some LCD-based watches, like the TI eZ430-Chronos, where you can see a flickering as the cells are alternately biased.  I chose a refresh rate of 32Hz, which seemed to work well for my LCD.

As you can see, the single digit of the LCD plus the back-plane consumed all eight pins of the MSP430... Some trickery might be possible to allow these same pins to be used for N.O. push buttons (consider biasing the LCD with only the pull-up/down resistors), but clearly this is an expensive display, from a hardware point of view.  I'm planning to do some experiments with the ICM7211 chip by Maxim to see how well it works at driving an entire 4 digit LCD display.

Source:



UPDATE (9/29/2010): This thing is still running... I'll update when it finally dies...

UPDATE (10/11/2010): It's still running.  Caps are down to 1.73V, which is below the msp's rated voltage, but it keeps spitting out numbers.  I don't know if I'm more surprised that the processor is still running, or the LCD.

UPDATE (11/2/2010): Still freakin running.  Caps are down to below 1.7V, hardly above the bias voltage on the LCDs, so you can hardly see the digits and they take half a second to really resolve.  Conclusion is that with a tiny solar panel, this thing could run indefinitely.  I'm going to have to be careful on power budget as for anything else I add, since a single digit display by itself isn't entirely useful.  There is a lot of potential for this controller.  I'm packing it in to free up the breadboard now.  Happy hacking.

UPDATE (2/6/2011): Having disassembled this project after finishing this experiment, I have come back and soldered the circuit together, with all four digits usable.  See the write-up for more information.

Thursday, September 23, 2010

Controlling a Crosswalk Signal

Two weeks ago was my not-boss's birthday (he wasn't my boss, but answered all of our silly intern questions).  Hes that guy in the office who managed to get nerf guns banned, so I needed to come up with something fitting for his birthday.  Luckily, in my many years of digging through surplus stores, I knew exactly what I wanted to get him, and exactly which bin it has sat in at Weird Stuff.
That's right.  A cross walk signal.  A real, genuine, GE crosswalk signal.  But, a crosswalk signal by itself wouldn't have been good enough, so I decided to add a simple microcontroller circuit to it to emulate the standard crosswalk signal pattern.  In the picture, the green board on top is the original power supply / LED driver that came with the sign, and the tan board below it is the part I added.  The second tan board to the left is a scrap 5V supply I had sitting around to save myself the trouble of building it from components.  Shown in the picture is my USBtinyISP hanging off the board for development.

Video:


The circuit for this consists of little more than an ATtiny85, a couple TRIACs to switch the 120VAC for the LED driver, and a off-the-shelf 5V power supply.  Note that I used essentially none of the protective circuits around the TRIACs (snubbers, current limiters on the optos, etc), so before implementing TRIACs, understand what trade-offs you can make in your design.  I probably could have even gotten away without the second larger TRIAC being triggered by the optoisolated one, since I'm only driving 6W worth of LEDs...

One thing I found very surprising about the LED driver that came with the sign was that it was not just two separate LED drivers for the walk and stop signals.  One of the two lines was power for the entire sign, and the second line was a latch that switched from the hand to the walk signal.  This means to go from the hand to the walk only requires pulsing the latch line, but there is no way to go from the walk signal back to the hand without completely removing power from the sign (watch a walk signal the next time you're out; you'll see that it always turns the walk off, then starts blinking the hand.).

Parts list:
  • 1 GE cross walk signal ($10 at Weird Stuff in Sunnyvale)
  • 5V power supply scavenged from an old cell phone charger
  • ATTiny85 (flash space is probably overkill, but it's the smallest AVR I had. A tiny25 would probably work) (Digikey $2.26)
  • 2x >=400V optoisolated TRIACs (MOC3063 - Digikey $0.74)
  • 1x >=400V 10A power TRIAC (overkill, for 6W of LEDs) (Q4010R5 - Digikey $2.26)
  • 2x 1k resistor
Source:

He really appreciate it, and it was a nice finish to the long lasting mark I left at that internship...

Tuesday, September 21, 2010

Hacking the WRT54G(L) Serial Port

or "How to Get Your Router to Talk to Your Arduino"

Two weeks ago was another De Anza electronics swap meet, so my father and I went for a day of digging through boxes of junk trying to find something actually worth money.  I hit the jackpot with a WRT54Gv2, which was before LinkSys switched that line over to VxWorks and started the WRT54GL line to continue the Linux-based line.

As the saying goes - If it's electronic, we can hack it.  If it runs Linux, it's really easy.

The WRT54 motherboard breaks out two 115k 3.3V serial ports.  A classic first hack is to solder on headers, and install a daughter board with a RS232 driver, and a DB-9 port on the outside of the case.  I'm thinking about eventually doing this, but for my first experiment, I kept the serial port at TTL levels and fed it into my Arduino to print on an HD44780 LCD screen.

Video:
 
 Errata: I'm talking about volts at the end.  The Arduino runs at 5 [volts].
Note that the Arduino board is just there as a convenient 5V power supply for the ATMega on the breadboard (which is running Arduino software, and is therefore still technically an Arduino-based platform).

The WRT54G runs at 3.3V, which means its serial port runs at the same.  Ideally, I would have the AVR running at 3V as well, but none of my LCD screens would run at 3V, so I VERY CAREFULLY kept the two systems at different voltages.  Since I am only passing information from the WRT54G to the Arduino, the difference between a 3V high and a 5V high signal is insignificant.  Going the other direction would require a voltage divider at the very least to keep the 5V from the AVR from doing very unfriendly things to the WRT mobo.

Specs:
WRT54Gv2 running Tomato 1.28
The serial port 0-out is JP1-pin 4 and runs at (115200, 8, N, 1)
I used pin 10 on the same jumper as a ground reference
The serial ports are /dev/tts/0 and /dev/tts/1, and can be treated just like every other file in *nix.
The demo command I demonstrated in the video was:
# echo "This is a test message" > /dev/tts/0
Source code running on Arduino.