Using the BU2090FS LED shift driver

I do a lot of scavenging for components. Whenever I get my hands on junk electronics I whip out my soldering iron, a desoldering pump, some pliers, and a pair of tweezers to see what I can extract from it. Scavenging is a long, tedious and sometimes painful process involving singed hair and burnt fingers, but every once in a while I come across a really nice component from an old TV or washing machine. I’ve learned a lot of desoldering (and some soldering) skills, and managed to save a few bucks by scavenging for components.

IIRC, I found the BU2090FS on a VCR board. I managed to desolder the SSOP16 chip by throwing the entire PCB into a toaster. I let the board cook for a few minutes and then started pulling off parts with my tweezers. The chip is quite solderable by hand, but I had no 0.8mm SSOP boards, so I superglued the chip onto veroboard and had a go at hand soldering the thing.

Now you’re probably thinking that hand soldering a 16 pin SSOP is a daunting job, but its not really that hard. All you need is a fine point soldering tip and a steady hand. A little bit of magnification and good lighting helps as well. All in all it took me less than 15 minutes to make the DIY SSOP-to-dip ‘adaptor’.

 
Left: the ‘adaptor’
Right: the chip can be seen below the wires

The ‘2090 is a 12-bit latched shift register, and is primarily used to drive LEDs. It runs off 5v and can sink upto 25mA per channel. Coding for the chip wasn’t difficult at all. Serial data can simply be clocked in and you’re ready to go.

Below is a ‘scope capture of the data to make output Q8 and Q0 low. Data is fed in MSB-first. Keep in mind that the outputs are active low since this is a sinking driver.

 Oscilloscope capture

Data and clock lines idle low. According to the datasheet data is sampled every rising clock. A shift occurs after every new bit of data is clocked in. Data is latched after all 12 bits are sampled by raising data high and then pulling clock low.

I used CCS-C on a PIC16F882 to test the chip. An excerpt of the driver is below:

#define clk pin_c5
#define data pin_c4

void writedata (int16 var)
{
    int8 loop;

    var<<=4;   

    for(loop=0;loop<11;loop++)
    {
        output_bit(data,var&0x8000);
        output_high(clk);
        output_low(data);
        output_low(clk);
        var<<=1;
    }
    output_bit(data,var&0x8000);
    output_high(clk);
    output_high(data);
    output_low(clk);
}

 

 
The BUF2090 mounted for prototyping

Hacking the Wii MotionPlus

So its been two days since I got my Nintendo Wii MotionPlus (henceforth simply ‘WM+’; yeah, I know I called it the ‘M+’ earlier :-|) clone from DealExtreme. And I’ve been itching to get some data off it.

The WM+ uses I2C to send and receive data from a host, which is normally a WiiMote, but in my case it is a PIC16F877.

The hacked WM+. I desoldered the pass-through port (normally used to connect a Wii Nunchuck) and used it as a mating female connecter for the WM+’s male connector.

On the net, I couldn’t find a single site that used a PIC as the host. And most sites had code specific to the microcontroller used by the site’s creator (which was more often than not an Arduino). So after cracking my nut trying to figure out what in the heck these Arduino chaps were doing, I decided to post pseudo-code so that others working with the WM+ can easily write code for their micros.

*        *        *

Pseudo-code:

//initialize the WM+
i2c_start
i2c_write(0xA6)
i2c_write(0xFE)
i2c_write(0x04)
i2c_stop
  
//read data
while(true)
{
    i2c_start
    i2c_write(0xA4)
    i2c_write(0x00)
    i2c_stop
   
    i2c_start
    i2c_write(0xA5)
    yaw_lo_byte = i2c_read(ack)
    roll_lo_byte = i2c_read(ack)
    pitch_lo_byte = i2c_read(ack)
    yaw_hi_byte = i2c_read(ack)
    roll_hi_byte = i2c_read(ack)
    pitch_hi_byte = i2c_read(nack)
    i2c_stop
   
    //this is necessary since the last two bits
    //in the high bytes are useless
    roll_hi_byte = roll_hi_byte >> 2
    pitch_hi_byte = pitch_hi_byte >> 2
    yaw_hi_byte = yaw_hi_byte >> 2
   
    //send to computer for displaying
    putc
    printf
}

