Metal detection: building the detector
IntroductionBefore starting, you may want to read this post describing the BFO stage:
//www.embeddedrelated.com/showarticle/911.php
I have detailed the implementation of a BFO stage for detecting metal. Now it has been validated on the bench, the next step is to integrate it in a stand alone instrument for testing on the field. A few things have to be done to reach this goal:
- make a PCB for the electronics,
- house the PCB in a box,
- add a power supply,
- make a frame to hold...
Autonomous vehicle - design questions to ponder
When designing an autonomous or remotely-controlled vehicle, there are a few factors to take into consideration. Three of these are purpose, environment, and terrain.
What is the purpose of the vehicle?
Will it be used in an industrial setting with people moving around it that it must not run over?
Will it be used in a hazardous environment, like Fukushima or Chernobyl, where it would be exposed to high levels of radiation and must be cleaned or left behind? If it must be left behind, any...
Margin Call: Fermi Problems, Highway Horrors, Black Swans, and Why You Should Worry About When You Should Worry
“Reports that say that something hasn’t happened are always interesting to me, because as we know, there are known knowns; there are things we know that we know. There are known unknowns; that is to say, there are things that we now know we don’t know. But there are also unknown unknowns — there are things we do not know we don’t know.” — Donald Rumsfeld, February 2002
Today’s topic is engineering margin.
XKCD had a what-if column involving Fermi...
Coding Step 4 - Design
Articles in this series:
- Coding Step 0 - Development Environments
- Coding Step 1 - Hello World and Makefiles
- Coding Step 2 - Source Control
- Coding Step 3 - High-Level Requirements
- Coding Step 4 - Design
The last article in this series discussed how to write functional high-level requirements: specifications for what your software is supposed to do. Software design is the other side of the coin....
The three laws of safe embedded systems
This short article is part of an ongoing series in which I aim to explore some techniques that may be useful for developers and organisations that are beginning their first safety-related embedded project.
Developing software for a safety-related embedded system for the first time
I spend most of my working life with organisations that develop software for high-reliability, real-time embedded systems. Some of these systems are created in compliance with IEC 61508, ISO 26262, DO-178C or similar international standards.
When working with organisations that are developing software for their first safety-related design, I’m often asked to identify the key issues that distinguish this process from the techniques used to develop “ordinary” embedded software.
...“Smarter” cars, unintended acceleration – and unintended consequences
In this article, I consider some recent press reports relating to embedded software in the automotive sector.
In The Times newspaper (London, 2015-10-16) the imminent arrival of Tesla cars that “use autopilot technology to park themselves and change lane without intervention from the driver” was noted.
By most definitions, the Tesla design incorporates what is sometimes called “Artificial Intelligence” (AI).Others might label it a “Smart” (or at least “Smarter”)...
Important Programming Concepts (Even on Embedded Systems) Part V: State Machines
Other articles in this series:
- Part I: Idempotence
- Part II: Immutability
- Part III: Volatility
- Part IV: Singletons
- Part VI: Abstraction
Oh, hell, this article just had to be about state machines, didn’t it? State machines! Those damned little circles and arrows and q’s.
Yeah, I know you don’t like them. They bring back bad memories from University, those Mealy and Moore machines with their state transition tables, the ones you had to write up...
Important Programming Concepts (Even on Embedded Systems) Part IV: Singletons
Other articles in this series:
- Part I: Idempotence
- Part II: Immutability
- Part III: Volatility
- Part V: State Machines
- Part VI: Abstraction
Today’s topic is the singleton. This article is unique (pun intended) in that unlike the others in this series, I tried to figure out a word to use that would be a positive concept to encourage, as an alternative to singletons, but
The CRC Wild Goose Chase: PPP Does What?!?!?!
I got a bad feeling yesterday when I had to include reference information about a 16-bit CRC in a serial protocol document I was writing. And I knew it wasn’t going to end well.
The last time I looked into CRC algorithms was about five years ago. And the time before that… sometime back in 2004 or 2005? It seems like it comes up periodically, like the seventeen-year locust or sunspots or El Niño,...
Unmanned Ground Vehicles - Design Considerations for Snow and Cold Environments
It's that time of year when the white stuff falls from the sky across the US, and with it comes lower temperatures. These conditions must be taken into consideration when designing a vehicle for outdoor use.
A few definitions from wikipedia:
Flurry: light, brief snowfall
Snow shower: intermittent snowfall
Light snow: over 1km visibility
Moderate snow: 0.5 to 1km visibility
Heavy snow: less than 0.5km visibility
Blizzard: lasts 3 hours or longer, sustained wind to 35mph, visibility...
Practical protection against dust and water (i.e. IP protection)
Recently, I was faced with a challenge to provide IP65 compliance in a product that had to have humidity and pressure sensors on it. The tricky part was to keep the cost of the unit under $15 while meeting this requirement.
Under normal circumstances, one can put all the electronics within an IP65 enclosure that is affordable and readily available off-the-shelf most of the time such as the ones shown in this link. However, given the humidity and the pressure sensor need to be exposed to...
The three laws of safe embedded systems
This short article is part of an ongoing series in which I aim to explore some techniques that may be useful for developers and organisations that are beginning their first safety-related embedded project.
Coding Step 4 - Design
Articles in this series:
- Coding Step 0 - Development Environments
- Coding Step 1 - Hello World and Makefiles
- Coding Step 2 - Source Control
- Coding Step 3 - High-Level Requirements
- Coding Step 4 - Design
The last article in this series discussed how to write functional high-level requirements: specifications for what your software is supposed to do. Software design is the other side of the coin....
OS influence on power consumption
Power consumption of an embedded system may be influenced in software in general, but selection of an operating system can be key.
Six Software Design Tools
Contents: Introduction
Here are six tools to help you with software design. The first two are very simple, almost deceptively trivial, while the last four are more involved. They apply universally, to all types of software, all types of systems, and all languages. This is part of good engineering discipline.
At face value, this is just a bunch of acronyms,...
Data Validity in Embedded Systems
If you take a high-level view of software systems you might say that the overall goal of software is to generate outputs from inputs. It’s a gross simplification of a nuanced and complex field but the truth of the statement is unarguable: data goes in, is manipulated and then is spat out again.That’s what software does. The simplicity of the statement contributes to the joy of Computer Science majors who take an abstract view of everything from software to love but infuriates...
Definite Article: Notes on Traceability
Electronic component distibutor Digi-Key recently announced part tracing for surface-mount components purchased in cut-tape form. This is a big deal, and it’s a feature that is a good example of traceability. Some thing or process that has traceability basically just means that it’s possible to determine an object’s history or provenance: where it came from and what has happened to it since its creation. There are a...
Autonomous vehicle - design questions to ponder
When designing an autonomous or remotely-controlled vehicle, there are a few factors to take into consideration. Three of these are purpose, environment, and terrain.
What is the purpose of the vehicle?
Will it be used in an industrial setting with people moving around it that it must not run over?
Will it be used in a hazardous environment, like Fukushima or Chernobyl, where it would be exposed to high levels of radiation and must be cleaned or left behind? If it must be left behind, any...
Open-Source Licenses Made Easy with Buildroot and Yocto for Embedded Linux
In this article I will try to explain what are the copyrights/copyleft, what are the popular opensource software licenses, and how to make sure that your Embedded Linux system complies with them using popular build systems ; Buildroot or YOCTO projec
Why Containers Are the Cheat Code for Embedded DevOps
Embedded software teams have long accepted toolchain setup as “part of the job,” but it’s a hidden productivity killer. Manual installs waste days, slow onboarding, and derail CI pipelines with “works on my machine” issues. While enterprise software solved this years ago with containerization, many embedded teams are still stuck replicating fragile environments. Containers offer a proven fix: a portable, reproducible build environment that works identically on laptops and CI servers. No brittle scripts, mismatched versions, or wasted time—just code that builds. IAR has gone further by delivering pre-built, performance-tuned Docker images for Arm, RISC-V, and Renesas architectures, ready for GitHub Actions and CI/CD pipelines. For regulated industries, containers simplify audits and compliance by enabling validation once and reuse everywhere. The result: faster onboarding, consistent builds, and stronger safety assurance. Containers aren’t a luxury—they’re the cheat code embedded teams need to modernize DevOps and compete effectively.
Definite Article: Notes on Traceability
Electronic component distibutor Digi-Key recently announced part tracing for surface-mount components purchased in cut-tape form. This is a big deal, and it’s a feature that is a good example of traceability. Some thing or process that has traceability basically just means that it’s possible to determine an object’s history or provenance: where it came from and what has happened to it since its creation. There are a...
Practical protection against dust and water (i.e. IP protection)
Recently, I was faced with a challenge to provide IP65 compliance in a product that had to have humidity and pressure sensors on it. The tricky part was to keep the cost of the unit under $15 while meeting this requirement.
Under normal circumstances, one can put all the electronics within an IP65 enclosure that is affordable and readily available off-the-shelf most of the time such as the ones shown in this link. However, given the humidity and the pressure sensor need to be exposed to...
Core competencies
Creating software from scratch is attractive, as the developer has total control. However, this is rarely economic or even possible with complex systems and tight deadlines.
Hidden Gems from the Embedded Online Conference Archives - Part 2
A look back at a deep dive into the Mars Perseverance flight software from one of the technical leads at JPL.
Data Validity in Embedded Systems
If you take a high-level view of software systems you might say that the overall goal of software is to generate outputs from inputs. It’s a gross simplification of a nuanced and complex field but the truth of the statement is unarguable: data goes in, is manipulated and then is spat out again.That’s what software does. The simplicity of the statement contributes to the joy of Computer Science majors who take an abstract view of everything from software to love but infuriates...
OS influence on power consumption
Power consumption of an embedded system may be influenced in software in general, but selection of an operating system can be key.
Better Hardware Design Decisions, Faster: A Lean Team’s Guide to MDO
As design complexity grows, siloed decision-making often leads to late-stage surprises, costly rework, and missed opportunities for optimization. Multidisciplinary Design Optimization (MDO) offers a structured approach to solving this by enabling teams to evaluate trade-offs and impacts across the full system before implementation begins. Traditionally used in large, high-budget industries like aerospace, MDO is now within reach for lean teams, thanks to more accessible modeling tools and an urgent need for tighter collaboration. This article outlines how small hardware teams can adopt MDO in a practical way, starting simple, integrating key models early, and building toward a culture of systems thinking. The result is better design decisions, faster development, and more robust, manufacturable products with fewer surprises along the way.
Unmanned Ground Vehicles - Design Considerations for Snow and Cold Environments
It's that time of year when the white stuff falls from the sky across the US, and with it comes lower temperatures. These conditions must be taken into consideration when designing a vehicle for outdoor use.
A few definitions from wikipedia:
Flurry: light, brief snowfall
Snow shower: intermittent snowfall
Light snow: over 1km visibility
Moderate snow: 0.5 to 1km visibility
Heavy snow: less than 0.5km visibility
Blizzard: lasts 3 hours or longer, sustained wind to 35mph, visibility...
