Recently I’ve have been playing the great game League of Legends but my friends list has not been working. After dealing with the problem for several weeks, I’ve finally found the issue.

I use Smoothwall for my router, and as Smoothwall users may know, it has a niffty IM proxy feature. Well, after playing with some settings, I discovered that the IM proxy blocks the League of Legends friends list and chat. So if using the Smoothwall IM proxy and wondering why the friends list in League of Legends in broken, try turning off the proxy.

With my media computer coming together nicely, I wanted to remove all user intervention such that the computer will boot directly to XBMC. The two primary obstacles to this are automatically logging in the user and automatically starting a program once in XFCE.

I decided to use SLiM as my log-in manager since it is very lightweight and works well with the XFCE environment I’m using. SLiM has autologin behavior built-in, just edit /etc/slim.confdefault_user syzygy
auto_login yes

Of course, change the default user to your username. And thats it, you’ll now be logged in automagically. Now that we are logged into XFCE, I want to autostart XBMC. These instructions are specific to XFCE, but I’m sure there is a similar solution for KDE or Gnome. When XFCE starts, it looks in the ~./config/autostart/ directory and any scripts within are then executed when XFCE starts.

Now create a script. I’ve named mine autostart_xbmc, but the name does not matter:$ cd ~./config/autostart/$ echo "xbmc" > autostart_xbmc

I while back I purchased an Intel D945GCLF2 motherboard to play with. This board features the dual core Atom 330 processor in a nice mini-ITX form factor. I’ve recently set this up as a media center PC, running Gentoo and XBMC. I’ve been quite happy with its performance in this role, but there was one thing that seemed missing… surround sound. The board only has the standard line in, line out, and mic jacks on the rear panel, but on Intel’s website, they claim it supports 5.1 surround sound. The snd-hda-intel kernel driver only provided 2 channel audio to my ALSA system. The user manual for the board was not much help either:

Advanced jack sense, for the back panel connectors, that enables the audio codec to recognize the device that is connected to an audio port and retask the connector via the audio driver.

…

Back panel audio connectors that are configurable through the audio device drivers:

Line in/retasking jack

Line out/retasking jack

Mic in/retasking jack

I’m not sure how this board behaves with the Windows driver, but needless to say, jack auto detection did not work in Linux. Some searching provided an answer: the kernel driver needs to be configured by ALSA to set the jacks to 6 channel mode. Adding this to the end of /etc/modprobe.d/alsa.conf did the trick:options snd-hda-intel model=3stack-6ch-dig

With the driver now set, make sure that alsamixer is set to 6 channel audio. The last item in alsamixer for me switches between 2ch and 6ch, so be sure to set it accordingly.

I’ve been trying to find a good use for the second network adapter in my fileserver, and what better than to increase the throughput to the network. Using something called bonding, its possible to combine two physical network adapters into one logical bonded adapter. Using a bonded adapter provides several advantages such as fallover should one network fail, but more interesting for me, increased throughput. There are several different methods that one can use to bond the adapters together. The best way to double the throughput of the bonded adapters is to use the IEEE 802.3ad protocol, however this requires support on the switch. 802.3ad support is generally limited to managed switches and is not supported on my unmanaged Netgear JGS516. The next best thing is to use a special mode of the bonding driver in Linux, called balance-alb. The other modes supported by the kernel bonding driver allow things such as fallover. I’ve been told that the following method does not work with all network adapters. Specifically, the driver needs to be able to change the MAC address on-the-fly, which is not supported in all drivers. I can say that it works with the r8169 (Realtek) and the Intel drivers (e100, e1000, etc.). This post is written with Gentoo in mind but should apply to other distributions.

First thing you need to do is enable bonding in the kernel. Be sure to compile it as a module since we will need to pass arguments to the module when it is loaded:

The two options above are important. The balance-alb (adaptive load balancing) specifies what bonding mode to use. There are several different options available here, but balance-alb provides the functionality I want since my switch does not support 802.3ad bonding. The second option, miimon=100, tells the module to use mii-tool to check if the network adapters are up every 100ms. This provides the fallover should one adapter fail.

This bonds eth0 and eth1 to form the bond0 interface. You can bond more than two adapters as necessary. The bond0 interface is configured to use DHCP to automatically obtain an IP address. The config_eth0=( “null” ) lines prevent the individual adapters from getting an IP address since we only want bond0 to get an IP.

Now lets create the startup script, have it start automatically on boot, and remove the individual adapters from starting at boot:

That should be it, reboot, and you’ll now have bonded adapters. I used a program called netio to measure my network speeds. Prior to bonding, I could read at about 60-80MB/sec from the fileserver over a gigabit network. With bonded adapters, that increased to about 120-150MB/sec, quite an improvement! Write speeds saw a significant improvement as well. Note that many hard drives will not be able to read/write at the same speed as the network adapter. So if your adapter can push out 150MB/sec, it doesn’t help you if your hard drive can only read at 60MB/sec. Internally, the RAID 5 array in my fileserver can read at up to 250MB/sec using hdparm, so the array can more that keep up with the bonded adapters. If you have an older computer with dual 10/100 adapters, bonding can give you a nice boost to throughput that most hard drives will still be able to keep up with.

