Look Ma, No Wires!

I’m blogging after aeons! Been really busy; work is such :-/ It’s not like I haven’t been tinkering at all, it’s just that I’ve been tinkering less, and haven’t had the time to document it.

A few weeks ago I decided that I needed a Bluetooth-to-audio adapter for my home (which has a decent but dated Sony home theatre) and car (which has an old stereo system). So this vacation I decided to make one.

Logitech’s Bluetooth Speaker Adapter has got a 3.5mm socket as well as RCA outputs

I was looking for an end result similar to Logitech’s Bluetooth Speaker Adapter, available on Amazon for INR1,100 (~USD16) as on Sep, ‘15. There are predominantly two types of Bluetooth audio adapters available online – one, which outputs analog audio through a 3.5mm jack, and connects to your sound system’s AUX/RCA input. The second, slightly more interesting version (to my mind, at least), plugs in to the USB port of more modern mp3-capable sound systems. The adapter ‘appears’ as a regular USB flash drive with an MP3 file on it. The audio streamed over bluetooth is constantly written and buffered to the ‘mp3 file’. Pretty ingenious!

As with most of my projects, I turned to the internet to do a little pre-hacking research. I took a look at a few DIY hacks – google “hack car stereo bluetooth”, and you’ll get links to several people who’ve given new life to the old cassette deck in their dad’s rickety jalopy.

Pretty straightforward: http://www.instructables.com/id/Add-bluetooth-to-your-car-stereo/?ALLSTEPS

A bluetooth speaker modified to do the business: http://www.instructables.com/id/Bluetooth-Speaker-Hack-Home-Theater-Streaming/?ALLSTEPS

And for those people still rocking cassette tapes in 2015 (my mom, for example), this guy made a ‘bluetooth cassette’: http://car-mods.wonderhowto.com/how-to/hack-your-cars-cassette-deck-into-wireless-bluetooth-music-player-0139843/

I was initially thinking of modifying the BT earpiece I use with my phone, however that would limit me to a mono output only (there are earpieces which have stereo outputs, so these too, may be good contenders for a hack). I had an old Corseca/Byte brand on-ear headphones lying around. The ear pads were crumbling, and the sound quality was absolute rubbish. But it was still working, and I was pretty certain that the poor audio was only due to the low cost sound drivers. So naturally, I took a screwdriver to the headphones, hehe.

Not sure if the brand is ‘Corseca’ or ‘Byte’

Disassembly was rather painless – just a few screws and plastic retention clips. The electronics were crammed into the plastic cover over one ear, and the battery was stuck with double sided tape in the other cover. The cover which had the electronics also had control buttons on the other side – FF, REW, Vol Up, Vol Down, Call Answer.

Teardown time!

No surprises about the main chip being from CSR (now acquired by Qualcomm). CSR is a major in BT consumer electronics ICs, and you’d find CSR chips in everything from keyboards, to headsets, to smart microwaves. The main chip is a CSR57F68 A2DP streaming audio chip. The chip is fully integrated, and has two onboard differential audio outputs, button handling capabilities (debounce, etc), GPIOs, and of course, the BT radio itself.

 
The electronics were on a double-sided board – one side with the chips and support circuitry (Left), and the other side with buttons and status LEDs (Right)

The TSSOP chip is an L24C32, 32kbit I2C EEPROM, which probably stores config data, descriptor strings, etc.

I then desoldered the sound driver and battery wires.

  
Desoldering the mini-USB charging socket, and replaced it with a micro-USB connector for convenience. The micro-USB’s pin pitch didn’t fit the board perfectly, and the connector itself had a different footprint, so I had to use mod-wires

I also removed the mini-USB charging connector, and soldered-on a micro-USB connector (side rant: just like everyone else, I get totally frustrated pulling out ten different cables to charge ten different devices. With most manufacturers now standardizing around the micro-USB connector, things have become a bit easier, but Apple still stubbornly pushes its weird proprietary connectors, each one different from the previous).

 
The covers, before (Left) and after (Right) modification