A few words about the pseudo-code. You’ll find that the hex value that you write in line 3 is 0xA6. Some websites say the WM+ ‘starts off at address 0x53’. This is confusing since 0xA6 is not equal to 0x53. To figure this out you need to know a little about the I2C protocol.

*        *        *

A little about I2C:

Quite often, I2C devices use 7-bit addressing, and a 1-bit read/write indicator. 7+1=8 bits=1 byte. All I2C communications start with the host sending a ‘start condition’, followed by the 7-bit address, followed by a 1 or a 0, telling the device that data is either to be written to, or read from that address. This may be followed by additional reads or writes. Between reads and writes, an ‘acknowledge (1)’ or ‘not acknowledge (0)’ is sent. Communication is terminated with a ‘stop condition’.

*        *        *

Anyway, so how is 0x53 equal to 0xA6? Simple. 0x53 is the address that we want to write to. So the first seven bits are 0x53, and since we are writing the next byte, we send a 1. In C this is written as:

(0x53<<1)+0

Which, in plain English reads as: “Shift 0x53 to the left by one bit; set the least significant bit to 0”.

Now we see that (0x53<<1)+0 = 0xA6. Do it yourself if you’re not convinced!

So once the WM+ is initialized, one can start reading gyro data. Some sites recommend that you wait 38ms before reading data, since the WM+ needs to initialize fully, but I haven’t done that and yet my WM+ gives me ‘nice’ data.

Close-up of the pass-through port female connector. Only four wires are needed. Red – Vcc; Black – Ground; Blue – SCL; Yellow – SDA. The pins that go into the bread board are scavenged from a broken DB25 male plug.

Gyro data is stored in six consecutive address. In my while loop, I set the address from which to start reading data from – this is 0x52 (which becomes 0xA4, since we’re writing). I write 0x00 to the register to indicate I ‘want’ data. Then I read data into the ‘hi’ and ‘lo’ bytes of the roll, pitch and yaw variables. Data reads are ‘ack-ed’, ie, acknowledged. The last byte is ‘nack-ed’. This is NOT to say that it is not acknowledged, rather the word ‘not’ in ‘not acknowledge’ actually refers to Boolean inversion. Since an ack is binary 1, a nack becomes binary 0.

In my actual code, I have a for loop inside the while loop. The for loop runs 32 times to average out the roll, pitch and yaw readings. After averaging, the data is sent out using a string of putc statements. Alternatively, printf may be used to print to a terminal program – the choice is yours. Infact, I threw together a simple LabVIEW program to display the roll, pitch and yaw on a dial. You can see that I am simultaneously also graphing the results.

The LabVIEW frontend. Roll, Pitch and Yaw are depicted.

My setup is pretty simple – just a PIC16F877 with the TinyBootloader on it, running at 20MHz; a MAX232 for serial comms; the PICKit2 provides 5v power to the PIC and the MAXIM chip; a TI LP2950 regulates the 5v to a safe 3.3v for the WM+. A cheap USB-to-Serial dongle is used to receive data @ 115.2Kbaud.

  The current setup - WM+ connected to a PIC16F877. Power provided by the PICKit2. Serial data sent to LabVIEW through a MAX232 and USB-Serial dongle.

I still need to calibrate the WiiMote, and see how accurate the data is. In the next few days I’ll be making my data acquisition board wireless (by including the RF code from an earlier project, and using a Li-ion battery). I’ll be going around the place, sticking the board to swivel chairs, on the wheel of a cycle, on a treadmill, to a fan blade, and whatever else I can think of :-P.

Updates, more pics and videos will be up in a while.

 

Credits:

