Inside a LED lamp

Using LED lamps instead of incandescent bulbs and fluorescent lamps is argued to be power efficient thus economically favorable. Longer life span is also usually cited as an advantage. I wanted to look into the details for a long time and recently I ordered some LED lamps on ebay, so I took one of them apart to see what is inside...

The lamp is a 48 LED device, and is written to use 4.5W on a 230V power supply. My intention is to present the schematics of the lamp so that we can see the details of its operation.

LED basics:

Just to understand the main building block of the lamp: LEDs (light emitting diodes) are semiconductor heterostructure devices meaning that they have rectifying properties so that current only passes through one direction, while in the other way around it doesn't. While this is true for all diodes, the plus for LEDs is that light emission will happen only when they are conducting. Even if this is the case there is a certain threshold for the light emission to start which is around 3.5V for blue and white LEDs. Above this threshold the current through the device rises exponentially so it needs to be regulated which is usually achieved by either an external resistor in series or a current generating power supply circuit.

LED lamp:

Let's see what we have here: Regulation on the AC side is done by C1 as it acts as a finite impedance at 50Hz. The point is that the this is achieved without any unnecessary dissipation as there is no heat generated on C1. D1 is an integrated Graetz-bridge which rectifies the input voltage. The role of C2 is smoothing the output and R4 is an additional protection for the LED block. R1, R2 and R3 discharge the capacitors after switching the lamp off (most likely due to safety reasons). I also put some measurement data on the schematics: the 48 LEDs in series operate from a sum of 179V meaning that each LED has a voltage drop of 3.73V on average, in good agreement with our expectations. The 110mV voltage across the 10 Ohm resistor tells that 11mA flows through the LEDs meaning that the dissipation of the block is 11mA×179V=1.97W which is way lower than the expected 4.5W! Indeed it is not surprising that the light output of this lamp is not enough especially if compared to compact fluorescent lamps. The power factor can also be calculated: the voltage drop over C1 is 124V leading to a  power factor of 0.84. This value of course becomes important if LED lighting is to take a major role in households.

