It looks like nobody will be adding ustream functionality to Boxee in a foreseeable future and Jeri seems to have settled there. I don’t like exiting Boxee on my media box to watch something because I can’t use my android phone as remote then. So I hacked together a little Boxee app to play Jeri Ellsworth’s Hardware Hacking channel. Just add my repository to use it.

My Boxee repo is located at:

http://dir.symbolengine.com/

Kudos to Jeri for being such a charming geek!

Write cycles are limited in flash drives. A memory cell can usually be written to about 100,000 times but nearly all flash memory devices have specialized circuitry to write to different locations each time the memory is access to even out the wear on all cells. So in theory you can write 200 TB of data on a 2 GB sd card before it fails. This may not be so in practice, but let’s halve it to 100 TB. How much time do you think your computer is gonna take to wear out your card completely? Well that depends on your computers swappiness, but I seriously think it is going to take about a year.

Another protest against the flash swap is the speed of flash devices. While flash devices are much slower than hard drives, think about this scenario: Your computer is playing back a high definition video file and using all its ram, and your hard drive just can keep up with reading the media from the drive. What happens when a cron job executes and needs some memory? Some pages need to be swapped to your hard drive which is on the same device but on a different partition. Your drive head will jump there to write the page, and jump back immediately to reading the media potentially skipping frames on decoding. Using another harddrive to hold the swap file would fix this problem but what if you can’t? What if you are a cheapskates like me? Using a flash memory device for swap would free your hard drive, and even though it is slower, the fact that it uses another media to read from and another bus to move the data makes for shorter I/O queues on devices and faster access times.

So while it may not be as good as upgrading your RAM, putting in a second hard drive for swap or buying a faster hard drive; it still makes a difference in systems where hard drive I/O is the bottleneck. If this applies to you, go on and make a swap partition on that old flash drive (just make sure it is not USB 1.1). It is a very cheap performance upgrade you can use for a year. And who knows what you will be using one year from now anyway?

All devices with remote control has a built in IR receiver chip. They are usually dark red and have a cylindical or hemispherical window and three pins. Those pins are Ground, VCC and data. It is the data pin we are intrested in. Infrared control signals consist of high frequency pulses of light, and the length of pulses and gaps determine the data. Fortunately for us the carrier frequency is filtered inside the IR receiver chip, so there is only clear +5/0 volt pulses on the data pin. We can send the same messages as the remote commander to this pin and trick the device into thinking it is getting the pulses from the original remote.

But there is a problem. How do we know how the commands are coded? This is where LIRC comes into play. LIRC allows you to record and decode the signals sent from a remote controller. You should have some kind of infrared receiver connected to your computer, but fortunately many of the receiver designs are very easy to build. If you just need it for this project I would suggest using the sound card input method. It uses only an IR receiver chip and a 5V power source. Actually you could just wire the data and ground pins of the IR receiver on the device you wish to control, to the sound card mic input and you’ll be good to go.

Set up Lirc following the documentation on its website and test it with mode2 command. If you are getting the signal from remote and everything seems ok, now is time to record the commands from our remote commander. Once again you can consult the LIRC documentation on how to do that, but on my ubuntu system this command works:

irrecord -f -d /dev/lirc0 ~/pmp.lirc

Do not forget the -f flag. It forces irrecord to save the output in raw format. We are going to need a raw format file to convert it to arduino code. The program will instruct you to press keys and record them to the file specified (“~/pmp.lirc” in this case”). If you feel curious you can take a peek at the file for a text editor. You’ll see many numbers after “name [key_name]” statements. Those numbers represent times in microseconds. For example:

9182 432 688

means first the remote send a 9182 µS pulse, followed by a 432 µS gap and another 688 µS pulse. Now we need to translate these numbers into an integer array in arduino’s memory. Since our ram is very small (512 bytes for Atmega168) we will be using the program memory to store these arrays. I wrote a little php script to convert the lirc data file to an arduino header file you can use right away. You can use the script online here, or download the script to use it locally here.

Once we convert the data files it now comes to this: Connect any digital pin on the arduino to IR receiver data pin. Download the arduino example code from here. Write it on the Arduino’s memory and fire away.

Have fun!

USBTinyISP is a very versatile USB AVR programmer by LadyAda that works with nearly all Atmel Microcontrollers.

Downloads:
USBTinyISP Eagle Files @ Symbolengine.com

Here is the basic schema of a 4 motor walker. You can see the numbering scheme we used to identify each motor. Arrow points to which way the robot is going when we say it is going forward. Motors are running counter-clockwise with negative voltage and clockwise with positive voltage. Now to get to the juicy part:

