I have always been a bit blasé about thunderstorms.  It is not my fault!  I grew up in an area prone to them and as such have become desensitised to their awesome fury.  I know the dangers are real, I have respect for their power, but at the same time I look forward to the light-show more than fear the possibility of damage and destruction.  A resident of Los Angeles probably feels the same way about minor earth tremors – whereas I would be scared witless by them.
A while back I replaced my aging ADSL modem/router in an attempt to fix drop-outs in service that I was experiencing.  The replacement did not really fare any better and eventually I traced the fault back to an under-spec line filter.  I kept the new modem/router as it had features useful for VOIP, but I was slightly annoyed at myself.
Recently, we experienced a heavy electrical storm.  Remember how I said I was blasé about storms?  Well, when the lightning is so close that there is no distinguishable gap between lightning and thunder, and you here arcing on the power lines, even I tend to duck and utter expletives in shock!  The roly-poly-cat took fright too, and wouldn’t be comforted by someone who was visibly shaken.  It has been my experience that electrical equipment doesn’t get damaged in storms as often as you may believe.  Most equipment just keeps on keeping on!  YMMV!
Of course, this time was different.  The new modem/router lost the Internet connection. I could still “see” the device, it could still report line attenuation and signal to noise ratios, but using it to access the Internet was beyond its post lightning strike capabilities.  So, it was time to drag out the old modem, which was now reserved for “emergency backup duties”.  Sure enough – it worked and so did I. (I had been working from home at the time)
The silver lining to my grey thundercloud turned out to be that the purchase of the newer modem had been necessary after-all. Whilst the new modem had not cured the dropouts until I upgraded the line-filter, the old modem still suffered from them – even with the new line filter.  So, I declared that the new modem was a “worthwhile” (if somewhat short-lived) purchase.  That night, having soldiered on through numerous drop-outs, I decided to have a closer look at the new modem.  It was worth the effort!  It turned out that the lightning strike had simply erased the settings of the new modem.  Having re-established these, I performed my lucky escape!  And everyone lived happily ever after!
Living without surge protectors in an area prone to thunderstoms may seem risky or careless to some people.  I do not know much about high-voltage, but do know that the close proximity of unprotected and protected wires on most “domestic” surge protector boards is likely to be insufficient to prevent arcing between them.  Still, when a horse points at an open gate and says “next time I’m bolting” I pay attention.  I have since bought myself an eight point surge protector, complete with phone line and coaxial cable shielding.  I will let you know, if lightning strikes twice.

Previously I described an engine as having pistons that travel up and down inside a cylinder.  The piston is attached to the engine’s crankshaft via a conrod.  Each piston in a four stroke engine has four distinct phases through which it travels.  For two of these “strokes”, the piston travels downwards. The other two strokes, the piston travels upwards.

	The first downward stroke is referred to as the Intake stroke.  At the top of the cylinder head, there are valves that open and close at different points in time.  The inlet valve (or valves) open during the intake stoke, allowing a fuel and air mixture to enter the cylinder.  Because the piston seals the cylinder when it travels downwards, it creates an area of low pressure above it.  This helps draw the fuel-air mixture in.
	At around the time the piston reaches bottom dead centre (BDC) the inlet valve closes, sealing the gasses in the cylinder. The piston then starts its second stroke: the compression stroke.  The piston travels back up, compressing the fuel-air mixture at the top of the cylinder.  The difference in volume between when the piston is at the bottom of its stroke and the top of its stroke, is commonly referred to as the engine’s compression ratio.
	Compressing a flammable gas in the presence of oxygen is somewhat fraught with problems.  Compressed gas gets hot.  Hot flammable gas can combust!  The octane rating of a fuel denotes how stable it is.  Engines with high compression ratios need high-octane fuel to prevent uncontrolled detonation during the compression stroke.
	Once the piston reaches top dead centre (TDC) the compressed fuel-air mixture is ignited by the spark plug. This causes the gas to ignite and expand rapidly.
	The valves in the cylinder head remain closed at this stage, so the only way the gas can expand is by forcing the piston back down the cylinder. This is referred to as the Power stroke.
	All things going well, by the time the cylinder reaches BDC again, all the gasses have been burnt.
	No further kinetic energy is to be gained from them and they need to be removed from the cylinder, ready for the next cycle. The outlet valve (or valves) open and the now rising piston forces the exhaust gasses out through them. This is known as the exhaust stroke. At the completion of the exhaust stroke, the exhaust valve has closed and we are ready to repeat the entire process.