My idea was to use the two covers – one from each ear – to form a sort of ‘case’ for the final product. I used my Dremel to trim away the plastic standoffs for the screws on the plastic covers. I then fashioned some new screw inserts out of acrylic. The inserts were hot glued into place. Small holes were drilled into the inserts and the bottom cover to allow for the screws.

 
The acrylic inserts/standoffs for screws, and the 3.5mm audio connector

I had a 3.5mm audio socket (probably scavenged from an old motherboard or CD drive) in my junk box, which I also hot glued in place. Wires were then used to connect the audio outputs from the board to the socket. I took care to connect the left and right channels to the correct legs on the socket. The negative output of each differential pair was soldered to the ground pin of the socket.

Connecting the wrong output to ground would result in an out-of-phase output from the speakers. While this may not be such a big deal with headphones, it would result in sound ‘cancelling’ itself out (primarily poor bass response) if I used the BT adapter with speakers. The AudioCheck website has cool online audio files that help you determine if your speakers are connected correctly.

 
 
The finished project – screws on the sides, and the PINK (!!) audio socket sticking out – not the prettiest

A small slot had to be cut in the bottom cover to accommodate the audio jack. The covers are held together by three screws. The final device is not the prettiest, but it’s functional and works really well.

   
Charging through the hacked-on micro-USB connector

No Strings (or Wires), Attached

It’s been a while since I’ve blogged. Its not like I haven’t been trying – my drafts pane in Windows Live Writer is full of half-finished posts. Maybe I’ll complete them and post them before the summer ends. Or maybe not.

This post is about using those cheap 300-bucks-a-pair modules. For international readers, INR300~USD6. If you look around where you live you’ll find the same or similar modules which do the same thing. Sparkfun carries these variants:
http://www.sparkfun.com/commerce/product_info.php?products_id=8946
http://www.sparkfun.com/commerce/product_info.php?products_id=8947

SeeedStudio stocks these:
http://www.seeedstudio.com/depot/433mhz-rf-link-kit-p-127.html?cPath=101_103

The difference between Sparkfun’s and Seeed’s is that the former has a receiver that is PLL synthesized, and the latter uses a relatively cheaper, albeit less reliable LC circuit. I have both types of modules, bought locally. Both types use a SAW resonator for transmission.

These dirt cheap RF modules work at 433MHz (you’ll also find the 315MHz variety), which puts them squarely in the ISM transmission band. They use ASK modulation to send data across. You can mix and match PLL/LC transmitters and receivers without a problem, just so long as they’re all on the same frequency (duh!).

A lot of people use these modules for low cost wireless control mainly because they’re a breeze to interface. The easiest way to work with the modules is to buy the HT12-E and HT12-D encoder-decoder pair. These chips are essentially parallel-to-serial shifters and output a user set 8-bit ‘address’ along with 4-bits of useful data.

But what if you want to send more that just 4 bits? Suppose you want to send an arbitrary text string? Or maybe the 8-bit brightness value of a wireless night lamp? In such situations these chips are useless. You could buy the HT640-HT648 encoder-decoder pair, but again, that would limit you to 8-bits of data at a time.

The best option (IMHO) is to use microcontrollers as the encoder and decoder. Using a micro will, in a manner of speaking, allow you to kill several birds with one stone. You can use the same micro to decode the received data, as well as perform control functions at the RX end.

So how do you go about using a micro? I’ll start at the beginning:

The reason why these modules are cheap is because they are very simple. They are, at most, just a crude pipe through which RF data passes. There is absolutely no form of error correction, no data protocol whatsoever, and certainly no guarantee of data transmission.

One of the biggest problems these modules suffer from is that of DC-drift. Think of digital data being passed through a series capacitor. Let us say that you try to send several 1s, the capacitor will soon charge up until it is saturated. Once it gets saturated you can’t transmit data any longer, since there is no charge mobility. Similarly if you send a long string of 0s the capacitor will get discharged, and again, you won’t be able to transmit data. The trick is to send a balanced number of 1s and 0s. Over a short period of time, if the number of 1s is equal to the number of 0s transmitted, then the ‘DC level’ of the RF module remains balanced.

Clever, you say. But how do I put this into practice? You could use the Manchester encoding scheme to transmit data. Put very simply, in Manchester encoding, each bit is encoded as two bits. A 1 is encoded as binary 01, and a 0 is encoded as a binary 10. Thus, regardless of what data is sent, the transmission is DC-balanced.

