Now, if I could only get that retard to read this.

About the best analogy I could come up with, would be asking a cook what are the specific ingredients for a sponge cake they haven’t made in 6 months when all they have been making recently, is main course.  Both involve cooking; either they can cook or they can’t, so asking them details about the the more recent items will let you know whether they are up to making a sponge cake (after all, configuring Apache+Tomcat is not difficult is it?).

I absolutely love the way the SRC system integrates into the helmet.  Yes, it adds a bit of weight, but it is barely noticeable, and the convenience far out ways the minimal weight increase.  The only real issue I have had with the installation is that the flip lid requires a bit more effort to close than it does without the SRC system installed.  Maybe this will get easier with use.

Although I have not been able to test the rider communication, I have been able to test the bluetooth integration with my mobile phone and TomTom GPS unit, as well as the radio.

I have to say, the radio reception has been really poor.  I live in Berkshire and ride to London most days.  Outside of London I have hardly been able to receive a signal of any quality.  The radio constantly crackles and the signal fades in and out -- so much so, that I have elected to void the warranty and take the system apart to see if there was anything I could do to improve the reception myself (video after the break).  I have soldered a wire onto the thick metal strip that runs around the back of the helmet and will let you know how I get on.  I would be interested to know if I had a faulty unit or whether or the SRC systems are this bad.

Turn the volume up for this one:

www.youtube.com/watch?v=qzdOTF5trCA

Four months later, in late March, I picked up my Thunderbird from Bulldog Triumph, in Twyford.  The time had finally arrived to find out whether that extra 100cc would make its presence known.  I had already told the shop that if I wasn’t happy with this one, I would be back for a Rocket III Roadster.

After nearly 1200 miles and six weeks of use, I have to say, the big bore kit makes a huge difference.

With the 1600, you feel compelled to change up through the gears quickly and at relatively low revs, whilst the 1700 is quite happy to linger in gears and feels content to use the full range of the available revs.

The graph to the left shows the difference in power delivery.  The 1600 reaches peak torque around 2700 rpm and then slowly drops off whilst the 1700 reaches peak torque a little later – at around 3000 rpm – dips a little and then hangs on to the power until around 3500 rpm.  Whilst this shows the 1700 has more power, I think the following describes how and why the 1700 feels more comfortable to linger in gears.  The 1700 exceeds the 1600′s peak torque sooner, at around 2400 rpm, and continues to exceed the 1600′s peak torque until around 4000 rpm.

For me, Triumph are onto a winner with the 1700 and my local dealer will be sorry to hear that I won’t be getting a Rocket III Roadster any time soon.  The 1700 is for keeps!

The only reason I sold the bike is because Triumph are releasing a special edition of the Thunderbird with a factory fitted big bore kit taking it up to 1700cc.  They are also releasing two new colours; Phantom Red Haze and Phantom Blue Haze.  I have already put my name down for one of the limited SE’s in Phantom Red, so watch this spac

Comparison of Aftermarket Handlebars

◄ Back

Next ►

Picture 1 of 5

The stock handlebars and mirrors are on the left.

As I could reach – and turn – the top of the engine sprocket, I tried to feed the chain in from the top, which wasn’t very successful because I couldn’t get any access to the lower part of the sprocket.  I then decided that if I could feed the chain in from the lower part it would be easier to pull the chain around by spinning the top of the front sprocket.  This worked a treat.  I used a thin, curved, metal bar from a Triumph America screen as a support for the chain.  By placing the chain on the metal bar and feeding them both under the swing arm until the chain pushed up against the sprocket I was able to hook the chain onto the sprocket after only four or five attempts of spinning the top of the sprocket with my hand.  Once the chain was sufficiently far enough around the top of the sprocket I was able to start pulling it through with ease.

