logo1.bmp (61374 byte)



designs f.a.q.


crc guide who am I ? awards

The Silicon Wallet

Forgot your password? To design my tiny password reminder, I devised an input circuit that enables any embedded device to capture information from a web browser.


How do you manage your ever-increasing set of password, secret numbers and personal ID codes? My list is very long: passwords for Internet and Intranet access at home and office, credit cards and ATM, mobile phone, burglar alarm, insurance, SSN, tax number, safe lock… To make matters worse, new passwords are being generated everyday. Apparently, every useful site requires you to register for a better, customized service. Not surprisingly, problems related to stolen ID, hacked databases and loss of confidential information are becoming more and more common.

I'm conscious of the importance of preventing identity thefts, but admittedly it is very troublesome to follow even the most basic prevention rules, like “never use the same password twice” and “avoid passwords that make sense in favour of abstract combinations of letters and numbers” . I understand that the intention is very reasonable, like limiting damage in case of stolen or lost passwords, or defeating automated scripts that programmatically try to login using the entire vocabulary (including popular pet names and plausible birthdates). But fact is that managing an ever-increasing crowd of passwords exceeds the skills of normal people like me. Actually, another popular rule states “always keep password lists in a secure place” (sic), implicitly admitting that no mere mortal can remember dozens of random alphanumeric sequences.

I have searched the secure place mentioned by the rule for a long time. I looked for something handy and dependable, something I can always carry with me, very user-friendly because I planned to use it often, and discreet enough to be comfortably used in situations like drawing cash from an ATM when travelling in a foreign country. I discarded common data-storage capable devices - like laptops, USB storage, mobile phones, data-bank calculators, palm computers – because they are ineffective for a variety of reasons (e.g., exposure to networks (hackers), inability to encrypt data, and inability to function alone). Realizing this, I have decided to design my own solution.


I'm going to show the magic that makes data passing from a computer screen (here a web browser showing a virtual keyboard) to the Silicon Wallet!




The Silicon Wallet fits a small plastic box, and can store hundreds of passwords, logins and secret codes. An alphanumeric LCD display fills the front side. It is battery operated and has no keyboards, just a wheel peeping out on one side, like the volume control in miniature radios (see Photo 1). Turning the wheel (you can do it with one hand) you enter a secret 5-digit code. This number is the only one you have to remember from now on. It's like having a safe in your pocket: once it is opened, you can use the wheel to scroll through the information that's inside it.

The most amazing feature of the Silicon Wallet is the way you enter new information: instead of awkward miniature keyboards like the ones found in Far-East gadgets, or uncomfortable input schemes based on invariably-too-few buttons, Wallet's input device is a single phototransistor.

How can you enter text using a phototransistor? Well, recognizing that whenever I get a new password I am also using a web browser, I have developed a JavaScript program capable of transforming ASCII text into encoded light flashes, changing the colour of screen objects. With this script I have built a nice web page (see Photo 2A), displaying a keyboard: thus, to enter fresh data into the Silicon Wallet, just direct your web browser to the keyboard page, place the Silicon Wallet on the PC screen so that it can see the flashes, and click whatever text you want to store (see Photo 2B). It's that easy!

By design, this “wireless” input technology requires just a web browser, and works on any combination of platforms and operating systems. Remarkably, it doesn't require you to install any specialized software and drivers. On the security side, the script encodes data on-the-fly, one character at a time, with the intention to defeat RAM and cache hacking. Once in the wallet, information is stored into processor's on-chip FLASH, which is hardware-protected from external reading. At last, I have found a fairly secure place for my password list!

In the following, I will unveil the details of Silicon Wallet's hardware and software, which is an elegant, clean, inexpensive single-chip project, exploiting both the analog and digital qualities of the PSoC microcontroller (refer to [1] and [2] for an introduction to this chip). I will describe how I managed to adapt it to the different signals captured from CRT and LCD monitors, adding Hamming ECC (Error Correction Code) and designing the filters in order to get rid of the noise coming from ambient light and superposition of the video raster. I will cover briefly the tricks used for embedding a signal encoder into a web page using a general-purpose language like JavaScript. Finally, I'll take some time to illustrate how, with the only addition of an inexpensive light sensor, a wide range of products - from toys to music players to industrial timers - can be configured, enabled or programmed using nothing more than web pages.