• WM+ using I2C on the Parallel Port (for those who have one on their systems). This was the most useful link, since code was in C, and therefore, the most understandable to me http://mtn.coolfactor.org/viewmtn.py/revision/file/9215fdc14d2c75cd9715068556c21b12f1266393/i2c.c
• Arduino-WM+ http://randomhacksofboredom.blogspot.com/2009/06/wii-motion-plus-arduino-love.html
• WM+ driver http://123a321.wordpress.com/2009/08/21/read-motion-plus-via-i2c/
• Wiibrew’s documentation http://wiibrew.org/wiki/Wiimote/Extension_Controllers#Wii_Motion_Plus
• Kalman filtering for the Nunchuck-WM+ combination http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1248889032/0

Touch Me Please: Video

You can watch the video of my touchpad interface here:

The touchpad is taken from an HP Pavilion dv2000 laptop. A PIC16F628A performs all the necessary PS/2 host functions; and a Nokia 3310 LCD is used to display ‘mouse’ movement.

The LCD uses custom graphics. I wrote both, the LCD driver, and the firmware to run the touchpad. Code is in CCS-C. Both drivers are based on info found online. Do note, that the touchpad code on this page is slightly different from the touchpad code posted in the original page.

You can find the original post here.

Touch Me Please!

Before I dive into this post I take a moment to profusely apologize for the title of the post – it is tragically horrendous.

OK, so now that I’ve got that out of the way, lemme begin. This post is a little out of ‘order’; it would have been more appropriate had I first blogged about how I procured some of the components mentioned in this post. But heck! Lazy as I am, I guess I’ll leave that for a later date.

A friend of mine (un)fortunately busted his laptop several months back. I managed to persuade him to let me scavenge parts from the laptop. What parts did I get? That’ll be the subject of a different post :-D I managed to rescue several components; a touchpad being one of them. And as usual, I went about trying to interface it.

Electronics being my love, and today being Valentine’s Day, it is most fitting that I have successfully managed to communicate with the touchpad. Now before you start making judgements about me, and why I fool about with electronics on this most awesome day, let me tell you how I went about the interfacing.

The touchpad is a mouse replacement ubiquitous on laptops. Synaptics is by far, the biggest touchpad manufacturer. Alps Electric, Cypress, and a few others are also into the touchpad market. Most touchpads today work on the principle of capacitive sensing.

The touchpad of my trusty IBM Thinkpad R51 

The touchpad I scavenged was from an HP Pavilion dv2000 series laptop. The touchpad used is probably manufactured by Alps Electric Corporation (there is a prominent “ALPS” silkscreened onto the back of the PCB). The touchpad is a capacitive sensing type and is controlled by a 48 pin QFP. The chip is marked 1CA026A. I googled high and I googled low but I couldn’t find anything useful; no datasheets, nothing. So it became necessary that I give experimentation a shot.

There is a four wire flat cable (FFC) heading off the PCB. Having fooled about with electronics for a while now, I knew that it was but obvious that the touchpad used some sort of serial protocol. I figured that there were a few possibilities – maybe USB, possibly I2C. Again, I googled to see if touchpads followed a standard protocol. Most sites on the net said that laptop touchpads invariably use the PS/2 protocol, however, none of them said it with ‘authority’. It was always “apparently, touchpads use the PS/2 protocol” or “the PS/2 protocol is used even on laptops”.

Anyway, I thought I’d give USB a try. I used a hacked-together USB dev board, pulled out V+, Gnd, D+, D-, and connected them to what seemed like the appropriate pins on the touchpad. When the error “USB device not recognized” popped up, I reversed D+ and D-. After I still got the same error, I guessed that it was the PS/2 protocol that the device used.

I don’t have a PS/2-to-USB converter so I had to use one of my trusty PICs (a ‘628A is this case) to emulate a PS/2 host. I wrote my own driver basing my ‘read data’ code on something written by Dheera Venkatraman (who has very kindly made his code available online).

I also referred to these sites for info about the timing specs of the PS/2 protocol:
http://www.computer-engineering.org/ps2protocol/
http://www.computer-engineering.org/ps2mouse/
http://documentation.renesas.com/eng/products/mpumcu/apn/reu05b0121_h8s2100ap.pdf

 

Below are a few pics that I took.

