Munich Embedded News Q3/2026
Quarterly Munich Embedded News for Q3/2026
IMPORTANT NOTE: New Newsletter Platform
We have switched to a new newsletter platform (Buttondown) to improve the experience of the Munich Embedded newsletter.
For you: An archive of all newsletters at https://buttondown.com/munich_embedded/archive/ (we will try migrating the previous issues) and better layout ✨
For us: Easier writing/editing, using a markdown-style editor
The only “drawback” is that this is no longer a service hosted in Germany. But we still only collect your e-mail address and you can unsubscribe at any time. See also Buttondown’s privacy policy for more details.
Dear Munich Embedded Community,
on 27 October we will have our second conference at WERK1 in Munich and we would love to see you there!
Check out the program and talks: https://www.munich-embedded.com/en
Get your ticket now: https://tickets.munich-embedded.com/
Please tell your friends and colleagues about the conference — it would help us a lot.
Special thanks to this year’s sponsors, without whom it would have been impossible to pull this off:
Rohde & Schwarz (Gold Sponsor)
Modelwise (Gold Sponsor)
Analog Devices (Silver Sponsor)
Texas Instruments (Silver Sponsor)
Aisler (Bronze Sponsor)
MicroConsult (Bronze Sponsor)
VDE Bayern (Partner)
News and Quick Bits
M5Stack Launches PaperMono: A Compact E-Ink Development Terminal for Connected Projects
Fun read: “The Load-Bearing Vocabulary of Claude”
The webapp also has a classifier available, where you can paste some text and learn how likely it has been written by Claude.Newsletter recommendation: The Embedded Rustacean – News about Embedded and Rust
OnMCU is looking for beta testers. If you want to try microcontroller development and testing in the cloud, you can request early access now
QuadRF reached its campaign goal: A 4x4 MIMO SDR tile for spatial RF vision & beamforming that scales as a phased array
Glasgow Interface Explorer revD announced on Crowd Supply
Events & Dates
22.09. Elektronik Solution Day, Stuttgart
04.10. - 09.10. Embedded Systems Week, Barcelona, Spain
05.10. Rust Munich Meetup @ Helsing, Munich
14.10. - 17.10. EuroRust, Barcelona, Spain
19.10. - 20.10. IoT Tech Expo, Amsterdam, Netherlands
27.10. Munich Embedded conference, Munich
10.11. - 13.11. electronica / SEMICON, Munich
17.11.-18.11. DVCon Europe, Munich
30.11. - 04.12. ESE Kongress, Sindelfingen
This year will be the 🦀 first Rust Embedded Hackathon 🦀 by Systemscape at ESE 2026 (details)
Probably end of September or beginning of October: Munich Hardware Meetup
Job Board
Hardware/Electrical Engineer – Functional Safety in Electronics (f/m/x), Modelwise
Working Student Hardware Engineering – Model-Based Safety Analysis (TED-MeD), Modelwise
Lead Engineer, Systems Applications – Power Solutions, Analog Devices
Trainer & Berater (w/m/d) für Mikrocontroller und Embedded-Software, MicroConsult
Director R&D Embedded Hardware - 5G/6G Mobile Radio Testing (m/w/d), Rohde & Schwarz
Guest Article and Book Intro:
“The AI Model Is Not the Product”
Artificial intelligence (AI) is increasingly being used to add new capabilities to embedded products across industrial, medical and autonomous applications. Advances in Arm Cortex processor technology, including Helium for accelerating digital signal processing (DSP) and machine learning (ML) workloads, are making increasingly sophisticated Edge AI implementations practical. However, an AI model must still perform reliably when exposed to changing real-world conditions, sensor variations and environmental disturbances that may not have been represented during development. At the same time, the complete implementation must provide the required processing capability within the product’s power and cost constraints.
A considerable amount of attention is often given to the AI model rather than the product itself. As such, it is important to realise that the AI model is not the product: it is only one part of a complete system that must solve the stakeholder's requirements, operate reliably in the physical world and satisfy its functional, engineering and regulatory requirements.
The following article introduces the Real-Time Edge Intelligence (RTEI) framework for designing first-time-right (FTR) Edge AI products, starting with stakeholder requirements and bringing together physical-world understanding, data intelligence and engineering implementation.
Start with the stakeholder requirements
Successful New Product Development starts with understanding what the stakeholder actually wants the product to do. These needs then have to be progressively translated into requirements and, ultimately, an engineering specification.
The New Product Development requirements hierarchy can be summarised as follows:
User requirements — define what the client and stakeholders expect the product to do and how it will be used by a typical user.
Functional requirements — define what the system must do to satisfy the user requirements, without specifying its internal design or how those functions will be implemented.
System specification — translates the user and functional requirements, together with information from stakeholder discussions and engineering know-how, into concrete design parameters and constraints. These may include the sensor type, system and signal-chain architecture, sampling rates and algorithmic concepts.
Technical specification — defines how the system specification will be implemented using real-world technology, including detailed hardware design, component selection and software implementation. This typically contains proprietary engineering details and is therefore normally an internal document.
Once the user and functional requirements are understood, appropriate technologies can be investigated and the system specification developed, rather than assuming that AI is the solution from the outset.
Understand the physical world and the data
Edge AI systems interact directly with the physical world. Sensors do not produce perfect data, operating conditions change, components have tolerances, and the data collected during development will rarely represent every situation encountered after deployment. As such, understanding the physical system and the available data is essential. Some fundamental questions include:
What does the sensor actually measure?
What are the wanted and unwanted signal components?
Which disturbances are expected?
What can we determine from physics and mathematics before asking an ML model to infer it from data?
This latter point is where domain knowledge and DSP algorithms can play an important role. Filtering, spectral analysis, tracking and feature extraction are all DSP algorithms that can expose characteristics of the physical system and provide an ML model with better-quality information. In many cases, better feature extraction can also simplify the ML problem itself.
The objective is therefore not to choose between DSP and AI. It is to use signal processing, mathematics, domain knowledge and AI where each provides the greatest value. This can lead to smaller and more efficient ML models — particularly important when deploying onto embedded processors where processing performance, memory, latency and power consumption all have to be considered.
From AI model to engineered product
The Real-Time Edge Intelligence (RTEI) framework brings these elements together into a structured process for developing FTR Edge AI products.
The process begins by fully understanding what the stakeholders want the product to do. Available technologies can then be investigated to help complete the requirements and specifications before system design begins. More importantly, this does not assume from the outset that AI or ML is necessarily the solution.
A key part of the subsequent stages is the collaboration between human and data intelligence. Domain knowledge and an understanding of physical-world behaviour are then used to interpret the available data and determine which information is actually relevant to the problem. This allows high-quality features to be developed that improve ML accuracy and robustness, while reducing the need for a complex model with greater processing, memory and power requirements.
The resulting DSP algorithms, ML models and embedded software must then be brought together with the processor, sensors, electronics and wider hardware platform as a complete real-time system. Finally, that system must then be validated against the stakeholder, engineering and certification requirements established at the beginning of the development process before customer deployment.
AI as part of the engineering toolbox
As AI technology matures, I believe it will increasingly become part of the engineering infrastructure, alongside processor technology, DSP algorithms, communications, embedded operating systems and software libraries. AI should therefore be seen as an incredibly powerful technology, but one of several that engineers can select according to the problem they are trying to solve.
The important engineering question is therefore not “How do we put AI into this product?”, but rather “What combination of technologies gives us the best solution to meet the stakeholder's requirements?” Sometimes the answer will involve significant AI and sometimes relatively little. Suffice to say, that in most successful Edge AI products, AI will remain an important component of the product, but not the product itself.
Further reading
These ideas, together with the New Product Development process and RTEI framework, are covered in depth in The Real-Time Edge Intelligence Solutions Handbook: A Practical Framework for Building Commercial Edge Systems Based on Physics and Mathematics.
The handbook has recently been updated to incorporate many of these latest insights, together with expanded discussions of AI, Physical AI, reinforcement learning and designing FTR Edge AI commercial products.
Author Bio
 |
| Dr. Sanjeev Sarpal is a RTEI (Real-Time Edge Intelligence) visionary and expert in signals and systems with a track record of successfully developing over 26 commercial products. He is a Distinguished Arm Ambassador and advises top international blue chip companies on their IoT and RTEI solutions and strategies for I5.0, telemedicine, smart healthcare, smart grids and smart buildings. |