My intent is to show you the thought-provoking potential of the underlying technology, which, when considered as a more general mechanism capable to transfer data from the web to electronic devices, can inspire a whole class of cutting-edge products.


The signals involved in this design are only apparently simple. CRT and LCD monitors work according to different processes, and although the images look similar to an human eye, the difference is very evident from a phototransistor's observation point.

Photo 3 shows the signals captured from a CRT monitor (top trace) and a LCD monitor (bottom trace). The test starts with a flashing rectangle (left) and ends with the rectangle still white (right). What we perceive as a continuous light level, in case of a CRT monitor is actually a series of very bright flashes at raster frequency, from 50 to 120 Hz depending on the VGA card. Conversely, the signal from the LCD monitor is greatly attenuated (I suppose its amplitude is close to the average energy level of CRT spikes), is continuous, and requires considerable time for changing from black to white. The opposite transition is much faster, making the waveform asymmetrical. Additionally, the “black” level of LCD monitors varies significantly from brand to brand.

Both monitor technologies influence the design of a data transmission scheme. LCD monitors require substantial amplification and compensation of the DC offset superimposed to the signal. The difference in rise and fall times for LCD monitors suggests to use the same edge to measure intervals. Signal picked up from CRT monitors are ample, but need additional circuitry to fill the gaps between two consecutive peaks in order to reconstruct the original signal.

The frame refresh rate (vertical raster frequency) produces a more subtle effect that must be taken in account for both monitors. The frame refresh rate is the time it takes for a full picture to pass from the video memory to the screen. This time can introduce significant jitter to the output stream (up to 16.7 mS for each transition at a 60Hz refresh rate). Although some graphics drivers provide hooks to sync to video refresh (they are useful for playing video and animation), the design objectives require the system to be platform independent and forbid to resort to drivers or software to be installed.

Besides the intricacies related to the inner workings of video, the system must cope with the errors generated by the PC itself. Browser timings are far from perfect. The operating system can delay a screen update from time to time, disturbing an on-going communication. In this case, automatic error correction and detection can be an useful feature.

According to the analysis above, I have devised a transmission scheme that uses white as the default rest level and black as the active level. This simplifies determining the exact amount of DC before transmission starts, setting the working point close to saturation. A logic 1 is represented with a 45ms black pulse followed by another 45 mS white (see Figure 1). A logic 0 is represented by a 90 mS black pulse followed by a 45 mS white. Data is transmitted in 10-bit codewords + 1 stop bit (11 pulses in total). The stop bit is always 1 and its purpose is to provide an extra edge for improved interval measurements especially on LCD monitors.

The 10-bit codeword contains 6 bits of data and 4 parity bits encoded according to the Hamming code H ( 10,6 ). This code is capable of self-correcting all single-bit errors and to detect all double-bit errors.


The input signal sensed by the phototransistor includes very low frequencies, therefore the sensor amplifier in Figure 2 is DC coupled. The amount of DC superimposed to the signal varies depending on ambient illumination and PC monitor characteristics; to remove the DC component, a 6-bit DAC generates a variable DC-offset which is subtracted from the input by the offset control block at the input of the main amplifier. A specialized software routine calculates the exact amount of DC to remove at every use, thus at the output of the amplifier we get only the modulation component of the original signal. The amplified signal then passes through a low-pass filter, which removes high frequency noise coming from the residues of horizontal video raster and from the environment.

The output from the filter goes to a 8-bit A/D converter that digitises it. The bit-stream rebuilder generates a logic value (sensor illuminated or dark) comparing the 8-bit input level coming from the A/D to reference thresholds and adding hysteresis. It also uses a monostable, based on a 8-bit timer, to fill the gaps in the pulsing signal caused by frame refresh rate on CRT monitors. The next block is the codeword decoder, that monitors the binary signal produced by the rebuilder, and measures bit intervals in order to reconstruct a 10-bit codeword according to the transmission encoding scheme. It uses a 16-bit timer in order to handle possible timeouts.

Due to the nature of the transmission process and unpredictable response times of PCs, reception errors can happen. Therefore the codeword generated by the decoder passes through a Hamming Error Correction block right after reception . The Hamming block (which is detailed in a separate article, see [3]), is capable to recover all single-bit errors; the resulting 6-bit wide keystroke data is now ready for use by the main application.

