If you have ever visited London as a tourist, what memories did you take away as iconic of the British capital city? The sound of Big Ben sounding the hour in the Elizabeth Tower of the Palace of Westminster perhaps, the Yeoman Warders at the Tower of London, or maybe the guardsmen at Buckingham Palace. Or how about the red double-decker buses? They’re something that, while not unique to the city, have certainly become part of its public image in a way that perhaps the public transport of other capitals hasn’t.
A city the size of London has many thousands of buses in the fleet required to provide transport to its sprawling suburbs. Until a few years ago the majority of these machines were built to a series of standard designs under the London Transport banner, so a Londoner with an eye for buses could have seen near-identical vehicles in any corner of the city. Each of these buses would have carried millions of passengers over hundreds of thousands of miles in a typical year, so many in fact that every few years they would have required a complete overhaul. For that task, London Transport maintained a dedicated factory capable of overhauling hundreds of buses simultaneously, and this factory is our subject today.
The overhaul works at Aldenham was the subject of a 1957 British Transport Films picture, Overhaul, in which we follow a bus in its journey through the system from tired-out to brand-new. We see the bus given a thorough inspection before being stripped of its upholstery and then having its body separated from its chassis and cleaned, then we see each part being refurbished. Along the way we gain a fascinating insight into the construction of a mid-century passenger transport vehicle, with its wooden frame and aluminium exterior panels being refurbished and rebuilt where necessary, before the camera. Meanwhile we see the chassis, with its separate gearbox in the centre of the vehicle, before it is painted to resist more years of road grime and reunited with a bus body. The completed vehicle is then taken for a test run before being sent to the paint shop for a coat of that iconic London Transport red. Enjoy the film in its entirety below the break.
The buses in the film are the AEC/London Transport “RT” vehicles, which entered service in the late 1930s and last ran in the 1970s. Their replacement, the visually similar “Routemaster” had only started to appear the previous year, and continued in regular service until 2005. Meanwhile the Aldenham bus overhaul works survived until its closure in 1986 due to the appearance of a range of new buses in the capital that did not conform to the standard design that it had been designed to serve.
Continue reading “Retrotechtacular: London Bus Overhaul”
A car is a rolling pile of hundreds of microcontrollers these days — just ask any greybeard mechanic and he’ll start his “carburetor” rant. All of these systems and sub-systems need to talk to each other in an electrically hostile environment, and it’s not an exaggeration to say that miscommunication, or even delayed communication, can have serious consequences. In-car networking is serious business. Mass production of cars makes many of the relevant transceiver ICs cheap for the non-automotive hardware hacker. So why don’t we see more hacker projects that leverage this tremendous resource base?
The backbone of a car’s network is the Controller Area Network (CAN). Hackaday’s own [Eric Evenchick] is a car-hacker extraordinaire, and wrote up most everything you’d want to know about the CAN bus in a multipart series that you’ll definitely want to bookmark for reading later. The engine, brakes, doors, and all instrumentation data goes over (differential) CAN. It’s fast and high reliability. It’s also complicated and a bit expensive to implement.
In the late 1990, many manufacturers had their own proprietary bus protocols running alongside CAN for the non-critical parts of the automotive network: how a door-mounted console speaks to the door-lock driver and window motors, for instance. It isn’t worth cluttering up the main CAN bus with non-critical and local communications like that, so sub-networks were spun off the main CAN. These didn’t need the speed or reliability guarantees of the main network, and for cost reasons they had to be simple to implement. The smallest microcontroller should suffice to roll a window up and down, right?
In the early 2000s, the Local Interconnect Network (LIN) specification standardized one approach to these sub-networks, focusing on low cost of implementation, medium speed, reconfigurability, and predictable behavior for communication between one master microcontroller and a small number of slaves in a cluster. Cheap, simple, implementable on small microcontrollers, and just right for medium-scale projects? A hacker’s dream! Why are you not using LIN in your multiple-micro projects? Let’s dig in and you can see if any of this is useful for you. Continue reading “Embed With Elliot: LIN is for Hackers”
The first music played on personal computers didn’t come out of fancy audio cards, or even a DAC. the first audio system in a personal computer was simply holding an AM radio up to the case and blinking address pins furiously. This worked wonderfully for homebrew computers where EMC compliance hadn’t even become an afterthought, but the technique still works today. [Chris] is playing music on the radio by sending bits over the system bus without using any wires at all.
[Chris]’ code is based on the earlier work of [fulldecent], and works pretty much the same. To play a sound over the radio, the code simply writes to a location in memory when the waveform should be high, and doesn’t when the waveform is low.
Of course the ability to exfiltrate information over an airgap has a few more nefarious purposes, but [Chris] also has another way of doing just that which is undefeatable by a TEMPEST shielded computer. He can send one bit at a time by opening and closing a CD-ROM drive, capturing these bits with a webcam. Is it useful? It’s hard to imagine how this setup could ever capture any valuable data, but it is a proof of concept.
A lot of great ICs use I2C to communicate, but debugging a non-working I2C setup can be opaque, especially if you’re just getting started with the protocol/bus. An I2C bus scanner can be a helpful first step in debugging an I2C system. Are all the devices that I think should be present actually there and responding? Do they all work at the bus speed that I’m trying to run? If you’ve got an Arduino or Bus Pirate sitting around, you’re only seconds away from scanning your I2C bus, and answering these questions.
Continue reading “Embed with Elliot: I2C Bus Scanning”
[Nightflyer] has been working on an open source project he calls CAMdrive. CAMdrive is designed to be a multi-axis controller for time-lapse photography. It currently only supports a single axis, but he’s looking for help in order to expand the functionality.
You may already be familiar with the idea of time-lapse photography. The principal is that your camera takes a photo automatically at a set interval. An example may be once per minute. This can be a good way to get see gradual changes over a long period of time. While this is interesting in itself, time-lapse videos can often be made more interesting by having the camera move slightly each time a photo is taken. CAMdrive aims to aid in this process by providing a framework for building systems that can pan, tilt, and slide all automatically.
The system is broken out into separate nodes. All nodes can communicate with each other via a communication bus. Power is also distributed to each node along the bus, making wiring easier. The entire network can be controlled via Bluetooth as long as any one of the nodes on the bus include a Bluetooth module. Each node also includes a motor controller and corresponding motor. This can either be a stepper motor or DC motor.
The system can be controlled using an Android app. [Nightflyer’s] main limitation at the moment is with the app. He doesn’t have much experience programming apps for Android and he’s looking for help to push the project forward. It seems like a promising project for those photography geeks out there. Continue reading “CAMdrive is an Open Source Time-lapse Photography Controller”
When a school bus has finished its life ferrying children around, it often ends up as someone’s pet project. Most buses in the US, however, have annoying back doors that lock only from the inside, which isn’t very convenient if you’re loading/unloading gear. Drawing inspiration from another project that fit a simple deadbolt upgrade, [Leonard] took the build one step further and hacked together his own keyless entry deadbolt system.
He started by removing the white safety bar that normally covers the long red handle and attached a slide bolt to the door. The slide bolt serves only as an extension for the deadbolt, which would otherwise get whacked by the red handle. [Leonard] made a few modifications to the slide bolt so it can sit flush against the bus’s lock bar, then went to work attaching the keyless deadbolt. At 2.5″, the bus’s door is actually thicker than standard doors, not to mention this build needs the deadbolt to move along the door’s surface to push the slide bolt fitted to the door. [Leonard] decided to throw in a chunk of wood as a kind of “simulated door,” which mounts next to the slide bolt and houses the deadbolt’s guts.
Check out the video after the break to make sense of the door’s operation and swing by [Leonard’s] blog to see what else he’s done to the bus. If you’re in the mood for more transportation hacks, make sure you see the Raspberry Pi CarPC.
Continue reading “School Bus Keyless Door Lock Conversion”
[John Graham-Cumming] was all set to start a new project based on the Raspberry Pi. Well, that was until shipment was delayed due to manufacturing issues. Not to fret, he transitioned over to a router board which displays the arrival countdown for mass transit bus service.
He based the build on a web page the Transport for London provided. You can load it up and see if your bus is running on time or not. There’s no published API, but by studying the source code from the site [John] was able to figure out how the JSON commands were formatted.
The next step is building a standalone device to pull the data and display it. The board seen above is from a Linksys WRT54GL router. This longtime favorite has a serial port header which can be driven from the Linux kernel. He wired up a jack on the router’s case, and uses an extension cable to get from it to the 7-segment displays mounted in a model of the bus. Since there’s four digits the display can tell you minutes until the arrival of two different buses.
[Thanks Pseudo Lobster]