Two stroke engines work in a similar manner, but combine the intake /power strokes together and the compression / exhaust strokes.  How this is done, is a story for another time.

I have some strong views on code quality.  One of my professional goals is to always attempt to improve my coding with the aim of producing better code.  In this day and age, making software “less broken” is about the most I can hope for.  I cannot foresee a time when written software becomes “perfect” / “bug free”.  Maybe it will – I have learnt: never say never…

Anyway, this is an article akin to playing devil’s advocate.  I am not particularly comfortable with what I suggest below. I have written it purely to get people thinking about the time and effort expended writing software.  As always, I encourage your comments – positive or negative.

One of the odd things about the software industry, is that code “rots”.  This is somewhat strange.  Source code, written in text files does not “degrade”.  Unlike organic reproduction, copying a file leads to a perfect reproduction.  If you kept a copy of code written say twenty years ago, it would still be the same today as it was then.  Things change rapidly in the computing industry.  As a result, it is extremely unlikely that you could use that twenty-year old code on a modern computer.  A different form of “rotting code” exists precisely because the code does change.  Over time, countless little hacks or quirks can be added to an active code base that leads to obfuscation and “unhealthy” code.

The common technique to reducing code-rot is refactoring.  By having comprehensive unit tests, refactoring exercises help keep a code base current and ensure that changes made do not lead to regression bugs.  Working on a well-maintained code-base is a more pleasant experience for a developer.  Well-maintained code is easier to extend and developers have less fear of making mistakes.
“Technical debt” is a term coined by Ward Cunningham and refers to the “price paid” for releasing code for the first time.  He argued that a small debt was useful to incur, as it helped speed up the development process.  It was okay to incur some debt as long as it was “paid back quickly” by refactoring the code.

“The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation…”

Productivity graphs show how progress drops away on poorly maintained projects.  The longer the project runs, the harder it becomes to add features or fix bugs without causing other regressions.  The solution to the problem is to avoid as much technical debt as possible. Following best practices will help achieve this goal.  But is this done at too high a cost?  Following best practices adds extra work and thus does slow down development early in the life-cycle of the project.

Not repaying technical debt will grind a software project to a halt.  If you use an analogy of credtit card debt equating to technical debt, having the software project grind to a halt is the equivalent of declaring bankruptcy.   Obviously, this is not a great outcome, but it is not the end of the world either.

What if your software has run the term of its natural life?  Your software will have been written to meet a specific need.  Maybe that need is no longer there.  Maybe that need is now perfectly met, or the market has been saturated and sales have evaporated.  Maybe every feature that could be added, has been added (including reading mail).    If the project gets “sun-setted” does it really matter how much technical debt is left in the code base?

Not “doing things the best I can” is something I struggle with.  “Doing the best I can” and “doing things well” do not necessarily mean the same thing.  Obviously, the process of software development happens on a linear scale.  Software tends not to be written “the best way” or “the worst way” but rather somewhere in the middle.  If the process your team uses is close enough to “the best way” end of the scale to not be crippled by technical debt, then maybe that is good enough.

Be they two-stroke, four-stroke, diesel or rotary, internal combustion engines all work on the same principle:  Fuel and air can be made to combust.  Doing so causes rapid expansion of the resulting gasses.  This expansion of gasses is “mechanically contained” in a combustion chamber in such a way that the energy from it is used to turn a crankshaft.

Rotary engines are dissimilar enough to require their own discussion, so if these are of interest to you, then I recommend you look elsewhere.  The other types of engines mentioned, all feature a piston attached to the crankshaft via a conrod travelling up and down inside a cylinder.