The user controls the device by means of a quadrature encoder, which is used for composing a 5-digit access number and for browsing through the pages of information stored in memory. Given the low data rates required, the encoder block takes advantage of the PSoC ability to generate interrupts on pin change, and implements a driver with a ISR.

The main application orchestrates the LCD block to display relevant information, EEPROM (actually a flash emulation) to store the user pages, the encoder to interact with the user, and keystroke data from the blocks detailed above to receive and edit new information from the PC.


The Silicon Wallet is a true system-on-chip (SoC): actually, the CY8C27443 microcontroller includes all of the blocks shown in the block diagram, consequently the final schematic circuit shown in Figure 3 counts only six parts. Well, to be fair, I have used the Invention Board module from the PSoC Contest Design Kit which includes a 0.1 m F and 10 m F bypass capacitors in parallel to power rails.

The circuit is not critical, the only aspect needing a bit of care is the working point of phototransistor PH1. If the sensor is made too sensitive, it will be disturbed by ambient light and screen base luminosity (a certain amount of light is always emitted, especially by LCD monitors). Conversely, insufficient sensitivity will make the device dumb on all but the brightest screens. I have found that a BP103 phototransistor and a 56 kilo ohm resistor works well; if you use a phototransistor other than the model specified, adjust R1 accordingly.

The quadrature encoder is a mechanical type manufactured by ALPS , the kind that replaced old potentiometers in most car stereos. It provides two quadrature outputs (A, B) that close to a common pin, plus a switch that can be operated pushing the shaft. I have used the switch for detecting when the Wallet is pressed against the PC screen, in order to enter automatically data-entry mode; of course, you can use alternatively a distinct detector switch as well. External pull-up on these inputs are unnecessary, as the PSoC provides programmable pull-up on its pins.

The display is a 16 characters by 2 rows alphanumeric LCD module based on the Hitachi HD44780 controller. Connection of pin 3 (contrast control) depends on the module model. Recent modules, including the MDLS16265BSS that I have used for the prototype, require connection of pin 3 to GND. Different parts may require to leave this pin floating, while older modules may need an external trimmer to adjust the contrast.

The application does not require precise timing, on the contrary it is designed to adapt to the unpredictable timing tolerances of web browsers and PC, therefore I have saved the cost of power regulation disabling the switch mode pump. Power comes directly from 3x1.5V batteries, with SW1 operating as power switch.

I think that the circuit is very optimized. Try using a conventional controller in place of the PSoC, and you will be surprised by the amount of extra parts required!


I have conceived this design as a building block suitable for being reused in many different devices. Therefore efficient internal placement was one of my objectives. Actually the placement takes only half of the analog and digital blocks available in a CY8C27443. Using as few I/O pins as possible is important as well, and the acquisition system requires only one extra pin other than the sensor input. The layout fills one digital row and one analog bi-column, making no restrictions on the use of the free blocks. You can download the placement diagram from Circuit Cellar's ftp site.

A PSoC Designer's PGA module placed in ACB01 implements the sensor amplifier illustrated in the block diagram. Its amplifies 16 times the signal coming from PORT_0_0. Its reference input comes from ACB0, another PGA that implements the unity-gain offset control buffer. The offset voltage is generated by a DAC_6 placed in the switched-capacitor block ASD11. It is necessary to use the sample and hold on the output to get a continuous signal from the DAC; the I/O pin PORT_0_5 is used for bridging DAC's continuous output to the PGA input.

The low-pass filter is a LPF2, configured as an unity-gain, 2-pole Butterworth; it is placed vertically in ASC10 and ASD20. Its frequency cut-off is 670 Hz and it is internally connected to the sensor amplifier's PGA.

The last analog block is the analog-to-digital converter that digitizes the signal coming from the filter, implemented as a delta-sigma converter by DELSIG8 in ASC21. This kind of converter requires only one timer module, placed in DBB01. As regards the clocks, both the ADC and DAC take the clock from VC1 = SysClk/16, while the filter uses VC2 = SysClk/256. The CPU runs at SysClk/8, which is more than adequate for this application, with nominal power set to 5V.

