Raspberry Pi Camera Module 3 released | Hacker News Reader

Raspberry Pi Camera Module 3 released

raspberrypi.com

141 pointstomstuart131 comments

They expanded the lineup for the Camera Module 3 to include a standard (75°) and wide (120°) FoV lens on both the regular and NoIR (no IR filter) camera modules, and all variants use the Sony IMX708, which bumps resolution from 8 to 12 megapixels, and almost doubles the sensor size.

The most important upgrade is the inclusion of autofocus (using PDAF) with full support from libcamera and Picamera2. It is pretty snappy though not quite as good as something like a Pixel or iPhone.

There's also a new M12-mount HQ camera, for the same price of $50, which is useful for some more specialty lenses (though I haven't run into any M12 lenses in my own work!).

Of course. Still no ability to go above 120FPS. I have tons of comments on this in my history about trying to extract raw frames from the RPi camera modules and go faster if anyone cares to help.

So ridiculous these sensors and data lanes on everything embedded can't get us 240FPS at even VGA resolution.

It is possible!

This article been on the HN frontpage at least twice: "A Guide to Recording 660FPS Video On A $6 Raspberry Pi Camera" - https://blog.robertelder.org/recording-660-fps-on-raspberry-...

- Aug 6, 2019 | 103 comments | https://news.ycombinator.com/item?id=20627574

- Dec 27, 2021 | 64 comments | https://news.ycombinator.com/item?id=29703293

Obviously, the resolution is really low (640x64) but for the price, the quality seems quite nice.

AFAIK the normal RPi boards only provide 2 MIPI lanes while 4 MIPI lanes would be possible by most camera modules and the processor. Therefore we only have half of the possible the bandwidth available. For higher resolutions the bandwidth is a limiting factor. There are some boards and camera modules that use 4 lanes. Those boards use different connectors and therefore are not compatible with the default RPi camera cables this is probably the reason why the 4 lane option is not offered by default.

In order to enable higher framerates you need to set up additional "modes" in some configuration file. I assume that by default only "relatively reliable modes" are configured. That's where the limitation to 120 FPS comes from. Calculating other modes requires some special tool that is specific to the camera chip. Also you need some luck that those modes actually work for you.

It’s so frustrating that the entire CSI camera module ecosystem has been completely handicapped by the choice of connector for the camera module.

The V1 camera module (OV5647) only supported two lanes, so it was a fair enough decision then, but they had a chance to change it when they changed connector on the PiZero.

The connector even had the 4 extra pins specifically to support 4 lane CSI, but it was as if it was forgotten about. The V2 camera came out not long after so the combination would have made for a massive upgrade.

I think they ended up back peddling from the new connector due to the horrific combination of a too thin custom flat flex cable with a connector that could barely meet its 10 mating cycle rating.

It didn’t have to be that way, a standard 0.5mm FFC with decent swing down latch connector is 10x more robust.

I think this is a typical case of nice-to-have but not-important-enough for >90% of customers. The decision is not optimal but the want-to-change is not big enough to overcome the existing installation base. The new camera reinforces this. We could have a new connector with more lanes and a cheap little adapter PCB to adapt to the old connector and cables. But even that seems too much right now.

Your solution lies here: https://github.com/raspberrypi/raspiraw You can use any camera with it and set parameters whatever you like.

Edit: Raspberry Pi compute module 4 has all 4 CSI-2 data lanes exposed. So you can get full bandwidth of this interface and could use high resolution sensors.

> Supported sensors: adv7282m, imx219, ov5647

The new sensor is IMX708 and probably not supported yet.

Write your own header and you’re good to go. I did it as electrical engineer generalist and it worked fine. Their support forum is also very helpful.

Could you give a bit more detail where to get the information that we need to put into the header?

Looking at https://github.com/raspberrypi/raspiraw/blob/master/imx477_m... it's not immediately obvious where to get the all the values from.

Fiddling with "struct mode_def imx477_modes[]" when you already have the rest of the header file would be the obvious thing to do and would probably work out fine but that is mostly trial-and-error and not a proper method.

Well you need a datasheet from your sensor’s vendor. There are whole description of the register and initialization sequence. Few hundred values. And from these values you can construct your own register map for the sensor in the way as it was done for supported sensors. For popular sensors datasheets can be obtained just by searching.