Choosing the Alix system: After getting fed up with the car I wanted to install a similar camera system onto my motorbike. Rather than doing something practical and spending lots of money on a bespoke system, I decided to use my experience from the CarCam project to build a system for the bike. Being short of space, I needed the smallest system I could find, with hardware encoding, USB support and run on 12V. Needless to say, I couldn’t find anything that fitted this requirement.  How ever, I did find a supplier of MPEG2 Mini PCI cards which meant I only needed to find a small system board that accepted Mini PCI.

Development: It’s been over a year since I started working on this project.  I have sold one system to a friend who has been using it to record his off-road exploits (as well as his commutes).  During this time, I have refined the code to a stable release and optimised the time it takes to start recording from power on to around 25 seconds (from around a minute in the early code).  The system is based on Slackware 13.0 with a heavily customised 2.6.30 kernel and environment.  I am using aufs2 to mount over “/etc” and “/var” to prevent the Compact Flash card from being prematurely destroyed by OS writes.  The handling of inserted/ejected media, as well as media errors, is done via syslog-ng which calls helper scripts when the appropriate kernel messages are generated.  Other scripts are called from cron to check that the recording doesn’t exceed the 4GB file size limit of the FAT32 file system and that the USB device doesn’t fill up.

Video Quality: The output video needs some deinterlacing, but the overall quality is very good.

www.youtube.com/watch?v=eXbcwII4biY

Linux Image: After much toil, I decided that the best way to offer the Linux image was through a Windows utility as most people will have access to a Windows system, even if they don’t run Windows themselves.  After further toil, I decided to use R-Tools Technologies R Drive Image to create the image.  It was a lightweight install without the need to boot from a CDROM or USB device to do its work.  A 15 day evaluation copy of their software can be downloaded here and the latest Alix Linux image can be downloaded from here.

Hardware Required: Obviously an Alix 3d2/3d3 system.  I would recommend the 3d2 as the older 3d3′s have a buggy BIOS (BIOS updates that fix the problem can be downloaded from here).  Not only that, the 3d2 is cheaper and the onboard sound and graphics of the 3d3 are not required.

And the MPC622 hardware MPEG2 encoder.

Writing the Linux Image to Compact Flash: Download the Alix Linux image and install R Drive Image.   Once R Drive Image is installed, you can double click on the “BikeCam.arc” file to begin the installation process.  The original CF device was 2GB as that was the smallest I had.  R Drive Image will allow you to install this on larger devices but not smaller.  I can’t really see this being a problem as most companies only stock 2GB CF cards or larger.  The process is straight forward apart from one little gotcha.  When selecting the source and the destination, you must click on the square boxes to the left of the listbox (see image below).  This instructs R Drive Image to include the whole image and not just a partition.

Once the source and destination have been selected the “Next” button will become available.  At the time of writing this, the next page should be left default.  When I experimented with “Expand/shrink partition to the whole disk”, this had no effect.

Once complete, you can insert the CF card into your Alix board and begin recording.

Function: The system uses the three LED lights to provide feedback on how it is functioning.

• LED #1 is used to indicate the power status.
• LED #2 is used to indicate that the inserted external media has been mounted.
• LED #3 is used to indicate that the system is recording from the video device to the external media.

The system will detect media insertion and removal.  If necessary, the inserted media will be repartitioned and formatted as FAT32.  Also, the inserted media will be repartitioned and formatted if it detects that the largest partition on the external storage is not within 95% (or so) of the total capacity of the external device.  I would recommend at least an 8GB, performance, USB Flash drive for recording, though any external media is acceptable.

Useful Links:

PC Engines Homepage (manufacturers of the Alix motherboards)

Twam’s homepage & weblog (useful information on the Alix system)

Picco Computers (MPC622 hardware encoder)

Zercom (MPC622 hardware encoder)

I have seen people approach this various ways, and here is mine. It requires a database to keep a history of scans; I have used MySQL but any database should be fine.
The script will work under Linux and FreeBSD. Although configured to use Shorewall under Linux it would be trivial to replace the Shorewall commands with a line similar to “iptables -I INPUT -s -j DROP”.