In playing with my Samsung u550 phone, I found some postings about various “hidden” menus. On my old Motorola V265, these hidden menus allowed you to change such things as the HTTP proxy that the phone would use for web browsing. By using your own proxy rather than the default Verizon proxy, you could avoid data charges for web browsing, but the time would still accumulate minutes (apparently Verizon tracked data usage at the proxy). The V265 had a pretty small screen, and as such was not very useful for web surfing, but I did use it a few times. From what I read now, Verizon has closed that hack, so using a private proxy will not get you free data usage anymore.

So in looking at what minor hacks are known about my newish u550, I only came across two things. The first is a Debug Menu. To get to this menu, do the following:

Navigate to the Settings & Tools menu.

Press #, which will bring up a prompt for the User Lock code.

Enter 000000 (six zeros).

The Debug Menu has several options, that can be used for debugging, such as setting the phone in CDMA only mode, EVDO only mode, and others. None of these options are that useful to the user. From the Debug Menu, one can access another hidden menu:

From the main Debug Menu, press # which will bring up a prompt for the Developer Lock code.

Enter 8886573982

The Developer Menu provides some options for testing bluetooth, sound, and sleep settings.

Although the hidden menus on this phone are interesting, they do not provide anything useful to the user as the older phones did. This phone is also a pretty generic flip phone, and since data plans have become much more common, there is probably very few people who care about tweaking this phone. I’m sure I’ll get a smart phone eventually, but I’m undecided as to which platform I would prefer.

For a while, I kept an old 733MHz computer in my rack to use as a test box, where I could play with various software without needing to worry that what I was doing could cause problems for my desktop. I have not used it in a while, but I decided that having a physical test machine is unecessary for what I generally want to test. So I decided to create a set of Gentoo virtual machines in VirtualBox (version 2.2.2) so that I could run software in an isolated environment and easily be able to start again from a clean state if necessary. Following the article on the Gentoo Wiki was helpful, but was not complete.

The first issue is the naming of the hard disk block device. The minimal live CD detects the drive as /dev/hda however, using the driver suggested in the wiki will detect the drive as /dev/sda. This is not a big problem so long as you make sure to use sda in /etc/fstab and in the GRUB configuration. I’m sure there is a reasonable explanation for why this happened, but this was the simplest solution that I could think of.

Now that I have a basic, clean Gentoo install, I make two copies. The first is a backup of the virtual machine without any extra programs installed. This will let me install any program from the state of a brand new Gentoo install. The second, copy is the same as the first, but with the addition of X and XFCE, so I can play with graphical programs without compiling X every time. Virtualbox supports creating snapshots of the virtual machine hard drive, so I can revert the machine to the last state before the software I’m testing was installed.

Now that everything is working, it’s time to start testing. First up will be XFCE 4.6.

While on Christmas break, I purchased a few things to get started on the stock clock project. First was the Explorer 16 development board, which is the same one that I used while an a co-op (internship). I bought this particular one since I was already familiar with its features and the processors that came with it (a PIC24 and a dsPIC33). To save on costs, I bought the In Circuit Debugger from ebay (a Microchip one, not a clone) for about half the cost of a new one. After playing with it for several hours, I could not get it to work. Reading through the Microchip fourms brought something to my attention. The old ICD2 modules do not work in Vista x64 but the newer ones do. This left me with a problem, as I no longer have a 32-bit install of Windows. I’m not willing to change my Vista install on my desktop, so this left me with a few options. I could install Windows 2000 on an old computer, but I would rather not have to boot another computer every time I want to work on this project. It then hit me that maybe Virtualbox could forward the USB connected ICD2. So my current setup is running Windows 2000 with the Microchip software as a Virtualbox guest with a Gentoo host. This also has the added bonus of not making me reboot into Windows Vista on my desktop (dual boot Gentoo and Vista. Vista is used for games.). I’ve only done some minor testing, but I have gotten MPLAB to talk to the board without any additional issues. Depending on how much free time I have, I should actually make some progress on the stock clock in the coming months.

A few weeks ago I installed DenyHosts, a small deamon (can also be run as a cron job) that runs on my server to block IP’s that make brute force SSH login attempts. The script has worked great, blocking over 500 hosts on the first day I used it (including myself a few times…). One of the features of the script is the ability to send an email each time it blocks a host. Although getting a few hundred emails at first was very annoying, setting up a few rules in gmail prevented me seeing them in my inbox (they go directly to a folder). I did, however, start to look at the times when the various hosts get denyed. They seem to come in large groups, so that there will be 50 or so hosts blocked in a rather short length of time, around 10 minutes or less. The IP’s of the computers also come from all over the world, but most seem to come from Asia, South America, and Russia. I think it would be interesting to do a more complete statistical analysis of the data in regards to the time and location of where the login attempts are coming from. Maybe I’ll write something to do this later.

