- a power button
- a real time clock
Crazy it took this long but finally, seriously.
Downsides here are that it might need more active cooling whereas previous generations worked without it.
Also, ugh:
> Gigabit Ethernet, with PoE+ support (requires separate PoE+ HAT)
The RTC is a huge deal to the people who care about it.
How many applications would you have where timing is critical but you won’t have an external time reference that would be still viable without a guaranteed power backup?
Here's the deal: RPi<5 runs at the speed of the voltage coming in. The OS creates a fake software clock that assumes it's a perfect 5v, but in reality not only does voltage fluctuate, it drops over the length of a cable run. If you have, I dunno, 70 Pis connected, the 5v on the first one is very different than the 5v on the last one, no matter how frequently you ask NTP to broadcast.
The first thing we did was deliver 12V down the wire with a high quality power supply. Then we used UBEC buck converter modules (intended for RC quadcopters) to deliver power directly into the Pi via its pins.
However, even now you're just chasing physics. There's no way to send a command to all of the Pis to do something right now. Instead, we tell all of them to do something at a very precise moment in about three seconds. In our case, this meant writing a very low-level C program to listen for raw UDP messages and trigger the camera module at the hardware register level.
The only way to verify that it was working as well as we believed it did was to create a reference clock. We had a friend build a 20 LED timer that would count 10ms and 1ms increments.
We achieved < 1ms syncronization across 70 Pis in this manner.
We needed it to be small, low power, low heat, provide hardware level access to a camera module, be ethernet accessible. Oh, and under $100 including a fixed M-mount lens.
At the time, it didn't seem like rolling our own hardware would have been faster.
I would argue - given we succeeded at sub 1ms syncronization - that the Pi was close to the perfect tool.
It just would have been even more perfect if it had an RTC.
For my Pi's I buy a separate RTC (uses GPIO pins). There's various available, the DS3231 is the most expensive but also the best. If you buy it in bulk (70+) I suppose you could shave some money off. If you're OK with a cheaper one (less than half the price) which functions less well (but still does the job) then PCF8523. I got mine from a local Adafruit reseller.
We couldn't justify adding ~$2500 to the bottom line, but you can be confident that we sure did argue about it.
I'd say 50/50 that I didn't know what I2C was in 2014.
Still, if we had gone and designed our own RTC daughterboard, it would have replaced the UBEC in our architecture diagram. We were buying those for $3-4 in 1000 unit quantities.
So, had you been on hand a decade ago, you might have won the argument although if I put on my board member hat, fabbing our own PCB sounds a lot scarier than buying boxes of buck converters.
It's hard to express how wild it is that they just pop right on and guarantee close to perfect voltage to each device.
https://www.alibaba.com/product-detail/UBEC-5V-3A-5A-7A-15A_...
From your URL, the second part made me wonder if the statement is correct: "UBEC 5V 3A/5A/7A/15A BEC 2-12S Lipo Step-down Module External Power Supply Full Shielding Antijamming For FPV Airplane" would this actually work?
And now, you too can share in the late night cackling joy we experienced so many years ago.
Those three pin headers on the UBEC just glide right into place on the +5/GND pins at the top of GPIO row.
Note that the graphic animation also explains that this UBEC is certified unisex... so make of that what you will.
Still, I would politely suggest that you're underestimating the part where we needed low level access to a camera module that came with the RPi.
Even if the ESP32 had been out, we didn't have anyone handy to spend six months reverse engineering CMOS registers.
Everything is super easy a) in hindsight and b) when you're commenting on Hacker News and not actually doing it.
(And I would politely ask that you don't make assumptions about what I might or might not have actually accomplished in similar spheres, you have zero idea.)
Happy to answer any further questions you might have to the degree that I'm able.
You can attach a function to a pin, and CPU force-jump into a preprogrammed address for a handler routine, which leads into your code, then return(return(return())) back to where it came from. The trigger can be delivered by, say, a Xenon flash pointed at the ceiling and a light sensor, or a dedicated pair of wires from a master Arduino, or a intentional glitch in power line, a drone receiver per each pi all on a same channel, etc.
> fixed M-mount lens
I assume this is meant to say metric threaded C/CS mount for surveillance cameras, as M-mount is boutique full-frame Leica mount.
The RP2 was indeed low powered compared to the Intel/AMD powered systems we were otherwise familiar with.
Outside of the bubble of people with EE skills, however big the bubble is, stopping to learn expert-level mcu programming from scratch is rarely the way things work in a software startup. Despite the obvious focus of this thread, the hardware we assembled and configured was all in support of our software.
On the contrary, I've had a number of solid back-and-forths with folks about GPS, GPIO and homebrew RTC daughterboards that we could likely find success with today - almost a decade after we built what we built.
I'm honestly not sure what else you expect from me. Should I apologize for our relative ignorance at the time? Are you upset that I'm proud we managed to succeed despite doing things differently than others might have?
However, if you have more specific technical questions, I'll try to do my best.
Each clock is monotonically increasing, with its individual drift. NTP will pretty soon find out exactly what the right polling interval is. Even if you run it in broadcast mode (why would you though, with only 70 devices).
Everything you said is totally legit unless you're addressing devices with software clocks that are running at speeds dictated by subtly shifting voltage.
Remember, according to the Pi itself, it's 100% in sync. No problem hereeeeeeee (robot voice as voltage dips to 4.9887 volts).
How cheap is cheap?
It depends. Hence my previous comment.
> How cheap is cheap?
Google says unit retail price for module with PPS output can be under $5.
However, if we could have used GPS at a marginal cost of $5 at the time, it's very likely we would have been excited to hear about this.
Thanks for the lightbulb moment.
The internal "clock" time would start to drift immediately after it was set.
Can we mutually agree that in a year of not-dumb people trying everything we could manage to achieve the best outcome, we tried a lot of things and we often didn't know what we didn't know?
If I was going to do it all over again with the decade of engineering skills I've learned, I would look towards fabbing our own RTC I2C daughterboards and trying some GPIO-based approaches to triggering.
However, given our constraints, the solution I've described above worked incredibly well. I wouldn't be embarrassed to do it again.
Mine does after I got an active antenna for it.
> How cheap is cheap?
I got a u-blox NEO-6m module for a few bucks, add another few bucks for the active antenna. The newer GPS modules are much better (more satellites, faster lock etc) but this is sufficient for me.
raspberrypi is about value engineering. Making stuff fast and cheap enough so that you can do useful work, but not worry too much if you break it (on the one hand) Or give access to someone who's never had a programmable computer for a price that's cheaper than most mid range lego sets.
peak power usage also raised to 25W, as now a 5W/5A psu is required.
But in the end... features require power, we can't really complain much.
isn't this just like the 4?
I'm happy with a separate accessory, but wish they could've kept compatibility with the previous versions.
Anyway, I have been wondering whether a headless-oriented SKU wouldn't make sense. Pay for the PoE BOM by jettisoning the video output.
"Wireless" speakers (they'd be networks speakers then) / home assistant devices / media players and whatever else should always be attached with a network cable, so just power them over PoE. I'm still annoying that the AppleTV isn't PoE enabled. That's not a device I'd use over WiFi anyway.
You could always use PLC to use your eletrical network as a data network. I use that for IP cameras. Unfortunately, I still haven't found a PCL adapter providing PoE power.
I've used "informal" poe where you have a cheap injector/splitter that puts a nonstandard lower voltage over the ethernet.
https://www.amazon.com/dp/B00NRHNPUA
but real poe is getting more popular, poe switches are becoming available and maybe the hat is worth it.
There are also middle-of-the-road solutions:
https://www.amazon.com/dp/B07TJ3ZNJ4
basically poe splitter that has a usb-c power out for the pi
I'd be surprised if the majority of RPi's userbase didn't used PoE. Having to cart around a power supply isn't a very attractive option when all you have to do to power the device is simply plugging in a yank-proof RJ45 cable. It's also cheaper as you don't have to buy a charger.
I actually though it was the other way around. Having the PI powers other devices like IP cameras.
I won't do PoE without reliable official hardware.
And no, you really wouldn’t want a lowest common denominator build anyways. That would leave a lot on the table.
The "firmware" is the now-Microsoft-owned, proprietary, ThreadX RTOS:
https://en.wikipedia.org/wiki/ThreadX
The Arm doesn't start the computer and you can't run any firmware on the Arm that will change this.