Right: The touchpad; left and right buttons are on the PCB
Left: Bottom view of the touchpad PCB

The test rig 

Initially, when the touchpad is powered up, it sends 0xAA (‘passed self-test’), followed by 0x00 (which is the mouse ID). The ‘628 then sends the byte 0xF4, which tells the touchpad to stream data, i.e. continuously send any activity on the touchpad or the buttons. Once all commands are received/issued the PIC asserts a pin connected to an LED.

The initialization sequence – 0xAA(self-test OK) followed by 0x00(Mouse ID)

Here is my code if you need it. While you are free to modify it in any way you wish without permission, it would be nice if you remember to give me credit. :-D

Video to come up shortly.

Update: Main(s) is a Pain

Here’s a quick update: remember I said in my original post on powerline networking that the reason why I wasn’t getting a clean sinusoidal wave on the transformer was probably due to the fact that the duty cycle of the PWM signal generated by the PIC’s CCP was not 50%? Turns out I was right. I set the duty to exactly 50% and though I not getting a sine wave even now, its still pretty close.

In blue is the pseudo-sinusoid at the transformer primary. The pulse train in green is the input given to the transformer secondary.

Main(s) is a Pain

NOTE: Windows Live Write S*CKS! WYSINWYG (what you see is NOT what you get). I used to type out something, and land up with some completely vague formatting! It took me a while to fix this.

* * * * * * * * * * * *

Now who would have thought
that the powerline would be fraught
with difficulties such as these –
from an imbalanced phase
to noisy EMI
it all just seems a maze
to me!

I want to send data, I wish to communicate
betwixt and between two PIC micros -
in short, that's the scene.
How shall I do it? Well that's the debate!

The TDA5051’s the answer to my problems,
but that darn piece of silicon’s elusive, I must say!
I’ve searched Lamington Road, I’ve scoured Lajpat Rai;
drat! I can’t source it! The only recourse left is to pray.

With God on my side, and inspiration high
I sat down with paper and pen.
I scribbled here, pondered there, calculated in mid-air.
Schematics in hand, my proof-of-concept is ready,
I’m gonna TX some 1's and 0's now, Amen!

 

* * * * * * * * * * *

 

WHY in the name of the good Lord would I compose such a poem? The current project that I’m working on entails transferring packets of data bi-directionally from my laptop to an appliance using nothing but the power line that both are connected to. Communication through the power lines - Power Line Communication. PLC.

So why compose atrocious ‘electro-poetry’? People do all sorts of things in frustration. And why write such rhymes? A poet-friend of mine would chide me for writing such stuff. In my defence, my poem composing skills are not much better than a kindergartener; to me, lines in a poem must rhyme (heck, that’s how I used to remember them in KG!).

Anyway, let us set aside my inanity for the time being and note that the power line in India carries 230V RMS at 50Hz (it’s 120V RMS at 60Hz in the US). Devices using the X10 scheme wait for zero crossings of the AC signal to send data. The idea is that when the instantaneous voltage is 0V, there is the least amount of spurious ‘external signal’ on the power line. One bit, modulated by a 120kHz carrier, is sent every zero crossing. Only a single bit at a time can be transmitted, because, understandably, the time for which AC is 0V or near-about, is very short.

Now while this method works (its been implemented in several home automation devices), data rates are abysmally slow (50bps for 50Hz systems, and 60bps for 60Hz systems), and the maximum number of controllable devices is low. There does exist an extended X10 protocol which increases the number of devices supported, but the lack of speed still remains an issue.

A workaround (it isn’t really a workaround, per se; more like the obvious solution :-P) is to send data not just at zero crossings, but at all times. By modulating the data at the TX end and then demodulating it at the receiver, and adding some good error checking schemes, higher data rates can be achieved. The TDA5051 works just like this.

The TDA5051 is a 600/1200bps, ASK, half-duplex PLC modem. It is a complete solution, with an integrated analog front-end, a BPF, a decoder, and a communication module for connection with a supervisor (a microcontroller, or a PC for instance). Only a few additional external components are required.

