Automate The Freight: Autonomous Buses To Start Operation In UK

The UK will get its first full-size autonomous bus service this summer, if final road testing that begins in the next two weeks goes according to plan.

Known as Project CAVForth for the UK government’s Center for Connected and Autonomous Vehicles (CCAV) and the Forth bridge, over which the buses will travel, it is said to be the most complex test of autonomous on-road mass transit yet undertaken in Europe. The full-size single-deck motorcoaches, five in total, will ply a 22-km (14-mile) route into Edinburgh from Fife, crossing the famous Firth of Forth on the Forth Road suspension bridge. The buses will carry about 36 passengers each and run at SAE Level 4 autonomy, meaning that a safety driver is optional under good driving conditions. Continue reading “Automate The Freight: Autonomous Buses To Start Operation In UK”

Robust I2C And SPI In Space Thanks To Bus Isolation

Imagine you’re sending a piece of hardware to space on a satellite. Unless you’re buddy-buddy with NASA, it’s pretty unlikely you’ll ever be able to head up there and fix something if it goes wrong once it’s launched. Robust design is key, so that even in the event of a failure in one component, the rest of the hardware can keep working.

The example I2C isolation circuit from [Max’s] paper. The SPI implementation is even simpler.
[Max Holliday] found himself in this exact situation, running 69 I2C and SPI devices in a single satellite. Thus, he came up with circuits to auto-isolate devices from these buses in the event of an issue. That work is the subject of a research paper now available on the TechRxiv Preprint Server.

The problem is that these simple buses aren’t always the most robust, being vulnerable to single-point failures where one bad part takes down other parts of the bus. [Max] notes that vast numbers of sensors and devices rely on these standards, and it can be difficult or prohibitively expensive to design without them, so a solution was needed.

To fix this, [Max] developed a simple external circuit that could be placed on each node of a I2C or SPI communication bus. In the event of malfunction, that node can be cut off from the bus by this circuit, allowing the rest of the system to go on functioning.

With little more than a few transistors, MOSFETs and passives, you too could protect your buses from malfunctions using these techniques. [Max] did just that on the NASA V-R3x mission which flew successfully in January 2021 if you needed any further confirmation of the value of this technique.

It’s something that won’t bother the home hobbyist building a garage door opener, but it could be of great value to those designing systems that must fail gracefully if they fail at all. Be sure to share your best tips and tricks for robust SPI and I2C buses in the comments below!

South Korea Blankets Country With Free WiFi On All Public Transit

Wrapping up a multi-year project to provide free WiFi on all public transportation, South Korea’s Ministry of Science and Information and Communications Technology (MSIT) announced that a total of 35,006 buses had been equipped nationwide.

Previously, subscriber-based WiFi had been installed on subways and in subway stations. It was provided privately by two phone carriers and free only for their subscribers. The coverage was spotty and slow, and in 2017 the government took over and implemented a better system. With this announcement, the whole public transportation system is now covered with stable and free WiFi.

We also noticed that the government has released the details of the 220,000 WiFi access points to the public. This includes the location, IP address, and RSSI data for use by people and companies wanting to develop location-based services. What is the state of free WiFi access points in your region, and does it extend to public transportation? Do you find it reliable, or do you use your data plan when out and about?

Credit: Lewin Day

The O-Bahn Busway – Obscure Transit For The Masses

Around the world, governments and city planners have long struggled with the issue of transport. Getting people where they need to be in a timely fashion is key to making a city a comfortable, attractive place to live. As far as public transport is concerned, this typically consists of buses on the roads, and trams and trains on rails.

Down in the city of Adelaide, Australia, things get a little muddled, however. Nestled in a river valley lies a special  transportation network known as the O-Bahn, where buses ride on concrete rails and the drivers can even take their hands off the wheel. The system remains a rarity worldwide, and was spawned by a perfect storm of conflicting requirements.

A Child of Circumstance

In the 1970s, the South Australian government found itself backed into a corner. Facing a booming population in the north-eastern suburbs, new transport links with greater capacity were needed to get people to the central business district. Original plans from the 1960s had called for more freeways to be built all over the city to solve the problem. In the face of stiff public opposition, legislation was passed in 1970 blocking the construction of any new freeways for a full decade, forcing the government to consider alternatives.

O-Bahn buses passing at speed near Stephens Terrace. Buses formerly reached speeds up to 100 km/h on the network; this was dropped to 85 km/h in 2012, adding 20 seconds to the average run. Credit: Lewin Day

Despite plans being shelved, a corridor of land stretching from the city to the north-east had already been acquired for freeway construction. This was retained, and studies were commissioned to determine the best transportation solution to suit the needs of the area. The “North East Adelaide Public Transport Review” suggested light-rail or a busway would be the best solution.

Initial plans were proposed to link the north-east with a light-rail tramway that would connect with the existing tramline from the city proper to Glenelg in the west. However, the City of Adelaide protested the plan, believing that extending the existing tramline to the east would damage the city’s carefully planned structure.  Plans were made to rectify this by running part of the line underground, massively increasing costs, and the proposal was shelved.

It was at this time, the guided busway in Essen, Germany came to the attention of the state government. Aiming to help reduce congestion by allowing buses to share tram tunnels, it began as a demonstration which later developed into the Spurbus network. The system offered lower cost and higher flexibility than light rail, and avoided the need to carve up the city to hook in to the existing light rail network. Had Adelaide laid out its existing heavy or light rail networks differently, the O-Bahn might not have gotten a look in. However, back in the early 1980s, it was an easy solution in a sea of difficult choices.

Continue reading “The O-Bahn Busway – Obscure Transit For The Masses”

Live Map Of London Tube Created In PCB And Lights

If you’re a frequent traveler on a public transit system, it can be helpful to know when the trains or buses are arriving and if there are any delays. We might reach for a tablet to mount on the wall, but that relies on keeping the OS, the software, and its library dependancies up to date. For true reliability you’ll need to build directly in hardware, which is exactly what this map of the London tube system uses.

The base map is printed directly on PCB, with LEDs along each of the major routes to indicate the current location of the trains. A few small chips handle the WiFi connection — it appears to our eye to be an ESP8266 — and pulling the information about the trains from the London Underground API (it would be virtually impossible to build everything for this project in hardware). The hardware can be easily reprogrammed, and with the PCB layout this could be adapted for other public transit fairly easily.

Even apart from the philosophical differences on design between hardware and software approaches, we still appreciate the aesthetic of LEDs on PCB. In fact, we’ve seen a whole host of artwork on PCBs ever since the price came down dramatically in the past two decades.

Thanks to [Al] for the tip!

Automate The Freight: When The Freight Is People

Before I got a license and a car, getting to and from high school was an ordeal. The hour-long bus ride was awful, as one would expect when sixty adolescents are crammed together with minimal supervision. Avoiding the realities going on around me was a constant chore, aided by frequent mental excursions. One such wandering led me to the conclusion that we high schoolers were nothing but cargo on a delivery truck designed for people. That was a cheery fact to face at the beginning of a school day.

What’s true for a bus full of students is equally true for every city bus, trolley, subway, or long-haul motorcoach you see. People can be freight just as much as pallets of groceries in a semi or a bunch of smiling boxes and envelopes in a brown panel truck. And the same economic factors that we’ve been insisting will make it far more likely that autonomous vehicles will penetrate the freight delivery market before we see self-driving passenger vehicles are at work with people moving. This time on Automate the Freight: what happens when the freight is people?

Continue reading “Automate The Freight: When The Freight Is People”

Multiple OLEDs? Save Pins By Sharing The I2C Clock

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.