When the fuel-air mixture is ignited the piston is at the top of its stroke and the gasses expand, forcing the piston down.  This is the “power stroke”.   The distance the piston travels from the top of its stroke to the bottom, is measured and referred to (rather unimaginatively)  as the engine’s “stroke”.  The diameter of the cylinder in which the piston travels is measured and called the “bore” size.

Together, the bore and stroke of an engine are used to define the engine capacity.  The volume of the cylinder , which has the diameter of the bore, and the height of the stroke, gives you the capacity of a single cylinder.  Multiply this figure by the number of cylinders in the engine and you have the total engine capacity.

EXAMPLE:
If a four cylinder engine has a bore of 74mm and a stroke of 58mm…
For those of you who do not remember:
V = π * r ² * height.
The radius is 3.7cm (half the bore) and the height is 5.8cm.
Using the formula, a single cylinder, has a capacity of 249.45 cubic centimetres (cc).
Multiply this by the number of cylinders and you end up with a 997.8cc engine.

As a piston travels up and down inside a cylinder, it must come to a complete stop and change direction.  Arresting and reversing the piston’s momentum takes energy.  The faster the piston is travelling, and the heavier the piston is, the more energy is required.  This energy is supplied by the momentum of the crankshaft.  This means that some of the engine’s output is spent  in changing the velocity of the piston.  For this reason, there tends to be an optimum speed at which the piston travels.  The longer the stroke of an engine, the further the piston travels.  So, in an engine with a long stroke, the piston travels faster at a given crankshaft speed than in an engine with a short stroke.  As a rule of thumb:  the longer the stroke of an engine, the slower the maximum revolutions per minute (RPM).

There is no ideal size for an engine bore or stroke.  A lot depends on what the engine is powering.   Engines that need to move a lot of weight, require more torque.

Torque is a twisting force applied to an object, like a wheel or a crankshaft.   For our purposes, we will consider that torque is measured in pounds-force feet (lbf-ft) meaning the equivalent of a given force, in pounds, acting on the end of a lever of length in feet. … For example, standing with 180 pounds body weight on a lug wrench one foot long yields 180 lbf-ft of torque.

Work is the application of force over a distance. Unfortunately, the units used are the same (pounds times feet) but we write this as ft-lb just to distinguish it. The real difference is that in this case, the “feet” part means feet of movement.

Power is the application of work within a finite time. 550 ft-lb of work in one second is one horsepower.

From this, we can see that torque and power are related.  In fact:

hp = (torque * RPM) / 5250
(Where torque is measured in lbf-ft)

Another rule of thumb is that: engines with a longer stroke produce more torque.  There are other factors that influence power and torque outputs of an engine.  Cubic capacity never goes astray when you need more power and torque…

A motorcycle does not need to shift a vast amount of mass – but tends to be size constrained.  (unless of course, you are prepared to just jam in a big car engine)

More weight conscious sports bikes tend to concentrate on obtaining a high power figure, over obtaining a high torque figure.  Given the formula above, we can see that to produce more power, we either need more torque or more engine revs.  So, sports bikes tend to concentrate on producing power by spinning quickly, which means they end up having a short stroke.

Getting the fuel-air mixture into the combustion chamber also affects power and torque figures of an engine, but that is a story for another time.

Sooner or later, there will be a need to fix bugs in whatever software you work on.  How long it takes to fix a bug tends to be non-deterministic.  Some bugs will be easy to fix, and others not so.  Unfortunately, bug fixes on commercial software are often done the wrong way – under the guise of being done quickly.  The “band-aid fix” is the wrong way of fixing a problem.  The metaphor of the “band-aid fix” extends beyond the software industry, but I.T. has turned it into a real art-form.

At the heart of a lot of band-aid fixes is the notion that you can fix a problem without really knowing what the problem is.  Commercial reality may well prevent a code base from being perfect, but the more band-aids that are applied to the code, the worse the software becomes to work on.

There may be a genuine need to apply a band-aid fix to code.  When there is a real financial loss or damage to customers’ data, expediting a fix is understandable.  Removing this kludged fix should be given a high priority.  It is important to recognise that the band-aid won’t continue to hold a large wound together!  If you do not remove the band-aid and perform proper surgery, the wound will rot.  Once you allow the code to start “rotting”, it becomes difficult to arrest this negative momentum.  It damages the maintainability of the code and encourages other programmers to act irresponsibly too.  It is difficult to put enough emphasis on this point.

