Monthly Archives: February 2007

DOE report on LEDs for general illumination

leds.JPG

While researching LED failure modes, stomach I came across a 2002 U.S. Department of Energy report outlining the viability of using light-emitting diodes for general illumination. This 112 page report covers many aspects of the physics behind LEDs as well as illumination profiles and manufacturing methods. This is kind-of a report on everything you wanted to know about LEDs but were afraid to ask. Unfortunately, rx it does not really cover LED failure modes.

( report_led_november_20_2002.pdf )

Some important aspects of PCB layout

christmas-small.JPG

About four years ago, when I first started using the Orcad suite, I embarked on an ambitious project to design one of my first EEG recording amplifier and stimulator interface boards. The project was pretty simple: route twelve differential channels from the pre-amp to the EEG amplifier, track the current going out of the stimulator by way of sense resistors and interface with a National Instruments acquisition board. I did the schematic entry correctly, but I neglected to double check the footprints used for the connectors. That is, in the schematic entry, I used a generic 68 pin connector for the NI connector and selected metal can regulators instead of TO-220 and then picked the wrong polarity on all of the d-sub connectors. The result was that the 68 pin connector just didn’t fit and required massive jumpering for even basic functionality, some of the db25 connectors had to go to the back  of the board (not shown) and the power regulators had to be kludged on. The board was not becoming a truly three-dimensional object that had wires coming out from every direction and could only be secured by clamping one edge of it in a vice. Otherwise, it functioned fairly well so it was still used in some experiments. Due to its green color and protruding wires, it became known as the “christmas tree” and be came synonymous with design failure.

christmas-tree01.jpg christmas-tree02.jpg

Looking inside the FON La Fonera firmware

fonera-small.JPG

I was recently introduced to FON and decided to buy a La Fonea to get in the mode. After getting the device I promptly opened it and looked inside. The core of the unit is a MIPS (Atheros SOC) processor with 16MB ram and 8MB flash. As expected, it has both ethernet and a dual-antenna wifi front-end. The FON network is a pretty good attempt at creating a world-wide wifi community, so I fully support their cause. The only thing is that with so much storage space, maybe I can add some useful features to their firmware, since it does run Linux (OpenWrt).

The first step was to download the firmware from the FON website. Luckily, Stefans Datenbruch already had a FON and analyzed the firmware. The first four bytes are “FON#” where # is either 3 meaning a firmware upgrade or 4 meaning a “hotfix”. The next four bytes are hypothesized to contain the length of the header or crypto key according to Datenbruch. Skipping 520 bytes, everything else is a gzip of a tar archive containing the files: upgrade, rootfs.squashfs, kernel.lzma and hotfix. Upgrade is a shell script, rootfs and kernel are what their names imply and hotfix is a text file that seems to list some version information.

The “easy” way to look at the file structure of this upgrade would be to install the squashfs userland on your Linux distribution and then apply the lzma patches and then upgrade your kernel to 2.6.x and then install the squashfs drivers/userland and then install the lzma and then recompile squashfs etc etc etc. The easier method is just to install a rs232 transciever on the machine and upload all of the files to another host. The memory management or spc on the unit is flaky, so it’s best to compress each root directory into a tar file on /tmp and upload those. An archive of the filesystem is at the bottom along with a boot log.

NB: The zip file below is the extracted filesystem, not the flash image!

fonera01.JPG fonera02.JPG fonera03.JPG

( fonera-0-7-1-2.zip ) ( fon-bootup.txt )

Just to clarify: E and B are the principle electromagnetic fields

ebfield.JPG

There is some confusion as to what the principle fields in electromagnetics are and what the derived fields are. In the force(Lorentz) equation we see that the force is equal to the charge of the particle times the electric field (E) plus the charge times the particles velocity crossed with the magnetic induction (B). The confusion arises from the way that the equations for the D and B field are written: it seems that B field is to be paired with D and E with H. The truth is that to maintain Lorentz invariance, the force equation must either contain D and H or E and B. That is to say, the force shouldn’t change depending on which direction the system moves. To accomplish this, the Lorentz force equation must contain either E and B fields or the D and H fields. Then do we use he E and B field or D and H field? D and H fields are computational aids; these fields do not exist in the microscopic world.  B and E fields do, which is why they are the principle electromagnetic fields (the concepts of current or charge density do not exist on the quantum level).