A very obvious disadvantage is that the data rate is immediately halved (or one can say that the bandwidth doubles). There are more complex coding schemes which are more bandwidth efficient such as 8B/10B encoding, but I’ve stuck with Manchester encoding, since it’s much easier to do.

Now I didn’t really do any Manchester coding or decoding – I used a bit of a cheat. Most micros have a UART as well, so I included that too in my ‘hack’ – using built-in hardware to do dirty work greatly reduces my effort :-) Since I’m using the UART, I can only send 8-bit chunks of data. The data transmitted must satisfy these conditions:

• Data is to be balanced, so each byte should have four 1s and four 0s.
• There should be no more than two consecutive 1s or 0s. This is a constraint which ensures that data is Manchester-like.

Of the 256 possible numbers, there are 26 8-bit binary strings that fulfil the above criteria. I’ve arranged the numbers in Gray-code-like order.

00110011   0x33 00110110   0x36 00110101   0x35 00101011   0x2B 00101101   0x2D 01100110   0x66 01100101   0x65 01101010   0x6A 01101001   0x69

01010011   0x53 01010110   0x56 01010101   0x55 01011010   0x5A 01011001   0x59 01001011   0x4B 01001101   0x4D 10100110   0xA6 10100101   0xA5

10101010   0xAA 10101001   0xA9 10110010   0xB2 10010011   0x93 10010110   0x96 10010101   0x95 10011010   0x9A 10011001   0x99

 

Each yellow number corresponds to a particular hexadecimal number from 0x0 to 0xF. Thus there are 16 ‘yellow numbers’. Each byte that I want to transmit can be broken into two nibbles. Each nibble is encoded using one of the numbers highlighted in yellow. So, for each nibble, I transmit a DC-balanced byte. At the receiving end the nibbles are collected and ‘re-formed’ into bytes. Clearly, the transmission rate is half of the data rate.

When using this scheme a few other things need to be kept in mind. The transmitter will only be turned on when transmitting data. However, the receiver is always on. And that’s a problem. The receiver will happily ‘lock-on’ to the strongest RF signal it can find. It doesn’t care if that signal is meaningless data – it will demodulate whatever it finds. So as it sits there, the receiver is demodulating junk. Suppose we now start sending data, how does the receiver UART know that this infact, is actual data, and not junk?

The way to solve this is to first send a ‘look-at-me’ sequence. The LAM sequence is just a series of balanced numbers sent by the transmitter to ‘wake’ it up. By doing this, the transmitter establishes itself as the strongest signal source. The LAM also serves as a kind or reference for the receiver’s UART to ‘lock’-onto. After much trial and error, and forum searching, I found that the LAM sequence of 0xBA 0xBE 0xFA 0xCE (or hex BABE FACE) works wonderfully, though it is NOT balanced!

After the LAM, a ‘start’ code is sent (I use the numbers in green, but any sequence may be used). Only once the ‘start’ is received does the receiver accept further data.

The data is followed by a simple checksum. The checksum is the 8-bit sum of all the data. If the checksum calculated at the receiver is not the same as the checksum transmitted, then it implies that some data has been lost in transmission.

Transmission ends when the number 0x99 (red) is received.

I am still working on error checking using data prediction. I’m also working on making this code adaptable to use in a multi-transmitter setup using arbitration.

The code in its current form is very robust and works very well. My setup has two transmitters and one receiver. One transmitter causes a red LED to blink on the receiver side; the other make a white one blink. Understandably, there are times when the transmitters interfere, but this doesn’t cause spurious results.

As testament to the robustness of the protocol (and maybe even the transmitter modules!) here is some data: though the datasheet specifies using a λ/4 monopole antenna (approx 17cm of wire @433MHz or 23cm of wire @315MHz), both transmitters and receivers are happily TX-ing and RX-ing without any external antennae. I suppose I could increase range and reliability by sticking on a wire, but I’m getting a 10m range with a 1.5v battery!

If you want the code ask in the comments. I’ll be posting pics of my setup soon.

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.