If you’ve ever had a medical team investigating cardiac issues, you’ve probably had a bunch of electrodes stuck all over your chest and been hooked up to an electrocardiogram. This is the gold standard when it comes to understanding electrical activity in the heart and can diagnose a great many conditions. However, sometimes doctors just need the basic information—your pulse rate, and whether or not there’s actually any oxygen in your blood.

Thankfully, there’s a cheap and simple device that can offer that exact information. It’s the pulse oximeter, and it’s a key piece of equipment that’s just about vital for monitoring vitals. Let’s learn how it works!

Pump It

If you’re unfamiliar with pulse oximeters, they’re that little plastic thing that clips on your finger at the doctor’s office. The device places two LEDs on one side of your finger, and a photodiode on the other. With just these simple components, it’s possible to determine the percentage of your blood’s hemoglobin that is currently carrying oxygen. It’s also possible to discern pulse rate, which also comes in handy when you’re trying to determine a patient’s current status at a glance.
A pulse oximeter is a small device typically worn on the finger. This example feeds a signal to a remote display, while some units will put the screen directly on the finger clamp itself. Credit: UusiAjaja, CC0
Pulse oximetery was the brainchild of Takuo Aoyagi, an electrical engineer at Nihon Kohden in Tokyo. In 1972 he was working on a non-invasive way to measure cardiac output using the dye dilution method, which involves injecting a tracer dye and watching how its concentration in the blood decays over time. He was reading that decay optically through an ear oximeter. These devices used red and infrared light passed through the ear tissue to determine blood oxygen levels, but required frustrating calibration to work properly and often required fussy steps like first squeezing blood out of the tissues prior to measurement. The problem was that early oximeters worked based on the total absorption of light, and were affected by things like the skin, tissue, and venous blood, when really the goal was to measure the oxygen levels in the arterial blood itself.

As Aoyagi worked with the device, he noted that the patient’s pulse kept showing up as an annoying ripple in the output. He spent some effort trying to cancel that ripple by balancing red and infrared signals against each other. Then he noticed that when a patient’s oxygen saturation dropped, the cancellation fell apart. This led to the realization that the ratio of how much red and infrared light was absorbed could be used to determine the oxygen saturation of the arterial blood.
Oxyhemoglobin and deoxyhemoglobin absorb red and infrared light at different rates. Measuring the ratio of each wavelength of light transmitted through the arterial blood allows the oxygen saturation to be calculated. Credit; Cmglee, CC BY SA 4.0
It all comes down to the nature of blood itself. Hemoglobin comes in two flavours relevant here: oxyhemoglobin, which is carrying an O₂ molecule, and deoxyhemoglobin, which isn’t. They are different colours, which is why arterial blood is bright red and venous blood is darker. They absorb light differently, to the point that it’s actually clinically useful. At a wavelength of 660 nm (red)—deoxyhemoglobin absorbs noticeably more light than its oxygenated cousin. At around 940 nm (near-infrared), oxyhemoglobin absorbs more. Almost every pulse oximeter uses these two wavelengths; both penetrate tissue quite easily, and it’s easy to find LEDs that spit out these wavelengths.

Reading the blood oxygen level is relatively straightforward. The device will typically alternate the two LEDs on and off, many times a second, also including a third phase with both off so the photodiode can subtract out ambient room light as well. The photodiode sees light that has passed through an entire finger, including the skin, bone, fat, as well as the venous and arterial blood. Most of that doesn’t change from second to second, but the arterial blood does, with every pump of the heart. Thus, when sampling light from the infrared and red LED pulses, the photodiode puts out a signal that’s mostly a continuous level from light passing through the finger, with a little wiggly bit on top that throbs at a human pulse rate. That’s due to the pulsing of the arterial blood, and the frequency can be used to measure pulse rate. Meanwhile, the continuous component is removed by subtracting the trough of both the infrared and red signals from the peak, which solely leaves the component of light absorption due to the fresh arterial blood itself.
The inside of a pulse oximeter sensor. Note the red LED and IR LED on one side, and the photodiode on the other. This design transmits light through the finger, though reflective approaches can also work. Credit: Eliran t, CC BY-SA 4.0
The level of oxygenation in the arterial blood itself can then be measured by comparing the ratio of red to infrared light picked up in this part of the signal. The light ratio is converted into an human-parseable number via a lookup table, based on the Beer-Lambert law of concentration of substances in a solution. The displayed number is flagged as “SpO₂.” The “p” stands for “peripheral,” to indicate it’s an optical measurement rather than determined directly with blood-gas measurement techniques. This distinction is important, as there are a range of conditions under which pulse oximetry readings can be inaccurate. At a very base level, pulse oximeters can get confused if a patient is moving while wearing the device, which makes the pulsatile signal itself less clear. The device also cannot tell carboxyhemoglobin from oxyhemoglobin, because they absorb light very similarly at 660 nm. Carboxyhemoglobin is the result of carbon monoxide entering the blood, so a smoke inhalation victim can display a high apparent SpO₂ figure while their blood is carrying very little oxygen. Nail polish and skin tone can impact the amount of light transmitted through the finger, impacting readings, while limited bloodflow to the fingers can also frustrate things.