This is all very nice and dandy, but for the misfortune that I just can’t seem to get my hands (well, tweezers actually – it’s a small chip) on a TDA5051.

So how did I get around the problem of the hard-to-find TDA chip? Simple – I rolled my own modem :-D . OK, OK, I’ll come clean. I haven’t yet built it completely, but I’m working on it. The basic testing that I’ve done seems most promising.

 

The steps involved at the TX end are:  

TX side block diagram

*        generation of a data carrier (38kHz PWM from a PIC16F628A)..…1

38kHz PWM @ 18.5% duty, from the CCP module of a ‘628. In retrospect, I should probably have used a 50% duty cycle.

 

  

*         the data itself (300bps UART data) …..2    

The graph is annotated. UARTs idle high; start-bit is low; data is streamed LSB-first; stop-bit is high, followed by idle-high.

 

 

*       modulating the carrier using the data (gating using NAND logic)…..3

The final Boolean output is

(UART) AND (PWM)

 

 

*       coupling the modulated signal to the power transformer (through a 0.1uf ceramic)…..4

Waveform on the mains side of the transformer; secondary side is loaded with an LM317-based power supply. The waveform is probably not sinusoidal due to the 18.5% PWM duty.  

 

 
Left: raw data and its modulated inverse, juxtaposed for comparison
Right: 38kHz PWM and the transformer output viewed with the same timebase - 20us

 The test setup

 

 

At the RX side (test data and pics will be up soon):

 

RX side block diagram

*         a transformer steps down the voltage…..5

*         a high pass filter removes 50Hz mains…..6

*         this is fed to a squaring circuit (made by NAND logic)…..7

*         the squarer drives an IR LED…..8

*         38kHz bursts are beamed at a TSOP1738 which demodulates the carrier…..9

*         the data is then fed to a microcontroller for further processing…..10

 

Using a TSOP1738 IR detector for demodulation – I admit that’s pretty smart even by my standards :-P I bet the chaps at Vishay never intended the TSOP to be used like this :-D

The Super Probe

I remember mentioning in one of my earlier posts that an Oscilloscope was very high on my wish-list. The other day I entered into a bidding war on eBay-USA for a no-name DSO. It was pretty inexpensive, and the features it had seemed reasonably good. Sadly, I was outdone by some chap from Germany, who was willing to pay more than four times the amount I was.

After the eBay misadventure, my electronics toolkit continued to remain woefully incomplete. Apart from a simple multimeter and the PICKit2-Logic Analyser, I lacked the resources to take essential circuit parameter measurements – frequency, event counting, capacitance, inductance. I would also like a function/signal generator which would be able to output a PWM signal, pulses, pseudo-random number sequences and such like. Was there a multipurpose, do-it-all out there that would enable me to do all of this without breaking a bank?

About two years ago I had chanced upon the Super Probe while googling for a low cost capacitance meter. The Super Probe, designed by Luhan Monat, is a DIY low-cost and very low parts-count tool. As its name suggests, the Super Probe is capable of taking a variety of measurements with a fair degree of accuracy. It can also be used to output some useful waveforms and signals.

When I first saw Luhan’s site, I built a solderless-breadboard-prototype for myself. It lasted all of three days before the rats-nest of wires and components was deemed unsightly and cumbersome, and was relegated to the corner of my room, before being cannibalised for parts. I’ve finally gotten around to building my self a ‘proper’ Super Probe – the ensuing photos are ‘proof’' :-)

 

My 'Probe is enclosed in an old Orpat ODM-100 Multimeter case. I ripped out the insides (naturally keeping some of the components – the LCD, and some precision resistors – for future projects :-D ), replacing them with my own circuits. The entire 'Probe is built on proto board using DIP components. I plan to design my own PCB later with SMD parts.