The digital blocks create less restrictions during placement, and can be laid out in many ways. The proposed pattern has the advantage of being contained in the same digital row. Whatever the placement, remember to select the same clock for the DELSIG8 TMR and its analog counterpart. The design requires two more digital timers, one 8-bit (Timer_8 in DBB00) and one 16-bit (Timer_16 in DCB02 and DCB03). The software uses these timers for measuring intervals whose length is in the order of the milliseconds. The clock comes from VC3 = Vc2 / 25 = 3750 Hz, with a maximum count time of 68 mS and 17 Sec respectively.

The LCD module occupies the I/O port 1; the quadrature encoder requires an additional 3 I/O pins, I have selected pins 0, 2, and 4 from port 2 as they are physically near on the Invention Board. Don't forget to enable pull-ups on encoder pins.


The application code is written in C and takes 32% of the FLASH available in a CY8C27443 device, leaving more than two thirds of the non-volatile memory for storage of user data. While developing the code, I have placed each logic block in a separate module, banning the use of global variables whenever possible. This is a discipline I have learned the hard way, working on large projects with other programmers, but it useful also in small designs, because it allows to make changes very easily. The price to pay for flexibility is that the code is dispersed in many files, but it is a practice that pays for itself when applied correctly: touching one module doesn't affect the others, therefore you can invent a different keyboard layout, or try an error correction code other than the Hamming's, or experiment a new offset-level control strategy, concentrating the changes only on one module at a time and leaving everything else untouched.

The receive() function demonstrates how modularization is implemented. The function in Listing 1 attempts to receive a codeword from the light detector; it keeps trying until a new codeword is detected or the quadrature encoder button is released. It does its job one bit at a time, calling the receive_bit() function, a lower-level routine that can return 0, 1 or BIT_INVALID. The last value indicates an error or a timeout condition, in that case the receiver discards all the bits previously received and restarts.

int receive( void )
    BYTE bits;
    T_ZERO_ONE_INVALID new_bit;
    int codeword = CODEWORD_INVALID;
    bits = 0;
    while ( bits < 10 && quadrature_encoder_button() )
        new_bit = receive_bit();
        if (new_bit == BIT_INVALID )
            bits = 0;
            codeword = CODEWORD_INVALID;
            codeword = (codeword << 1) | new_bit;
    return codeword;

The receive() function reduces the problem of receiving a codeword to the problem of receiving a single bit. This new problem is handled by another function, receive_bit() , detailed in Listing 2. Our protocol encodes bits as the sequence starting with logic one (for 45 to 90 mS), followed by a logic zero (45 mS). Based on the duration of the previous sequence (with due tolerances) the function determines if the bit just received is a one (shorter) or a zero (longer). Timeouts are provided during reception to abort the operation if no valid data arrives after a fixed amount of time.

At this stage the problem is further reduced do detecting input logic levels with a couple of functions: is_one() and is_zero() . This is done in another module, “ light_sensor.c ”, that reads the AD converter, adds hysteresis, fills inter-frame gaps in CRT monitors, etc. It is important to note that, as long as you provide the same couple of functions, the receiver code continues to work untouched even if the logic levels are determined in a different way. The mechanism is very flexible: for example, you may want to experiment a two-tone sound as a data source in place of light; or you can get the data as a logic level from an external circuit connected directly to an I/O pin. In both cases, all you have to do is to replace is_one() and is_zero() with an alterative implementation.

You can download the source code (a PSoC Designer project tree) from Circuit Cellar's ftp site, beside a flow chart and a detailed explanation of the Hamming decoder algorithm.


The PC interface does not require you to install specialized software or drivers, but just to open a HTML file with an ordinary web browser. HTML files can be stored locally or accessed on-line, as they can be used as pages in a web site. Photo 2A shows what happens when you open "web_keyboard.htm" with Internet Explorer 6. The screen displays a virtual QWERTY keyboard and a big white pad, which is the area that sends the signals to Wallet's photodetector, changing its colour from white to black and vice-versa The keyboard picture is made active by means of a JavaScript program embedded in the HTML file, which runs automatically when the web browser loads the file. A nice feature of JavaScript programs is that they are platform independent; additionally, many popular web sites require JavaScript, therefore most browsers enable it by default.