How to get root access on the Linksys WAP54G (v2)

wap54gv2-small.jpg

One of the first uses for the rs232 line converter that I built last week was to access the serial port on a Linksys WAP54G that I have around. The board has a connector labeled J5 that has both power (+3.3V, link GND) and the UART0 pins available. After putting headers in the holes, cialis I was able to follow the pinout guide from Seattle Wireless:

 O O O O left to right: +3.3v +3.3v grnd grnd

O O O O O ttyS0 output, medicine  unknown, unknown, ttyS0 input, unknown
 ^

The com port setting is 115200 bps, 8N1, no flow control. The device shows a typical Linux bootup (included below) and goes straight to the root prompt (with the root fs mounted readonly). By holding down Ctrl-C while the device is powered up, the boot monitor can be invoked (also included below). So far, there is access to a pretty decent boot monitor, 2MB flash and 8MB ram. There is an unpopulated footprint for a second SDRAM chip on the back, where each should accommodate a 16MB chip bringing the total RAM on the board to 32MB. The flash might also be replaceable, but it would be difficult to recover the boot monitor without being able to program the TSSOP flash module, so that might be a bit harder. In any case, the next step for me is to modify the OS image and flash the device using tftp or the web interface.

( wap54gv2-linux.txt ) ( wap54gv2-cfe.txt )

Nintendo rolls out “everybody votes” channel

wii-vote-small.JPG

While taking a break from homework, I walked to the kitchen to get a drink only to notice that the Wii had a message for me. The message was a surprise announcement of the Everybody Votes channel where users can cast their votes on various questions. New tool for the Nintendo marketing department or some sort of collaboration channel? Who knows, so far there are only four questions up and no voting data. More to come as information becomes available.

Current questions are:

- What is the most romantic valentine’s gift? (chocolates or roses)

- I’d rather live in a house on … ? (a mountain or the beach)

- Which century would you rather live in? (19th or 22nd)

- Do you prefer dogs or cats?

wi-vote-01.JPG wi-vote-02.JPG wi-vote-03.JPG

wi-vote-04.JPG wi-vote-05.JPG wi-vote-06.JPG

wi-vote-07.JPG wi-vote-08.JPG wi-vote-09.JPG

wi-vote-10.JPG wi-vote-11.JPG

IC Friday: Generic 7906 voltage regulator

7906-4x-small.jpg

Since the Virtual Slice software has not yet been installed on our scope, sovaldi sale taking images of large, thumb complicated chips and reconstrucing the montage in photoshop is a pain. For this reason, online Ihave elected to uncap a ubiquitous, linear voltage regulator of unknown make: the 7906. Hopefully we will get the software in place soon, otherwise it will be op amps and related circuits for the next few weeks.

7906-4x.jpg 7906-10x.jpg 7906-20x.jpg

How to look inside your (Linksys) firmware

small-wap54g.JPG

Since I am not interested in shaping the Wii wireless network traffic further than I already have, I am moving on to modifying the provided Linksys firmware for the WAP54G access point. The very first step is to examine the filesystem to see what tools are available and how I might be able to hack a telnetd or something into it. The second step would be to download the sources from Linksys’ GPL code center.

After downloading the 2.08 firmware, we have a readme and a .trx file. The TRX file contains the kernel at the start and a cramfs (compressed ram filesystem) image at the end. The trick is to find the start of the cramfs image, and a good one to use can be found on this Seattle Wireless page. We look for the start of the cramfs magic number (3d4528cd), calculate the offset to it from the start of the file (0x0095f00 = 614144, add 12 for the offset to 0x3d45). Mounting the filesystem is pretty straightforward on a Linux sytem to read the contents. If you are too lazy to dedicate a machine, download the free VMware server, register it to get the serial code, download a Linux ISO and install it in a virtual machine. Most kernels come with cramfs pre-compiled and most systems with modest development tools will have hexdump.

( contents of the 2.08 WAP54G firmware: tmproot.zip )