I reverse-engineered the first Pi camera and you can make it record at all sorts of combinations of frame rate and resolution if you bypass the libraries provided.

The limiting factor is how long it takes to shift a row of pixels out of the CCD and into the ADC - wide-but-short videos can be recorded at 200+ fps pretty easily.

this is exactly what we needed, a camera to attach to an unobtainable device

Even in its height of "unobtainable" I was able to get one without having to try too hard and I was being picky about the configuration I wanted. I did have to buy from a German site but it was obtainable.

I believe it should be much easier now.

To anyone looking, follow rpilocator.com. Supply has been slowly improving.

I managed to get one via a rpilocator.com alert (used the rss feed to send myself an email alert) within about 2-3 weeks of setting it up. It's not perfect but it worked and I managed to get an 8GB Pi 4.

the height of unobtainable was just a couple of weeks ago, and it lasted for almost a year in which rpilocator was only showing a few shops in the world selling a few dozen pis in a different form factor you are looking for at a time.

It certainly wasn't a couple weeks ago and this has been going on a lot longer than a years ago.

Yeah, sometimes you can get one, however it doesn't make much sense to pay 150 Euros, or 100 for a 1GB version.

I paid $60 total. That included shipping for a 4 gig raspberry pi 4

I believe you :) The prices I quoted where from yesterday in Europe / Germany.

The Pi foundation believes supply will steadily improve as this year progresses & will be back to ”you can buy any Pi you want today” by the end of the year.

It’s not /great/, but given the supply chaos of the last few years it is what it is.

Last I heard they were making 7M a year, with very few reserved for end users. To improve the situation they promised 100k reserved for end users. Seems much like the GPU fiasco where a company reserves all their product, leaving none for end users, and the market collapses (worst GPU sales in 20 hears).

What is this legendary Raspberry Pi that this article talks about?

Does this make the Pi webcam a viable project now?

I looked into making one during the pandemic - but i think lack of auto-focus was one of the things that caused me to rule it out at the time…

Auto-focus seems like one of the lesser useful features for webcam (or rather, the use case of a webcam seems to not require auto-focus that much) since the object distance remains largely the same for the duration of the video call, at least the video calls I'm usually in.

Maybe people have a different setup that I, but I usually remain the same distance away from my monitor at most times.

Good webcam setups have a sharp depth of field, which makes the speaker look sharp and the background blurred. This requires auto-focus because a few centimetres matters to be in field.

> Good webcam setups have a sharp depth of field, which makes the speaker look sharp and the background blurred

I'm guessing you mean "shallow depth of field" rather than "sharp" here.

And you probably don't want it to be so shallow so a few centimeters would matter, then your nose could be in focus but your ears not, or vice-versa. That's a bit too shallow.

It also doesn't require auto-focus, it requires you to be able to put the camera at a good distance with the correct f-stop, or being able to change the f-stop one way or another.

Auto-focus is more for cases when the subject/object moves a lot forward/backward from the perspective of the camera, so you don't have to manually adjust things.

I'd say auto-focus is a requirement for UX. Most users won't find the manual focus adjust button.

When taking portrait photos ideally you want the eyes to be perfectly in focus, and the nose and ears very slightly out of focus.

I doubt a small sensor auto-focus camera will achieve that though.

It all depends on your setup. In my experience, effective autofocus provides a bigger quality improvement than the step from 720p to 1080p.

Webcams in poor lighting conditions benefit from autofocus, because autofocus makes it easier to use a larger aperture, improving low light performance.

Laptop webcams benefit from autofocus because there's no room for manual focus controls, and the distance to the user will vary substantially depending on if the laptop's in a docking station, if the user's leaning in to read some small text, etc.

Meeting room webcams benefit from autofocus so you don't need a technician to attend every time it gets knocked out of focus.

PC webcams sometimes benefit from autofocus, because the cable usually weighs more than the camera, meaning the camera often gets moved and knocked about. Plus about 95% of home users with manual focus webcams don't even know they need to focus them.

Streamers have great lighting and cameras firmly mounted on solid tripods - but they're often using mirrorless interchangeable-lens cameras, so they get autofocus for free anyway.

I built one at the time. Imo the lack of auto-focus was a plus, as I'm not moving that much and hate the complete blur to refocus some cameras do occasionally.

