Inexpensive OLED displays with I2C interfaces abound, but there is a catch: they tend to be stuck on I2C address 0x3C. Some have a jumper or solder pads to select an alternate (usually 0x3D), but they lack any other method. Since an I2C bus expects every device to have a unique address, this limits the number of displays per bus to one (or two, at best.) That is all still true, but what [Larry Bank] discovered is a way to get multiple OLED displays working with considerably fewer microcontroller pins than usually needed.
While bit-banging I2C to host one display per bus on the same microcontroller, an idea occurred to him. The I2C start signal requires both clock (SCL) and data (SDA) to be brought low together, but what would happen if the displays shared a single clock line? To be clear, each OLED would — logically speaking — still be on its own I2C bus with its own data line, but they would share a clock signal. Would a shared clock cause attached devices to activate unintentionally?
A quick test consisting of four OLED displays (all with address 0x3C) showed that it was indeed possible to address each display with no interference if they shared a clock. Those four individually controlled displays needed only five I/O lines (four SDA, one shared SCL) instead of eight. The Multi_OLED library is available on GitHub, and in case it is useful for devices other than OLED displays, bit-banged I2C with support for shared clock lines is available separately.
There’s more to do with OLEDs than get clever with signals: check out these slick number-change animations, and that even looks to be a project that could benefit from a few saved GPIO pins, since it uses one small display per digit.
They say necessity is the mother of invention. But if the thing you need has already been invented but is extremely expensive, another mother of invention might be budget overruns. That was the case when [klinstifen]’s local government decided to put in countdown clocks at bus stops, at a whopping $25,000 per clock. Thinking that was a little extreme, he decided to build his own with a much smaller price tag.
The project uses a Raspberry Pi Zero W as its core, and a 16×32 RGB LED matrix for a display. Some of the work is done already, since the bus system has an API that is readily available for use. The Pi receives the information about bus schedules through this API and, based on its location, is able to determine the next bus arrival time and display it on the LED matrix. With the custom 3D printed enclosure and all of the other material, the cost of each clock is only $100, more than two orders of magnitude less expensive.
Hopefully the local government takes a hint from [klinstifen] and decides to use a more sane solution. In the meantime, you might be able to build your own mass transit clock that you can use inside your own house, rather than at the train station, if you’re someone who has a hard time getting to the bus stop on time.
Continue reading “GuerillaClock Could Save This City Thousands”
[Blecky]’s entry to the Hackaday Prize is MappyDot, a tiny board less than a square inch in size that holds a VL53L0X time-of-flight distance sensor and can measure distances of up to 2 meters.
MappyDot is more than just a breakout board; the ATMega328PB microcontroller on each PCB provides filtering, an easy to use I2C interface, and automatically handles up to 112 boards connected in a bus. The idea is that one or a few MappyDots can be used by themselves, but managing a large number is just as easy. By dotting a device with multiple MappyDots pointing in different directions, a device could combine the readings to gain a LiDAR-like understanding of its physical environment. Its big numbers of MappyDots [Blecky] is going for, too: he just received a few panels of bare PCBs that he’ll soon be laboriously populating. The good news is, there aren’t that many components on each board.
It’s great to see open sourced projects and tools in which it is clear some thought has gone into making them flexible and easy to use. This means they are easier to incorporate into other work and helps make them a great contestant for the Hackaday Prize.
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”