n.b. I'm the executive director of the non-profit behind OneBusAway, which is an open source project used by millions of people every day to find out where their buses, trains, trams, and funiculars are, and when they'll be arriving.
If you live in a city that DOES NOT have a OneBusAway server, we've spent a ton of time and energy this year building Docker images and OpenTofu configurations[2], which will allow you to take GTFS and GTFS-RT feeds and turn them into an easy to use REST API.
I know that BART provides GTFS and GTFS-RT feeds: https://mobilitydatabase.org/feeds/mdb-53. Similarly, every other transit agency in the United States should now be publicly sharing at least their static schedule data as GTFS due to a newish federal rule.
Also, if you're interested in hacking on software like what I described above, or on our end user-focused software, we always need more developers to pitch in—all skill levels and essentially any language.
In particular, we desperately need an iOS developer to help our 250,000 daily users get some much needed improvements.
My email address is aaron@onebusaway.org. Reach out!
----
[1] New York, Seattle, Washington, D.C., San Diego, Alexandria, Victoria, Adelaide, Buenos Aires, etc.
Currently there's only 9 cities supported worldwide, and of those 2 are in beta. If this software had broader reach, it may be easier to get open source support.
Having said that, I'd add my city if it were straightforward. It looks like you've spent a lot of engineering time in library and SDK support lately - I suggest investing in the DX happy path to encourage new folks to invest their time.
If you live in a city that already has a OneBusAway server
How do you find a list of places it's deployed. I tried Googling "onebusaway cities" which got me this page https://onebusaway.org/onebusaway-deployments/ but that doesn't list cities like Adelaide that you mention.
I'd be curious if you have any insight on why the tracking apps for buses are so inaccurate - OneBusAway but also Google maps and the others. The estimates are often off in one way or another and sometimes a bus just doesn't show up at all. I assume the problem is with the source data but I'd be curious if you have insight into just what causes it to be so unreliable. I'm in Seattle FWIW
Do you know how reliable is the realtime info? I find that Google maps very often says “bus coming in 4 min” as im watching the bus drive away. Or “delayed by 5 min” and it’s early by 2, etc.
IME Google's realtime data in many places isn't very good; even where it _claims_ to have realtime data (there's a little radio symbol beside the bus), it sometimes disagrees with both the local operator's own realtime data, and, well, consensus reality.
> Or “delayed by 5 min” and it’s early by 2, etc.
This, in particular, you can never really trust, especially for buses, no matter who's telling you it. If a bus is delayed 5 minutes, and has the opportunity to make up the time, it will. If a bus is delayed by five minutes, but there's no-one at the next five stops and no-one wants to get off there, it may well be on time by the time it gets to the next stop. In many bus systems, buses will sometimes just stop to avoid getting too far _ahead_ of schedule, though.
In my experience in NYC, the subway data is extremely accurate in terms of the minimum time until the next train. The subway virtually never arrives "early".
Buses seem to have a problem where their location transmission sometimes fails for a few minutes. The system always assumes the bus is still stuck at its last reported location rather than moving. That's why you get a bus arriving when the feed says it's 4 minutes away.
A good rule of thumb is that if you see the minutes away change, e.g. from 7 to 6 minutes, it's accurate. If it's not changing (e.g. just sits at 7), it might be because it's genuinely stuck in traffic, or because it's stopped transmitting. (Which explains the "delayed by" situation you describe.)
I love this. As a formerly car-free resident of Boston, I cobbled together something far cruder to handle the cases of there being many ways for me to get from point A to point B, but the "best" way depended on time and any stops I'd make along the way.
For example, I walked my son to school before heading to work, and sometimes I got breakfast after dropoff. Having the "next departure" view let me have a more fluid experience that handled the non-deterministic nature of walking with a 4 year old in a very interesting place, or deciding whether to hustle to get the train because missing it hit a schedule gap, etc.
I'm kind of surprised that no one in here seems to have mentioned https://oeffi.schildbach.de/index.html so far. It does exactly what seems to be wanted here.
I also live in SF and made an iOS app (A Better Ride) to solve this exact problem. Just shows you departure times of transit for stops around you. The goal is to make transit less stressful by making it predictable and explorable. It’s just a passion project I work on in my free time with zero monetization
This app is fantastic - nice job! It is unique among transit apps in that it shows you only the routes near you and where they go. This lets you explore all the places you could travel to without dealing with transfers.
I'm working on some hardware in this space (I've been up to my eyeballs in GTFS lately) and I can tell just how much went into parsing and presenting the transit data.
If you're willing, I would love to chat about some of the UX decisions you made - specifically in summarizing and grouping the trips available at each stop, and your backend!
You could make your own if you are sufficiently crafty: the data needed in the UK is available from public sources, https://www.bus-data.dft.gov.uk/ being the main one (I discovered this when checking the data sources of bustimes.org, which they helpfully list on an easy to find page: https://bustimes.org/data).
Let me tell you about the time my wife ordered some cheap furniture on Amazon once ... it was all doll-house furniture. The photos and title did make it seem life-size, and it was super high-quality furniture at that. Just the wrong size...
You don't have to jailbreak your Kindle, or render images.
You can just point its web browser at any webpage you design, and disable the Kindle's "screensaver" (its ads or sleep screen) with debug commands [1, 2].
You'll be stuck with a browser bar along some edge of the Kindle (you can rotate the device orientation to put it at the bottom or right edge), but it's a small price to pay for being able to write your weather/transit/news screen in easy HTML/CSS/JS and whatever backend language you want, and run it on a cheap DigitalOcean $4 instance or whatever.
(author here) I've also been thinking about this - I've since built out a Rust library (https://github.com/lily-mara/kindling) for scaffolding the server piece of this and I've been considering creating a Kindle client app that integrates with it. This is possible but would require using the Kindle Java SDK, which does not fill me with excitement.
That would be fantastic, although even just the way you've done this here is great. I've got a few old Kindles that would be good to convert to displays, and if I could just install a server and a client, it would take a lot of the work out of it.
No matter what, jailbreaking would be the most difficult step in the process, but the library I linked above takes a lot of the work out of it. It's entirely undocumented atm (I am surely the only one using it), but it comes with an install script you can run on the Kindle to do the setup once you have the jailbreak done.
They really ought to, it's a fantastic reuse mechanism.
Like I totally understand why they wouldn't for new Kindles, since I assume part of their ebook sales help subsidize the hardware, but if they enabled it once a device hit 5 years old or something, I don't see what they'd have to lose.
I did this with an inkBOOK, which just runs Android. Loaded on a Chrome APK and pointed it at a webpage I made. `document.documentElement.requestFullscreen()` enters true fullscreen, no status bars. And my local transit service's API is accessible directly from web pages, no backend needed.
I looked into this with my 4th generation Kindle; it seems like it won't be able to use any HTTPS website due to invalid certificate. However, setting it up to talk to a server on my local network would be the way to go. Thanks for the idea!
I didn't seem to be last I checked -- the older Kindles require the sequence:
;debugOn
~disableScreensaver
;debugOff
while newer ones only require:
~ds
I know that for some ad-supported Kindles it doesn't work unless you pay to remove the ads (for obvious reasons), but if you pay then it will.
But last I checked was a couple of years ago. I'd be very curious if anyone can report it not working. (Also note the command doesn't survive reboot, you have to re-disable after rebooting.)
I don’t follow the space closely, but if you find a Kindle Keyboard (third generation of the product) or earlier, they stopped getting updates ages ago and in fact can no longer use the store (though USB sideloading still works fine). They are all jailbreakable.
As a kiosk-like display, though, they do have that keyboard taking up space.
I only use my Kindle to read outside (at the beach or pool); in the house, my iPad is faster and has a bigger screen. But in the sun, it’s useless. eInk is far superior for that. For the week or two a year that I need one, my 15-ish-year-old Kindle is fine. I travel with a laptop and tons of cables anyway; sideloading just means a few minutes of work after dinner to make sure there’s enough on there to read tomorrow and isn’t much slower than using the internal interface to get books was.
Maybe I'm not understanding the use case. I don't want to "take the train". I want to get from A to B. If the train is broken, the workers are on strike, the route is blocked between 1pm and 4pm, or it's outside of operating hours then I want an alternative. So for me, I actually want what Google Maps gives me (or tries to give me). I do not just want to know about trains. Maybe I want to get from the Ferry Building to Oakland and maybe the Bart is broken so i'd be better to take the ferry. Maybe it's late so my only option is a taxi/uber.
Alternatives are especially important in other cities. In Tokyo if I want to go from Shibuya to Azabujuban I can take
* Ginza Line->Namboku line - advantages, (1) Ginza line starts at Shibuya so guaranteed a seat if I wait for the next train - though only for 4 stops where I have to switch (2) both lines are same train company so $1 cheaper
* Hanzomon Line->Oedo line - advantages, fastest
* Yamanoto line->Namboku line
* #6 bus - advantages: no changes, disadvantage, slowest
* taxi - advantage: fastest if there's no line for taxis or if I'm confident I can find one quickly
Extra considerations. Each line's station and the bus stop are 3 to 8 minutes walk from each other so if I'm closest to one that would weigh on my choice. Speed matters too, if I'm late. If I have large or heavy packages I'd be more likely to take the cab. Etc....
> So for me, I actually want what Google Maps gives me (or tries to give me).
One thing I find is that Google Maps really, really assumes that walking is very very bad and no-one wants to do it. So for instance, if I'm going to a particular place I will get a 39 bus and then walk 15 minutes. If I ask Google how to get there, I'll get a route with two transfers; if the stars align it'll take about as long as one-bus plus walk. So if I want Google to tell me when the 39 bus is coming, I'll have to lie about where I'm going.
(Also, at least where I am Google's realtime data is questionable, with the data from the operator and some other third parties being more reliable.)
Indeed, they assume all kinds of things - with no option to customize. For example, they assume that a 1 or 2 minute transfer will happen. Which you might want to override, but can't. You have your reasons to want to route through Caltrain instead of BART... and you can't. This is a characteristic of the brand really: Google people know what's good for you. I mean, them.
> Maybe I'm not understanding the use case. I don't want to "take the train".
The use case is routine. A lot of people, most of the time, do indeed want to "take the train". Heroic feats of real-time planning have their place, and it's great to have tools that help you with that, but routine can be covered with much simpler tools just as well.
Even in the Tokyo scenario you gave (which is fascinating -- thank you!) Google gives 30-40 min. for most public transit options, so for rough planning they're all equivalent. Taxi is faster, and bicycle is almost at par.
never met that person. as someone that has long lived in cities with amazing transportation (sf is not one of those with good transportation) there are too many options and people always want whatever is best now, not routine.
you're out drinking - which mode is last. you're on the east side of X, which route is closest. you're tired, does any route guauntee a seat. etc....
Berlin, London, Paris, Tokyo, Singapore, Kyoto, Osaka. All this way . there is no "one train"
In many cities certain parts of the transit network follow a star / hub-and-spoke layout. The station nearest to my house is on a spoke, and has trains going south and those going north. So for me, an in-home train display only really needs to show the next train in each direction.
And a lot of transit decisions are conditional on things the planning app doesn't know. Am I comfortable riding a hire bike, appropriately dressed, and carrying a helmet? Do I already have a return ticket for the light rail making it the obvious choice? Am I the kind of person who enjoys a brisk 20 minute walk?
Combine that with the fact that the multimodal transit apps don't understand fares, and I find it's simpler to just start the taxi app if you need a taxi.
> Combine that with the fact that the multimodal transit apps don't understand fares
Kakao Maps will give you exact timing and fares for every mode except air
> In many cities certain parts of the transit network follow a star / hub-and-spoke layout
Yeah those who live on a spoke and mostly go back and forth that spoke are a minority because the farthter away from the center the more space between the spokes:)
Even though most times my train comes every 15 Minutes (and in other places even every 5), I still check for: Disruptions and I try to catch the train exactly. I often get on the platform a minute before the train departs and rarely miss it.
I would find this slightly useful, I live in Madrid. For most of my trips I take the metro; I have two lines nearby, and they are frequent enough that I just show up. But there are a few parts of town that are just not well connected to my place by metro. If I want to go to Atocha, Cibeles or Piramides, the bus is better. But I have three buses that take me to each of those places, and they show up every 25 minutes. If I'm going there, I want to know which stop will have a bus soonest.
I also live in Madrid. Many years ago, wrote a bash script that downloaded the real time data for the bus stop nearest to home from the EMT website and read out loud the minutes for the next bus with festival.
We had a keyboard next to the couch, many keys were shortcuts to execute commands like that one. So it was a matter of pushing a key and listening.
For your daily commute, you really do just want to "take the train".
If the train is broken or the workers are on strike, that will be reflected in the unexpected absence of live trains listed.
I pull up Google Maps and plug in my destination when I'm running around the city. I don't pull it up when I'm leaving my home to go somewhere I've been 500 times before.
Experiences with public transit in central Tokyo is don't generalize to the world. It's as pointless as talking in-store shopping or dining experience based solely on that inside a Disneyland. Just tapping Suica takes couple times less than what takes you elsewhere, if at all supported.
without more info you can't know that. further. I want to go to one app. If I want to go to Geary and 24th, there is no train. I don't want to have to take the extra step of thinking about where I want to go and then having to choose the appropriate app. one app will do
Nice. I have something similar with a repurposed Lenovo ThinkSmart View tablet/conference room device, with Home Assistant and its integration to my local transit authority. The advantage is that it's much more out of the box (okay, I did have to flash a custom Android ROM on the Lenovo, but still), it can show whatever I want, and I can also use it to control stuff like my lights or robot vacuum.
If you want a transportation app built for locals I highly recommend Transit. When you open the app it shows you the transit options closest to you, where they’re heading, and when the next one arrives. Never have to put in a destination.
My local transit agency (Trimet) is _really_ good with their api. It's public, and a single HTTP GET to get the ETA on every bus that serves a given stop, so it wasn't event that much work.
When realtime information was first available from my public transit system, it was via an SMS system that was widely advertised at every bus stop and train station, wherein each received a five-digit ID code. So you'd text that code to a special number, and it'd reply with the "NextRide" timings.
Unfortunately, it was wildly inaccurate. Every time I queried it, it said the bus had already left (I'd been standing there 10 minutes) or it didn't take into account active detours, or something. The only thing it was good for was determining the headways between buses (15, 20, 30 minutes?) and then you could at least calculate your longest wait at that stop.
The next iteration involved installing the bespoke and quite buggy app provided by the transit authority themselves. Now this theoretically depended on the same GPS trackers in the coaches as the SMS system had. But I had major troubles with the app, and I didn't like it, and it barely did anything else, and so I uninstalled it. And I did without it for a while longer.
Now the app is improved, and it's got QR pass technology included, so I reinstalled it, and I use it more. But, for tracking the buses, I prefer Google Maps.
Our transit authority graciously shares 100% real-time tracking info with Google, and you can track any bus in Maps, including crowdsourced info, such as "How crowded? Is security aboard?"
It works really well, and really accurate; displays every delay and updates by-the-minute as buses or trains pass each stop. Sometimes I pass the time just sitting there and watching my bus make its way down the street.
"""
Caltrain is a Pebble app that displays upcoming trains at a station, and where those trains will stop along the remainder of each of their routes.
Finally, it uses PebbleKit JS to retrieve your location on launch. If it gets a response before you manually choose a station, it will automatically show the station closest to you.
"""
...you could literally map that "applet" to long-press on a button, and get the info in like 5 seconds.
For extra "dick tracy" spice, call an uber from your wristwatch with 3-4 clicks (long-press, ok, next, ok => "your uber will arrive in __ minutes"). Actually, reviewing the app docs, it looks like it was only two long-presses to request $LAST_USED_CAR to $CURRENT_LOCATION.
We've really taken steps backwards since pebble. We used to be able to respond to messages by talking into our wrists, for ~$100. I switched to Garmin after using rebble for a bit, and that's the feature I miss most.
I'm the reverse, I never wanted to "input" to the wrist, but really appreciated the notifications, Bluetooth disconnect warnings, "the timeline" interface, and the necessarily limiting interface of 4 buttons (specifically: music control while in the shower... play/pause, next track, pick a station from a list, etc).
Totally understand how some loved the ability to compose/respond to messages, but that never made sense to me.
Garmin, Amazfit, and BangleJS comes close, but #buttons, #battery, and #b&w (well, always on, transflective, sunlight readable)
I love the premise and I felt that a lot in SF. The transport system is not really a complex enough network that I need to be shown routing options. Just wanted to know when to leave the house and not stand at the stop for 20 minutes :’(
(In a highly networked place like London, seeing all options is helpful)
I made a (free and ad free) app for BART that tells you if you need to run to catch your train or not. Instantly upon opening the app, without needing to tap anything, it automatically figures out which train you want and helps you hurry, just a little bit, to make the next one rather than wait.
I made this BART arrival display website designed to just show upcoming departure times for a specific stop. The idea was that this could be used on a wall mounted display so you could glance at it on your way out the door to help you know how fast to walk. https://bart.blinktag.com
It ought to be easier to get a blank slate of a small device with some compute power and a screen, like the Kindle here, without having to jailbreak something.
There is one, it's called the Raspberry Pi ecosystem, but due to the small volume and the target audience largely being not-my-own-money (think educational institutions), the price is quite detached from the production cost.
A 4.37inch E-Paper in 3 colors is $24, problem is need you to program yourself (they have code sample in python, for raspberry pi), and you need a raspberry pi, case, cables, etc.
Also, these cheap epaper displays are, of course, of lower quality (slower, lower resolution) than an kindle display.
They jump up in price pretty quickly as size goes up. The cheapest 5+ inch display I found at your link was over $40, and it's about 100PPI. It's certainly not prohibitive, but certainly priced high compared to "just jailbreak a kindle" for any remotely kindle-comparable display, right? (remotely comparable in size and resolution)
I imagine the Kindle is sold as a loss leader, plus whatever economies of scale/negotiating Amazon does pushes the price down heavily vs buying a single unit from an electronics retailer
Not to diminish OP’s project, but the stated goal of “know when each transit line has an upcoming train/tram/bus” is probably already achieved by https://transitapp.com/ - the default view when you open the app is a list of nearby transit lines, sorted by distance and showing the next departure for each.
Like that there's no ads but it's a big no on the "data shared with third parties". Assuming this is how they make money? I'd rather wait 10 more mins for the bus I just missed.
That works when it's high frequency enough. If it's every five minutes, no problem. If it's every 20, this doesn't work quite as well. If it's every hour it's unworkable.
Really timely, I'm currently writing Arduino code to get my bus departure times displayed on a cheap TFT screen. There's so many projects around this, but it's the first time I see it on a Kindle. Awesome!
Given the post's title, I hoped it would work with trains. In Washington, DC, it works with buses but not trains. What help would you need to make it work with trains?
It's really just a question of the transit provider giving you access to the data. My display shows mostly light rail schedules with a few buses. If your transit provider has real-time data for trains you can display it, if not you can't.
I love how they blamed the flake on node and Javascript, then switched to Rust and also changed the whole approach, which had a hundred times more effect than changing the language did.
I don't blame Node/JS for the reliability issues of the first version at all, they're simply not the tools that I prefer to work in.
> Each of the seven sections on the image represents a browser tab that Puppeteer needs to keep open in order to fetch screenshots. Remember that the Node.js server was running on a Raspberry Pi, it didn’t have an excess of memory to operate in and Chrome is not known for its svelte-ness.
> I picked Node.js for the first server because I was using Puppeteer. I don’t particularly like Javascript, so given the ability to start from scratch I happily pivoted to Rust.
> Next, since we’re not relying on a browser engine to render the display, we will be using a 2D graphics library to render a PNG directly. This should have a much lower resource cost than using an entire browser engine, at the cost of some decreased flexibility.
I don't think they really blamed node and js? They seemed pretty aware that it was the overall arch of the thing that made it non-viable.
> Each of the seven sections on the image represents a browser tab that Puppeteer needs to keep open in order to fetch screenshots. Remember that the Node.js server was running on a Raspberry Pi, it didn’t have an excess of memory to operate in and Chrome is not known for its svelte-ness.
So then figuring they had to effectively redo it from scratch with a new solution, they then switched over to a language and stack they enjoyed, which seems completely reasonable.
> I picked Node.js for the first server because I was using Puppeteer. I don’t particularly like Javascript, so given the ability to start from scratch I happily pivoted to Rust.
edit: Just beaten and directly from the author it seems. :)
> like most truly useful things we need to build it ourselves
but I was surprised that the author insists on displaying an image on the Kindle. The last third of the post is dedicated to building that PNG file. Is it possible to send text? It would be easier but maybe it's not possible...?
It's the easiest way to display complex graphics on the Kindle which take over the entire screen. Yes, I could use HTML and the browser, but there's a header and footer that I don't want to see (plus I'm not convinced the Kindle would stay awake). I could have sent text, but the renderer available at the CLI is extremely limited. I'm not sure if I could have tapped into a mobi/pdf renderer to make it show up similarly to an e-book, but I'm doubtful if I could have made a mobi file show up in landscape like this. I was also building on several other tutorials that use PNG files, so it just made sense to do this.
Cool! I made something like this on an old netbook in university.
I plotted bus locations in matplotlib, which was what I knew at the time.
The busses would clump up where I lived, so it was helpful to know if I should rush breakfast to catch a burst of busses or just wait for the next wave.
I always want to get into rust but examples like this always make me reconsider. Every time I want to code something and start with rust, I switch to python 5 minutes later because it’s just so much easier (for me at least). The code to build exactly this dashboard would probably be less than 100 lines of python. Rust is much better for performance (and maybe runtime correctness, but most errors here would be parser errors anyways) of course, but for this application, I don’t think it really matters.
“where are you and where are you going?” Is a delusional question for a transit system but it’s a good question for Uber.
When I was involved with the Green Party we were thinking of “just doing” the things the local government wasn’t doing and I think we set a fire under the bus company’s butt to fix a large number of usability problems that we were going to fix for them (and stick our logo everywhere.)
The bus company was very negative on us extracting schedules from their web site because they wanted to see what people were searching for — hypothetically they could have added new service somewhere if there was demand for it but (1) it seemed hard to believe they’d really do it because changes are so infrequent and (2) they never showed any sign of caring what people thought, why would they start now?
I wrote something similar on a smaller scale for the keihin-kyuukou line in japan: https://rail.esrh.me. Now I live in tokyo and there's several transit options closeby so I would love to have some always on display like this in my room.
Unfortunately, while public transit in the US and Europe seem to be tracked by services with developer friendly APIs, this is not the case in Japan as far as i know -- not that much of a problem back then, i just needed to do some light web scraping.
I wrote all of the scraping/data and processing/frontend code in clojure and clojurescript, and wrote a small blog post about it here: https://esrh.me/posts/2023-03-23-clojure
Wow what a cool writeup. Two things stuck out for me (I'm only halfway so forgive me if you address these issues). I have two comments on processing the 511.org data. First, you generally want to use a streaming parser rather than one that allocates memory to the entire response. Second, you should filter out the most data first (in this case, dropping the stops you don't care about) and then filter the least data second (dropping the fields you don't care about). This idea is similar to how, in SQL, you want to order your WHERE clauses such that the most impactful comes first.
This may not be strictly required by your use-case at this scale - 27MB of data is not a lot, after all. And the filter ordering performance is probably trivial given its all in memory (I'd be curious to see a benchmark!) However, a) efficiency is always good, especially on a Pi, and b) if you make the code more efficient it makes it easier to scale later if you want to.
Also, regarding the BOM problem you had, wouldn't it be nice if all APIs had a "developer feedback" mode built into it? That is, you can send feedback to the ppl who own the API endpoint by...posting to the endpoint. In this case you could send "Please remove the BOM. k thanks."
This sounds like a fun project, but there are existing apps whose default page is "when is the next bus/train coming up on stops near me"
Transit App (https://transitapp.com/) is one of them and I freaking love their interface overall. This app's default view shows you the next bus (in either directions) at the 3-4 transit stops closest to your current location. And you can customize/add favs too. It's a beautiful app, also allows for multi/mixed-modal route planning (part walking, part bike, part bus).
To be honest, I found having something physical and on the wall and always present _really_ helpful. When the train/bus comes every 15 minutes, being able to casually look and see if you should make a dash for it is way better than pulling out your phone, bringing up an app, and entering your destination.
Plugging my own project here [1] for SF's Muni to say I 100% agree with you - the phone is a trap! There's something so charming about having a thing you know you can look at anytime and __no matter what__ it's doing exactly what you expect it to be doing.
Oh yeah of course, I personally have a physical screen that shows live feed from my local transit agency's GTFS real time feed. I was just pointing out the app for those who don't have the time/interest to build something physical.
A. "Busses" should be "buses", I think? Or am I stepping into a holy war... Maybe it's a British vs American English thing, but a quick look says that Merriam-Webster agrees. Maybe it's a choice by the author, in which case, fair enough. If I was the author, I'd prefer knowing, anyway.
B. Super cool article! I've an old Nook somewhere being neglected which I am now moving up my list of devices to do some messing with and find a use for. Excellent stuff.
'Buses' is probably more standard, but 'busses' as a plural noun is common enough that it's probably not worth making a fuss about. The great/terrible thing about English is that there is no central authority; if people use it, it is English.
The OED says that "busses" is an acceptable plural in American English (I haven't read the article though, so I don't know what dialect the author speaks/writes).
> You might see the plural busses, but that form is so rare that it seems like an error to many people. [...] When the word bus was new, the two plurals were in competition, but buses overtook busses in frequency in the 1930s, and today is the overwhelming choice of writers and editors.
Went ahead and used Google Ngram viewer to show the popularity difference, with some context-words to ensure it's comparing cases where a plural noun is being used:
Ooh nice, I didn't know that Ngram tool! I've heard references to word frequency but didn't know where to do it. Thanks for jumping in with a bit of analysis.
Of course, if USA-based anglophones want to continue using a particular spelling or pronunciation, we know we don't have the power to stop them. I bow out of this one.
In this case, we really, really don’t want to continue using “busses” as a plural noun. Merriam-Webster is the authority. We’d rather fight our holy war over labor and center.
Ehh... Cough, tough, bough, lough, slough, and rough called, they wanted to know when English phonology became logical and consistent, and why no one informed them about it?
-ough notoriously has anywhere between four and twelve different pronunciations (if you count strange example with a limited number of words, like hiccough for hiccup).
The point I believe the parent post is making is that you cannot assume that buses would rhyme with fuses, because English orthography is so inconsistent.
Which is partially true - I haven’t seen any research to the effect, but I’d guess you can still predict the pronunciation of an English word with better than a fifty percent chance of success.
Sorry, I thought it'd be obvious that all those -ough words have different pronunciations (for most people, anyway, I think) and that I'd be making my point clearly and lightheartedly. I was just saying that English spelling isn't always "guessable", or how you think it logically should be. [Even though it may well be guessable the majority of the time, as another responder points out, for some reason].
The fact you think "busses" is a preferable spelling to "buses" because it might help you pronounce "buses" differently to "fuses" is only relevant to you yourself. I would have thought this was tautological, myself.
In summary, we could avoid all these fusses with a bit of effort to adhere to accepted usage.
n.b. I'm the executive director of the non-profit behind OneBusAway, which is an open source project used by millions of people every day to find out where their buses, trains, trams, and funiculars are, and when they'll be arriving.
If you live in a city that already has a OneBusAway server[1], you can use one of our brand new SDKs to build your own custom app experience: https://github.com/onebusAway/?q=sdk&type=all&language=&sort...
If you live in a city that DOES NOT have a OneBusAway server, we've spent a ton of time and energy this year building Docker images and OpenTofu configurations[2], which will allow you to take GTFS and GTFS-RT feeds and turn them into an easy to use REST API.
I know that BART provides GTFS and GTFS-RT feeds: https://mobilitydatabase.org/feeds/mdb-53. Similarly, every other transit agency in the United States should now be publicly sharing at least their static schedule data as GTFS due to a newish federal rule.
Also, if you're interested in hacking on software like what I described above, or on our end user-focused software, we always need more developers to pitch in—all skill levels and essentially any language.
In particular, we desperately need an iOS developer to help our 250,000 daily users get some much needed improvements.
My email address is aaron@onebusaway.org. Reach out!
----
[1] New York, Seattle, Washington, D.C., San Diego, Alexandria, Victoria, Adelaide, Buenos Aires, etc.
[2] Docker: https://github.com/OneBusAway/onebusaway-docker and OpenTofu: https://github.com/OneBusAway/onebusaway-deployment
Currently there's only 9 cities supported worldwide, and of those 2 are in beta. If this software had broader reach, it may be easier to get open source support.
Having said that, I'd add my city if it were straightforward. It looks like you've spent a lot of engineering time in library and SDK support lately - I suggest investing in the DX happy path to encourage new folks to invest their time.
For example, this document is rather complicated https://github.com/OneBusAway/onebusaway/wiki/Multi-Region
If you live in a city that already has a OneBusAway server
How do you find a list of places it's deployed. I tried Googling "onebusaway cities" which got me this page https://onebusaway.org/onebusaway-deployments/ but that doesn't list cities like Adelaide that you mention.
had to install app to check, only USA and only few places... so basically useless
See the footnote in GP's comment.
This one?
[1] New York, Seattle, Washington, D.C., San Diego, Alexandria, Victoria, Adelaide, Buenos Aires, etc.
I was trying to figure out what "etc." meant.
As an aside, being opensource is there a reason you only publish in Play store and not F-Droid?
I'd be curious if you have any insight on why the tracking apps for buses are so inaccurate - OneBusAway but also Google maps and the others. The estimates are often off in one way or another and sometimes a bus just doesn't show up at all. I assume the problem is with the source data but I'd be curious if you have insight into just what causes it to be so unreliable. I'm in Seattle FWIW
BART and MUNI both support the General Transit Feed Specification.[1] There's a standard way to obtain this data.
[1] https://gtfs.org/documentation/overview/#gtfs-realtime
Do you know how reliable is the realtime info? I find that Google maps very often says “bus coming in 4 min” as im watching the bus drive away. Or “delayed by 5 min” and it’s early by 2, etc.
IME Google's realtime data in many places isn't very good; even where it _claims_ to have realtime data (there's a little radio symbol beside the bus), it sometimes disagrees with both the local operator's own realtime data, and, well, consensus reality.
> Or “delayed by 5 min” and it’s early by 2, etc.
This, in particular, you can never really trust, especially for buses, no matter who's telling you it. If a bus is delayed 5 minutes, and has the opportunity to make up the time, it will. If a bus is delayed by five minutes, but there's no-one at the next five stops and no-one wants to get off there, it may well be on time by the time it gets to the next stop. In many bus systems, buses will sometimes just stop to avoid getting too far _ahead_ of schedule, though.
The app is very clear when a time is based on gps vs the schedule. You can even watch the gps like you can on Uber.
No one can predict the traffic but in my daily experience it is reliable to the minute
It depends on the specific transit system.
In my experience in NYC, the subway data is extremely accurate in terms of the minimum time until the next train. The subway virtually never arrives "early".
Buses seem to have a problem where their location transmission sometimes fails for a few minutes. The system always assumes the bus is still stuck at its last reported location rather than moving. That's why you get a bus arriving when the feed says it's 4 minutes away.
A good rule of thumb is that if you see the minutes away change, e.g. from 7 to 6 minutes, it's accurate. If it's not changing (e.g. just sits at 7), it might be because it's genuinely stuck in traffic, or because it's stopped transmitting. (Which explains the "delayed by" situation you describe.)
I love this. As a formerly car-free resident of Boston, I cobbled together something far cruder to handle the cases of there being many ways for me to get from point A to point B, but the "best" way depended on time and any stops I'd make along the way.
For example, I walked my son to school before heading to work, and sometimes I got breakfast after dropoff. Having the "next departure" view let me have a more fluid experience that handled the non-deterministic nature of walking with a 4 year old in a very interesting place, or deciding whether to hustle to get the train because missing it hit a schedule gap, etc.
I'm kind of surprised that no one in here seems to have mentioned https://oeffi.schildbach.de/index.html so far. It does exactly what seems to be wanted here.
These are also worth a mention:
https://play.google.com/store/apps/details?id=nl.skywave.ovi... / https://apps.apple.com/nl/app/ovinfo/id1144468923
https://drgl.nl/
https://www.rijdendetreinen.nl/
https://spoorkaart.mwnn.nl/
There are a bunch of things that do broadly this, though largely not on a kindle on a wall, of course :)
Wow, I had no idea something like that would work out in the deep forests of north sweden, With live updating times! Thankyou!
So much better than the official app, it directly shows exactly what is most needed, closest bus-stop with live times for next busses.
I also live in SF and made an iOS app (A Better Ride) to solve this exact problem. Just shows you departure times of transit for stops around you. The goal is to make transit less stressful by making it predictable and explorable. It’s just a passion project I work on in my free time with zero monetization
This app is fantastic - nice job! It is unique among transit apps in that it shows you only the routes near you and where they go. This lets you explore all the places you could travel to without dealing with transfers.
Your app is stunning! Love the real-time map!
I'm working on some hardware in this space (I've been up to my eyeballs in GTFS lately) and I can tell just how much went into parsing and presenting the transit data.
If you're willing, I would love to chat about some of the UX decisions you made - specifically in summarizing and grouping the trips available at each stop, and your backend!
That's really great! So many nice touches, like how it shows the side of the street and the overall direction of transit!
If you're in the UK you can buy a depature board that mimics a station departure board:
https://ukdepartureboards.co.uk/store/product/desktop-depart...
There's also https://departureboards.mobi/departures/BTH which mimics the departure boards used in some stations.
Is there a bus version? This is excellent.
You could make your own if you are sufficiently crafty: the data needed in the UK is available from public sources, https://www.bus-data.dft.gov.uk/ being the main one (I discovered this when checking the data sources of bustimes.org, which they helpfully list on an easy to find page: https://bustimes.org/data).
This is great - rather hard to justify as an impulse buy though, it’s pricey.
You can build it yourself very easily for 1/3 of the price:
https://departureboard.jonathanfoot.com/
There's a Swiss equivalent of it mimicking tram boards:
https://tramli.ch/en
> Note: Please review product dimensions before purchase to avoid any surprises
LOL, this must happen quite a lot to them.
Let me tell you about the time my wife ordered some cheap furniture on Amazon once ... it was all doll-house furniture. The photos and title did make it seem life-size, and it was super high-quality furniture at that. Just the wrong size...
You don't have to jailbreak your Kindle, or render images.
You can just point its web browser at any webpage you design, and disable the Kindle's "screensaver" (its ads or sleep screen) with debug commands [1, 2].
You'll be stuck with a browser bar along some edge of the Kindle (you can rotate the device orientation to put it at the bottom or right edge), but it's a small price to pay for being able to write your weather/transit/news screen in easy HTML/CSS/JS and whatever backend language you want, and run it on a cheap DigitalOcean $4 instance or whatever.
[1] https://blog.notfaqs.com/2018/06/kindle-e-reader-disable-scr...
[2] https://www.mobileread.com/forums/showthread.php?t=198334
It would be even cooler if Amazon also encouraged and built a "Kiosk mode" browser view of the kindle for this sort of display hacking.
(author here) I've also been thinking about this - I've since built out a Rust library (https://github.com/lily-mara/kindling) for scaffolding the server piece of this and I've been considering creating a Kindle client app that integrates with it. This is possible but would require using the Kindle Java SDK, which does not fill me with excitement.
That would be fantastic, although even just the way you've done this here is great. I've got a few old Kindles that would be good to convert to displays, and if I could just install a server and a client, it would take a lot of the work out of it.
No matter what, jailbreaking would be the most difficult step in the process, but the library I linked above takes a lot of the work out of it. It's entirely undocumented atm (I am surely the only one using it), but it comes with an install script you can run on the Kindle to do the setup once you have the jailbreak done.
They really ought to, it's a fantastic reuse mechanism.
Like I totally understand why they wouldn't for new Kindles, since I assume part of their ebook sales help subsidize the hardware, but if they enabled it once a device hit 5 years old or something, I don't see what they'd have to lose.
> I don't see what they'd have to lose.
If there is a cost or liability, then most businesses will avoid doing it.
There usually has to be a clear financial benefit: businesses should make profits - they are not social services or hobbies.
Fortunately businesses contain people and people often do altruistic things for non-financial reasons.
I did this with an inkBOOK, which just runs Android. Loaded on a Chrome APK and pointed it at a webpage I made. `document.documentElement.requestFullscreen()` enters true fullscreen, no status bars. And my local transit service's API is accessible directly from web pages, no backend needed.
I looked into this with my 4th generation Kindle; it seems like it won't be able to use any HTTPS website due to invalid certificate. However, setting it up to talk to a server on my local network would be the way to go. Thanks for the idea!
I am almost certain disable screensaver was removed for later Kindles.
I didn't seem to be last I checked -- the older Kindles require the sequence:
while newer ones only require: I know that for some ad-supported Kindles it doesn't work unless you pay to remove the ads (for obvious reasons), but if you pay then it will.But last I checked was a couple of years ago. I'd be very curious if anyone can report it not working. (Also note the command doesn't survive reboot, you have to re-disable after rebooting.)
Unfortunately, ~ds was disabled by a firmware update a few years ago.
Ugh, that sucks. Any idea how to determine which ones are affected? I.e. what firmware version, or which models it started affecting?
Older models still support ~disableScreensaver -- at some point Amazon just stopped issuing firmware updates for them, I have to assume.
How ironic that not having firmware updates is good... I found the following April 2022 Reddit thread [0] that I remember visiting back in the day.
[0] https://old.reddit.com/r/kindle/comments/u8u7up/disable_auto...
> How ironic that not having firmware updates is good
That's often the case, things going from good to worse. Cf. the removal of Manifest 2 on Chrome for instance.
I don’t follow the space closely, but if you find a Kindle Keyboard (third generation of the product) or earlier, they stopped getting updates ages ago and in fact can no longer use the store (though USB sideloading still works fine). They are all jailbreakable.
As a kiosk-like display, though, they do have that keyboard taking up space.
I only use my Kindle to read outside (at the beach or pool); in the house, my iPad is faster and has a bigger screen. But in the sun, it’s useless. eInk is far superior for that. For the week or two a year that I need one, my 15-ish-year-old Kindle is fine. I travel with a laptop and tons of cables anyway; sideloading just means a few minutes of work after dinner to make sure there’s enough on there to read tomorrow and isn’t much slower than using the internal interface to get books was.
I do miss the free 3G. Obligatory XKCD: https://xkcd.com/548/
Maybe I'm not understanding the use case. I don't want to "take the train". I want to get from A to B. If the train is broken, the workers are on strike, the route is blocked between 1pm and 4pm, or it's outside of operating hours then I want an alternative. So for me, I actually want what Google Maps gives me (or tries to give me). I do not just want to know about trains. Maybe I want to get from the Ferry Building to Oakland and maybe the Bart is broken so i'd be better to take the ferry. Maybe it's late so my only option is a taxi/uber.
Alternatives are especially important in other cities. In Tokyo if I want to go from Shibuya to Azabujuban I can take
* Ginza Line->Namboku line - advantages, (1) Ginza line starts at Shibuya so guaranteed a seat if I wait for the next train - though only for 4 stops where I have to switch (2) both lines are same train company so $1 cheaper
* Hanzomon Line->Oedo line - advantages, fastest
* Yamanoto line->Namboku line
* #6 bus - advantages: no changes, disadvantage, slowest
* taxi - advantage: fastest if there's no line for taxis or if I'm confident I can find one quickly
Extra considerations. Each line's station and the bus stop are 3 to 8 minutes walk from each other so if I'm closest to one that would weigh on my choice. Speed matters too, if I'm late. If I have large or heavy packages I'd be more likely to take the cab. Etc....
> So for me, I actually want what Google Maps gives me (or tries to give me).
One thing I find is that Google Maps really, really assumes that walking is very very bad and no-one wants to do it. So for instance, if I'm going to a particular place I will get a 39 bus and then walk 15 minutes. If I ask Google how to get there, I'll get a route with two transfers; if the stars align it'll take about as long as one-bus plus walk. So if I want Google to tell me when the 39 bus is coming, I'll have to lie about where I'm going.
(Also, at least where I am Google's realtime data is questionable, with the data from the operator and some other third parties being more reliable.)
> Google Maps really, really assumes
Indeed, they assume all kinds of things - with no option to customize. For example, they assume that a 1 or 2 minute transfer will happen. Which you might want to override, but can't. You have your reasons to want to route through Caltrain instead of BART... and you can't. This is a characteristic of the brand really: Google people know what's good for you. I mean, them.
I had the same problems with Google Maps. I ended up using Apple Maps in Japan and it gave much more realistic routes
> Maybe I'm not understanding the use case. I don't want to "take the train".
The use case is routine. A lot of people, most of the time, do indeed want to "take the train". Heroic feats of real-time planning have their place, and it's great to have tools that help you with that, but routine can be covered with much simpler tools just as well.
Even in the Tokyo scenario you gave (which is fascinating -- thank you!) Google gives 30-40 min. for most public transit options, so for rough planning they're all equivalent. Taxi is faster, and bicycle is almost at par.
never met that person. as someone that has long lived in cities with amazing transportation (sf is not one of those with good transportation) there are too many options and people always want whatever is best now, not routine.
you're out drinking - which mode is last. you're on the east side of X, which route is closest. you're tired, does any route guauntee a seat. etc....
Berlin, London, Paris, Tokyo, Singapore, Kyoto, Osaka. All this way . there is no "one train"
> never met that person.
Hello! Now you have.
In many cities certain parts of the transit network follow a star / hub-and-spoke layout. The station nearest to my house is on a spoke, and has trains going south and those going north. So for me, an in-home train display only really needs to show the next train in each direction.
And a lot of transit decisions are conditional on things the planning app doesn't know. Am I comfortable riding a hire bike, appropriately dressed, and carrying a helmet? Do I already have a return ticket for the light rail making it the obvious choice? Am I the kind of person who enjoys a brisk 20 minute walk?
Combine that with the fact that the multimodal transit apps don't understand fares, and I find it's simpler to just start the taxi app if you need a taxi.
> Combine that with the fact that the multimodal transit apps don't understand fares
Kakao Maps will give you exact timing and fares for every mode except air
> In many cities certain parts of the transit network follow a star / hub-and-spoke layout
Yeah those who live on a spoke and mostly go back and forth that spoke are a minority because the farthter away from the center the more space between the spokes:)
I feel like the OP is overcomplicating the solution, I don't own a car and all commuting is basically either:
- bus/train/tram crosses my stop 5 times a day - its trivial to learn the 5 times
- bus/train/tram crosses my stop more than 5 times a day - i just show up at the stop and wait
Perhaps my point of view is like this because I'm in Europe, I can't tell really.
Even though most times my train comes every 15 Minutes (and in other places even every 5), I still check for: Disruptions and I try to catch the train exactly. I often get on the platform a minute before the train departs and rarely miss it.
I would find this slightly useful, I live in Madrid. For most of my trips I take the metro; I have two lines nearby, and they are frequent enough that I just show up. But there are a few parts of town that are just not well connected to my place by metro. If I want to go to Atocha, Cibeles or Piramides, the bus is better. But I have three buses that take me to each of those places, and they show up every 25 minutes. If I'm going there, I want to know which stop will have a bus soonest.
I also live in Madrid. Many years ago, wrote a bash script that downloaded the real time data for the bus stop nearest to home from the EMT website and read out loud the minutes for the next bus with festival. We had a keyboard next to the couch, many keys were shortcuts to execute commands like that one. So it was a matter of pushing a key and listening.
For your daily commute, you really do just want to "take the train".
If the train is broken or the workers are on strike, that will be reflected in the unexpected absence of live trains listed.
I pull up Google Maps and plug in my destination when I'm running around the city. I don't pull it up when I'm leaving my home to go somewhere I've been 500 times before.
Experiences with public transit in central Tokyo is don't generalize to the world. It's as pointless as talking in-store shopping or dining experience based solely on that inside a Disneyland. Just tapping Suica takes couple times less than what takes you elsewhere, if at all supported.
[flagged]
without more info you can't know that. further. I want to go to one app. If I want to go to Geary and 24th, there is no train. I don't want to have to take the extra step of thinking about where I want to go and then having to choose the appropriate app. one app will do
Nice. I have something similar with a repurposed Lenovo ThinkSmart View tablet/conference room device, with Home Assistant and its integration to my local transit authority. The advantage is that it's much more out of the box (okay, I did have to flash a custom Android ROM on the Lenovo, but still), it can show whatever I want, and I can also use it to control stuff like my lights or robot vacuum.
I want to mention this beautiful physical led sign of the BART map: https://www.designrules.co/
If you want a transportation app built for locals I highly recommend Transit. When you open the app it shows you the transit options closest to you, where they’re heading, and when the next one arrives. Never have to put in a destination.
Android here. Have you looked at the amount of data this shares with third parties? No ads but holy hell. No thanks.
Super cool. I did the same kind of thing with my tidbyt display:
https://github.com/pkulak/tidbyt
My local transit agency (Trimet) is _really_ good with their api. It's public, and a single HTTP GET to get the ETA on every bus that serves a given stop, so it wasn't event that much work.
When realtime information was first available from my public transit system, it was via an SMS system that was widely advertised at every bus stop and train station, wherein each received a five-digit ID code. So you'd text that code to a special number, and it'd reply with the "NextRide" timings.
Unfortunately, it was wildly inaccurate. Every time I queried it, it said the bus had already left (I'd been standing there 10 minutes) or it didn't take into account active detours, or something. The only thing it was good for was determining the headways between buses (15, 20, 30 minutes?) and then you could at least calculate your longest wait at that stop.
The next iteration involved installing the bespoke and quite buggy app provided by the transit authority themselves. Now this theoretically depended on the same GPS trackers in the coaches as the SMS system had. But I had major troubles with the app, and I didn't like it, and it barely did anything else, and so I uninstalled it. And I did without it for a while longer.
Now the app is improved, and it's got QR pass technology included, so I reinstalled it, and I use it more. But, for tracking the buses, I prefer Google Maps.
Our transit authority graciously shares 100% real-time tracking info with Google, and you can track any bus in Maps, including crowdsourced info, such as "How crowded? Is security aboard?"
It works really well, and really accurate; displays every delay and updates by-the-minute as buses or trains pass each stop. Sometimes I pass the time just sitting there and watching my bus make its way down the street.
R.I.P. Pebble:
https://developer.rebble.io/developer.pebble.com/community/a...
""" Caltrain is a Pebble app that displays upcoming trains at a station, and where those trains will stop along the remainder of each of their routes.
Finally, it uses PebbleKit JS to retrieve your location on launch. If it gets a response before you manually choose a station, it will automatically show the station closest to you. """
...you could literally map that "applet" to long-press on a button, and get the info in like 5 seconds.
For extra "dick tracy" spice, call an uber from your wristwatch with 3-4 clicks (long-press, ok, next, ok => "your uber will arrive in __ minutes"). Actually, reviewing the app docs, it looks like it was only two long-presses to request $LAST_USED_CAR to $CURRENT_LOCATION.
https://www.uber.com/blog/pebble-smartwatch/
https://pebble-help-legacy.rebble.io/help.getpebble.com/cust...
Buttons, people! Buttons!
We've really taken steps backwards since pebble. We used to be able to respond to messages by talking into our wrists, for ~$100. I switched to Garmin after using rebble for a bit, and that's the feature I miss most.
I'm the reverse, I never wanted to "input" to the wrist, but really appreciated the notifications, Bluetooth disconnect warnings, "the timeline" interface, and the necessarily limiting interface of 4 buttons (specifically: music control while in the shower... play/pause, next track, pick a station from a list, etc).
Totally understand how some loved the ability to compose/respond to messages, but that never made sense to me.
Garmin, Amazfit, and BangleJS comes close, but #buttons, #battery, and #b&w (well, always on, transflective, sunlight readable)
I love the premise and I felt that a lot in SF. The transport system is not really a complex enough network that I need to be shown routing options. Just wanted to know when to leave the house and not stand at the stop for 20 minutes :’(
(In a highly networked place like London, seeing all options is helpful)
I made a (free and ad free) app for BART that tells you if you need to run to catch your train or not. Instantly upon opening the app, without needing to tap anything, it automatically figures out which train you want and helps you hurry, just a little bit, to make the next one rather than wait.
Feedback appreciated!
https://apps.apple.com/us/app/should-i-run/id933717076
I made this BART arrival display website designed to just show upcoming departure times for a specific stop. The idea was that this could be used on a wall mounted display so you could glance at it on your way out the door to help you know how fast to walk. https://bart.blinktag.com
It ought to be easier to get a blank slate of a small device with some compute power and a screen, like the Kindle here, without having to jailbreak something.
There is one, it's called the Raspberry Pi ecosystem, but due to the small volume and the target audience largely being not-my-own-money (think educational institutions), the price is quite detached from the production cost.
I think more of the issue might be the eink screens. As far as I can tell, there just aren't 5+ inch eink screens for cheap.
yes they are: https://www.waveshare.com/product/displays/e-paper.htm?___SI...
A 4.37inch E-Paper in 3 colors is $24, problem is need you to program yourself (they have code sample in python, for raspberry pi), and you need a raspberry pi, case, cables, etc.
Also, these cheap epaper displays are, of course, of lower quality (slower, lower resolution) than an kindle display.
They jump up in price pretty quickly as size goes up. The cheapest 5+ inch display I found at your link was over $40, and it's about 100PPI. It's certainly not prohibitive, but certainly priced high compared to "just jailbreak a kindle" for any remotely kindle-comparable display, right? (remotely comparable in size and resolution)
I imagine the Kindle is sold as a loss leader, plus whatever economies of scale/negotiating Amazon does pushes the price down heavily vs buying a single unit from an electronics retailer
They look kind of cool, and now I'm trying to come up with a project such that I can justify buying one.
Arduino-compatible devices based on ESP32 are plenty powerful enough at a fraction of the cost.
CPU is indeed beefy for a small wi-fi chip, but the small RAM hurts. Yeah, there's QSPI PSRAM but the bandwidth is lacking as well.
Not to diminish OP’s project, but the stated goal of “know when each transit line has an upcoming train/tram/bus” is probably already achieved by https://transitapp.com/ - the default view when you open the app is a list of nearby transit lines, sorted by distance and showing the next departure for each.
Like that there's no ads but it's a big no on the "data shared with third parties". Assuming this is how they make money? I'd rather wait 10 more mins for the bus I just missed.
You can also bring up a station's departure board in CityMapper by clicking on its marker in the map view.
And Apple Maps has a built-in nearby transit button that does similar.
In truth I rarely ever miss a train, a bus, or a plane. They miss me though because they are delayed.
I think travel by bus/train is more friendly when they have "headway".
Instead of a specific schedule, there is a bus/train every "n" minutes.
That works when it's high frequency enough. If it's every five minutes, no problem. If it's every 20, this doesn't work quite as well. If it's every hour it's unworkable.
Really timely, I'm currently writing Arduino code to get my bus departure times displayed on a cheap TFT screen. There's so many projects around this, but it's the first time I see it on a Kindle. Awesome!
Given the post's title, I hoped it would work with trains. In Washington, DC, it works with buses but not trains. What help would you need to make it work with trains?
It's really just a question of the transit provider giving you access to the data. My display shows mostly light rail schedules with a few buses. If your transit provider has real-time data for trains you can display it, if not you can't.
Why render a PNG when the Kindle already has a perfectly workable web browser? And don't even get me started on using Rust for parsing a JSON...
I love how they blamed the flake on node and Javascript, then switched to Rust and also changed the whole approach, which had a hundred times more effect than changing the language did.
I don't blame Node/JS for the reliability issues of the first version at all, they're simply not the tools that I prefer to work in.
> Each of the seven sections on the image represents a browser tab that Puppeteer needs to keep open in order to fetch screenshots. Remember that the Node.js server was running on a Raspberry Pi, it didn’t have an excess of memory to operate in and Chrome is not known for its svelte-ness.
> I picked Node.js for the first server because I was using Puppeteer. I don’t particularly like Javascript, so given the ability to start from scratch I happily pivoted to Rust.
> Next, since we’re not relying on a browser engine to render the display, we will be using a 2D graphics library to render a PNG directly. This should have a much lower resource cost than using an entire browser engine, at the cost of some decreased flexibility.
I don't think they really blamed node and js? They seemed pretty aware that it was the overall arch of the thing that made it non-viable.
> Each of the seven sections on the image represents a browser tab that Puppeteer needs to keep open in order to fetch screenshots. Remember that the Node.js server was running on a Raspberry Pi, it didn’t have an excess of memory to operate in and Chrome is not known for its svelte-ness.
So then figuring they had to effectively redo it from scratch with a new solution, they then switched over to a language and stack they enjoyed, which seems completely reasonable.
> I picked Node.js for the first server because I was using Puppeteer. I don’t particularly like Javascript, so given the ability to start from scratch I happily pivoted to Rust.
edit: Just beaten and directly from the author it seems. :)
I love this kind of observation:
> like most truly useful things we need to build it ourselves
but I was surprised that the author insists on displaying an image on the Kindle. The last third of the post is dedicated to building that PNG file. Is it possible to send text? It would be easier but maybe it's not possible...?
It's the easiest way to display complex graphics on the Kindle which take over the entire screen. Yes, I could use HTML and the browser, but there's a header and footer that I don't want to see (plus I'm not convinced the Kindle would stay awake). I could have sent text, but the renderer available at the CLI is extremely limited. I'm not sure if I could have tapped into a mobi/pdf renderer to make it show up similarly to an e-book, but I'm doubtful if I could have made a mobi file show up in landscape like this. I was also building on several other tutorials that use PNG files, so it just made sense to do this.
Cool! I made something like this on an old netbook in university.
I plotted bus locations in matplotlib, which was what I knew at the time.
The busses would clump up where I lived, so it was helpful to know if I should rush breakfast to catch a burst of busses or just wait for the next wave.
its interesting that the author is using rust and is also trans. its kind of a trend with these blog posts
I say this completely unironically: trans women programmers w/ blogs are a critical pillar of the OSS ecosystem, it rules
[flagged]
I really enjoyed this read. I've been wanting to tackle a side project that uses old hardware and this has been inspiring!
I also didn't know that skia had rust bindings and it seemed pretty easy to setup.
It's been a nightmare to try setup in c++.
Haven't finished reading yet but a transport version of a bloomberg terminal would be great.
If anything goes wrong with a train journey I find it useful to have as much information as possible.
Nice! Much more sophisticated than my Raspi Zero version from 7 years ago [1].
[1] https://github.com/Scarysize/transit-pi
This was wonderful. Extremely hackery. I did skim the last half, because it’s largely code.
The CTA (in Chicago) has a nice customizable “next train screen” web app that’s perfect for this:
https://www.transitchicago.com/developers/diydisplay/
I always want to get into rust but examples like this always make me reconsider. Every time I want to code something and start with rust, I switch to python 5 minutes later because it’s just so much easier (for me at least). The code to build exactly this dashboard would probably be less than 100 lines of python. Rust is much better for performance (and maybe runtime correctness, but most errors here would be parser errors anyways) of course, but for this application, I don’t think it really matters.
“where are you and where are you going?” Is a delusional question for a transit system but it’s a good question for Uber.
When I was involved with the Green Party we were thinking of “just doing” the things the local government wasn’t doing and I think we set a fire under the bus company’s butt to fix a large number of usability problems that we were going to fix for them (and stick our logo everywhere.)
The bus company was very negative on us extracting schedules from their web site because they wanted to see what people were searching for — hypothetically they could have added new service somewhere if there was demand for it but (1) it seemed hard to believe they’d really do it because changes are so infrequent and (2) they never showed any sign of caring what people thought, why would they start now?
BART's on a takt now though. so you just have to memorize like 3 times for your local station
That’s only true if they reliably follow their schedule.
Yeah, i wish more programs worked like this.
I wrote something similar on a smaller scale for the keihin-kyuukou line in japan: https://rail.esrh.me. Now I live in tokyo and there's several transit options closeby so I would love to have some always on display like this in my room.
Unfortunately, while public transit in the US and Europe seem to be tracked by services with developer friendly APIs, this is not the case in Japan as far as i know -- not that much of a problem back then, i just needed to do some light web scraping.
I wrote all of the scraping/data and processing/frontend code in clojure and clojurescript, and wrote a small blog post about it here: https://esrh.me/posts/2023-03-23-clojure
Feels like a feature Google could make by using the same data they use for traffic monitoring. They know where the train shaped mass of people is.
Wow what a cool writeup. Two things stuck out for me (I'm only halfway so forgive me if you address these issues). I have two comments on processing the 511.org data. First, you generally want to use a streaming parser rather than one that allocates memory to the entire response. Second, you should filter out the most data first (in this case, dropping the stops you don't care about) and then filter the least data second (dropping the fields you don't care about). This idea is similar to how, in SQL, you want to order your WHERE clauses such that the most impactful comes first.
This may not be strictly required by your use-case at this scale - 27MB of data is not a lot, after all. And the filter ordering performance is probably trivial given its all in memory (I'd be curious to see a benchmark!) However, a) efficiency is always good, especially on a Pi, and b) if you make the code more efficient it makes it easier to scale later if you want to.
Also, regarding the BOM problem you had, wouldn't it be nice if all APIs had a "developer feedback" mode built into it? That is, you can send feedback to the ppl who own the API endpoint by...posting to the endpoint. In this case you could send "Please remove the BOM. k thanks."
This sounds like a fun project, but there are existing apps whose default page is "when is the next bus/train coming up on stops near me"
Transit App (https://transitapp.com/) is one of them and I freaking love their interface overall. This app's default view shows you the next bus (in either directions) at the 3-4 transit stops closest to your current location. And you can customize/add favs too. It's a beautiful app, also allows for multi/mixed-modal route planning (part walking, part bike, part bus).
To be honest, I found having something physical and on the wall and always present _really_ helpful. When the train/bus comes every 15 minutes, being able to casually look and see if you should make a dash for it is way better than pulling out your phone, bringing up an app, and entering your destination.
Plugging my own project here [1] for SF's Muni to say I 100% agree with you - the phone is a trap! There's something so charming about having a thing you know you can look at anytime and __no matter what__ it's doing exactly what you expect it to be doing.
[1]: https://github.com/mattegan/muniscreen
Oh yeah of course, I personally have a physical screen that shows live feed from my local transit agency's GTFS real time feed. I was just pointing out the app for those who don't have the time/interest to build something physical.
Thanks - this is exactly what I need especially the widget which displays nearby upcoming trains and buses on the home screen.
A. "Busses" should be "buses", I think? Or am I stepping into a holy war... Maybe it's a British vs American English thing, but a quick look says that Merriam-Webster agrees. Maybe it's a choice by the author, in which case, fair enough. If I was the author, I'd prefer knowing, anyway.
B. Super cool article! I've an old Nook somewhere being neglected which I am now moving up my list of devices to do some messing with and find a use for. Excellent stuff.
'Buses' is probably more standard, but 'busses' as a plural noun is common enough that it's probably not worth making a fuss about. The great/terrible thing about English is that there is no central authority; if people use it, it is English.
Yeah, IMO the plural noun is "buses", while "busses" is a conjugated verb, ex:
"When the regular buses aren't running, he busses people around in the minivan."
The OED says that "busses" is an acceptable plural in American English (I haven't read the article though, so I don't know what dialect the author speaks/writes).
> You might see the plural busses, but that form is so rare that it seems like an error to many people. [...] When the word bus was new, the two plurals were in competition, but buses overtook busses in frequency in the 1930s, and today is the overwhelming choice of writers and editors.
-- https://www.merriam-webster.com/grammar/plural-of-bus
Went ahead and used Google Ngram viewer to show the popularity difference, with some context-words to ensure it's comparing cases where a plural noun is being used:
https://books.google.com/ngrams/graph?content=the+busses%2C+...
https://books.google.com/ngrams/graph?content=multiple+busse...
https://books.google.com/ngrams/graph?content=took+buses%2C+...
Ooh nice, I didn't know that Ngram tool! I've heard references to word frequency but didn't know where to do it. Thanks for jumping in with a bit of analysis.
Of course, if USA-based anglophones want to continue using a particular spelling or pronunciation, we know we don't have the power to stop them. I bow out of this one.
In this case, we really, really don’t want to continue using “busses” as a plural noun. Merriam-Webster is the authority. We’d rather fight our holy war over labor and center.
The buses spelling looks to me like it should rhyme with fuses. Busses has the virtue of not... doing that.
Ehh... Cough, tough, bough, lough, slough, and rough called, they wanted to know when English phonology became logical and consistent, and why no one informed them about it?
Rough and cough have different sounds so... buses is the winner? Not seeing the connection.
-ough notoriously has anywhere between four and twelve different pronunciations (if you count strange example with a limited number of words, like hiccough for hiccup).
The point I believe the parent post is making is that you cannot assume that buses would rhyme with fuses, because English orthography is so inconsistent.
Which is partially true - I haven’t seen any research to the effect, but I’d guess you can still predict the pronunciation of an English word with better than a fifty percent chance of success.
Sorry, I thought it'd be obvious that all those -ough words have different pronunciations (for most people, anyway, I think) and that I'd be making my point clearly and lightheartedly. I was just saying that English spelling isn't always "guessable", or how you think it logically should be. [Even though it may well be guessable the majority of the time, as another responder points out, for some reason].
The fact you think "busses" is a preferable spelling to "buses" because it might help you pronounce "buses" differently to "fuses" is only relevant to you yourself. I would have thought this was tautological, myself.
In summary, we could avoid all these fusses with a bit of effort to adhere to accepted usage.
I sympathizzze he-ugely with what you're saying, as "busses" looks very strange to me, I admit.
"Buss" is an archaic word for a kiss, so "busses" looks like a verb straight outta Shakespeare to me!
[dead]
[dead]