Monthly Archives: December 2013

Herrmans H-Track rear light teardown and schematic

I’m in the process of fitting dynamo lights to my wife’s bike and to mine. For our rear lights, I chose a light I hadn’t seen before: the Herrmans H-Track. It’s relatively cheap but seems to have good reviews. It meets all the relevant standards, if you care about that sort of thing. A quick test on the bench showed that it was nice and bright, and the illuminated ring round the outside is eye-catching.

The standlight works quite well but stays lit for a long time (around 15 minutes, I’d estimate), gradually dimming until it gives up. That’s not as nice as the B+M DTopLight I have on another bike, which stays lit for the requisite four minutes then switches off. I was curious to see if it was possible to improve it, so I took it apart.

The light is glued together but there are little gaps between the two halves at the bottom, which make it relatively easy to lever apart without damaging it. Here’s what’s inside.

A little PCB with not much visible – three LEDs and a capacitor. It’s nicely made, with a fibreglass PCB, but there’s no waterproofing or other sealing. The rest of the components are surface-mounted on the other side of the board. I noted in passing that neither of the wires is connected to the mounting screws, which is handy for lighting systems like the Solidlights 1203DR which need both wires to the rear light to be isolated from the frame. Here’s a closeup of the PCB.

Not a lot to it, really. You get what you pay for. For the curious, here’s the circuit diagram I traced out. It’s clear that the H-Track doesn’t have any protection against overvoltage, so you’re in trouble if your front light comes disconnected.

What about improving the standlight behaviour? Well, I’ve worked out a modification for that but haven’t tried it out in a real light yet. Watch this space.

SheevaPlug Power Supply – Sorted

Orange Livebox 2.0, port forwarding and NAT loopback

2 Replies

For several years, I’ve been running a small server (a Sheevaplug, as it happens) connected to my home broadband connection. It’s not running anything public, but it’s simply handy to have somewhere I can log in to and do things with from anywhere on the internet. It used to be connected via Virgin Media’s cable broadband service, using an Apple Time Capsule as a router, and a dynamic DNS service to handle the name lookup, and it all worked just fine. I could access my server from computers both inside and outside the house.

Recently I moved house, and the new place has broadband provided by Telekomunikacja Polska masquerading as Orange. Their broadband deal comes with its own router which also provides the VoIP phone service as well as having something to do with the TV. It’s a Livebox 2.0. It would probably be possible to set up a different router to do the same job, but the thought of getting the VoIP stuff to work is too awful to contemplate.

The Livebox 2.0 is a fairly flexible box, and I managed to set it up to forward traffic on one port to my server. The server has a little script which updates its dynamic DNS entry, and that did exactly what it said on the tin. I could log in to the server from elsewhere on the internet. But could I connect to the server’s public IP address from inside the house? No way. The router just reported ‘no route to host’. This was annoying. I have various things set up on my laptop which assume they’ll be able to connect to my server, and to have those not work when I’m at home would be a real pain.

The problem seemed to be that the Livebox didn’t want to route traffic from the internal network, where my laptop was, to its external IP address. Reading Wikipedia on NAT, it turns out that this is a feature called NAT loopback. I didn’t even know it was possible for routers not to support it, but I learn something every day. The Orange Livebox 2.0 won’t do it (and yes, I played exhaustively with all the security/firewalling/port forwarding options).

This called for a workaround. My server has a DNS entry with a dynamic DNS provider. Let’s call it server.dyn.com (it’s not, actually). This resolves to whatever the external IP address of my router happens to be – let’s say 203.0.113.1. From inside my home network, the router makes a mess of handling traffic to 203.0.113.1 so I can’t contact it. However, I have control of DNS on the home network: it’s one of the services on my Sheevaplug. I know that ‘spoofing’ DNS entries is bad practice, but I’m going to do it anyway. I can add entries to my local DNS server which make server.dyn.com look up to 192.168.1.10, the local address of the server. The laptop won’t know the difference, but it’ll be able to contact the server. And outside the home network, there’s no chance of anyone, including me, accidentally contacting my DNS server because there’s no way for traffic to get to it. Here’s a picture.

I use bind9 as my internal DNS server. I added a section to /etc/bind/named.conf.local:

zone "dyn.com" {
  type master;
  file "/etc/bind/db.dyn.com";
};

and then created another file /etc/bind/db.dyn.com:

$ORIGIN .
$TTL 604800 ; 1 week
dyn.com IN SOA localhost. root.localhost. (
  2009060801 ; serial
  604800 ; refresh (1 week)
  86400 ; retry (1 day)
  2419200 ; expire (4 weeks)
  604800 ; minimum (1 week)
  )
  NS sheevaplug
$ORIGIN dyn.com
example A 192.168.1.10

It worked! At home, example.dyn.com resolves to 192.168.1.10, and out on the internet, it resolves to 203.0.113.1. I think it’s far from perfect – the timing settings on my dyn.com record probably need to be made shorter, so that the laptop doesn’t hang on to them when I leave home, and this setup means that all other subdomains of dyn.com don’t work, but it’s good enough for me for now. Maybe it’ll be helpful for you too.

Overheated 300Tdi engine

1 Reply

This blog was originally supposed to be about what’s going on in my workshop. However, this post is about what’s going on in someone else’s workshop – the garage which is currently working on my Land Rover. I’m putting it here because it’s an interesting engineering lesson.

My Land Rover’s 300Tdi engine is very badly broken, and apparently it’s all because of the failure of the ‘P gasket’. This part, which costs £3.24 according to a web search I’ve just done, forms a seal between the engine block and the mounting bracket which holds the water pump, alternator and various other things. It’s supposed to play its part in keeping the coolant inside the engine where it belongs. Trouble is, sometimes it doesn’t. And when the cooling water escapes on the motorway, the engine overheats before you’ve even got time to look at the the temperature gauge. This is an object lesson in the damage an engine can do to itself when it overheats badly.

The first I knew about it was that the engine suddenly lost power and then died altogether. I was only able to drift to the hard shoulder in a cloud of steam and smoke. Once cool, the engine would restart but ran badly, making an odd tapping noise, and the Land Rover’s top speed was about 40mph. It’s no racing car, but it’s not supposed to be that slow.

Cutting a long story short, the head is now off the engine. Here are pictures of what’s inside.

Firstly, cylinder number 4. I think this is the reason that the engine stopped: the piston got so hot that it started seizing in the bore, scoring it badly. The score lines are more than just visible, they’re perceptible with a fingernail, too.

The other cylinders look OK, but one bad one is enough.

Sadly the head gasket has also failed, between cylinders 2 and 3:

That would explain the loss of power. Considering that only one out of the four cylinders was in anything like normal condition, it’s amazing that it still ran at all.

I’ve now spoken to several people who’ve said that if a 300Tdi engine has been overheated this badly, the head will be wrecked as well. The search for a replacement engine is now on.

martinjonestechnology

What's going on in the workshop?