Depending on the culture in the workplace, it can be easy to dismiss fixing “less than ideal” code.  Studies have shown how counter-productive poorly maintained code is on development productivity.  I have yet to work with someone in the software industry that would disagree with that thought. Yet barriers are still erected that prevent acting upon it.  There is a vicious circle alive and well in parts of the software industry:

• Code is recognised to be poorly maintained.
• Poorly maintained code is recognised to hinder productivity
• People are too busy to fix old code.

I cannot believe people do not see the irony with this!  Allowing software to get in to this vicious circle is the first mistake.  Programmers need to promote the culture that refactoring is not a luxury, but a necessity.  Allowing some refactoring time on all development work can avoid the problem in the first place.  Digging your software out of the hole created by the vicious circle is altogether a more expensive proposition.  Not refactoring the code at all is even worse!
The idea that refactoring time needs to be allocated with development time appears to imply that you will not be able to push out new features as quickly.  At a superficial level, this is true enough.  Over the lifetime of the code base, this argument would not hold up.  The neater and more maintainable the code base, the quicker it is to perform work on.  In other words, good code is easier to add features to.

The biggest problem I see with a “band-aid” fix is simply that it is not a fix at all!  It cures a symptom in rather the same way that pain-killers can stop broken legs from hurting.  It masks the issue – but it does not mean you’re right to walk home! Masking problems in software, just makes them harder to track down.  Software can be complex enough for one bug to be at the root of several problems. If you only mask the problem, you never know where else the bug will show up

I have an admission to make.  I have been riding motorcycles for over sixteen years and (at a rough guess) around a quarter of a million kilometres.  I have ridden many different bikes and also raced motorcycles at a club level.  My admission is, until the last few days I had never ridden a dirt bike.  Thanks to my brother-in-laws, this is now something I can add to my riding experiences.

Unlike some other road-riders, I was under no false-illusion as to what I would be like on dirt.  Apart from knowing what controls did what, my experience counted for little when it came to riding dirt.  These days I try to avoid taking road bikes on dirt roads.  I have got all the excuses under the sun as to why, such as: A lot of modern bikes have become too “single-purpose” to do dirt roads well / The big wide tyres of a road bike tend to skate around on a dirt surface / It takes ages to clean them afterward.  Basically, I would rather just try and avoid it.

The one warning I continually got about riding dirt bikes was that you just can’t grab the front brakes to stop.  This well may be true, but used correctly, the front brake is very useful.  Maybe some road riders tend to be more boisterous with front brake application than I am, because after some time I became more relaxed with using the front brake.

As for my actual riding on the dirt, I was predictably crap to start off with.  My road-riding bias meant I was unable to comprehend how the long travelling suspension of the bike could handle the deep ruts in the track as well as they could.  I had a couple of low speed “step-offs” when dealing with steep and rutted four-wheel drive tracks (both uphill and down) In retrospect, it was my lack of speed that got me in trouble far more than going too quickly.  I don’t think I have ever had the attitude of being ten foot tall and bullet-proof and going faster in a situation where I didn’t feel in control was the furthest thing from my mind.

I did see noticeable improvement in my riding as the day wore on and finished the day with some descents and a hill climb that I was proud of – whilst still being acutely aware of how remarkably simple they would be to someone with more riding experience.   Despite slowing them down, my riding companions patiently waited for me and offered encouragement.  I would have loved a few more riding tips, but they probably did the right thing by not overloading me with information to try and apply.

My faithful bike for the day was a Suzuki DRZ400 – complete with electric start. (A feature I was quite thankful for!) The torque of the 400 single cylinder meant it would chug along quite happily when I left it in a gear that was too high for the situation.  More accomplished dirt riders may have found some fault with the bike, but to me it seemed just about perfect!