A project that a friend of mine wants to complete is to build a small clock type device that can connect to the internet and show something like +/- 10% for the stock market (or a specific stock). The preliminary concept involves 2 physical devices and a program on the computer. The program on the computer will obatin the information on the stock performance from the internet, and format it into a percentage to be sent to the actual clock. The program will send the data to the first device, which will take the data from the program and send it wirelessly to the stock clock via a ZigBee controller. The second device, which is the clock itself, will then recieve the data and adjust the clock accordingly. The plan for the clock is to use a PIC microcontrollor to take the data from the ZigBee reciever and use the information to determine how to move the clock. The look we are going for is an analog needle type clock, so a stepper motor will be used to control the position of the needle.

Since we have just started working on this, not all the details have been worked out. My friend will be writing the computer software and the ZigBee transmitter; I will be building and programming the clock itself.

The choice of using ZigBee is to evetually allow multiple stock clocks to recieve data from the computer without needing to dramatically increase the complexity of the network. Plus, its a good excuse to use the ZigBee controllors that we already have.

I just purchased one of the PIC development kits that I have used before at a previous job, so once that comes in next week, I will be able to get started programming the microcontroller. I will eventually design a PCB and have one built for the final device. Updates will be posted once work actually starts.

As part of a Robotics class I took as a professional elective, I designed and built two robots with the intent of having them interact with each other. My original idea was to have them play a hide and seek type game, where one robot would chase the other, while both of them would avoid hitting objects in the room. This idea was overly ambitious considering the amount of time I had to complete the project, so during the construction, I modified the design goals of the robots. In the end, I built two robots named Oedipus and Tiresias both based on a small 4 wheel drive platform used in one of the basic labs done in class. I fitted both robots with 2 proximity sensors to allow them to wander the room without bumping into objects. Tiresias, in addition to the proximity sensors, was fitted with 4 IR LEDs. These LEDs would be a beacon for Oedipus to see with a detection circuit, and thus take action. Oedipus was programmed to turn away from the direction that Tiresias was detected. If the other robot is not detected, Oedipus will wander the room in the same manner that Tiresias does.

The core of the robots is a OOPic controller, the OOPic-R board with the B.2.2+ controller worked well for this project. Its certainly not the fastest or most powerful board or processor, but provided the basic functionality I needed. This board has 4 ADC ports and 16 digital I/O ports and provides a regulated 5V supply to sensors or any other peripherals. The compiler for the chip uses its own custom syntax for many things, but also allows BASIC and C syntax for the code. The custom commands make setting up some sensors quite easy. On these robots, each wheel has its own servo, and the servo commands that are part of this compiler made it relatively easy to control them.

The obstacle avoidance used in each robot is quite simple. Each robot has two Sharp GP2D12 infrared rangefinders mounted on the lower platform on the front of each robot. They are angled out from the center of the robot by about 30 degrees so that an object that would clip the side of the robot will be detected. When an object is detected within the range specified by the code (in this case, about 40cm) the robot will turn away from the object until there is no longer an obstruction. The proximity sensors themselves are analog and will output a voltage that is very nearly linear to the real distance of the object detected. The sensors are connected to the first two ADC ports on the OOPic board. In the code, the voltage read by the ADC is compared to a predetermined value that I found through testing the sensors. These sensors were very easy to use and seemed to be quite reliable in the testing that I did on my robots. They did not fail to detect an object even under bright fluorescent lighting, but I’m sure one could find a situation where they may not be ideal. The only time I could cause the sensors to fail was to put something about 5cm in front of the sensor in which case they would fail to see it, but due to the rather slow movement of the robot, it is very unlikely that something could get that close before the robot could react.

Perhaps the most important part of the robot was the infrared detection of the other robot. The circuit to do so is rather simple and consists of just a comparator connected to the photo transistor, a voltage divider, and an output LED to provide visual confirmation that it is working.

Infrared Detector Schematic

The IR LED is shown on the schematic for reference. To demonstrate the capabilities of the robots, I took two short videos of them in the lab. The LM339 comparator chip used is a quad package. I used three of the comparators to allow Oedipus to sense from the left, right, and behind. I could not get the fourth to work and I was not able to determine why. Tiresias had 4 of the IR LEDs in it with the 470 ohm current limiting resistors on each LED. I could have run all four of the LEDs in series and used a single resistor, but I did not think of that until after I started building the board.

The only issues I had in getting the robots to work properly, besides my own inability to build a perfboard right the first time, is that the phototransistors could detect the IR LEDs from behind and on the side as well as in front of them where I wanted. This meant that when the IR LED was supposed to trigger the right detector, the left would also trigger due to IR light going into the bottom of the left phototransistor. To solve this, I put a small piece of electrical tape to cover the side and bottom of the phototransistors which solved the issue. The robots work to my expectations, but there is certainly more that could be done with them. First of all, only one robot is able to detect the other. One robot wanders around the room without any knowledge that there is another robot involved. I would like to put detectors on both robots, and have one actively chase the other. In its current state, on robot runs away from the other, but no attempt is made to make chase. Since this project has already been completed for a grade, I doubt I will continue working on it. Below is a zip file with the code used for the OOPic controller and an EAGLE schematic of the controller board.

robotics_project.zip These files are released under GPL version 3 as specified in the COPYING file contained within.