All day I’ve been trying to figure out why I’m getting double requests when I load certain pages on my Apache2 web server. I noticed it only seemed to happen in Firefox. I saw several posts about FireBug causing this so I disabled it. Still happened. I also saw posts about the placement of character set meta tags and images with not source. This could not be the problem because the second request would it the webserver 300ms after the first and before the first request returned any html.

Then I noticed that refreshing the page did not cause the double requests. It was only when I click a link to the page. All the links to the page used a button inside an anchor tag.


<a href="/someurl/"><button>Click Here</button></a>


When I changed the link to a javascript button the problem when away.


<button onclick="location='/someurl/';">Status</button>


This sort of explains how to connect a BluePort-XP bluetooth serial port to an Linux (Ubuntu) computer.

First pair your BluePort-XP with your computer. This was tricky, because the bluetooth wizard would not prompt for a pass code. It would just pick a random one. Using various combinations of the following commands I was table to get a pass code prompt so that I could enter the default code of the BluePort, ‘1234′. Sorry, I don’t know what actually made it work. At some point I just noticed a pacc code prompt.


hcitool scan
sudo hcitool cc XX:XX:XX:XX:XX:XX
sudo hcitool auth XX:XX:XX:XX:XX:XX
hciconfig
hciconfig noauth
hciconfig hci0 noauth


hcitool scan will give you the address of your BluePort as well as everybody’s cell phone in the office. This address should be used for the other commands.

Once you have the BluePort paired with you system you will need to setup a serial port.


sdptool browse XX:XX:XX:XX:XX:XX

sdptool browse should list all the services provided by a device and tell you the channel number needed for the last parameter of rfcomm. My BluePort does not respond to this command so I just used ‘1′ and it worked.


rfcomm connect 0 XX:XX:XX:XX:XX:XX 1
Connected /dev/rfcomm0 to XX:XX:XX:XX:XX:XX on channel 1
Press CTRL-C for hangup


If you don’t get an error you should now have a serial port on /dev/rfcomm0. Use your favorite terminal program to test it out.

If that works then you can edit /etc/bluetooth/rfcomm.conf so that all this will start up automatically.

Like most things setting up an SVN server on Mac OS X is not hard if you know how to do it. I spent the better part of two days trying various howtos before I got just the right combination. Please understand that 2 months ago was the first time I’ve used a Mac since my Mac 128 is the 80’s.

There are several choices for setting up an SVN server. First, if your client has access to the file system containing the repository you don’t even need a server. For me the file server is remote so this was not an option. Second, you can install the svn apache module. I’m sure this can be done, but I did not choose to go down this road because I had such a hard time getting another module to work on the Mac. Third, you can use the standalone SVN server. This seemed to be the most straight forward way to me.

First either install or update SVN on your server. SVN was already installed on my server but it was old. I used MacPorts to install the new version.

port install subversion

This failed because db46, a dependency, would not compile. I updated MacPorts and all MacPorts installed packages.

Updated MacPorts

port selfupdate

port upgrade outdated

At some point a non-MacPorts install put some db source files in /usr/local. I didn’t know what was using these files so I renamed /usr/local temporarily and then MacPorts was able to install SVN.

Wrote a .plist file and placed it in /Library/LaunchDaemons/. This starts the svn server at boot.


<xmp>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Debug</key>
<false/>
<key>GroupName</key>
<string>daemon</string>
<key>Label</key>
<string>org.tigris.subversion.svnserve</string>
<key>OnDemand</key>
<true/>
<key>Program</key>
<string>/opt/local/bin/svnserve</string>
<key>ProgramArguments</key>
<array>
<string>svnserve</string>
<string>--inetd</string>
<string>--root=/Volumes/TeledrillRaid/SVNRepo</string>
</array>
<key>Sockets</key>
<dict>
<key>Listeners</key>
<array>
<dict>
<key>SockFamily</key>
<string>IPv4</string>
<key>SockServiceName</key>
<string>svn</string>
<key>SockType</key>
<string>stream</string>
</dict>
<dict>
<key>SockFamily</key>
<string>IPv6</string>
<key>SockServiceName</key>
<string>svn</string>
<key>SockType</key>
<string>stream</string>
</dict>
</array>
</dict>
<key>Umask</key>
<integer>2</integer>
<key>UserName</key>
<string>daemon</string>
<key>inetdCompatibility</key>
<dict>
<key>Wait</key>
<false/>
</dict>
</dict>
</plist>