In conclusion it turns out that the electrical circuit is as simple as possible leading to a high average lifetime of the device (I expect it to be comparable to the couple of thousand hours of compact fluorescent lamps). No 50Hz wobbling of the light output is also a benefit of the device. However the efficiency of the principle described above is given by the fact that many low power LEDs was put in series leading to a voltage drop of 179V on the LED block with only 11mA current consumption. High power LEDs cannot be used this way since each single (!) chip has a light output better then this entire block while consuming several hundred mA-s at around 3.5V (a good example is Cree's XLamp series). This means that a more complicated power supply is necessary for such a LED lamp which together with the more expensive LED means more expensive device but way better light output as well (especially true for devices equipped with three or four high power LEDs), so I recommend buying such a lamp instead of these cheap ones.

WD MyBook Hacks - Remove Default Shares

The default shares - [Download] and [Public] - always annoyed me quite a lot, so I figured out how to remove them, since simply deleting them obviously won't work:

1. stop samba daemon: #~: /etc/init.d/S90smbd stop
2. edit /usr/private/user_smb_conf/.overall_share:  remove sections [Download] and [Public] (should be first two sections). Note: Here you can also check the other shares manually.
3. start samba daemon: #~: /etc/init.d/S90smbd start

Well, that's all. It is also possible to make a backup copy of .overall_share so that it can be restored if necessary since we did not delete the actual directories.
Update: the web interface seems to overwrite .overall_share adding the removed sections always if a new user is added or user credentials are changed. The obvious yet inconvenient solution is to do this hack every time it is necessary, while the proper solution would be to alter the corresponding part of the web interface. This I haven't figured out yet, but I will post it if I succeed.

WD MyBook Hacks - Built-in Webserver

Apparently the white light version of MBWE broke up with lighttpd, and hooked up with mini_httpd. Reason for this is unknown for me, one thing is sure however: If you want to be on the safe side and use the web-based admin interface, it is better to live with it. I do believe that other http servers can be installed, including:

~#: ipkg list | grep httpd

lighttpd - 1.4.25-1 - A fast webserver with minimal memory footprint.
minihttpd - 1.19-2 - small HTTP server
nostromo - 1.9-1 - nhttpd is a simple, fast and secure HTTP server.
php-thttpd - 2.25b-5.2.12-1 - php-thttpd is thttpd webserver with php support
thttpd - 2.25b-5 - thttpd is a lightweight http server

Each has a separate way to configure, the only thing that has to be made sure is that it binds to a different port than the default 80. Or, even better the admin interface can be removed from port 80, by using -p command-line parameter discussed later on.

Anyhow, at the moment we deal with the mini_httpd:

~#: ps ax | grep http

 2566 root        832 S < /usr/sbin/mini_httpd -d /proto/SxM_webui -c **.mp3|**
16981 root        584 S   grep http

which tells us that the served directory is /proto/SxM_webui. This means that additional files or directories created there will be served as well by the daemon so it is suitable for share simple things not including password protection, virtual hosts and so on...

In fact, I did not find any reasonable online manual page for mini_httpd, yet its basic features are easy to find:

~#: mini_httpd --help

usage:  mini_httpd [-C configfile] [-D] [-S] [-E certfile] [-Y cipher] [-p port] [-d dir] [-dd data_dir] [-c cgipat] [-u user] [-h hostname] [-r] [-v] [-l logfile] [-i pidfile] [-T charset] [-P P3P] [-M maxage] [-maxproc max_concurrent_procs]

On my system /etc/init.d/S55mini_httpd starts the server with the following syntax:

/bin/nice -n -20 \
    /usr/sbin/mini_httpd \
    -d $WEBROOT \
    -c "**.mp3|**.m4a|**.mp4|**.mov|**.pdf|**.wma|**.m4v|**.php|**.cgi" \
    -u root \
    -l /var/log/mini_httpd.log \
    -i /var/run/mini_httpd.pid \
    -maxproc 16 \
    -p $HTTP_PORT

with $WEBROOT being just as above and $HTTP_PORT = "80".

Why not charging battery on wifi signal?

I just became aware of this nice piece of video made on CES 2010.

They argue that batteries of cellphones and similar devices can be recharged by solely relying on power emitted by wifi hotspots. In fact for me this is somewhat hard to believe so let's make some calculations:

First, let's assume that the efficiency of the device is 100%, meaning that all received signal is converted to battery power (this is quite optimistic, since charging up a battery usually worse than 70%). Anyhow, if we have a single cell LiIon battery of 1500mAh, that will need approximately 1.5Ah*3.7V=5.55Wh energy input to be charged up completely.

Now let's see the other side of the equation: According to this howto page, the maximum transmitted power of a wifi hotspot can be 1W. This itself would be sufficient if we can catch everything, our battery is charged up in 5.55 hours. In fact, usually this is not the case (luckily for others, because they still would like to use wifi as it is intended :) ). For me it seems, that the size of the device is around 5cm × 10cm, giving an area of 50cm^2. You can measure this for example at 2:24 in the video above, where you have the hand of the guy for comparison. In this case, if we are 1m away from the access point, then this 1W goes through an area of 12.5m^2 (simply assuming that it the pattern isotrop), meaning that we catch 0.005/12.5=0.0004 part of the transmitted power. This is 0.04%! Anyhow, we get a power input of 0.4mW, so the time we need to charge up the battery above will be:

5.55Wh/0.0004W = 13875h = 578 days = 1.6 years.

I think I have been quite generous with the approximations above, so this might be some sort of best case scenario :) In fact, if go further away from the access point, the power input will cut off with the second power of the distance, and also the power conversion can add a factor of at least two.

I anyhow wish good luck for every end users so that they can make a single charge once every elections :)

WD MyBook Hacks - Print Server

There are a plenty of tutorials on web on this topic, yet none of them worked for me out of the box, so I put   together this guide with steps that worked for me (mostly based on this and this tutorial).

The printer was a HP Laserjet 2300L equipped with USB connection only. Upon connecting the printer to the storage I encountered the first issue:

~#: lsusb

had no output at all. However

~#: cat /sys/bus/usb/devices/1-1/product

hp Laserjet 2300L

revealed that the printer is indeed there so that there is no hardware problem.

What we need first of all is the following:

 ~#: mount -t usbfs none /proc/bus/usb   

so that lsusb will be able to list devices. CUPS is ready to roll now:

~#: ipkg install cups cups-doc cups-driver-gutenprint cups-pdf hpijs