Processing takes place using strings, that are handy to manipulate with scripting languages. Each time you click on the picture, the browser invokes the "keypress()" function, passing it a string argument representing the 10-bit code to transmit, e.g. "0001010101" for the letter "Q". Analysing the string character-by-character, the "encode()" function builds another string that represents the sequence of colour bursts to be transmitted, with "B" representing a 45mS black pulse and "W" representing a white one. The string includes the stop bit and is appended to the transmission queue (another string, tx_queue ).

A timer-invoked function ( timeout in JavaScript parlance) checks the queue every 45 mS; if it is empty, then there is no data to transmit and the transmission colour is set to white, otherwise the colour is set to either black or white according to the first character from the queue ("B" or "W").

This is a quite liberal use of timeouts , a mechanism originally included in JavaScript in order to support stuff like animation effects, automatic picture switching, page changeovers etc. Nonetheless it proved to be effective for data transmission, too!

Now that we know what colour to display, the last method we need is a technique for painting a rectangle. Surprisingly for a language that runs in a web browser, JavaScript does not include graphics primitives like drawing lines or boxes, not to mention filling screen areas. All you can do is limited to load an entire GIF or JPG file (slow) or change the colour attribute of screen objects like fonts and buttons. I selected the second option because it's fast and compact: actually the “set_color()” function is just one line of code long.


Before building the prototype, I have refined the design fitting the Invention Board in solder-less breadboard, so at the time of first power-up I was confident that everything worked well. Well, almost: after switching from USB to battery power, I quickly discovered that the unused parts on the Invention Boards were drawing significant power. I suggest you to use a bare CY8C27443 for best battery life.

My prototype uses point-to-point wiring and a few drops of hot-melt glue to bond the parts to a 60x90mm plastic box . Placement is not critical, just try to shield the phototransistor from ambient light.

After powering the device up, turn the encoder knob to enter the combination: the default code is 3 to the left, 4 to the right, 5 to the left, 6 to the right, 7 to the left. Once the combination is accepted, the knob scrolls between the data records until the device is powered off.


Being a designer can be exciting. The part of the design process that I like most is when a fresh idea suddenly comes to your mind, triggering a sequence of new inspiring applications. Well-educated people call it brainstorming, but it is not very different from genuine daydreaming!

The abstract idea that makes the Silicon Wallet work is that you can lock, setup or control features of any device just exposing it to a PC screen. Therefore this technology can be adapted to lots of interesting uses.

For instance, Videogame cartridges can be sold at an introductory price, with limited playing time or some features locked. Later, customers can buy extra time and extra levels connecting to the vendor's web site and placing the cartridge on the PC screen (CD-based consoles could use a specialized memory card instead). From another prospective, parents could be interested to control time spent by kids playing videogames: then a joystick that works only at programmed times, fully adjustable exposing it to a PC screen running an user-friendly interface, can be a very convenient solution.

In a similar way, Wallet's technology can improve the way we configure most microcontroller-based products. Setting up my last universal remote control took hours. It could take minutes if only I can go to the manufacturer's web site, and visually select the brand of my current TV, DVD, satellite receiver, and VCR: then transfer the whole setup to the remote control with a single mouse click. The same applies to my pulse-check bicycle computer: every time I replace the battery it forces me to enter, using 2 ugly buttons: wheel diameter, date, time, beep on/off, age, sex, normal pulse rate, maximum pulse rate, kind of training desired. The same information can be pleasantly laid out and stored in a web page, and transferred to the device just placing it on the screen.

Those working with electronic keys should be intrigued by the possibility of programming a key from the Net. Many electronic keys are already embedding a microcontroller, so the extra cost reduces to the addition of a phototransistor and a power source. These keys are often used as cash replacement for vending machines, photocopiers, and even to lock expensive equipment given for lease in case a payment were omitted. It is not difficult to design soft-drink key that gets credits online, or a photocopy key you can refill straight from the Intranet.

I'm sure you can add many more imaginative ideas to the list: I look forward to see your creations!


Documentation and source source code are available for download on Circuit Cellar's ftp site: ftp://ftp.circuitcellar.com/pub/Circuit_Cellar/2005/183/. Look for the file Ricci_Bitti-183.zip. Please note that it is copyrighted material.

Also from Circuit Cellar's web site: PSOC contest winner announcement and polished, on-line version of the article.



designs f.a.q.


crc guide who am I ? awards
home | nutchips | designs | f.a.q. | provokations | crc guide | who am I ? | awards