</xmp>


I used the user/group “daemon”. It would probably be best to create an svn account and use that, but I did not do this. You need to make sure the path to svnserve is correct and set the path to where you want your repository.

Load the .plist file

sudo launchctl load /Library/LaunchDaemons/org.tigris.subversion.plist

Check that is it running

sudo lsof -i | grep svn

Note: svnserve can be stopped with

sudo launchctl unload /Library/LaunchDaemons/org.tigris.subversion.plist

Created a repository.

svnadmin create /path/to/svnrepo

By default your repository will not allow remote anonymous access. You will need to edit yoursvnrepo/conf/svn.conf to either allow anonymous access or setup a password file. See the svn manual.
Edited /Volumes/TeleDrillRaid/TeleDrillSVN/svn.conf to allow anonimous access.

I’ve tried several svn clients on the Mac.

scplugin This is an open-source finder plugin much like TortiosSVN on Windows but the icon tagging does not work very well.

svnX This open-source client works but only has basic features and is a little hard to use.

Syncro SVN, $59 per seat, is the most full featured client I’ve seen for the Mac, but could be hard to use.

Versions is about $50 per seat and is clean, easy to use.

This year for Christmas I gave my two boys, and let’s face it myself, a new Wii console. It was an instant hit. However, we were a little frustrated by how hard it was to work the menus. The games seemed to work ok, but it was very hard to “find” the pointer and select menu options. When my brother-in-law came over he confirmed that something was not right. He thought it was a bad controller.

I read the manual and found the sensitivity settings. It said I should adjust the sensitivity until I only saw two white lights on the screen. No mater what setting I used I only saw one. After I slept on it I knew what this must mean. One side of the sensor bar must be out. At least that is what I suspected.

A little background before I explain the problem and solution. The name sensor bar is misleading. The bar senses nothing. It is simply two sets of infrared LEDs. The Wii controllers have a camera on the front that can see these two lights. The Wii uses the images to determine where the controller is in 3D space.

I suspected one side of the sensor bar was not lighting up, but I needed to prove it was actually the sensor bar and not something wrong with the Wii. I noticed that one side of the sensor bar was warm and one was cold. Was the bad side cold because it was not on or was it hot because something was wrong. I remembered that most video cameras can see infrared light. If you point your TV remote at a video camera you can usually see it. I got out my video camera and sure enough the cold side was not lighting up.

I called GameStop where I purchased the unit and asked if I could trade out sensor bars. They were unwilling to help. They had sensor bars but they would not trade them out. They would only replace the whole console and they were out of stock. They also said I could sell them my broken bar to them for $4.52 and then buy a new bar for $20. Totally silly!

Since I needed a working bar for a party that night I figured I would tear into it myself and try to fix it. Since GameStop would buy broken bars I figured I couldn’t break it more than it already was.

Nintendo uses tiny triangle head screw which is a pain, but a small standard driver works ok. Nintendo also uses that age old trick of putting stickers over some screws. There is a screw under each double sick pad on each end of the bar.

I figured it was just a loose wire so once the bar was open I wiggled everything while looking through the video camera. The LEDs flickered on a couple of times, but nothing reproducible.

Next, I used a volt meter to measure the working side compared to the broken side. The bar is supplied with a little over 8 volts. Each side of the bar has 5 IR LEDs in series with a resistor. The two sides are in parallel. On the working side there was a 1.2 volt drop across each of the 5 LEDs and about 2 volts across the resistor. On the broken side there was a 5 volt drop across the first LED, less than one volt across each of the rest and no drop across the resistor. No drop across the resistor means no current. No current is bad.

Once possibility was a cold solder joint. I re-flowed all the solder on the broken side, but that didn’t help. Next I started shorting across each LED. When I shorted across the LED with the 5 volt drop the other LEDs came on. So, the problem was a bad LED.

Since I didn’t have an IR LED handy and I didn’t have time to go to Radio Shack I decided to just short across it permanently. There are 4 other LEDs on that side so it shouldn’t make much of a difference.

When I buttoned everything back up the system worked much better. No more problems with menus. As it turned out we never even turn it on for the party.