There was once a race to put out cameras with ever higher numbers of megapixels to snare customers eager to take the highest quality digital photos. These days, we know that things like optics, processing, and finer qualities of an image sensor are all very important beyond pure resolution. But, for a time, companies behaved as if megapixels mattered over all else.

But what if you could go farther—shooting not millions, but billions of pixels in a single image? That’s precisely what [Yannick Richter] came to Hackaday Europe to talk about, covering his Project Gigapixel build.

More Pixels

When it comes to building a consumer camera with higher resolution, manufacturers achieve this by creating an image sensor with a greater number of sensing elements. This, of course, can get expensive and difficult the farther you want to scale, particularly if you’re trying to fit more sensing elements into a given standard sensor size.

However, there are other ways to capture images in greater resolution that don’t require a larger image sensor. Namely, you can actually use quite a simple image sensor of limited resolution, and simply move it to various positions, capturing light all the while. Then, all you need to do is stitch the output together and you have a remarkably high resolution image. It might sound complicated, but as [Yannick] explains, it’s a perfectly cromulent way to build a gigapixel image.

[Yannick’s] project began with an old Epson flatbed scanner. This made the perfect donor for such a project, as it came with a linear image sensor with quite good resolution for scanning photographs and documents. The only problem is that it needs to move in a straight path in order to capture a full image. The goal was to build it into a scanner-style camera that was truly portable, which required some reverse engineering and creative design to make it into a practical tool for real-world photography. [Yannick] didn’t want to just stuff the existing scanner in a bodged-together camera body, either. He wanted to interface the sensor directly and build a custom linear-scanning camera from the ground up, with the high-resolution linear sensor mounted behind a nice medium-format Pentax lens.

The key was that the scanner in question—an Epson V370—used a Sony CCD scanning element, rather than a cheaper CIS element. A proper CCD sensor is more expensive, but produces better output, and is more suitable for the sort of imaging [Yannick] was trying to do with this build. Namely, by running the scanning element behind a medium format lens to capture incredibly high-resolution images at up to 40800 x 80000 pixels, or 3.2 gigapixels if you multiply it out.

The talk covers all the work that [Yannick] did to make this a fully functional camera. That included doing a deep dive into Epson documentation to figure out how to interface the sensor at all. Thankfully, service manuals provided enough detail on how the 12-line RGB sensor works to get the project over the line. Interfacing the sensor was achieved via reusing the ADC and timing generation hardware from the scanner itself, hooked up to a Raspberry Pi 5 and a RP2350.

Plenty of work was required to figure out how to properly offset all the R, G, and B pixels to line up properly into a coherent color image. [Yannick] also dives into the mechanical design, regarding how the sensor was assembled on a 100-millimeter linear drive to scan it behind the lens assembly to capture images. There were also issues generating a live preview that you’d get on any other digital camera, which is not exactly practical to generate from a scanning image sensor. Instead, a standard Raspberry Pi camera was included in the build for live preview to help with lining up a shot.

Perhaps the best part of the talk is when [Yannick] shows off the final results. The simple fact is that 3.2 gigapixel images capture a ton of detail when they’re taken well and focused correctly. A simple shot of some benchtop instruments doesn’t look like anything special, until [Yannick] shows that cropping in will let you read the codes off a 0603 SMD resistor. Obviously, the camera is limited when it comes to speed and it can’t really capture moving objects well. However, when it comes to grabbing very high resolution shots of still scenes, it’s a great performer. If taking gorgeously detailed landscapes or stunning architectural shots is your thing, you might find such a build an appealing proposition for your own needs.

A problem facing the designers of event badges is this: what happens to the badge after the event? It’s one that designers have tried to solve in many ways with varying levels of success, whether that be by making it a dev board, a games console, a mesh-networked communicator, or as in the case of Electromagnetic Field, a continuing badge for future events. Ar BornHack 2026 they have taken a novel approach, by making it a useful desktop appliance. The BornHack Cyber Ægg is a half-egg-shaped badge with a 3D-printed case, and aside from its on-camp applications it’s both a desktop clock/calendar, and a MeshCore node.

Produced with the assistance of the badge.team European badge makers, it’s an egg-shaped PCB with a Nordic nRF52840 at its heart, a Semtech LoRa module, and an e-paper display. On-site there’s a Tamagotchi-style virtual pet game, an event calender, and an RFID token game, but it’s the other two features that give it a life after the camp. The clock and Meshcore, coupled with its case being designed with a flat spot to sit on a desk, make this badge as much an appliance as it is a badge. This is where it will sit in the Hackaday office, and we’re pretty sure most BornHack attendees will use it thus too.

We like this approach to giving a badge a life after the event, and we look forward to seeing what influence it has on future badges. A badge should be a thing to enjoy, not a piece of e-waste.

Even for those of us that are quite technically minded, we spend precious little time thinking about the cables that carry our signals and do all the important work we need them to do on a daily basis. A great deal of theory and engineering goes into making things like telephone lines and HDMI cables work, but we mostly just plug them in and get on with whatever we’re doing.