It may not be perfect, but pulse oximetry is nevertheless very useful a lot of the time. It enables medical teams to get a near-instant look at a patient’s most vital signs in a completely non-invasive manner. The use of this technology has revolutionized both emergency care and surgery, where it has played a huge role in patient monitoring under anaesthesia. Plus, the simplicity of the device has made this critical medical insight accessible to anyone that can afford a $20 device with a few LEDs and a photodiode in it. It’s now even possible to track your oxygen saturation during sleep with an off-the-shelf smartwatch due to developments from this technology, helping aid in the diagnosis of complex conditions like sleep apnea. All because blood tends to pass light a little differently depending on how oxygenated it is. Sometimes you have to thank nature for those little conveniences.

hackaday.com/2026/05/19/how-pu…

Biofeedback is the idea of making one conscious of a biological process or feature, and then using this to try and exert control over the very same. [Mariia Hruntes] demonstrates this ably with a fluttering build of her own design.

In this case, the biological process being made clear is that of the user’s heartbeat. This is tracked with a MAX30102 pulse oximetry sensor, which can be used to measure both heart rate and blood oxygen levels if so desired. It’s hooked up to an Arduino Uno, which polls for pulse rate data, and then actuates an SG90 micro servo in turn. This operates the wings of a 3D printed butterfly, such that they flap in pace with the wearer’s pulse. The goal is to observe this, and then try and calm one’s self to relax and slow the flapping through the power of the mind.

It’s a simple build, but one that clearly demonstrates the concepts of biofeedback in action. We’ve seen similar principles applied to everything from aiding sleep to improving the practice of mediation. If you’re working on your own neat biofeedback project, be sure to let us know on the tipsline.

hackaday.com/2026/05/19/biofee…

When the World Wide Web surged into existence during the 1990s, we were introduced to the problem of how to actually find something in this ever-ballooning construction zone that easily outpaced even the fastest post-WW2 urban sprawl. Although domain names provided a way to find servers using DNS rather than having to mash in IP addresses, you still somehow had to know the relevant URL.

A range of solutions were thought up over time, ranging from printed Yellow Pages type guides, to online curated lists of resources, as well as things like web rings where one website would link to a relevant similar website. This was the time when word-of-mouth was also very relevant, with people proudly announcing their own website on Geocities or other hosting service.

Search engines already existed long before the WWW became the hot new thing during the 1990s, but it was the WWW that would really push them to their limits. As anyone who used search engines for the WWW can attest, they had many issues. Often you’d end up using multiple search engines to find something, and despite fierce competition between web search engines to become the starting page for their browser, actually finding things on the WWW remained a tough problem.

Since a web search engine ‘just’ has to index the WWW and match a search query against the results, why was this such a hard problem that persisted until Google apparently cracked the code?

Unplanned Sprawl

URLs branching off from the main Wikipedia page in 2004. (Credit: Chris 73, Wikimedia)
A nice thing about the WWW is that it was designed to be accessible to all, requiring only an Internet connection and thus opening up the possibility of setting up your own webserver. This unsurprisingly led to a very rapid growth of pages on the WWW, with content appearing, being modified and sometimes vanishing at an ever-increasing pace, making it extremely hard to keep up with.

This is however not how things started when the World Wide Web was created in 1989. Before its opening to the public in 1993 the pace of growth was slow enough that a manually maintained index was maintained. This was kept up until late 1992, with the last version of said index still online on the W3 website.

Over the course of a short few years, the WWW would change the face of the world forever alongside a surge of IBM-compatible PCs, exploding multimedia content, all the dot-com hype and perhaps best of all endless ‘free’ hosting services as long as you didn’t mind an advertising banner plastered above your personal homepage’s content.

Even internet service providers (ISPs) would often offer their own hosting service, along with endless n00b-friendly tools to make something resembling a website for whatever hobby you fancied. In addition to proving that one can absolutely argue about style and the prevalence of colorblindness, this would also serve to balloon the number of websites at an exponential rate.

Whether or not the WWW killing off the Gopher-based internet was a bad thing remains the topic of debate, though it’s beyond question that Gopher integrated search functionality into its protocol, mirroring a file system.

Infinite Library Indexing

Without any provisions in the HTTP protocol of the WWW, the only realistic way for search engines to create an index of the ever-expanding and changing WWW is to perform so-called web crawling. This means going through every known document, following any links found in them, and making sure to revisit any documents in case their contents got changed since the last visit.