Using my Dremel XPR400, I cut a slot in the side of the old multimeter to accommodate an ON-OFF slide switch. A circular piece of acrylic was glued in place of the rotary switch of the multimeter. Openings were also cut for buttons, which were ‘borrowed’  from an old non-functional calculator. Both, the button holes, and the switch slot, were made using the etching bit of the Dremel. To make the circular acrylic piece, I started by trimming the sides of a square piece. I drilled a small hole in the circular-ish piece and mounted it on a mandrel. This setup was spun at about 20,000RPM on a rough file till a circular shape was achieved, and then on a smooth file for finishing. You could just as well use a lathe to do this, but I had to make do with what tools I have :-( The circular acrylic piece was super-glued into place, as was the slide-switch.

The images below, from left to right, are of the slot cut for the switch; the switch glued from the inside; and, the modifications made to accommodate the buttons.

There are four PCBs inside the multimeter case – the display board, the actual 'Probe, a button mount, and a 7805 regulator. The reason I used a ‘modular’ approach is for ‘upgradeability’. Yeah, yeah, don’t laugh! I’ll tell you how ‘upgradeable’ this device is – I plan to replace the just PCBs with just one, which integrates everything. But until the time I actually design and etch the integrated PCB (I use the toner-FeCl3 method, and I no longer have access to a good laser printer) I would like to tinker and test the individual circuits. Each time I fiddle with a certain sub-circuit, and I wouldn’t want to build a completely new 'Probe.

The PCB wrapped up in red electrical tape is the 7805. The tape was necessary to prevent shorting. In the second pic, the crystal, wrapped in black electrical tape (also to prevent shorting) is visible.

For example, tomorrow I’m going to swap out the power-hungry and inefficient 7805 regulator with the much nicer, and comparatively power-thrifty MAX1836 buck converter from Maxim. I’m currently running off a 9v PP3 battery. With the 7805, I’d get 5v on the output as long as the PP3 voltage is above 7v. Current draw by the circuit is 20mA peak and about 10mA average, so with 9v on the PP3, I’d lose across the 7805. With 7v, I’d lose 20mW.

Now, although this doesn’t seem like much, I could improve battery life tremendously by using a buck regulator which is near about 85-95% efficient. So I’d reduce the power lost across the regulator to about 8mW – a reduction in power loss of 80%. Another advantage of Maxim’s 1836 is that it allows me to run the PP3 down to 5.5v, and it will still give me a nominal 5v on its output.

Back to the construction. For the display, I used individual 7 segment LED displays. The original 'Probe uses a 4-digit multiplexed display, but individual display blocks can be used as well, though soldering them is one hell of a pain in the butt (literally! Hehe :-D ). I put a sheet of cellophane paper (plastic) on top of the display to improve contrast.

The 'Probe uses a PIC16F870 as its brain. Luhan has been kind enough to provide a pre-complied HEX file which only needs to be burnt onto the PIC. He’s also provided the source code for download so you can modify the code as per your needs.

The Super Probe does have its limitations. It certainly is very inexpensive; the caveat is accuracy. The device’s readings are only as reliable as its components. Measurements should not be taken as God’s Word and whenever possible, must be checked against standard tools.

Anyway, the 'Probe has rapidly become one of my most useful tools. Of its 17 functions, I use the Frequency Counter, Event Counter, Servo Pulse Generator, Square Wave Generator, PWM Generator, and 38kHz IR Pulse Generator most often. For a list and description of all its functions look at the list below or visit the Super Probe website.

 

Super Probe Functions
Logic Probe – High, Low, Tristate
Logic Pulser with variable pulse rate
Autoranging Frequency Counter
Event Counter
Voltmeter 5v max.
Diode Junction Drop
Capacitance Meter
Inductance Meter
Signal Generator – 0.5v, 500Hz square wave
NTSC Video Signal Generator
Serial ASCII Generator – selectable baud rates: 1.2/2.4/4.8/9.6K
MIDI Note Generator
Hobby Servo Pulse Generator
Square Wave Generator – 1 to 9999 Hz
10kHz Pseudorandom Number Generator
38kHz Generator – useful for testing IR receivers
PWM Generator – 3 to 97% duty of a 6kHz square wave

Of Scopes and SMDs

I've always loved electronics for its 'minuteness'. I'm fascinated, even today, by how small consumer electronics can get. Have you ever opened up your cell phone or iPod and seen the myriad tiny chips and resistors and capacitors and whatnot? And do you realize that what you see is actually not small; it is HUGE when compared to what is on the inside of those silicon chips.

With Intel, using the 45nm process to manufacture its current processors, now talking about switching to the 30nm, and progressing to the 10nm fab, everything is set to get very, very small. The SMD resistors on your Nokia motherboard seem gargantuan in comparison.

Anyway, I absolutely needed to get myself a piece of this deliciously small pie. So in the past few months I've stared working with surface mount devices. Naturally, if I've reached the level where I'm working with SMDs, I would also have reached the level where I would need the services of an oscilloscope. Problem is, an oscilloscope, even a government-office-used, second-hand, two channel, 100MHz scope - the minimum demanded by any respectable hobbyist - costs about 10 grand. 10 grand is something I would like to have, but sadly, I don't. A new plain-jane CRO-oscope is about 25-30K, while (drool) Agilent DSOs start at a prohibitive 70K. Even cheapo entry-level USB oscilloscopes are a minimum of 10K, and to make matters worse, they aren't available in India.

So, like any other respectable hobbyist (all respectable hobbyists have what is called 'electronics-ego' - some may call it a touch of madness, others, an obsession, and yet others, an incurable disease; to hell with you, you vile naysayers! May you all burn!). Umm, yes, where was I? Aah, as I was saying, like any other respectable hobbyist, I decided to go the DIY way, and build my own scope.

The advantages of building your own scope - it's dirt cheap, and you learn a ton of other stuff (analog layout design, ADC nitty-gritties, USB firmware coding, and host data-handling to name just a few).

The scope would follow this kind of layout:

(Analog front end) --> (Data packaging for USB, on the PIC) --> (Host data display)

AFE:

(Buffer) --> (PGA) --> (Hardware AA) --> (High speed dual-channel parallel-out ADC from MAXIM/TI)

PIC:
(PIC 18F4550)

-> (8Mbit memory from Cypress, for deep capture)
-> (External trigger sources)
-> (USB2.0 Full speed @ approx 1.2MBytes/sec bulk transfer)

Host:

(LabVIEW software frontend)

Upto now I've built, and tested various parts of the AFE - I still need to throw everything together, and see if I actually get the desired results (this, without a doubt, is the biggest thorn in any engineer's side; everything works perfect in the lab, it works well as individual modules, and then, when you try to put stuff together, it all just falls apart. You start swearing and tearing your hair out in frustration; that's the reason why I'm.....uuh, forget it).

