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?
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.
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.
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.
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?
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.
[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.