Back then you needed a Pi Zero for USB device mode and a specific software version for this to be supported other than that it just worked.

I have the exact same experience with mine. I have been running a specialised software build on my pi zero that I found somewhere and have been very happy with it.

I don't think a Pi webcam is worth the complexity and hassle unless there is a need for processing video on-device on the cheap, but even then, a USB camera may be preferable. For serious streaming quality will still be too far a cry from a Lumix with OBS and for video calls the pricier commercially available webcams like the Razer Kiyo Pro or the Logitech Streamcam give pretty good quality too and they'll actually work in an instant when needed, at not (much) higher cost than a Pi 4 plus accessories plus camera.

But before getting a better camera I'd try to improve lighting, try to have lots of uniform white diffused light coming from at or behind the camera; simple things like white LED strips at the back of the monitor bounced off a wall or other surface behind it can work well because Teams/Zoom will compress and shrink your video to death anyway, so high resolution and fine detail are wasted, but a kinda well-lit person will still look decent even in a tiny and brutally compressed thumbnail on a laptop screen and I'm not aware of any AI filter that actually does a good job at simulating that, and any that did probably wouldn't fit on a Raspberry Pi anyway.

And before doing even that, I'd make sure my audio is actually decent, since that's what most people take for granted since it is for granted in real-life meetings, but being hard to understand or sounding harsh and jarring is something people react to a lot more strongly and viscerally to than bad-ish video, often without even realizing that's what bothers them about a person. Think of it like meeting to get work done in a dimly-lit room vs. in the middle of a construction site – people sometimes do the former on purpose, e.g. to improve projector image quality, but the latter will feel jarring to most, especially if you're the only person who sounds like that. Important to use the test call functionality in Zoom/Teams/... since their compression may reduce quality by a lot. External USB microphones can be a good inexpensive option, something like a Behringer C-1U, anything bluetooth tends to sound rather ugly.

And before doing even that, I'd think real hard if even that's actually needed. Most people seem to not give a damn and are just fine not sounding and looking like a newsperson. There might be more profitable things to put that time and money towards.

This is nice but it's impossible to get a Raspberry Pi 4 anymore without selling a kidney.

> impossible

Exaggeration. I can walk to a shop 20 minutes away and buy them off the shelf for RRP.

That's nice. I live in Taiwan, there's no where to buy it off the shelf.

I could get it off Amazon but it's $260 USD.

Someone who lives in Cambridge saying "let them eat cake" ?

You are very fortunate. https://rpilocator.com/

Seriously, where in the world do you live? Plane tickets will likely be cheaper than aquiring one here

When's the last time you actually went to check if they are on the shelf?

Then why aren't you reselling them?

You could make a request to rpilocator for support in your region.

Stock is set to improve this year anyway so don't sell your kidney quite yet.