The first complication here is that since the search engine’s database is the only real index for the web, initial discovery is purely organic, starting from a certain number of URL seeds in what is called the crawl frontier. This forms an integral part of a web crawler.
The Structure of Queues that Feed the URL Stream in the WebFountain Crawler (Credit: Edwards et al., 2001)
Development of the algorithms and architecture behind these crawlers formed a major part of the early WWW, with IBM researchers on the WebFountain project in 2001 estimating a grand total of about 500 million pages, with – as they put it – web crawlers caught between the comfortable cushion of Moore’s Law and the hard place of the web’s exponential growth. Today this number is probably closer to forty billion pages.

Although the Google Search web crawler was already pretty good back in 2001, WebFountain improved on it by using a distributed system, with ‘ants’ working through their own list of URLs to crawl, as described in the development paper by Jenny Edwards et al.

Beyond the basic recursive following of links in a document there are many confounding factors, such as when to recrawl a URL, which very much depends on how often the content on it is expected to be updated. Here one dives into the territory of statistics, as depending on the type of site we can make an educated guess on how often it is expected to be updated. For example, a government’s historical news pages are unlikely to see frequent updates, whereas the front page of a news site can see updates practically every few minutes.

Inverted Indexing

As complex the topic of web crawling is, the fun part begins when you have pruned all duplicate documents and stripped all the irrelevant fluff that’s not text to be indexed. In order to make the resulting search index at all searchable before the heat death of the Universe you cannot simply do a full text search on every single document whenever someone enters a search query.

Instead an index is constructed whereby certain keywords are mapped to documents. This inverted index is generally implemented as a hash table or similar data structure where it provides a quick access into the full text documents, not unlike the keyword index in the back of a book, or the more elaborate concordance of yesteryear. These latter works also provide a keyword index, but add accompanying text to provide immediate context to further save time.

Creating an inverted index is a fairly labor-intensive process, with a new document often used for a forward index that decomposes the text into its keywords prior to updating (or creating) the inverted index. As with all of such text processing related tasks and data structures in general there are many ways to go about it, with some fun curveballs thrown into the mix such as parsing languages that do not separate words with spaces, like Japanese.

All of which is to say that implementing a search engine is easy, but making it performant, accurate and efficient at the same time is a minor nightmare. This is basically why search engines took so long to stop being so terrible, as the engineers behind them were trying to solve many rather complex problems, presumably with the C-suite and investors breathing down their necks during the dot-com days.

Search Battles

Over on the Wikipedia entry for ‘Search engine‘ we find a pretty good timeline of web search engines, along with their current status. Perhaps unsurprisingly none of the 1993-era ones made it, but 1994’s WebCrawler somehow crawled into the modern age, along with Lycos. Much like 1990’s Archie search engine and similar for the Gopher web, many of these early search engines simply couldn’t compete in the rapidly changing years leading up to the new millennium.

This was also the era in which some figured that the WWW simply needed to become more ‘3D’ with virtual environments using VRML, bringing it closer to sci-fi like that portrayed in Snow Crash or Tron. Perhaps unfortunately the WWW remained the domain of mostly text and images, although most recently the flood of JavaScript frameworks appear to want to turn once simple HTML documents into full-blown desktop-like applications, all probably to the delight of web crawler engineers.

Meanwhile some search engines figured that they could lift along on the hard work of others, with so-called meta search engines collating the results from multiple search engines to save people the trouble of querying them individually. Here 1996’s Dogpile is still going strong.

Some search engines are missing from the list, such as Marginalia, which boasts the use of open source software for its indexing and crawling, while focusing on non-commercial content. There is also the ever excellent Frog Find that provides a bridge between modern search engines and systems that really cannot run the latest web browser.

Today’s Survivors

The search engine landscape remains a brutal one today, with us having to recently say farewell to Jeeves, of Ask Jeeves fame, most recently seen carrying the Ask.com name. Personally I didn’t really Ask Jeeves much back in the day, instead mostly using AltaVista (RIP) and probably Lycos and a few others that I do not recall off the top of my head.

Having Google Search burst on the scene by 2000 was definitely quite the event, which was certainly when the web search game improved. Looking back it probably was less that Google Search was simply better, but more that it pushed hard just being a search engine, whereas the others were still very much stuck in that early WWW mindset of being a portal to the web.

To a certain extent this is understandable, as search engines aren’t a charity and running the associated hardware as well as the required bandwidth costs a lot of money. Despite this it would seem that we still have a rather thriving web search engine landscape, even if ChatGPT, Claude and kin are trying to become the very last ‘site’ you will ever need. This even as their little web crawlers are still doing the same crawling as has been done since the birth of the WWW.

hackaday.com/2026/05/19/how-se…