Last night (in Sid's words, and CCS-C) I was on cloud [unsigned int8 cloud 0b00001001]. I got USB bulk transfers to work with LabVIEW, albeit, in a crude way. Nevertheless, it worked, pleasing me tremendously. LabVIEW makes development super-easy. Easy, in a way that makes you feel dumb. Amit Sabne, who I've been brain-storming with, puts it very concisely - "Yaar, feel hi nahi aati!" - which is kind of true. The chaps at NI have done a great job of making hardware interfacing a snap. Wait for your USB device to enumerate, enter its VID and PID (device/manufacturer specific 'serial numbers'), throw a few icons and VIs here and there, and voila! You have délicieux transferts de USB bulke, served hot! (yes, translate.google.com is most helpful). The NI engineers have robbed hardware-software hackers from the trials and tribulations of mind-messing driver-writing, back-breakingly long hours of prouring over hardware, and sleepless red-eye-rubbing nights. Damn! Where's the joy and satisfaction if you can do something in 10 minutes, what used to otherwise take hours?

Now that I've got a rough and dirty implementation of PIC to USB transfers to work, what remains is putting it all together. Gimme a few days, and I'll upload the PIC firmware in CCS-C, and the LabVIEW VI here for you to use, enjoy, redistribute!

My वायरलेस प्रेसेंटर

Wow! Hindi transliteration on blogspot! That's an interesting feature! :-) Useless, but interesting, nonetheless.

Just a small point to note: I'm typing these first few lines from 15 feet away, using my wireless presenter. (Big smile :-) )

Naturally, you scoff, "How can you do that? Oh! You have a wireless keyboard! Umm, hang on a sec! You said वायरलेस प्रेसेंटर . How are you typing text?" (Bigger, mysterious smile :-) )