I doubt my single day’s ride has made me a better road rider.  I don’t think I reached any great levels of competence from my day in the saddle, but it was great fun and a real eye-opener for me.  Whilst I am not about to rush out and buy a trail bike for myself, it has gone on that list of things I want to do again some time.  When “some time” arises, hopefully I will have remembered what little skills I have gained and forgotten how stiff and sore my legs were the next couple of days after the ride!

When you work with other people, “office politics” will always be a factor.  I have heard people say that they did not like office politics as if it were something that they could avoid.  I am not talking about the sort of “Office politics” resulting in the metaphorical stabbing of fellow co-workers in the back. It is true that office psychopaths definitely attempt to manipulate co-workers for their own purposes, but a lot of daily interactions can also be seen as a form of “office politics”.

Internal restructuring has seen my role change recently.  I was working on a framework team, providing code (and various other infrastructure) to various teams in my company.  My “customers” were the teams that wrote the applications that sold to the real customers…  That is, the ones that paid money!
Since the restructure, I have been moved onto one of these teams as a senior developer.  Former “customers” are now team-mates.  When I was working on the framework, I had a certain perception of how our code was being used to create the end-product.  Now that I have become exposed to their code base, I have discovered the truth behind how they use the framework code!  The fact that there are differences indicates some degree of a breakdown in communications.  There is nothing catastrophic about what they have done, but it shows a disparity between the directions the framework and end-products were heading.  This difference was due largely to the difference in motivations between the two teams.

The framework was responsible for the core of twelve different applications.  As such, consistency and flexibility in the architecture were highly valuable commodities.  I would not be presumptuous enough to claim that we succeeded in providing the perfect architecture every time, but those were primary goals of the code we wrote.

The end-products have a far more tangible goal: To make money.  I am not in product management, but having developed commercial software for a long time now, “making money” tends to be about writing software that adds features that customers want and alleviates the worst of the bugs that have been reported.  In terms of priority, “adding wanted features” are more important.  Trade shows never focus on showing customers how the software no longer crashes when you do steps X,Y and Z!

In terms of how this affects code in the long-run, there is a natural tendency to leave “good enough” code alone.  Short term deadlines enforce short-term thinking.  Commercial reality allows code to deteriorate in rather the same way that an untended garden becomes an overgrown jungle.  Active pruning and weeding would avoid the problem, if only it were seen as an important goal.
Given that the software still sells and still provides real value to the customers, it can be seen as an unimportant goal.  The fact that new features become difficult to shoe-horn in to the existing code base is seldom given consideration when writing code.  Which brings me back to my original point on office politics.

Now that I am on a new team, I see the “weeds in the garden”.  No individual issue is worthy of much attention, and so the existing team members simply ignore such issues for more important work.  I would highly doubt there is a piece of commercial software being sold that did not have some degree of this occurring in their own code base.  I have worked alongside my new team members for many years.  They know how important code quality is to me and I know that they will expect me to try and improve their code’s overall quality.  Here is where the “office politics” lie.  I could just blunder in and make changes which I believe are for the better.  I have known programmers who would.  Different cultures in different parts of the world would probably react differently to such an “intrusion”.  In Australian culture, this would not go down well and so it will not be the approach I will take!  I’m also someone who is only too painfully aware of their own short-comings as a programmer. So, tact and and a measured approach, remembering one’s own shortcomings will definitely be the order of the day.   See, even in the most ordinary of jobs, “office politics” will play a role!

Having built my “under-seat” tray to hold the CDI and SAPC units, all that was left to do, was to place the battery somewhere.  Part of the problem of owning a track bike, is that it is unlikely to see regular enough usage to keep a standard battery charged.  Standard lead-acid batteries are heavy too.  If you are used to seeing a car battery, motorcycle batteries do look miniature by comparison, but my new tray did not allow room for the standard RGV battery.

The VJ21 and VJ22 model RGVs were fitted with a kick-start system.  Given that there is no electric start on this bike and that is devoid of lights and indicators, the only real function of the battery is to power the CDI and SAPC units and spark plug coils.  Like most engines, an “electrical generator” of sorts uses the spinning of the crankshaft to recharge the battery.