I hope so. I’m wondering when the pi5 is due. I thought it was meant to be 2023 but internet says no now :(

My money is 2023. Eben never announces releases early so what he did/didn't say in that recent interview is meaningless. With the added bonus that this time he can also screw over all the scalpers. Let's see!

I thought they announced no pi5 this year specifically.

He said "don't expect a pi 5 next year [2023]". In my optimistic mind that's because he wants to maintain the surprise. I know this is foolish, I know the background of his statement, but I'm going to keep the faith for something in Q3. Maybe it'll be a 4+ instead.

Now if I could just get a Raspberry Pi for under $100.

For the past month I've been seeing some supply of RPi 4 on rpilocator.com almost every day.

Not much, but better than when there were only like a dozen per week. And Eben Upton says it should improve and not be an issue by the second half of this year.

I sure hope that's the case, because it feels like it's been 2 years since I could just buy one at Micro Center, and the other SBC boards I've been testing are either too unsupported/unpopular or quite expensive as well.

Looks interesting, but could find no links to full-res images.

How can we assess a ~12MP camera based on examining images from it that are all inexplicably reduced to 0.3MP?

I have a video up on YouTube with some comparisons up close, and a blog post with one in particular that looks at center sharpness (my website's in my bio). I haven't had a chance to upload the originals anywhere yet, though.

I'd say the sensor is very good but the lenses they're using aren't capable of a full 12 MP of resolution. The wide angle lens controls distortion pretty well, but the standard lens shows a little distortion around the sides.

Still a huge improvement over the Camera Module v2 in every aspect. Autofocus worked especially well, even better than the ArduCam models I tested last year.

Haven't checked the blog yet but that's a great video - thorough and impartial. Thank you! Everything I needed to know.

Link: https://youtu.be/watch?v=1EIFfln3Kxs

Jeff:

Love your channel. Watched your last video on this - neat project.

Do you have any advice on getting 240FPS out of these modules?

I'm not Jeff, but this will be helpful regardless: https://news.ycombinator.com/item?id=34308773

TIP: the image urls in the blog post have width and height in the url, you can remove them view the original image.

https://www.raspberrypi.com/app/uploads/2023/01/ely2_no_hdr-...

https://www.raspberrypi.com/app/uploads/2023/01/ely2_wide_no...

https://www.raspberrypi.com/app/uploads/2023/01/underexposed...

https://www.raspberrypi.com/app/uploads/2023/01/overexposed....

https://www.raspberrypi.com/app/uploads/2023/01/hdr_on.jpg

Thanks for this! I just ordered one for OctoPi to monitor printer progress. I decided to try the wide version.

The camera modules(with PIR, PTZ, auto-focus, night-mode) on a 38mm*38mm board were a solved problem at lower cost due to huge volume of IP cameras from China. However the code on those modules are fully closed(most running an older version of Linux).

RPi's modules are priced reasonably enough to compete against clones from China's vendor, really hard to do, but it did it so far like a magic.

>RPi's modules are priced reasonably enough to compete against clones

third party cameras using _same sensor_ are $5 compared to official $25

do you have a link,thanks!

Is anyone aware of any projects to do auto-zoom on a fisheye lens? (ie, the camera is set up to see the whole room, and then software crops that to just show the area with a person in it, and then re-export that video as a new source so that other software can use it without needing to be fisheye-aware)

This isn’t a complete project, but it’s a good start if you wanted to hack on the idea yourself: https://learnopencv.com/center-stage-for-zoom-calls-using-me...

Can we PLEASE have a proper 35mm full frame sensor in a Raspberry Pi camera? Something like a IMX521?

I realize it would be $1500 but I'd buy it in a heartbeat, there is SO much I could do with a hacker-friendly DSLR-quality sensor.

Have you heard of anyone trying to reuse these kinds of sensors from dead cameras? Are they too difficult to resurrect and reuse?

I want to build a device/product that needs a board+wide-angle-camera combo? Board does not need to be fast. I suspect, even a fast arduino might work.

What are other great combos that exist out there?

ESP-CAM https://randomnerdtutorials.com/esp32-cam-video-streaming-fa...

Does this one have DRM like the last one?

most likely. that's how the pi foundation retains control to prevent cheap Chinese knock offs.

What does the DRM prevent, specifically? Any use of the camera ribbon cable interface by any non-licensed camera?

Edit edit: I still have no idea...see reply from 'mrbteveman below.

Old first edit (wrong): Apparently, yes. This comment[0](2019) explains it slightly more. Evidently the ribbon cable ("CSI interface") can be used by pretty much anything...as long as that thing is not a camera / doesn't need the usual on-board image processing.

Evidently this prevents anyone from coming out with pi-compatible cameras with different features, e.g. different resolutions/framerates/night vision/infrared/zoom/etc.

0: https://news.ycombinator.com/item?id=20261787

I can't be specific but your answer seems correct based on my experience.

it also makes it more challenging (unintentionally?) when trying to use the camera on other OSs like Ubuntu core.

in my experience you're better off just going with a USB camera most of the time. it's a cleaner abstraction point and supports more hardware and operating systems.

> What does the DRM prevent, specifically? Any use of the camera ribbon cable interface by any non-licensed camera?

> Apparently, yes. This comment[0](2019) explains it slightly more. Evidently the ribbon cable ("CSI interface") can be used by pretty much anything...as long as that thing is not a camera / doesn't need the usual on-board image processing.

This isn't accurate, the only thing they do is limit specific sensors from being used unless there is a matching authentication chip on the module, because those specific sensors are the ones they have manufactured camera modules with.

So for example the Pi Camera v2 module uses an imx219 sensor from sony and an authentication chip that the Pi firmware can check to verify the module was actually made by the Raspberry Pi company.

If you buy a 3rd party imx219 camera module (which would not have that authentication chip), it will not work on the regular Pi boards (but it will work with the Pi compute module boards because they don't do the authentication chip verification).

There have been plenty of 3rd party camera modules with entirely different sensors that work on the Pi for years, though with quirks related to the closed source drivers, but the modern libcamera stack on the Pi is explicitly designed to enable 3rd party camera modules.

Really useful info, thanks. I've never heard of this.

It's really disappointing. I have wondered if there are any very-high-quality cameras you can connect to a Pi, but found none. I guess this is why.

there are but you connect them via USB

But then you have the data-rate limitation of USB... is it equal to or better than that of the camera interface on the Pi?

I have a Pi 4, but don't remember if it's USB 2 or 3.

it's 3

Thanks

For a company that likes to pretend it's a champion of open source, it's not very open source though, is it?

Yes, we can forgive them if a vendor refuses to release specs or source (Broadcom, for example), but implementing their own DRM to prevent others from making compatible cameras seems hypocritical and needlessly anti-user.

Is there some legitimate, user-serving benefit to this move that isn't apparent?

the raspberry pi foundation wants to recoup the cost and profit from the time and money spent to develop the raspberry pi camera software stack

this benefits the user by nature of the stack existing.

on the other hand now that an ecosystem has sprung up around this it's arguable that the DRM scheme is only needed to bootstrap the community

Did THEY develop this stack, or did the open-source community?

probably both

They have no business locking it down and preventing people from implementing higher-quality cameras, which would only add value to the Pi camera-interface "stack" anyway. No matter how you slice it, it's anti-community and encourages someone to come along and undermine the entire platform... which would REALLY squander the investment made.

I get your point. the problem these days is if you develop a completely open product your design will be copied and your device will be undercut and often beaten to the market by Chinese competitors.

How is the pi foundation supposed to make money in order to continue manufacturing and designing computers if they are unable to make any money? donations?

They're obviously selling computers as fast as they can make them. Locking down an interface on said computers doesn't seem to be protecting their core business; it seems to limit the usefulness of their core business. And make no mistake: I want them to survive and continue to churn out very cool products.

I just want a really high-quality (even if "only HD") camera, which would cost much more than what the Pi Foundation is targeting. I don't think it would cannibalize sales from anything they're trying to put out.

The Arduino ecosystem seems to have survived being truly open, hasn't it?

i love the raspberry pi ecosystem but I really see it as a stopgap until we have wide support for open risc V based soc devices across the industry. the DRM really is a major limiting factor for the platform in a number of ways.

Does it gave DRM this time too ?

Are you talking about DRM as in "Digital Rights Management"? As far as I know, cameras have nothing to do with that type of DRM, that's up to the playback device, not the recording.

RPi won't use generic cameras, only RPi-signed ones, it is a form of DRM.

Quite the opposite. The v3 camera does not support the old proprietary drivers, current versions of pi OS ship with open source drivers by default.

It seems Raspberry Foundation didn't like the old driver any more than we did.

Does that actually mean you can use a knock-off v3-like camera? There is no contradiction between an open source driver and the camera having to authenticate against closed-source videocore firmware.

Ah, I see. I'm more familiar with the terms "hardware restrictions" or "vendor lock-in" in that case, as I see DRM to be strictly software enforced restrictions, guess the "Digital" in DRM throws me off or something.

If DRM is still needed (no idea) then you'd expect an official product to support it. I can't think of a use case where lack of DRM support by the camera could possibly be a problem for you.

DRM might be not exact term here, basically "original" cameras had a chip that identified itself to the rPi driver and driver required that to work.

That was because the previous camera was widely copied and they wanted to not put money into making driver for a camera just for user to go and buy cheap copy

What case do you use for this? How do you put this in the device?

There's a camera connector on the board: https://www.pishop.us/raspberry-pi-4-information/

A variety of cases either provide access to the connector, or have a camera mount. You can find them by searching.

There's a warning in the article that the official Zero case does not support the new camera. According to the specs it is around 30% thicker than the original camera module, and the fish eye variant is even thicker still. Many cases fit pretty tightly and will not be compatible.

if you need more specific MIPI CSI sensors RPi compatible you can check this company:

https://www.vision-components.com/

their support wasn't exceptional in the past but kinda improved recently.

the modular camera module ecosystem is quite interesting, using this for research.

This is great, I just hope that stock gets better for the pi and stays that way. I have a few projects I'm waiting to start.

According to Pi Locator, there hasn't been an 8gb RasPi in USA since October 2022. Best to move on to another company that prioritizes retail rather than donation-commitments.

Not sure there have been any in New Zealand for a couple of years. It is something of a cruel joke each time new hardware is announced knowing there is no chance I am getting my hands in it.

Any suggestions on what's a good Pi replacement?

The new Orange Pi 5 has a good price for the RK3588s it uses, and can support up to 32gb of RAM. My testing shows it being 3-4x faster than the Raspberry Pi 4 4gb.

Down side is it just released, so the software support is still in its infancy. And it doesn't have wifi+bt built in, so you need to use a dongle or use up the NVME slot for adding that functionality.

I bought a orange pi 5, but havent tried it yet.

Various kernel-devs on ActivityPub had some very very nasty things to say about rk3588 board stability. Different folk, on different boards. Maybe this time will be better, who knows, and maybe better drivers will improve things, but seeing such sad kernel devs has been demoralizing.

I would love to read the rants if you can find them. I was really considering getting some RK3588 based boards since it seems to be the most powerful ARM based SoC you can actually buy.

Glance through the Radxa and orange pi forums; there are plenty of growing pains still at this point, from power issues, Imagination GPU lacking support in Linux, and mostly other hardware/driver related quirks that will take time to sort out.

For some use cases they're great though, as long as you don't need specific features.

Not sure if I'm lucky, or if things have improved. But I've probably ran it at all cores busy compiling for 100 hours so far, and had uptime in the weeks, currently at 5 days.

I did use a beefy usb-c power brick, rated for 40 watts to ensure it's never getting less power than it asks for.

So far I'd say it's at least as stable as my RPi, and doesn't have anything ugly like storage or network connected via USB.

For what?

As a router or small server for running DNS, PiHole, and related services I'd recommend one of the Rk3588 systems, I bought a NanoPi R6S. The 8gb flavor is $120, $140 with a nice metal case. It's pretty fast, I compared compiling rust and it was 6-7 times faster than a RPi4 8GB. Even has two 2.5gbe interfaces.

Are you able to run a mainline kernel, or are you stuck with the vendor patched BSP kernel?

Not yet, all NanoPi images use the same not upstreamed 5.10.110 kernel.

However progress has been made, various reports of it working, some progress, some accepted patches, some rejected. More info at:

https://forum.radxa.com/t/any-progress-with-mainline-linux-k...

Also: https://lore.kernel.org/linux-arm-kernel/5bec43fe-ff81-bc68-...

Thanks. If pcie support in 6.3 pans out, that isn't long to wait at all.

Odroid is my go to low cost SBC. If you just need something like a WiFi connected display/sensor/switch, esp32. I really like the M5stick. Other than that specific projects usually have a list of alternatives which can help. There's a multi board build for Octoprint for example

I had a pretty bad experience with Odroid. I purchased a home assistant blue, which uses the Odroid N2+ and the USB ports died on it, which is a non-starter since I use Zigbee and Zwave USB sticks. Apparently this issue is not uncommon, and there was no way to get it warrantied or do an RMA.

I had a pretty bad experience with a Sandisk branded "Industrial" SD I purchased directly from Odroid (they put their sticker on it, partitioned it then added the payloads) as died within 1 year of very very low use.

I'm wondering if it was a real Sandisk.

Since I got about 10 at the same time it sucks: I'd have to individually test them before entrusting any of these with any data.

That's good to know. I've used them in the past for embedded vision for FIRST robotics. I was actually thinking about getting the N2+ to replace my Rpi4 for HA, but might just go with a NUC.

I've been using these with overall good results: Le Potato https://libre.computer/products/aml-s905x-cc/

For the most part I've found that RaspPis are over-dimensioned for many projects I'm inclined to do, for example around the house, and have switched to much more readily-available and cheaper ESP32 and STM32 boards.

I do have a RasPi in use that runs some heavier software like a Hue bridge emulator written in Python (diyHue), and for some of my projects I now have that Pi do more intensive computation centrally and then just dispatch results to esp32s.

I'm currently building one of those refresh-once-a-day framed e-ink "newspaper on the wall" projects. In the picture frame I just have the panel, an IT8951 display controller and an esp32, all running off a LiPo pouch, mostly in deep sleep. The RSS scraping and pdflatex+ghostscript pipeline to produce the image is running on the central Pi in this.

A single Pi may be all you need if your projects live on a network!

How much time can you get off a lipo pouch?

If it's "on the wall", why isn't it powered by an ac adapter?

> How much time can you get off a lipo pouch?

Time will tell, but I'm hoping for at least a couple of months on a 1100 mAh. Napkin calculations had me at 6-7 months.

It's e-ink, so I can shut down the entire display and controller after the refresh, and the ESP32 is in deep sleep until it wakes up on timer and performs a network fetch and display update, then back to sleep.

> If it's "on the wall", why isn't it powered by an ac adapter?

Effort :-) It's a picture frame on a wall, I don't want to have an externally visible cable going into it and burying a cable in the wall is more work than all the rest of it.

Wow, I'm not used to thinking of batteries in those terms. If you hit 3 months, you deserve to crack a bottle of champagne, that's a really impressive bit of engineering. Although now that I think about it, smoke detectors have been lasting a year on a 9-volt for all my life, so maybe I'm just short-sighted. :-)

An ESP32 just draws about 0.15mA or less in deep sleep mode, even less if the ULP co-processor is turned off - down to about 5 µA if you're willing to keep no state/data around and just need timer wakeup. That's 220000 hours of hibernation on an ideal 1100 mAh battery (i.e. one that doesn't lose charge by itself over time)!

In practice this is unattainable, because batteries are not ideal, and there's quite some efficiency loss from e.g. voltage regulators. But you can realistically get to years of hibernation.

Of course the power draw is much higher if you e.g. need to permanently keep a WiFi connection open and can't sleep (there's lower-power alternatives to WiFi like ESP-NOW for some applications), but I just need a connection for a very short time to fetch a 1600x1200x4 image. And to power a full display refresh on the e-ink panel.

If you think about it, a Kindle or similar also runs for days to weeks off a single charge, and that has a lot more interaction and computation going on during use, a more powerful processor with higher power draw and it sleeps less deeply and for shorter time. My application is suitable to extend beyond that by a large factor.

Yeah, I have a single 4b doing everything from openhab to shinobi to LoRA bridging, MQTT brokering, VPN termination, DNS, routing, pretty much anything where I need a Linux box to do a thing - we live off grid, so having a handy utility server that uses very little power is dead handy.

Plans to get another, as some redundancy would be good and it strains transcoding video, but you can pile a surprising amount onto one.

What panel are you using?

This one: https://www.waveshare.com/product/displays/e-paper/epaper-1/...

13.3", the largest I could afford :-)

That's so cool. Did you build this from instructions somewhere or just using your imagination and seeing what works? Perhaps a build log article maybe?

My inspiration is this: https://www.youtube.com/watch?v=gECj1AE9D2c

But I actually only watched the first 30 seconds and then got hooked on the idea. The impl is mine :-)

Agreed. I’ve used refurbished thinkcentres recently. They are more power hungry (and powerful), but within the realm of an 8GB rPI+power adapter+housing+SD card. Upside: x86-64!

Very good now someone come up with a solution to the wiring mess that comes with any kind of RPI thing.

use the 40pin connector either to a custom designed hat or to a separate board with a ribbon cable

The goal is to eliminate that altogether, at least in the design phase. You put down the modules, they see each other, can communicate, do the coding about which modules' signal goes where, what processes what etc., and when you are done it either works as is or an automated thing can create the final boards/cabling/wiring for you.

The less hurdles in the prototyping phase the better. I know it sounds impossible, but this wiring this to that always gets on my nerves.

So a software wiring kinda thing with a "wireless" approach would be very much welcomed.

I just designed and built an RPI-hat style PCB with JLCPCB that has multiple MCUs, power, and a 40-pin connector on-board.

Each 100mm x 100mm board was $~10 a piece, assembled and delivered to the US (the cost mostly consisting of my specific parts.)

It's pretty cheap, low effort to prototype a real PCB.

Sounds like you don't enjoy hardware in the first place... or maybe would enjoy something like PLC more than prototyping.

Once you get things in place making a PCB that connects modules neatly really isn't a big deal, especially if you use ready-made modules

Reply on news.ycombinator.com