If this is your experience, you might find the Hackaday Europe talk from [Michael Wiebusch] to be particularly interesting. He dives into transmission line theory from an accessible standpoint, explaining how two disparate signals can go in opposite directions on the very same wire. Then he demonstrates the theory by building a cable modem… well, sort of!

Signal

Michael begins his talk by discussing the Telegrapher’s Equation, but only as a fakeout. Given the limited time on offer, he decided a quicker, easier explanation of the physics involved would be more appropriate. Key to this was explaining the difference between cables and transmission lines. To create a true transmission line, by his definition, he explains that there is a necessity to have two conductors that are relatively close together. Such a transmission line is effectively a distributed network of inductances and capacitances all the way down, though often we talk about “lossless” transmission lines for modelling purposes. He also covers the point of coaxial cables, wherein one conductor is wrapped around another to shield a signal from external noise, and to prevent signal from leaking out.

There are several basic facts to remember about transmission lines. They are fundamentally just channels down which EM signals can travel. It’s also good to remember that they delay signals. To a human, the signal may appear to travel instantaneously, but it does take time. This also has other impacts; for example, coax cables are filled with plastic, a material in which the speed of light is roughly 66% of the speed of light in a vacuum.

This slows the rate at which the field of an EM signal can travel to this fundamental limit. [Michael] also notes that transmission lines, as a wave medium, essentially allow waves travelling in different directions to pass each other, much like ripples spreading on the surface of a pond. This is why it’s possible to have bidirectional communication on a single transmission line. It’s also important to terminate a transmission line properly, such that the wave you’re transmitting down it ends where you want it to—at the receiver. Fail to terminate your transmission line, and you’ll have that wave bouncing back and forth which is undesirable for clear transmission.

[Michael] demonstrates basic transmission line theory by building a sort of cable modem out of an Arduino and some supporting hardware. He notes it’s not really a modem—there is no modulation or demodulation going on. Instead, he’s simply squirting TTL signals into either end of a cable and receiving them on the other end. The “black box” that couples the signals into and out of the transmission line is a simple directional coupler. Built out of resistors and an op-amp, it allows sending a signal down a transmission line, as well as receiving a signal coming the other way. The design works all the way down to DC logic level signals, which let [Michael] use it to send TTL signals up and down 50-ohm and 75-ohm coaxial cables. He notes this has very obvious practical applications where it’s desirable to reduce cable counts when sending signals in multiple directions, relating this directly to his professional work on science experiments.

If you’ve ever wanted to get two devices talking over a single cable in a relatively easy fashion, then [Michael’s] talk may be valuable to you. At the very least, it’s a great way to learn some of the basics of transmission lines and better understand what’s going on when you shoot a signal down a random bit of wire. It’s all good stuff.

We are absolutely stoked to announce that the Hackaday Superconference is taking place this year November 6th through 8th in glorious Pasadena California, and we want to see you there!

If you’ve been to any of the previous nine Supercons, you know that it’s a fantastic gathering of the most motivated and interesting hackers around — but it’s also been a relatively small gathering. And while we love the very high signal-to-noise ratio of folks who show up, we’re always a little bit sad when the tickets sell out because it represents hackers who couldn’t be there.

So this year, we’re celebrating Supercon Ten by expanding out of our traditional location at the Design Lab so that we can accommodate 20% more hackers, while still keeping the cosy nature of the event intact. So if you’ve been wanting to come to Supercon, but procrastinated the ticket sales every year, this year is looking 20% better.

Call for Proposals

If you want to give a talk to an interested audience of hackers just like you, now is your chance. Fill out the Call for Participation form before Wednesday, Aug 12th to put your hat in the ring. Presenters not only get to share their work with a like-minded audience, but they get in the door free! Presenting really is the best way to attend a conference like this – it’s the ultimate ice-breaker. (Plus, did we mention free?)

We will have two tracks of talks on two stages, and both are a mix of shorter 20-minute talks and longer 40-minute sessions, so whatever the size of your ideas, we have the slot for you. As always, we like to hear about your projects: hardware, software, creation, destruction, or anything in-between. In short, if you have a talk that would interest the readers of Hackaday, it fits. Check out last year’s slate if you’re curious, but bear in mind that we like to see new stuff, so don’t feel constrained by precedent. If you’re into it, there’s a good chance that many of us are too!

All you need is an abstract, a title, and a solid general idea of how the talk is going to go. First time speaker, or grizzled veteran: get your proposal in now.

Plus ça Change…

Supercon Ten starts out as usual with a casual badge-hacking day at Supplyframe HQ on the morning of Friday Nov 6th. We love this day because there’s “nothing” to do! It’s the perfect way to ease into the conference: the doors open, and the food and coffee starts flowing. As the solder melts, brought-along hacks get demoed, friendships form, and plans get hatched. We go on well into the night, with music and festivities to keep you motivated or distracted – the choice is yours.

Saturday and Sunday are chock-full of talks, workshops, challenges, and other events. This year, we’ll be a few blocks south at the ArtCenter South Campus, which means that we’ll be relocating our traditional back-alley ambiance to significantly fancier digs. But of course, we’ll have space for hacking, mingling, and watching the talks.