Some racing bikes run a total-loss system.  The charging system causes a drag on the engine.  The more current you try and draw from it, the more the drag and the bigger the performance hit will be on the engine.  A total-loss system will not recharge your battery as the engine runs. By doing so, less load is put on the engine, leaving more power to actually propel the bike.  Unless you are at the elite level of the sport, it is unlikely that having a total-loss electrical system is worth the trouble of recharging the battery after every race.

Given that the generator provides electrical power, the battery becomes superfluous to requirements. The regulator/rectifier and AC generator of the RGV is sufficient to power the electrics of the bike while it is running, and your leg (and kick-start) is enough to provide the initial power to start the bike.  A “battery eliminator” can be built and substituted for the regular battery, saving weight, space and the “oh-no” moment, caused by a battery that has gone flat through lack of use.
Although commercially available “battery eliminators” can be purchased, “Mick” on the currently out of action Yamaha-rd forum  wrote a succinct post on how to build one:

You need;
3 x 4700µF 25V electrolytic capacitors
1 x 500ohm resistor
some solder
a soldering iron
source of power for the soldering iron
cup of tea
decent music

OK, solder all of the components together in parallel; that is +ve terminal to +ve terminal. This is important. The resistor can go in any way round, but they must all be connected in parallel with each other.

Remove the battery from your bike.
Connect the eliminator up the right way round (+ve end to +ve connection on the loom)
Switch the bike on (note: the PVs won’t move until the engine’s running)
Start ‘er up.
Ride the bike, and enjoy the feeling of having lost 2.5kg of ugly fat.

Mick.

How hard could it be?  There was a discrepancy between the commercially available, and Mick’s battery eliminator.  Mick suggested a total of 14100 micro-farads, whilst the Zeeltronic schematic had 30000 micro-farads. (and a different amount of resistance).  From my limited understanding, the capacitance allows a good way to smooth out the voltage provided across the unit, whilst the resistance provides the regulator/rectifier with a workload.  Without this load, the regulator/rectifier would overheat.  (Feel free to correct me here)

I bought the components from Futurlec.  Shortly after I ordered the parts, I read the horror stories from “customer review” websites.  Put simply, they grossly understate shipping times and I am not convinced they ship your order when they claim to.  They also allow normal mail shipping of their products and hence they cannot be tracked on-line.  This further reduced the transparency of their operation.  The parts did arrive after four weeks.  Their website made me believe it should have only taken two…  In days before Internet shopping and on-line tracking of parcels, I would not have thought twice about the length of time it took for my order to arrive.  These days though, it is a different story.

Once I knew how large the capacitors were, I purchased some cabling and a zippy box of sufficient size from the local Dick Smith Electronics shop.  Then all I was missing was the cup of tea and some decent music!

Rather than use a breadboard, I drilled holes in a piece of Perspex to hold the wiring in place and rubber mounted the board inside the zippy-box in an attempt to shield the components from solder loosening vibrations.  Once I had finished construction and fitted it to the bike, I tried to start the bike… At 30,000 micro-farads, I could not generate a spark.  In the end, I removed one of the capacitors (reducing the overall capacitance to 20,000 µF) and had instant success!  (Yay!)

Given that my de-soldering technique is even rougher than my soldering technique, I didn’t bother providing photographs of the final product.
For those of you tempted to try building your own battery eliminator, I have ended up with the following configuration:

• 2 x 10,000 µF 25V electrolytic capacitors
• 1 x 1000ohm resistor (5W)

So now you have three different sets of figures to guess at!  Good luck!

(Edit: Pictures added)

There is nothing like a foreign operating system to remind you how narrow your knowledge of computers may be.  All of my professional computing days and many of my academic ones have been spent on Microsoft platforms.

Although this is not my first foray into the land of Linux, I have recently started some home development projects based on a Linux machine.  My chosen “distro” is Ubuntu Jaunty Jackalope.  I do not have a good reason for not choosing the “Karmic Koala”, I just didn’t.