Well, I made my own Wireless Presenter-cum-Keyboard-cum-Mouse. (Biggest smile yet :-) And, in Sheldon's words - TBBTS02E07 - Muaa-hah-hah). Here are the details.

This project originally started off beacuse I used to get exceedingly irritated with the abysmal lack of dexterity afforded by standard keyboards. This lack was / is felt, most painfully, when getting fragged in a fast-paced game of CoD. "I need my grenade! Where the hell is the 'G' key. Dratted keyboard." My rifle! My rifle! '1'! '1'! '1'. Shots fired! Duck! 'Q'! 'Q'! 'Qqqqqqq....!'. I'm sure you get the point. I also do a lot of 3D modelling in AutoCAD, and image editing in Photoshop. My mouse, which would ordinarily be considered reasonably good, fares pathetically at this zoom-in-zoom-out-click-to-do-this-tap-to-do-that kind of stuff. Wouldn't just be great to have an additional fully customizeable keyboard? It would have a zoom slider, a wonderfully sexy scroll wheel (much like the iPod's), multiple buttons, and special keys which have several keyboard buttons bound to one (so to press 'Ctrl-Alt-Del', I'd just need to press one key on this keyboard). The mouse would be integrated into this device, and would have similar useful features.

I can, of course, buy such a device, but that would mean shelling out absurd quantities of cash - something that I don't have much of! Making one would mean I'd save potloads of money. I have been reasonably successful; hence this post.

So far, I've only made a Wireless Presenter, but this same device can be adapted to do all the stuff I mentioned above. A little effort, some pain, and a couple of milk-and-cookies-filled all-nighters are all that are necessary.

Without going into the overly-technical details of the device I'll tell you what the system consists of:
- a full speed USB PICmicro (the 18F2550) (free from Microchip);
- a TSOP1738 IR detector (Rs.10);
- a cheap roadside SONY TV remote (Rs. 60);
- a USB cable (free from an old mouse), crystal (Rs. 4), capacitors (Rs. 4).

The SONY remote sends IR data to the TSOP, which is connected to the '2550. The PIC decodes the IR signals (which are in SONY's SIRC format). The '2550 then sends this data through USB to the PC. Now, I've programmed the PIC to enumerate as a USB keyboard-mouse combo device. So my PC, for all practical purposes, thinks that it has a second keyboard and mouse. I have mapped certain keys of my laptop keyboard to keys on the remote. So pressing the 'Program +' key on the remote, is equivalent to pressing the 'Right Arrow' key on my keyboard. Pressing the 'Power' button on the remote is like pressing 'Esc' on the keyboard.

This is the nice thing about putting software (firmware) onto a microcontroller - you can fiddle around, and map virtually any key combination to any remote key!

I use this device to control MS Powerpoint slides from upto 30 feet away. I've mapped most of the Powerpoint keyboard shortcuts to buttons on the remote. The 'Contrast' button is 'F5', the 'Program Jump' button is 'Enter', and so on.

For a full listing of the source code go here .

I've made this using a PIC, but if you get the logic and code right, I'm pretty sure you could use any processor.

Future modifications include adding an accelerometer to provide intuitive mouse support (right now I'm pressing 'Mute' and the 'Volume / Program +/-' buttons for mouse-like action). Maybe I'll even port the whole thing to RF (Zigbee, or MiWi); it's running IR now - the great thing about IR is that its laughably cheap and easy! RF would involve additional cost and effort (protocols, and other crazinesses). For now, this is good. Anyway, in the beginning you had asked (well, alright, I had made you ask) how I was typing out text using my वायरलेस प्रेसेंटर.....I think you have the answer now.

I will be, at some point in time, making the gaming device I talked about earlier, but until then, I'll have to amuse myself with this :-) If anyone is planning on building something similar drop me a mail - I'll be glad to help.