Sunday 10 July 2011

Trailer repair (Part 1)

This weekend I'm at my parents, working on the a trailer which belongs to a friend of mine from Cambridge. I need a trailer to transport a big (30" cut, ~300kg weight, 600cc engine) antique lawn-mower I'm rescuing from being scrapped, and a friend of mine kindly agreed to lend me his - with the caveat that I might have to reinforce the wooden trailer bed to support the load.

I towed the trailer up to Linconshire last night, leaving Cambridge quite nervously - as this is the first time I've ever towed anything (other than a broken-down car on the end of a tow-rope). Dad was with me, having visited the university open day I was working at during the day, which was nice. I don't think I would have liked doing this on my own the first time.

By the time we reached Eye, I was feeling a bit more confident with the car / trailer combination. We even stopped at the McDonalds' for food on the way (Finding somewhere to park the car + trailer there was interesting), and having eaten - came out to attempt my first tricky reversing / un-parking maneuverer with the trailer attached! I found the technique required reassuringly intuitive, although I did eventually wimp out and un-hitch the trailer, having run out of space to complete my reversing / turning though. (A stupid 4x4 was parked in my way!)


Anyway.. I suggested to my friend that I do some repair work on the trailer in return for borrowing it, perhaps give it a lick of paint, replace the rotten parts of its bed and grease / replace some suspension pivots. About 2 hours into the job, we have this:



Removing the suspension has to be the most awkward job I could ever have imagined. Wire-brushing, cleaning, lubricating the lock-nuts got me so far, but there was still a lot of work involving ritual swearing, jumping up and down on a socket wrench and gently persuading things with a large crowbar. We initially tried to move the nut with a large stilson wrench, but this only appeared to apply pressure into crushing and holding the nut in place. A quick trip to the excellent local hardware shop (E.J. Tong and Sons) yielded the correct 24mm socket to continue our rotational persuasion.

I finally got the leaf-spring bolt's nut off, but it turns out that was only the beginning of the next - more awkward part of the job - persuading the bolt to part company from its rusty companion - the leaf spring eye. New weapons came out now.. in addition to the penetrating oil and WD40 of the nut job, came a lump hammer and beach-wood whacking interface (used to avoid mushroom the end of the bolt). These were brought to bear on the stubborn bolt with limited avail.

Having thoroughly doused the area in flammable solvents, it was the turn of my much loved Rothenburger Superfire 2 plumbing torch to apply a little heat to the problem. (Ok - a lot of heat.. I put the MAP gas canister on rather than the boring propane one). In the end a combination of heat, whacking, wiggling and ritual swearing finally liberated the bolt. (And this was one of the EASY ones to remove ;)).




A blood sacrifice was offered for the last and most stubborn bolt holding the suspension in place. (Note to self - next time, DON'T drop the axle onto your finger). This didn't seem to appease trailer, so Mr. DeWalt eventually had to step in and confiscate half of the offending bolt. (I used an angle grinder with a slitting disk to cut the head off the bolt). The nut came off easily enough, but it was the spacer / bushing which had become fused with the bolt and did not wish to leave.



With the axle removed, I stripped the other parts of the trailer ready to give the metalwork a lick of Hammerite paint before we start adding new woodwork. Stripping the old woodwork yielded 4 (live) snails and small mountain of very deteriorated roofing screws. These aren't particularly keen to be undone using a screwdriver, so it was mole-wrench to the rescue here. As I wasn't planning to re-use these bolts anyway (we bought some zinc plated coach-bolts to replace them with) it would only have been necessary to wave the angle grinder at them - but that seemed an unnecessarily crude way of doing things.



We manged to free off the seized jockey wheel and started some work on the rather stubbornly stuck brake linkages.



Finally, Dad and I got a first coat of paint on the chassis. Hammerite is brilliant stuff ;)

Toyota Corolla tow-bar

