I upgraded a virtual server from x86 to x86.64 and found that I needed to recompile the Ruby bindings for the St. George Internet Payment Gateway library. I have only a vague recollection of how I did this once before, many years ago.

Download the Linux API. Install swig.

cd webpaySWIG-3.3/swig/
swig -ruby webpay.i
cat > extconf.rb << EOF
require 'mkmf'
create_makefile('webpay')
EOF
ruby extconf.rb
make
make install # (even better: just copy webpay.so to your application's directory)

Now, install the shared library. I tried but failed to get this working from the application’s directory (probably due to library search paths). It was quicker to just stick it in /usr/lib/.

cp ../libwebpayclient.1.17.so.x86_64 /usr/lib/
cd /usr/lib
ln -s libwebpayclient.1.17.so.x86_64 libwebpayclient.so
ldconfig

The TextMate project view gets a bit cluttered with LaTeX intermediate files. Here’s an easy way to hide them:

Preferences -> Advanced -> Folder References -> File Pattern

I added the extensions highlighted in bold.

!(/\.(?!htaccess)[^/]*|\.(tmproj|o|pyc)|/Icon\r|/svn-commit(\.[2-9])?\.tmp|\.aux|\.bbl|\.synctex\.gz|\.blg|\.fdb_latexmk)$

Ignore that last post!

I have now forked s3cmd on GitHub and have hacked in a proper bandwidth limiting system for uploads.

Edit: it uses timedelta’s total_seconds() method, which isn’t present in Python versions before 2.7. I should fix it to use the crummier, manual method.

Edit 2: I’ve now done this.

I use s3cmd to automatically back up files to Amazon S3. Recently I’ve noticed that it is flooding my upload bandwidth and making my VPS unusably slow because it doesn’t implement any bandwidth limiting options.

I haven’t been bothered to implement a complete rate limiting system, but there is one easy hack based on the built-in throttling system. Normally this only kicks in when a transfer fails, but you can hard-code a value in by modifying S3/S3.py:

def send_file(self, request, file, labels, throttle = 0, retries = _max_retries, offset = 0, chunk_size = -1):

I set throttle to 0.1 and upload speed seems to have settled at about 39 KB/s, which is perfectly acceptable for a background transfer of a big file that I’m in no particular hurry to upload.

It should be very easy to make a proper limiting. I had a look how wget implements this - essentially, it calculates the amount of time it would take to download a chunk at the specified speed, and sleeps to make up the difference.

I’ve entered the 21st century and replaced the hard drive in my late 2009 27” iMac with a 240GB OCZ Vertex 3 SSD. Changing the drive took about twenty minutes. Trying to get all of the dust out of the iMac’s screen took about an hour and a half and ultimately failed. In the end, it didn’t really matter - I can’t see them during normal operation!

Bootup when reopening all windows is very snappy (after a crash while I was in the middle of some work, this was what annoyed me enough to invest in an SSD) but during normal operation I haven’t noticed any huge benefits - perhaps I’m not doing enough real work :(

The other problem I had was that my Parallels Windows 7 virtual machine began blue screening and wouldn’t boot at all. In the end I had to reinstall it and my applications from scratch.

I’ve made some adjustments to my ADRF6850 PLL parameter spreadsheet, after some poor datasheet reading caused me to miscalculate a CR10 value. The spreadsheet now calculates the correct CR10 (Reference Frequency Control) value.

I’ve only got a working version for Apple Numbers - I tried opening it in Excel earlier and it didn’t work, but didn’t bother figuring out why. If anyone is actually interested, I’d be happy to fix it.

It took quite a lot of pain, but I’ve managed to get all four RF chips initialising! There were several problems, or perhaps only two. The four chips each have their own linear regulator, the MCP1725, but this was outputting a very low voltage. The four regulators have a shared shutdown control signal, which seemed to be floating at 1.1 V, and the PIC controlling the shutdown signal either didn’t have the drive strength to control it or couldn’t due to a soldering problem that I couldn’t spot. Solution? Set the PIC pin as an input and tie the control signal high.

One of the regulators was bad, cycling on and off at about 2 Hz, so I replaced it, which fixed it.

One of the RF chips might have been bad, but now I can’t be sure if the problem was with it or the bad regulator all along. I’ve put it aside and will try it on my next board.

All in all, a frustrating few days! Now I can get on with some quick and simple RF tests (which will also let me check the channel synchronisation, which I suspect I’ll need to correct for later), and then test the ADC.

I foolishly used a PIC18F24K22 on my receiver board, possibly because it has a good compromise of large flash size, two MSSP controllers, low price, and availability from element14. It turns out my PICkit 2 can only program and not debug with this part. I spent a good few hours stuck on a problem with getting SPI to work, so I broke down and ordered a PICkit 3 for just under $50, which arrived the following morning.

It turned out that the SPI problem was a very stupid typo that I fixed in the meantime - I was setting SSPXCON1 to 0b0010000, which is most definitely not eight bits, so the ‘enable SPI’ flag was not being set at all.

Anyway, PICkit 3 is well supported by MPLAB X, which runs on Mac OS X! I installed it and after a bit of fiddling around (the MPLAB X download page gives you older versions of HI-TECH C that don’t support the PIC18F24K22), was up and running. First impressions are that it is loads better than the old MPLAB. The editor sucks a whole lot less and has SCM support. Best of all, I don’t need to run Windows XP in VMWare any longer (PICkit 2 didn’t work well with Parallels).