Having spent many years in GUI land, there was no way known I was going to start with a “server edition” and command prompt!   I remember the basics for navigating around a Unix system, but there is only so much fun you can have changing directories and listing files found in them!  I need as much “hand-holding” as possible, thank you!
I have a number of reasons for choosing Linux over Windows this time around.

1. I wanted to see what a modern Linux system was like.
2. I wanted some experience at using Linux.  (Never say “never”!  It may come in handy!)
3. It was free!  (as in “free beer”)

I have already discovered that “free” as in “free speech” is not always what you will want.  For those of you still in Microsoft land, Ubuntu features a package manager that allows you to install software through a nice GUI.  Simply search a list of applications, choose the one you want and allow the magic to happen!   (Using the power of the Internet to update this list and retrieve the packages)

This is great, but it favours installations that “do not restrict your rights”.  After using Windows and software that features the words “All Rights Reserved”, I don’t really care!  “Free beer” still means more to me than “free speech”.  Well, when it relates to software, at any rate!

I wanted to use the Eclipse IDE on this system, which meant I needed a Java Runtime Environment installed.  The package manager will default to using an Open Source version.  It turns out that this does cause Eclipse to have a few head-aches and it is better to get the “original” from Sun.  This too is possible – it is just not the default behaviour of the package manager.

For those of you contemplating trying Linux, Ubuntu does have a classy offering.  As long as you get to the point of having Internet connectivity, you should not get too stuck!  The biggest thing I have noted is how often you will turn to editing configuration files and using a “terminal window” to perform operations on the system.

The internet appears to have answers to the most commonly asked questions such as, “How do I turn off the annoying system beep?”  .  I am sure earlier versions featured a way to do this from the desktop window, but these days, it is time to modify those configuration files!  Times such as this help remind me that there is nothing like a foreign operating system to remind you how narrow your knowledge of computers may be.  Wish me luck!

As I mentioned earlier,  I recently fired up the RGV for the first time in a long time.  Before starting the bike, I needed to re-fit the various electronic boxes to the wiring harness.  Specifically the SAPC unit, and the CDI unit.  The SAPC unit attaches to the sub-frame of the motorcycle, which meant I had to re-install that as well.

This was the first time I had installed these parts, since installing the rear shock absorber from the GSX-R 600.  Unlike the standard RGV shock-absorber, the remote canister “piggy-backs” on the main body of the shock-absorber.  Although it did not touch the SAPC unit, this canister was in close proximity to the expensive box of electronic trickery. 

It was not hard to imagine that a minor tumble may have flexed the swing-arm sideways enough for the canister to collide and damage the SAPC unit.  Whether or not this sort of incident could occur was irrelevant - I decided it was safest to avoid the problem altogether by relocating the unit.

I am definitely no expert when it comes to fabrication of parts, but I was enthused with the optimism gained by having the right parts and tools for the job.  First effort was to make a cardboard mock-up of the tray.  I decided not to allow too much depth in the tray, as experience has taught me that the rear wheel travels further than would otherwise seem likely.  Careful measuring allowed for a neat fit between the rails of the sub-frame.  Having gone through this process, my only recommendation is you take great care to “flex” your cardboard cut-out as little as possible when lowering in and out of position.  Parts of the final design were influenced by the need to be able to manoeuvre the tray into position without bending it.

The rest of the build process was slow and methodical.  I used 0.6mm galvanised steel sheet – as that is what I had available.  After carefully measuring out the dimensions of the tray, a pair of tin-snips cut it to approximately the right shape, and then a bench grinder and hand-file finished off the shaping.

Folding the sheet was done by hand, holding the plate in the vice, with bits of timber to add support to either side of the fold line.   Somehow, I managed to avoid any silly mistakes caused by folding the sheet the wrong way!

Another rectangular sheet was riveted to the tray, and folded in position to form the “back piece” of the tray.  This then bolts to the sub-frame where the pillion seat brace is.

At this stage, I have yet to put bolts in to secure the SAPC and CDI boxes.   Final placement of these parts is still to be determined.  If there are any readers with an RGV, they may be wondering where I am planning on putting the battery.  – On a standard bike, this tray sits where the battery recess was.  Well, rest assured that I have not forgotten about it, but that is a story for another time.