Last week I re-discovered the "joys" of car repair whilst fitting my new tow-bar and its electrics. Despite the relative youth of my 2004 registered car, the usual hatefulness of seized fastenings reared its head and I spent an afternoon drilling out the two bolts I sheared off removing the air-filter box from the engine bay. (A hint for Toyota Corolla owners doing that... work inside the wheel arch and thoroughly wire-brush the road-dirt off, then oil these bolts from the underside before trying to remove them!

Anyway - I was having a bad day, and would not have even needed to remove the air-filter box had I not rather enthusiastically attempted to remove the 100A main alternator fuse with a pair of pliers - damaging it in the process.

It turns out that whilst all the other (admittedly smaller) rectangular fuses in this car just pull out - and are stiff, (so you use pliers), that the main fuse (A male straight-legged PAL type which is specific to Japanese vehicles), is BOLTED from within the fuse-box. You have to unbolt the fuse-box, split it in two - then unbolt the fuse before removing it. These fuses are quite hard to find (especially on a Sunday), and for now I've got an 80A replacement tiding me over as an interim fix until the 100A fuse comes through the post.

Car electrics are an interesting game, and despite being an electrical engineer (ok - perhaps this is WHY it took so long), fitting the tow-bar wiring was a time-consuming process. The tow-bar I bought online, with a £30+ 13-pin Euro style wiring "kit" actually only came with the hitch socket and a rather poorly thought out wiring assembly consisting of 12 wires threaded through a PVC sheath. None of the (legally required) bypass / bulb-failure notification relays were included, and I was left to improvise my own wiring to the battery.

I bought a neat little bypass relay from the local car-parts place, which performs the required functions of stopping the trailer lighting board "hiding" a blown indicator bulb on the car, and allowing you to identify a bulb failure on the trailer when towing. (It beeps when indicating if the bulbs are Ok, and is silent when you don't have a trailer attached, or its indicator bulb is blown).

It turns out that splicing into the ungenerously short wiring looms of the car is very time-consuming if you (like me) have a partly irrational hatred of the ubiquitous "ScotchLok" connectors usually used for this kind of job.



Whilst in general, I like IDC connectors, I have never liked to see these in car wiring. It is difficult to imagine how the insulation piercing contact part can be sized correctly for whatever arbitrary cable your car might be wired with. Usually, IDC connectors are designed to work with a particular type of wire, and I think Scotchlok are popular for their ease of use rather than their technical excellence.

Rather than use Scotchlok connectors and risk "damaging" my car wiring loom, I opted to take the more drastic approach of cutting the existing wiring and soldering in my new branches, sealing up the joints using adhesive lined heat-shrink tubing. This produces a much neater modification than when using bulky Scotchlok connectors, but it does take a lot more time and effort.

Being rather pedantic, I ended up creating a new wiring loom for the tow-bar electrics to tap into, using a 20 pin mating connector carrying all the necessary lighting and power connections. This should allow me to unplug and change the towing electrics if that ever became necessary.

I found that by cutting one support on the back of the C-pillar trim panel, I was able to create enough space to locate the towing relay behind that and away from the usual boot-area installation commonly seen when tow-bars are fitted. The relay beeps at me to inform of its operation, so I don't really want to bury it behind a trim panel deep inside the boot of the car underneath all my tat where I won't hear it! (I installed the towing electrics on the passenger side of the RHD vehicle. The central locking transponder module occupies the corresponding area underneath the driver's side C-pillar.

Wiring up to the vehicle's power supply was the big job.. rather than route straight to the battery, I opted to find somewhere to connect to in the dash-board fuse-box wiring. To get the new wires past the bulkhead and into the engine bay I would have had to dismantle a significant amount of the dashboard anyway, so I figured it would not be a big deal.

Removing the dashboard is a 5-spanners job according to the Haynes manual I bought _after_ having completed the task. (I wanted to check up on the wiring diagrams for my model year, and could only find the face-lift 2004- version online.) To remove the top half of the dashboard (arguably the easy half of the job), you have to:

  • Remove the air-vents
  • Unscrew the top half of the dashboard (screws under the air-vent)
  • Remove the instrument cluster from the dashboard
  • Remove the air-conditioning controls from the center console
  • Remove the car stereo (and remaining air-vents it is attached to)
  • Disconnect the sensor on the dashboard (I think this is a sensor relating to the air-conditioning system, but am not sure)
  • Disconnect the passenger airbag, and remove the large bolt which fixes it to the structural member running inside the dashboard
  • Remove the A-Pillar trims
  • Finally, unclip and remove the top of the dashboard (taking precautions to store it carefully, and upright - as there is an airbag still attached to it!)


This gives you access to the fuse board wiring, and I opted to dismantle the main feed connector to it and solder on an additional tail to the crimp-tag inside, taking it out to my new in-line fuses to power the tow-electrics. This avoids me having to route wires through the bulkhead (which is already pretty busy with wires), play with the engine-bay fuse box or add additional ugly wires directly to the battery.

Soldering to the main fuse-board feed connector was a little challenging, and required a powerful and hot gas soldering iron. The wiring feeding the fuse board is by necessity, quite large - and it and the connector it crimps to have both a lot of thermal mass and an effective thermal path to conduct heat through and away from where you're trying to solder. I certainly wouldn't recommend this method to anyone.. I'm "special" sometimes, so chose a rather obtuse (and potentially risky to achieve) way to connect my new wiring.

I added a new relay to power the switched live supply in the trailer socket, and took the coil feed for the relay from a splice off the cigarette lighter socket wiring, which was conveniently available. I also took the opportunity to gut my TomTom Satnav charger and wire the circuit board directly to the cigarette lighter wiring loom - thus freeing the socket again for other things, such as my phone charger. (My Satnav sits on a custom made bracket to keep it from obscuring my precious windscreen visibility, and the wiring is routed through the driver's side air vent where the Satanv bracket is mounted).

Sunday 20 February 2011

PCB+GL repository instructions

Ethan Swint suggested I write about my PCB+GL branches and how people can check out the code. I'm heartened to know that there are several people who use my PCB+GL branches regularly, and it does motivate me to continue working on the branches (and eventually, I hope - to merge them back to git HEAD).

The branches have been in existance for a very long time now - far longer than I originally intended. I first started an effort of porting PCB to OpenGL many years ago, and I would have liked to have seen the work a long time ago.


The primary advantages of the branches are:
  • Rendering performance
  • Layer translucency
  • 3D view helps visualise the board


The repository I push to is at:
git://repo.or.cz/geda-pcb/pcjc2.git

A gitweb view of the repository is at http://repo.or.cz/w/geda-pcb/pcjc2.git

To clone this repository, you want some variant of:

git clone -o pcjc2 git://repo.or.cz/geda-pcb/pcjc2.git

Which will clone the repository into the "pcjc2" directory, with "pcjc2" as the remote name (rather than "origin"). If you have an existing checkout of PCB (e.g. from git://git.gpleda.org/pcb.git), you can add it as a new "remote" to that checkout with this command:

git remote add pcjc2 git://repo.or.cz/geda-pcb/pcjc2.git

I use the excellent "stgit" tools to manage my branches, which means that as I re-arrange and refactor the patch series' which constitute my branches, git history for those branches will be re-written. As long as you have no changes made, you can update your checkout with:

git fetch pcjc2
git reset --hard pcjc2/BRANCH_NAME


If you wish to base code changes from my branches, you should use stgit to manage your additions as patches. You CANNOT "git pull" or even "git rebase" to update your local branches cleanly, as the re-written history from my stgit branches will confuse both processes. (Sorry!).

Checkout the branch you want and initialise stgit:

git checkout -b local_pcb+gl_experimental pcjc2/pcb+gl_experimental
stg init


You can then "git fetch pcjc2" to fetch updates, and "stg rebase pcjc2/BRANCH_NAME" to rebase your changes against the latest changes I have pushed in the given branch. (You might find that "stg pull" will also work as an alternative to the fetch / rebase combination if your checkout is set to track my remote branch - try it!)

There are several branches in the repository, and the one most people will want is either "pcb+gl", or "pcb+gl_experimental". I use both for work, and you should find they are stable. The experimental varient has had less testing though, and might not work flawlessly with your graphics card if it doesn't support GLSL shaders. If you see square vias and pins, you need the "pcb+gl" branch as I've not yet added fallbacks to the old rendering code in the experimental branch.

Here is an example board rendering from the pcb+gl_experimental branch:

Now for some background on the branches...

What has been merged to git HEAD already?
  • Faster polygon rendering (by caching "NoHoles" polygons)
  • Speeding up polygon boolean calculations through various tricks and optimisations
  • Rendering bug fixes for hairlines
  • DRC rendering improvements
  • Polygon holes
  • Various refactoring of the GTK hid rendering code

What will you find in the branches?
  • Fast OpenGL rendering
  • Translucent layer rendering
  • 3D board view
  • Beginnings of crude 3D model rendering support (not visible unless you look at the non-committed stgit patches)
  • Polygon pours support (with island removal)

What are all the different branches for?
  • for_master

    (Staging area for pushing patches)

  • thermal-geometry

    Work on fixing thermal calculations - DO NOT USE (will cause geometry changes in your layouts!)

  • void_ptr_to_hid_flags

    An attempt to stop some harmless 64bit compiler warnings

    Author: Peter Clifton
    Date: Thu Dec 9 18:06:06 2010 +0000

    Convert argument in HID_Flags to (void *) rather than (int)

    void * allows us to pass pointers on all platforms, 64bit or
    otherwise. We can still use casting macros to safely pass integer
    values via this pointer.

    Avoids the ugliness of castnig a size_t sized offset_of value into
    an int. Due to the size of our structures, this did not cause any
    actual bugs, but was not good practice.

  • polygon_speedup

    Where I was working on performance of our polygon routines - now mostly merged, only debug stuff remains in my local stgit branch

    • bentley_ottmann_intersect

      Finding intersections between polygon contours is one of the tasks whcih consumes a lot of computation time when performing polygon operations. This branch attempts to use a sweepline algorithm (implementation from cairo), to compute intersections in a more efficient way.

  • pcb+gl

    Basic OpenGL rendering support for the GTK HID. Does not yet compile with --disable-gl

    • pcb+gl_experimental

      More experimental rendering changes, including:

      • More rendering in world coordinates
      • GLSL shader to speed up rendering line caps and circles (e.g. vias)
      • Caching of polygon tesselations for better performance
      • Perspective rendering
      • More efficient stencil buffer usage
      • More efficient rendering order for masking holes in polygons

      • local_customisation_pcb+gl

        A few favourite local patches I keep applied - such as changing mouse bindings and a handful of little hacks I use.

      • pours

        Adds support for keeping all pieces of a "poured" polygon, rather than PCB's default behaviour of only using the largest piece. The main contribution in this branch is the ability to track connectivity of each polygon fragment created when clipping "pours" against the board geometry.

        The branch also includes crude island-removal capability, in that any polygon fragment from a pour must be connected to a line or via before it will be drawn. (It is still possible to create floating polygon fragments, so long as they connect to a via or track).

        • local_customisation_pours

          A few favourite local patches I keep applied - such as changing mouse bindings and a handful of little hacks I use.

    • lesstif_gl (Not currently tested)

      A proof-of concept to show that the Lesstif HID could eventually share OpenGL rendering code with the GTK HID. Not recommended for use.

    • anti-polygons

      Before I merged support for holes in polygons to git HEAD, this was the first approach I experimented with. It allows a polygon with a special flag to cut holes in other polygons, just as tracks with clearance do. I've kept it around as it documents some of the changes required for support of "negative objects" (in polygons at least).

      • pours_with_anti_polygons

        Version of the pours branch which supports "anti-polygon" objects

        Kept for interest's sake in case anti-polygons are ever useful.

    • display_list_debug (not updated)
  • old_idea (not updated - an old version of "pours")


Finally, a screen-shot showing some of the things to come (when I get time to work on them!)


As always, constructive feedback and bug reports about my branches are welcome. For general PCB bugs (or bugs which can be reproduced in git HEAD, please file a bug on launchpad.

Thursday 17 February 2011

No user servicable parts inside - Philips HF3490 Wakeup light repair


I'm not a morning person. I don't like getting up early unless I've got a very good reason to do so. When I was working on a project in Lowestoft we would get up at 7AM, and I could mange this - despite the very late nights coding or working on electronics design for the project. What it turned out to be (aside from the motivating job to get up for), was the bright sunrise we would get in the morning on the coast.

I came across the Philips Wakeup light which can wake you up with a gentle 30 minute sunrise at your chosen alarm time - followed by more usual (yet gentle) alarm noises, FM radio or music from your iPod. I wanted one, but sadly the iPod version was subject to a recall and was not available for purchase last year. My parents got me one as an IOU last Christmas, and when the product was re-introduced onto the market, they duly sent it to me.

I love the stylish design of the Philips Wakeup light, and for a small lamp-sized object, it is a very good speaker system for your iPod. Not Hi-Fi quality (and it is only mono), but it is certainly good - featuring a cleverly designed ported speaker inside.

Sadly - my wakeup light got a bit cranky lately - a couple of times it has refused to light, and would require disconnecting the mains and power-cycling for the lamp ballast inside the unit to reset and have another go. Last weekend it finally bit the dust (less than a year old), with a fault which appeared to be a stuck volume button - the unit would dial its-self to minimum volume and not respond to any other controls. (Not so good as an alarm any more!)

Having quizzed my parents about the possibility of finding a receipt for it (I still have all the original packaging), it seemed that we would not be able to find the proof of purchase necessary to send the item back to the (online) retailer it was purchased from. We couldn't even identify which retailer it would likely have been. (There is a moral here.. to put receipts or printed copies of order confirmation inside the products box if you're going to take the trouble of keeping it!)

Anyway, long story sort - I figured I had nothing to loose by attempting a repair. I figured that Philips would not entertain a warranty claim without proof of purchase. (I later realized that the recall and serial number should prove fairly conclusively that the unit WAS under warranty!).

Out came my trusty bag of Hozan brand JIS screwdrivers. I cannot recommend these enough for repairing electrical goods which have fasteners made in Japan or China. Real JIS screws have a single dot punched on them on their face - the ones in the Wakeup light didn't. I'm not sure if Chinese cross head screws are actually JIS, but these screwdrivers fit so much better on most electronic equipment that I tend to use them exclusively (for non-live work).

For live-work, or general cabinet / electrical work where one "might" encounter live wires, my other tool of choice is the Wera Kraftform series of VDE rated screwdrivers. If you get the right one for the screw, they are amazing. (They do wear and break if you misuse them with the wrong screws).

Warning

I'm an electrical engineer, and routinely work with mains voltage equipment. If you do not, you might be better talking to Philips customer relations than trying this.

Getting killed can hurt, and tends to be inconvenient.


So.. boring bits out of the way.. lets get to the good stuff!

I separated the lamp from the iPod dock, then peeled off the four rubber feet hiding screws for the lamp diffuser. The fifth rubber foot doesn't have a screw under it.



There are another four screws hiding under the top plate of the lamp (the one labeled) "PHILIPS". Unfortunately, it appears this has been designed to be assemble only - and I broke two of the four plastic snap-ins holding it in place. If you have to remove this, I'd suggest trying to apply pressure diagonally across the top of the lamp diffuser whilst an assistant levers up the lid. I just levered the lid up, and it broke. (Oh well).



I find it really frustrating Philips didn't make this more accessible or less easily broken, but during the course of my investigation, I decided the unit had clearly been designed not to be serviced. Perhaps Philips do take them apart to repair, and have a stack of spare plastics to hand - but my guess is that for a £150 product, the built cost is about £40-50, and they will just replace, rather than repair warranty returns.

Separating the sides of the lamp diffuser is difficult, and I started at the bottom, using my thumb to lever between the diffuser and moldings on the base of the lamp. This freed a few snaps along the side of the housing, and allowed me to get a guitar plectrum into the seam between the diffuser and white trim along the side of the unit. Both sides of this white trim can be released, but you only really need to release both sides on the side with the controls.

Once the diffusers are eventually removed, you can free the button trim by levering at the snaps joining it with the button unit with a small flat screwdriver. The result is here:



The opposite side trim is even more delicate, but you should not need to remove it from one of the faces of the diffuser. Removing the top vent ring is somewhat awkward, and requires distorting the side-trims carefully to unhook them from it. The diffusers are glued into the vent ring, but this comes away with gently pressure. Be careful not to distort the diffuser too much when removing it, as the screw-tabs retaining it are slotted through holes in the side of the vent ring.

I'm cheating here - this is a picture of the lamp during re-assembly after the repair but I thought it would show the idea..



Having removed the diffusers and side trim, four long screws are all that remains to access to the innards of the lamp. It goes without saying.. but you did unplug it already - right? Inside the lamp is a mains fed HF fluorescent lamp ballast, which operates at very high voltages - upwards of 300V DC.

It is very wise to leave the unit "a while" since you last had it plugged in before opening it up. The exact definition of "a while" might be minutes, hours or days depending on the appliance. I've seen TVs retain very high charge in capacitors for days after being unplugged. I have not measured the discharge time for this circuit, so can only advise caution. I waited about five minutes and was careful not to poke at the ballast PCB too much until further time had passed.



The lamp was pretty well dead - after less than a year. One of the heater coils had open-circuited in the lamp. I don't know if this was due to my "encouragement" trying to "unstick" the volume button with "vibration" (read - banging the damned thing in frustration against the desk) - but from the looks of the tube and previous no-light symptoms, I'm fairly sure it was on its way out before then.

Removing the bulb was a bit of a pain, as Philips have gone to a lot of trouble to try and ensure the things don't get dislodged in transit. Fortunately, the glue they used to goop it into place is soft and can be cut through with a small screwdriver quite easily. There are four small cross-head screws holding two clamp shells around the lamp which also need to be removed.

Clipped in the center of the tube is a white-painted electrode which acts as a "teaser" to help the ballast achieve flicker free dimming of the lamp. This will be LIVE when in use, and is (I suspect) the main reason why Philips had to make the lamp in this unit non-user serviceable. Providing access to enclosures containing unexpected live-electrodes is not a generally good thing - and you could bet someone would try changing the lamp live and get zapped.

Remove the clamps, unclip the insulator on top of the lamp (noting its orientation), then pull out the teaser electrode. It should now (just) be possible to lift the lamp up a bit. Unfortunately (to save cost one presumes), the lamp socket is basically a one-way grip affair, and requires gently levering the contact electrodes back from the lamp electrodes. This is the assembly after removing the lamp:



I love the way Philips have engineered beam springs into the supports for the lamp in order to make it more resistant to failure in transit. This is a really clever touch to what I view as a superbly engineered product. I noticed that the electrical build quality isn't that high in some places but then this is a "Made in China" product, and made for a good price. I was a bit concerned to see dark brown "goop" used to retain components like capacitors on the ballast board this compound is similar (in appearance at least) to the kind of thing one might look out for as a potential cause of current leakage when repairing TVs or PSUs - some kinds of adhesive looking like this lower in resistance when they get old.



Anyway - I replaced the lamp with an equivalent Osram model. I'd have liked to have found a Philips bulb (MASTER PL-C 827 26W 4pin), but I couldn't find one cheaply. It turns out that the thickness of the bulb base and glass envelope construction is not standard, so I had trouble fitting the Osram lamp. I had to file down two recesses on the side of the lamp base to accommodate the retaining clips, and was not able to screw the retaining clamps down completely. Still - it works, and it is held in. More irritating is that the insulator cap for the teaser electrode doesn't fit with the Osram lamp - so I had to leave it out. I strongly recommend you use a genuine Philips lamp if you want to repair your own out of warranty wakeup light.



Fixing the buttons on my unit (so far) has seemed just to require re-seating a badly assembled ribbon connector made at the factory. It is the one on the left in this picture.



This said - I'm not 100% convinced the fault has gone away, as I did find the unit on zero volume again the other day. On closer inspection - there has been factory rework of the main alarm PCB assembly, right in the area concerning button input decoding. The factory have done a very poor job of this rework, leaving an uncleaned residue of potentially corrosive / conductive burnt flux on the board where they did the rework. I would have expected (or hoped for) better from Philips:



I cleaned the worst of this residue, and if I have any further problems with the buttons, I'll probably de-solder and rework some of the components in this area. The macro photographs have made me suspicious of the solder connections on L309-310, along with others in the area.

Anyway.. it works again:



(Don't try this at home - put the covers on first, and remember that live teaser electrode on the lamp too!)

Good luck!

Sunday 12 December 2010

PCB+GL

I just couldn't resist posting a gratuitous eye-candy shot..




Sadly, static screen-shots just don't do this branch justice, as they can't capture its rendering speed, or just how natural it feels to navigate the board. Perhaps I'll have to produce a screen-cast at some point.

gEDA development

There has been a lot of talk recently about how, as a community, gEDA (including PCB), has failed to make best use of its community contributions. The standard excuses have all been made for why we have not been better at integrating patches:

  • Developer bandwidth
  • Unfamiliarity with the code, so I can't review it
  • Submitted code quality not high enough
  • Sumbitted code not confirmat to our (non-existant) formal coding style.
  • "I hate SourceForge" - Ok, that one was just me!

All of the above are true for various cases, but as a community we need to do better. As such, I've been trying to devote some spare cycles to doing what I can to improve the situation.

For me, the SourceForge trackers are a real productivity drain when reviewing code. I've been doing some of the groundwork to trial Canonical's Launchpad as an alternative. This has meant exporting a dump of data from SourceForge, and applying various scripts and manual editing to convert this data into a format Launchpad admins can import into their database.

There have been a few snags along the way, mostly just requiring customisations to the python script which converts the SourceForge export into a Launchpad import format. I have added custom code for mapping release targets assigned to our bugs, cleaning up various auto-generated headers from comments, and tagging the imported bugs to specify which of the SourceForge trackers they originated from.



The results look promising, and in a few days I hope to be able to show people an editable demonstration of the import (for PCB), on the Launchpad staging server.




An example of an imported feature request

Long time, no post!

I just noted that it has been over two years since I wrote anything here!

Whilst I've been constantly encouraging other people I know to blog more about interesting projects they have been working on, I have not been writing anything myself.

Interesting projects have been happening though - mostly afforded by the fact I've had to take some time off from my PhD work in order to overcome some personal problems with depression. I'm pleased to report that I'm feeling a lot better now, and that addressing the issue was what needed to be done.

Anyway, on to the fun stuff..

I've been trying to slowly persuade the PCB+GL branches I've been maintaining into a shape suitable for being pushed back upstream. This effort is taking shape, and a number of commits have already been pushed.

I recently had a cleaning spree, pushing over 30 new commits to make PCB compile without warnings. We now stand a chance of seeing new warnings as and when they appear, and hopefully not letting bugs hide in the forrest that was until recently, our compile output.