• Please note that the patterns for rotating are 2 times longer than the patterns for movement. As a result turning is slower.
• If your robot is moving in very small steps, try longer delays between steps.
• If the robot is moving faster in one directionor leaning slightly to one direction while walking, there is probably a problem with its weight distribution. Try to distribute the weight as equally as you can, especially between back and front

• There is no battery indicator
• You can't watch the CPU temperature
• and you can't set the CPU frequency governor

Of course you can use gkrellm for the first two but it does not play nicely with dynamic window managers like wmii. If I wanted to drag windows around I'd use Gnome, thank you. It is much nicer to change the right side of the status bar to show current temperature and battery status. 

Beware! This change is for the sh script version of wmiirc. If you are using the other version this may not work.

In file: ~/.wmii-3.5/wmiirc change the part that says

# Status Bar Info
status() {
        echo -n $(uptime | sed 's/.*://; s/,//g') '|' $(date)
}

to

# Status Bar Info
status() {
	BAT=`acpi -b`
	LEFT=`echo $BAT | cut -d ',' -f 2`
	TEMP=`acpi -t -B -c | cut -d ',' -f 2 | cut -d "." -f 1`
	LOAD=$(uptime | sed 's/.*://; s/,//g')
	DATE=`date +"%d/%m/%y %R:%S"`
	echo -n T: $TEMP '|' B: $LEFT '|' $LOAD '|' $DATE
}

You can of course keep the longer date format by changing "$DATE" to $(date) but I like it shorter.

Now on to the Frequency Governor! You can download the script below and put it in ~/.wmii-3.5 . Don't forget to make it executable.

cpufreq @ SymbolEngine

Now when you run the cpufreq action you will be asked for your password. This is because CPU governor can only be changed by root user. After that you'll get a nice dmenu on top of the screen to choose a governor.

I hope you find these scripts useful.

You need completely steady hands, eagle eyes or a stereo microscope, a really good tweezer to grip the tiny resistors, a soldering iron with heat control and a good quality soldering& paste flux. I had& none of them. After 2 hours of agony I could only solder one (1) resistor into place. Then when I accidentally touched the one I soldered when I was trying my luck on the second one, the first one came off… Complete with the original resistor on the DTV board. Talk about pain.

I left everything on the table and fired up my a1200 to normalize the levels of stress hormones in my blood.

The other day I decided it would be much easier to take the original resistors out and solder new ones in than to try to piggyback them. And here it is, the turning point:

Spiff's page says these resistors should ideally be 165 ohms. What I had in hand was the 220 ohms resistors I prepared for the easy fix. The ones on the board where 680 ohms, so I decided to try my luck. 220 ohms is much closer to the ideal value than 680. I soldered them in and as I thought it was much easier.

The result is as anyone can guess, not as good as the original fix, but is much better than the original buggy board. It would have been much better if I had resistor with a closer value to 165 ohm. So I dub this fix Half a Spaceman Spiff's Ghetto Color Fix, or HaSSGCF.

So the moral of the story boys and girls is, it's much easier to replace SMD's than to solder them piggybacked if you don't have right tools.

I'll add my experiences doing these hack here somewhere when I find the time to do them.  

1- Fix the colors:

    PAL version of the DTV is cursed with a buggy video generator. White is not white at all, and some colors are very hard to distinguish. If you don't like your DTV with ghetto colors, try spacman spiff's easy colorfix: (scroll down to easy and better fix)

Spaceman Spiff's DTV colorfix

Note: I have tried this hack with limited success. You can read about it here.

2- Build keyboard and IEC (Disk drive) ports:

     DTV unit has all the needed pins for connecting a ps/2 keyboard and multiple daisy chained disk drives. If you are going to do any serious hacking you need these ports. 

Connecting a PS/2 keyboard to DTV

Connecting a disk drive to DTV 

    There's also a faster way to transfer homebrew software into DTV. Dtvtrans by Daniel Kahlin lets you transfer files from your PC to DTV using a special cable that connects your PC's parallel port to DTV's joystick port.

C64 DTV transfer cable & dtvtrans     

3- Install DTVMON & DTVBOOT:

    Now that we can transfer files to DTV and we made it into something more than a toy we need to get rid of automatic booting into game menu.  This software lets you configure boot behaviour, get screenshots, run a machine language monitor, run dtvtrans without entering the bootstrap code into basic and some more. It is a pretty useful piece of software by, again Daniel Kahlin (This guy just loves DTV, and we just love this guy) :

DTVMON & DTVBOOT

   You are going to need Kahlin's Flash utility if you want to write DTVBOOT to DTV's flash rom and believe me you will:

C64DTV Flash info

Amiga 600 PDF Schematics @ Symbolengine