A Raspberry Pi-powered live train station sign
balena.io
balena.io
A bit more glass half full, and reduces the light count by 33%!
[1] https://gist.github.com/kevana/32bfa486d9fb0aa20a19694d1b69d...
Much better than the MTA's website... though slightly less useful if you're not me commuting to work.
What I learned from this exercise is that:
1) The estimates are consistently inaccurate; downtown trains at Chambers St. always arrive when the clock says "2" (minutes until arrival).
2) They use some sort of distributed cache that doesn't remain consistent; as you bounce between backend instances you get different results, but often the same two results. (The red/green lines under the station names indicate freshness.)
3) The clocks in the stations don't work when it's too hot, but the actual data collection/processing is fine.
It was very annoying to implement, but as a user it is very nice to know how much thought has gone into it.
There is a ~mirror at https://unop.uk/tube/ in case CloudFlare go down. Although as I discovered recently, this doesn't help as the API runs on them too! There's another API I could use as a backup but it's not as good.
For the curious: https://reactube.com/
Given that we've both independently implemented basically exactly the same thing, I wonder how many other people would want something like this.
Happy to answer any balena (or train station sign) related questions, of course :)
I have been looking at building a project on Balena OS and raspberry pi 0 W. I want to deploy it in a hard to get to place and don't want to have to replace the SD card for a good amount of time.
I was wondering if Balena OS with Balena cloud managing it puts more or less strain the the sd card write cycles than Raspbian.
Chris's application seems to write little or nothing to the sd card so in your experience how would it last? A couple years?
Is there a way to push device logs to another service to keep track of them long term?
How did you come up with the pricing model of essentials vs micro-services?
The pricing model is along the lines of "essentials is for people looking for a better OTA solution whereas microservices is for people who consider their devices mini-servers". So it's more a difference of perspective of the customer that allows us to group features and give more to the one crowd without alienating the other crowd with high prices. Not sure if that makes sense.
Having built a similar bespoke stack in the past, Balena would have been a steal! It gives you the development, provisioning, build & deployment, configuration, management, and even remote debugging workflows out of the box. On top of that, it's built to require web/cloud developer skills, not embedded skills.
To do that, we have created several companies worth of infrastructure, from a cross-architecture container build system, to a bespoke OS supporting many device types, customized docker engine for embedded use cases, container deltas for bandwidth saving, etc. Even simple things like "how do I make sure my device gets DNS in an arbitrary home network" are incredibly tricky, and balenaOS gets it right almost always.
Which brings me to my next point. We are fanatical about support. We take responsibility for our customers succeeding, which means we constantly find and improve sources of friction. Using Balena gets you that backup team, but most importantly gets you hooked up to the flow of improvements we make all the time. Cloud companies charge $15 per server per month for various devops type services. We do very similar things but for devices that are smaller, more diverse, in tougher conditions, with less reliable networking, and ask for just $1 per device per month.
In other words, when I was in the shoes of our customers, producing even a fraction of the value and piece of mind that Balena provides in house took a lot of work, which was money, and that's not accounting for the time and risk of not getting there in the end. If I found myself in that situation again, knowing Balena and not using it would essentially be negligent. Our most fanatical customers are those who have tried to build something like it themselves, because infrastructure is so easy to underestimate.
As a long time customer of balena, I can assure they are a ton for what you pay for.
* faster development times: git push and your code is built and compiled in their cloud (with real ARM servers), and downloaded from your devices. Doing CI/CD for iot is a great experience with balena.
* the support is tremendous: several times I found very specific use cases that failed or wasn't what the balena APIs where expecting, and after contacting the support, they even put me directly with the developers in charge of those areas to discuss if it makes sense to add it as a feature to balena, or if they can provide me a workaround
* again, the support: I have around 10 years of experience with Linux derived systems, but some things still are black magic to me (like debugging problems with aufs partitions). The support of balena goes to the deepest level possible to solve your problem, even if you aren't in the private support tier. You just enable access to your board to support and they get inside and try to find the problem. It's truly amazing. They are even open to discuss how to improve what they are giving you or the tools.
* total control of your fleet: need to set a flag for a client? Just set an environment variable from the api or the dashboard and each device will update its state when they come back online
* amazing tools: the balena dashboard feels as polished as their other projects, like etcher, if not even more. Any kind of need you have (remote access to the device? Proxy to a port in the device? contact the supervisor of the device from a proxy inside their VPN?) they give to you.
And even more, but this is already a long post.
This job looks awesome. Is it full time? I assume it is but worth asking.
In either case I can completely see the value in these IoT SaaS services. A lot of companies I see which want to get into IoT are experts in their own field - not networking. It is very easy to underestimate how much work it is getting everything up and running which is required for a product. You can always roll your own cloud solution later on once you gain the expertise and market fit.
Thanks so much for Etcher, btw - it’s the only GUI software for flashing Pi images to SD that I’ve had good luck with on Mac.
But admittedly when I saw the title i was hoping for a mini version of those massive flipboard signs. Those things are amazing.
Maybe someone enterprising might (or has?) created a character flipping routine that mimics the search through the tiles and set it to the authentic sounds?
The attempt by that company to create their own digital version is really bad. (search youtube for it)
https://www.theverge.com/circuitbreaker/2018/1/11/16876582/v...
I've never used it, but it does look interesting.
I'm also sort of happy with the 'modern' ones that are actually LCD screens with speakers making the noises. It's cheating, but it's a nice tribute.
"Yep. Its origins lie in the old <std.h> header we developed at Whitesmiths, Ltd. in the late 1970s. We used the typedef BYTES as the type of sizeof, to be sure we could count all the bytes in the largest declarable (or allocatable) object. X3J11 chose size_t to follow the *_t convention that had begun to creep up in Posix."
https://bytes.com/topic/c/answers/221996-origin-size_t-curio...
Do we have different senses of humour, or have you heard something different???
[1] https://www.telcomhistory.org/connections-museum-seattle/
As an indirect result I now have a project in the works to make them. The concept is simple, but building them to be inexpensive is a challenge. Every extra bracket or fastener gets multiplied by _n_ modules.
I'm a lazy engineer, so I avoid doing tedious hand-crafted stuff. I'm using 30pt museum board for the flaps currently (I was going to use plastic, but found that matte paper types of material work really well).
Thus most of the work has gone into designing something that's highly repeatable with minimal labor. All the cards are printed and then laser cut, the bracketry will be CNC waterjet and has a single bend, the center hub is 3D printed. I'm making it DIN rail mountable for easy installation and maintenance.
Here's a sneak peek. https://imgur.com/a/2ROn6Nd
Right now it's focusing on 40-character flaps (not super convent for clock-making), but it's open-source so I'm sure you could modify it for your purposes with some effort.
Software: https://github.com/dmd/clack
There's still a problem I don't know solve well, holistically. When you do something with UI there's inputs from humans (buttons, knobs, etc), the network and timers. I'm completely lost how to coordinate that, especially when I use an LED/OLED display.
How to make sure a single screen is displayed long enough to be readable? But on the other hand how to react to all inputs? And how to deal with some inputs/triggers being more and less important (e.g. "modal" screens over static screens)? Also how to make sure not to get lost in the threading mess that I just created? The cherry on top is, some inputs require "short term memory" -- like patterns of button pressing (double/triple press/long hold) or rotary encoders.
In the end I give up implementing a lot of features.
Each task has its own stack, and can communicate with other tasks with mailboxes or shared memory (with a lock).
You'd have a task for each of the things you mention: debouncing a button, drive the display from a buffer, and application logic.
The application logic then doesn't have to worry about bounces, how long it'll take to drive the display, etc.
Modal screens over static screens is orthogonal to this though. You'd need to build a priority scheme, and only pass down events to the current on-screen view.
I'm using MicroPython and this is what I want to stick with. But I'll research how RTOS is doing things and make an equivalent.
One thing that always annoys me with those signs is when they try to put too much information on them. You have all of the stops, fine. You then have all of the information about the train splitting which you might well need. But then they start adding information about short platforms etc. It takes several minutes for it all to scroll past. Which is super annoying if you're trying to work out if the train standing there stops at your station.
https://www.windytan.com/2014/06/headerless-train-announceme...
https://www.windytan.com/2013/11/decoding-radio-controlled-b...
I have like 10 ESP32's lying around my house, they're fun to tinker with, but my Raspberry Pis get a lot more attention from me because there is a substantially lower cognitive overhead with them than the ESPs. If I had a plan on selling my stuff, then yeah, the Raspberry Pi might be overkill and I'd consider going for an MCU module. However, for a fun little DIY project, I don't see how an RPi is a problem.
EDIT: Realized I forgot to mention another point; not everyone really wants to muck with pointer arithmetic for simple things; this app was written in Python, and as far as I know, the ESP32 chips are mostly C/Arduino; I realize that there exists NodeMCU and such variants, but due to the Raspberry Pi being "Just a computer", you have access to virtually every language under the sun.
Easier than what? Considering you have to use the already ill-suited for UI HTML/CSS/JS cesspit, I'd say Electron is a lot worse for the "simple desktop app" than something like Lazarus.
If this was a commercial project, I would agree completely (and from a BOM cost, the manufacturer would be a lot better off investing the time in the dev on a microcontroller)
μPython is fine, but typically a programming language is about more than just the language.
All things you basically don't need for a little project like this.
The catches are a) you don't have a lot of memory, and b) you have to watch little flickering LEDs to know if your app installed correction.
They're designed for different things though - if you wanted a battery powered version that updated on a button press else slept, ESP, if you want live updates all the time, Pi is fine!
The Pi0W probably won't run a day on the same battery.
http://www.geekstips.com/wp-content/uploads/2017/10/esp32-po...
vs
https://raspi.tv/2017/how-much-power-does-pi-zero-w-use
Considering that he pi as way more ram, an SD card and a GPU, and is running 4 times as fast.
the important take away is that they have different use cases.
Though I do agree it depends on your use case, if you're plugged into the wall, a Pi0 might be the better option.
I much prefer using an ESP32 for something like this because I don't have to deal with installing distro's, updates, etc.
Ubuiquity can only be stretched so far in a single tool before the benefit you derive from adding yet another feature is outweighed by it becoming very slightly worse at everything else it does. Smartphones are great, but as a backup computing device, in much the same way keyring multitools are. And the best of them are still measurably worse than the best non-smartphones at actually being mobile phones.
Next meeting in X minutes. Also my calendar is kinda full, so seeing conflicts for the next meetings would be super-cool.
Christ. No wonder everything in our industry sucks.
Been meaning to get a PI and do something with it for years!
Phone someone? Phone them? Gods man, do you think this is the 1800's?!
I remember trying to do a similar project for the bus stop at the corner of my street to know when to leave to catch the bus. It was fun, but I never really finished when I realised how big just the Pi would be (still powered by usb-a, etc).
Nice to see this one so well executed!
Regarding the size of B series, unless I need the ports, I almost always snip out the ports — don’t bother desoldering it, the ground plane in Pi acts as a massive heat sink. Instead, I snip slowly and carefully the metal housing of ports, and then wiggle the plastic bits until the break away. Reduces the size, and leaves sufficient space to put small modules in place.
I posted a few pictures in my previous comment here: https://news.ycombinator.com/item?id=20462711
I haven’t written it up into a blog yet, but everything to get you started is on my GitHub at https://github.com/chrishutchinson/train-departure-screen. Very happy to help answer any questions too
I wrote a proxy to make it easier to use (https://github.com/jpsingleton/Huxley). Been meaning to port it to .NET Core when I find the time. There is also an old Python client here: https://github.com/HackPartners/darwinrest
You can find many more resources in the community (https://wiki.openraildata.com/ https://github.com/openraildata https://groups.google.com/forum/#!forum/openraildata-talk). We're pretty friendly, say hi.
If easy to install using the OS we build and you can update it remotely through an API or of course on-device.
And it made me wonder if bus transport data in my city is available for everyone - we got few displays around, two services/applications that show the current position for each line...
(Not my video; someone made it using the program I made)
Maybe a bit too primitive. It worked pretty well for about a year, until I found that the CompactFlash WiFi adapter was only 802.11b and there was nothing newer available that was compatibility with the PocketPC. It ended up being a choice between keeping the gadget running, or being able to run my WiFi network at 802.11g speeds with modern (WPA) security, so the latter won out.