Firstly, create a custom destination that points to our external script to process the reports from the SSH daemon:

destination ssh_scan { program(“/root/bin/sshscan”); };

Then create a filter to match the SSH daemon reporting an “Invalid User”:

filter f_ssh_scan   { program(“sshd.*”) and match(“Invalid user”); };

We can then create a log rule that passes any line that matches our filter to our script for processing:

log { source(s_sys); filter(f_ssh_scan); destination(ssh_scan); };

The contents of the script are as follows (including the code to create the MySQL database):

#!/usr/bin/perl

use strict;
use warnings;

use POSIX qw(uname);
use DBI();

$| = 1;

my $dbh;
my $scans;

my($uname_s, $uname_r) = (POSIX::uname())[0,2];

sub _db_connect
{
  $dbh   = DBI->connect("DBI:mysql:database","username","password") or die "Completely fucked";
  $scans = $dbh->prepare("SELECT COUNT(*) FROM sshd WHERE ip=? AND time > (now() - 1000)");
}

#CREATE TABLE `sshd` (
#  `time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
#  `username` varchar(20) NOT NULL DEFAULT '',
#  `ip` varchar(16) NOT NULL DEFAULT '',
#  KEY `time` (`time`)
#) ENGINE=MyISAM DEFAULT CHARSET=latin1;

#
# Open the connection to the database
#
_db_connect();

open LOG, ">>/var/tmp/sshcan.log";

while()
{
  print LOG $_;

  chomp;

  if ( /[Invalid|Illegal] user (\S+) from (\d+\.\d+\.\d+\.\d+)/ )
  {
    my($name,$ip) = ($1,$2);

    _db_connect();

    if ( $dbh )
    {
      $dbh->do("INSERT INTO sshd (username,ip) VALUES ('$name','$ip')") or die "Failed to update database";

      $scans->execute($ip);
      if ( $scans->rows() )
      {
        my @cc = $scans->fetchrow_array();

        if ( $cc[0] >= 5 )
        {
          print LOG "dropping $ip\n";

          if ( $uname_s eq "FreeBSD" )
          {
            # Spoilt for choice here...

            #system("/sbin/ipfw -q add drop ip from $ip to any");
            # Delete a rule
            #open OUT, "|/sbin/ipf -rf -";
            # Add a rule
            open OUT, "|/sbin/ipf -f - 2>/dev/null";
            print OUT "block in quick on em0 from $ip/32 to any";
            close OUT;
            #system("/sbin/route add -host $ip 127.0.0.1 -blackhole > /dev/null 2>&1");
          }
          elsif ( $uname_s eq "Linux" )
          {
            system("/sbin/shorewall nolock drop $ip > /dev/null");
            system("/sbin/shorewall nolock save > /dev/null");
          }
        }
      }
      $scans->finish();
      $dbh->disconnect() if ($dbh);
    }
    else
    {
      print LOG "$DBI::err\n$DBI::errstr\n$DBI::state";
    }
  }
}
close(LOG);

# Exit zero so's we get called again
exit (0);

The main reasons for deciding to build my own circuit were as follows:

• Off-the-shelf LED bulbs are not efficient at putting the light where you want it -- and because of this, are often not as bright as filament bulbs.
• My bike was blowing bulbs quicker than I was able to buy replacements.
• I wanted to incorporate a flashing brake light circuit
• I fancied doing something different

The initial design included two 12v regulators and two polarity protective diodes; one for each of the stop and  tail light circuits.

When fitted to the bike, I found that the voltage drop across the regulators and various diodes was too much and the LEDs were not bright enough.  I removed the voltage regulators from the circuit and this solved the problem -- thought the LEDs were still not as bright as during testing.  This was my fault as I only had an 18v source when testing.

Videos of the original breadboard test circuit:

www.youtube.com/watch?v=nVaoPf5UH2k

www.youtube.com/watch?v=olOTQJe5ZAo

I only have pictures of the installed circuit on the bike -- no video.  Since installation, whatever was killing the bulbs seems to have affected the brake flasher circuit and, although it still works, it no longer works the way it should.

Update: I replaced a capacitor on the circuit board and it is now working -- shame about the rest of the bike

www.youtube.com/watch?v=9CyHkxGUnw4

I am sorry there is no circuit diagram or more in depth detail about the circuitry.  I didn’t keep the circuit diagrams as I was using unregistered software which wouldn’t let me save the diagrams.  I am planning a version 2 of this circuit that will be based on 9v instead of 12v so that voltage drop shouldn’t be a problem (if anyone reads this, can you please recommend a decent circuit diagram package).

The exhausts took a little over a week from order, to be custom made, and to eventually arrive at the door.

I was a little disappointed with some aspects of the exhausts; One of the baffles was dented to the one side, the pipework were of different lengths and – this is a little picky as I am happy with the finish – but the stainless pipework does not look as polished as the website pictures:

Having read various reviews of people fitting Trident exhausts to other Triumph models, I had anticipated that installation was likely to be tricky.  I was not disappointed.  The first thing I noticed straight away, was that the standard fittings for the cans were not going to work.

The cans were touching the bodywork and frame and no amount of effort was going to make them align correctly.

Fortunately, I had some spacers lying around and these were able to shift the top of the can braces far enough out for the exhausts to sit vertically.  The photos below only show one spacer fitted, but I ended up using two.

Great, I can move on to fitting and finishing the installation.  Alas, not so simple, as this is where I hit my next hurdle.  The cans only came with one slit below the clamp for them to attach to the pipework.  When trying to clamp the cans to the pipework, I couldn’t get the clamp to tighten up and grip the pipework.  I took the cans off and examined the cans and discovered that the single slit was not working.  When I had tightened the clamps, the metalwork had deformed on one side rather than compressing evenly all the way around.

Well, this one was easily solved – though I don’t understand why this wasn’t done by Trident, surely they have made enough exhausts for them to realise this was an issue?  I broke out the Dremel and cut more slits into the cans where the clamps would tighten against the pipework.

With that done, it was really time to complete the installation.  The spacers kept the cans away from the bodywork and allowed them to sit vertically, the slits cut into the back of the cans allowed them to grip tightly against the pipework and it was only 45 minutes or so before the bike was ready to roll.

I have to say, I am extremely pleased with the sound.  I don’t think I will be removing the baffles, but it is nice to know that I can.

With the America and the Thunderbird side by side, the big 1600cc looks quite small in comparison.  This is not just an illusion;  The seat height of the Thunderbird is around an inch lower, whilst the height and length of the Thunderbird are reduced by 2 inches and 3 inches, respectively.  Even the larger, 22 litre, fuel tank looks smaller than the 19.2 litre tank on the America.

After a short test ride I was impressed with the handling.  Even though the Thunderbird boasts a large 200/70 rear tyre, the bike leaned into the corners with ease.  The front brakes were sharp and responsive and  the forks didn’t dive when braking (like they do with the stock springs on the America).  Gear changes were smooth – something unique to a Triumph.  The engine seems happiest at low RPMs with peak torque arriving around 3,000 rpm.  For anyone expecting a lot of excitement when opening the throttle, I would steer them towards the Rocket III.  This bike is quite sluggish given the huge 1600cc capacity.

The big dissappointment for me was the sound from the stock exhausts and I eagerly awaited the dealer putting on the Triumph after market pipes.

With the after market exhausts the Thunderbird is more expressive but with more of a rasp than the bark of the America.  This is a real shame.  I want bark, and if Triumph want to win any Harley owners over, they will need to provide it.  I have been informed that the rasp could be due to the catalytic convertor as a similar problem was found with the Rocket III’s.