Teensy Version

Even though I haven't fully finished the Arduino Uno R3 based AardRemote prototype, I've already started plotting the second system version using the Teensy 2.0 board which, as you can see, is aptly named:

Obviously, I should be able to make the Teensy version fit in a much smaller enclosure :-).

The Teensy also has the advantage that the USB and UART are not tied together like they are on the Uno, so if I wanted to, I could write the microcode to be able to talk over both interfaces, or I could just use the USB for loading new microcode and the bluetooth and UART for running the AardRemote protocol.

I plan to power the Teensy version via the USB connector with an ordinary USB charger, so I wanted to look at the output voltage of the charger under various load conditions.

I picked up a Staples brand dual port USB charger (rated for 1000mA output) and stuck a voltmeter on it. Under no load it provided 4.88 volts. With some hefty resistors to provide loads in the range of 100mA to 500mA, the voltage never dropped below 4.7, and while I might like it to be closer to 5, these are probably good numbers (at least they aren't too high).

Just for grins, I tried measuring my computer's no load value and got 5.1V. A powered USB hub I have gives 5.2V, and the USB power output on my fancy expensive Panamax power conditioner gives 4.999V (good to know that the expensive equipment produces the most accurate value :-). Another charger from some unknown source showed 5.2V under no load, but also dropped down to 4.7V under load, so the charger from Staples has a more consistent voltage output.

I can't really do a lot of work on this second system version till my JY-MCU Arduino Bluetooth Wireless Serial Port Module arrives from dealextreme.com in Hong Kong (which usually takes a week or so in customs in both Hong Kong and New York plus whatever shipping time is also required, but boy are the prices good :-).

I'm currently envisioning wedging everything into a short piece of plastic pipe as a case with the IR LED, IR decoder, and USB connector sticking out of a few holes.

Meanwhile, as long as I'm suffering from second system syndrome, I should work out a different IR driver circuit using some darlington switching transitors I have laying around. They would probably be more efficient than the 2N2222A transistor.

The circuit below seems to be working - I measure 96mA through the IR LED when I run the +5V source through my multimeter:

The darlington switching transistor is from a batch I bought a long time ago at Radio Shack. Looking at them closely, I see that none of them have the same markings, but I guess they all have similar characteristics, the important one being rated for 800mA, so the 96mA to blast the LED should be no problem. When I leave the circuit on for a while, nothing gets warm, so the modulated IR signal should not strain things at all. Also, the 100K resistor I can use with the darlington switch means very little load on the PWM output from the Teensy.

After experimenting with the prototype and observing how directional the IR output is, I decided two LEDs would be better than one (maybe mounted on nice bendable wires I can point in different directions), so I've adjusted the circuit, adding two LEDs in series and reducing the resistor to 10 Ohms. I measure 98mA with this new circuit, so both LEDs should be blasting away:

Here's the breadboard rig I used for testing. The USB cable I once salvaged from a dead mouse was handy since has a nice plug on the end I can use with jumpers. I was able to use the exact same USB charger to power the breadboard as I am planning to use on the final AardRemote, so the conditions should be as similar as possible:

Meanwhile, I've been examining the datasheet for the atmega32u4 chip, and one obvious problem shows up: There is no Counter/Timer2 on the chip. Since I use that to generate the modulated IR output, I'll have to adjust the microcode for the port to the Teensy. Looks like I can probably use Counter/Timer4 to do similar PWM output.

Turns out I can use timer4, and the Ken Shirriff IRremote library has already been ported by Paul Stoffregen for use on different chips (including the Teensy 2.0 I have). I should be able to use that source for all the hints I need to adapt my library (I need different source code because I run everything with interrupts rather than delays).

Without trying to understand it (which I still plan to go back and do), I grabbed bits of the teensy 2.0 version of the IR code and wedged it into my library with ifdefs, and when I soldered on some wires and plugged the teensy into the breadboard, it worked perfectly:

Here's a close up of the wires soldered to the teensy (turned out to be easier than I thought with a small vise to hold the teensy and the wires wedged into place against the side of the vise - all I needed to worry about was holding the soldering iron and the solder).

I have VCC and GND for the power connection, OC4A (teensyduino pin 10) for the modulated IR output and ICP1 (teensyduino pin 22) to use input capture for reading the output of the IR receiver.

I'll need a few more wires hooked up when it is time to interface with the bluetooth modules (RXD1, TXD1, and possibly an output pin to control command versus radio mode on the bluetooth module), but they haven't shown up yet (still in New York the last time I checked the tracking info).

Despite the USPS tracking info saying the modules were still in New York this morning, they actually showed up at my door around noon. Here's the size comparison with the Teensy:

Hopefully I can desolder the header on the end. I need all six signals, and it would look cleaner to use wires for all of them rather than a silly mix.

Here's the extensive documentation printed on the back of the bluetooth module:

And now I have made a breadboard full of spaghetti:

And while playing with this spaghetti, I have learned a few things:

• These modules have the linvor microcode as described on Byron's Blog.
• This means that all my work to switch to wires so I could hookup the KEY pin to switch in and out of command mode was wasted effort: This bluetooth module is always in command mode when it isn't connected to a bluetooth master.
• On the positive side, this means that the 4 pins hooked to the header were all I really needed. Possibly having the STATE hooked up might be useful, but it probably isn't really necessary.
• Experimenting with checking the baud rate seems to show that the OKbaud response prints at the current baud rate, but soon (perhaps immediately) after that response is printed, the baud rate changes, and the new rate is permanent, taking effect in command mode as well as when connected.
• Just as a note, I don't get the exact same string back as Byron's Blog describes when I send AT+VERSION. I see a leading OK, with the full string being OKlinvorV1.5
• I was able to successfully pair with the module and use a terminal program to communicate with the serial monitor while running a simple sketch on the Teensy, so all the basics seem to be in place.

I've been playing with my microcode some, and I can indeed just stick a HardwareSerial bt = HardwareSerial(); initializer up front and change all the Serial references to bt and the Teensy breadboard works just like the original UNO prototype.

But what I really want to do is make it possible to talk to the USB or the bluetooth interface, and my first attempt at that didn't work very well. I need to investigate how to detect that the host computer has actually opened the USB interface, then switch to USB communication when that happens.

Fortunately a bit of poking around found Serial.dtr() on pjrc.com. I can use that to notice when someone opens the USB data connection and switch to talking USB instead of bluetooth.

I got the microcode working well with both USB and bluetooth, so I have been working on cobbling up my 2nd prototype. Here's the diagram I whipped out in GIMP to guide my soldering:

And here are the results of that soldering:

I plan to mount it inside that plastic tube with the IR LEDs on flexible stalks made of heavy (but not too heavy) copper wire run outside of the tube so they can be bent and pointed in any direction.

It was beyond my kludging skills to figure out a way to mount the teensy so that a cable could be plugged and unplugged at will (the force required would need a very solid mounting), so out of necessity the plan is to plug in the USB cable permanently and run the cable out of the tube:

...and it even fits in the tube:

It is finished! Here it is with the twin IR LEDs poised like striking cobras :-).

Turning out this case was equal parts ship in a bottle and Japanese puzzle box, but I eventually got it all put together (I can definitely say it would have been simpler to run wires through the holes in the plastic tube before soldering them to the IR driver circuit :-).

Now my problem is that I no longer have anything to divert me from having to work on figuring out android programming where my android discoveries are taking shape in the form of an imaginary book: MyAndroidBook.