will install CUPS version 1.4.2 and HP printer device drivers.

Contrary to earlier versions in the package repository,  this one works well so no recompile is necessary (so the presence of gcc is not required). The web interface of CUPS will be available at http://IP_of_NAS:631. Since for /admin https is required (and is a good practice anyhow), we still need to create the proper ssl certificate since this automatism fails for some reason:

~#: openssl req -new -x509 -keyout /opt/etc/cups/ssl/server.key -out
/opt/etc/cups/ssl/server.crt -days 365 -nodes -config /opt/share/openssl/openssl.cnf

and then:

~#: cupsd

starts the daemon itself. We still lack the USB printing support which should be available as a kernel modul. This I found here (great thanks for Bertram Winter!). This should be put to the following directory:

/lib/modules/2.6.24.4/kernel/drivers/usb/class/. This can be easily achieved by issuing:

~#: mkdir /lib/modules/2.6.24.4/kernel/drivers/usb/class/

~#: wget http://members.aon.at/berwinter/mbwe/usblp.ko.whitelight -O /lib/modules/2.6.24.4/kernel/drivers/usb/class/usblp.ko

Don't forget to create the corresponding node!

~#: mknod /dev/lp0 c 180 0

So the modul is ready to be loaded:

~#: insmod /lib/modules/2.6.24.4/kernel/drivers/usb/class/usblp.ko

It worth a note that even though /dev/usb/lp0 exists, still /dev/lp0 has to be used.

So now we have three USB related moduls:

~#: lsmod | grep usb

usblp                  12064  0

usb_storage            35936  0

usbcore               120212  4 usblp,ehci_hcd,usb_storage

We can also test whether CUPS also sees what needs to be seen:

#:/opt/lib/cups/backend/usb 

DEBUG: list_devices

DEBUG: usb_find_busses=1

DEBUG: usb_find_devices=2

Now we can add the printer on the web interface: https://IP_of_NAS:631/admin

Login/pass are the root credentials. The printer should be visible after choosing "Find New Printer". The rest is quite self-explaining, I chose the corresponding HP Laserjet 2300 PS driver. Note: the "Share Printer" checkbox should be checked! Most of the default options are OK, only paper size has to be changed to A4 (at least in Europe ;)). Some fine tuning includes reduce of maximum amount of jobs and clients as this one is anyhow an embedded system. For this, refer to the following screenshot:

Now the printer should be visible if pressing "Manage Printers":

For the clients the printer will be available as: https://IP_of_NAS/printers/name_of_printer. In Windows one simply has to press Add Printer, choose Network Printer and provide the above address. As for printer driver, Generic -> MS Publisher Imagesetter works well:

It worth a note that here we chose to use the specific driver in CUPS, and issued the client to use a generic (postscript) driver. It can be done in the other way around as well: in that case Raw driver has to be chosen when adding the printer on the server and the specific driver has to be installed on the client.

At this point the only remaining task is to have all of these persistent, so have the CUPS daemon started when the device boots up. For this I made the following script based on this one:

#!/bin/sh

MODULE=/lib/modules/2.6.24.4/kernel/drivers/usb/class/usblp.ko
LPNODE=/dev/lp0
CUPSD=/opt/sbin/cupsd
SETUP=/opt/sbin/lpadmin
PRINTER="LaserJet_2300L"

case "$1" in
        start)
                if ( [ ! -c /dev/lp0 ] ) then
                        mknod $LPNODE c 180 0
                fi
                #/bin/chown sys:lp /dev/lp0

                if ( !(lsmod | grep "^usblp" -q) ); then
                         insmod $MODULE
                fi

                if [ -n "`pidof cupsd`" ]; then
                        /usr/bin/killall cupsd 2>/dev/null
                fi
        $CUPSD
        $SETUP -p $PRINTER -E
        ;;
        stop)
                if [ -n "`pidof cupsd`" ]; then
                        /usr/bin/killall cupsd 2>/dev/null
                fi
        ;;
        *)
                echo "Usage: (start|stop)"
                exit 1
esac

The script first makes sure that the device node exists and the module is loaded (the rest of the usb modules are anyhow loaded on startup). Then kills all instances of the daemon before starting the new process. Note that the printer has to be specifically enabled by lpadmin -p "printer name" -E which is done just after the daemon started.