Sunday evening comes too soon, and at the end of this second day of talks, we’ll let you showcase all of the badge hacks that you’ve been working on before spilling out into the town and falling far too late into bed.

Just because enough is never enough, we’ll probably also meet up informally sometime Thursday night if you’re already in town. And if you’re able to finagle a half-day Monday into your schedule, you’ll find that a bunch of folks have off-schedule side trips that are always popular.

Get Excited!

We know that we’re announcing late this year. The new venue, combined with a late Hackaday Europe, made for a lot more planning to be done. But now that all of our ducks are in a row, we’re very much looking forward to November. And of course, we can’t wait to see what you all are going to bring with you to Supercon. After all, it’s the Hackaday community that makes it great.

Get your talk proposals in now, and in the next few weeks, we’ll open up ticket pre-sales. Tell your friends, neglect to mention it to your enemies, and start making your Supercon plans today.

Blood pressure is one of the so-called “vital signs” that medical practitioners use to determine the basic state of a patient in any given moment. It’s exactly what it sounds like—a measurement of the pressure of the blood flowing through the body, with some complications to account for the pulsatile nature of human blood flow.

You might think measuring blood pressure is a solved concern, and it mostly is. With that said, some blood pressure monitors out there aren’t quite doing their job properly, and [Milos Rasic] came to Hackaday Europe 2026 to spell out the problem.

Under Pressure

Before exploring the issue, it’s worth first understanding how blood pressure is actually measured. On a baseline level, it’s the same as pressure being measured in any other fluid. Specifically, though, when it comes to blood, it’s important to measure the pressure at two points. There is the peak, when the heart muscle is contracting, referred to as systolic pressure, and the low point, when the heart relaxes, referred to as diastolic pressure. Thus, blood pressure is referred to with two numbers, such as “140 over 90” or 140/90, referring to systolic and diastolic pressures respectively. It’s sometimes important to track the mean arterial pressure, too. Typically, nominal blood pressure would be considered around 120/80 mmHg. High blood pressure, or hypertension, starts at figures over 130/80 mmHg, while low blood pressure, or hypotension, would be considered relevant below 90/60 mmHg.

Blood pressure can be monitored in a number of ways. Most of the time, non-invasive methods are preferred, whether in the doctor’s office or at home. [Milos] notes that the classic hand-pumped blood pressure cuff device (sphygmomanometer) and a stethoscope is still a perfectly excellent way to measure blood pressure in a clinical scenario. This is referred to as the Korotkoff method, where the doctor listens for pulsations in the artery to begin as the pressure of the cuff slowly drops below the systolic pressure, and then later ease as it reduces below the diastolic pressure, monitoring pressure in the cuff on a gauge as they go. Then there are digital versions of arm cuff blood pressure monitors, which [Milos] notes can have some problems. Meanwhile, there are advanced technologies in development to do live measurement with things like mmWave radar devices or ultrasonic tricks, but they’re still emerging and less established in clinical contexts.

[Milos’s] talk focuses on the digital oscillometric analysis that is behind cheap electronic blood pressure monitors that commonly retail for $30-50. These devices start by pumping up an arm cuff to well above typical systolic pressures, before slowly letting it deflate. A sensor hooked up to the cuff is used to monitor the pressure during deflation. When the cuff is below systolic pressure but above diastolic pressure, the pressure in the cuff will oscillate with the pulsing of the blood flow. When isolated from the overall pressure loss from deflation, the amplitude of this oscillatory signal is maximum at the mean arterial pressure. According to [Milos], it’s common for electronic blood pressure monitors to then take some figure like 40% and 80% of the amplitude of the oscillation envelope, and grab the systolic and diastolic pressure values at those points. As far as accuracy goes, this method isn’t exactly perfect, being more of a useful approximation rather than something that’s rooted in a true direct measurement. Furthermore, [Milos] notes that, for example, Category A blood pressure monitors are only expected to land within a +/- 15 mmHg range, for 85% of their measurements. That’s not fantastic.

The method used by these electronic devices tends to be a little inaccurate compared to the traditional clinical methods performed by trained professionals. For that reason, [Milos] developed the Open Cardiography Signal Measuring Device. It is specifically designed to test different algorithms for blood pressure measurement. It can measure pressure in an arm cuff, and also takes signals from a photopletyzmography (PPG) clamp for measuring blood oxygen saturation.  There are also inputs for ECG and digital stethoscope signals, too. [Milos] has published the device’s design on Github for anyone to explore as desired. His talk explains how the device came together, and how he has been using it to evaluate the accuracy of off-the-shelf monitors and the use of alternative algorithms to those used in such units. He also discusses the challenges of measuring blood pressure accurately in this way when dealing with, for example, patients with less stable heart rates.

It’s an interesting exploration of a very specific part of vital sign measurement that few of us ever think about in detail. Sometimes it pays to know how the machines that you’re getting measurements from actually work, and whether you can trust what they’re saying. In the world of blood pressure measurement, [Milos] has done just that.