Feed aggregator

Within my teardown published last summer of Walmart’s “onn.”-branded original Android TV-based streaming receiver, the UHD Streaming Device:

I mentioned that I already had Google TV operating system-based successors for both the “box” and “stick” Android TV form factor (subsequently dissected by me and published last December) sitting on my shelves awaiting my teardown attention. That time is now, specifically for the onn. Google TV 4K Streaming Box I’d bought at intro in April 2023 for $19.88 (the exact same price as its Android TV-based forebear):

The sizes of the two device generations are near-identical, although it’s near-impossible to find published dimension specs for either device online, only for the retail packaging containing them. As such, however, a correction is in order. I’d said in my earlier teardown that the Android TV version of the device was 4.9” both long-and-wide, and 0.8” tall: it’s actually 2.8” (70mm, to be precise) in both length and width, with a height of ~0.5” (13 mm). And the newer Google TV-based variant is ~3.1” (78mm) both long and wide and ~0.7” (18 mm) tall.

Here are more “stock” shots of the newer device that we’ll be dissecting today, along with its bundled remote control and other accessories:

Eagle-eyed readers may have already noticed the sole layout difference between the two generations’ devices. The reset switch and status LED are standalone along one side in the original Android TV version, whereas they’re at either side of, and on the same side as, the HDMI connector in the new Google TV variant. The two generations’ remote controls also vary slightly, although I bet the foundation hardware design is identical. The lower right button in the original gave user-access favoritism to HBO Max (previously HBO Go, now known as just “Max”):

whereas now it’s Paramount+ getting the special treatment (a transition which I’m guessing was motivated by the more recent membership partnership between the two companies and implemented via a relabel of that button along with an integrated-software tweak).

Next, let’s look at some “real-life” shots, beginning with the outside packaging:

Note that, versus the front-of-box picture of its precursor that follows, Walmart’s now referring to it as capable of up to “4K” output resolution, versus the previous, less trendy “UHD”:

Also, it’s now called a “box”, versus a “device”. Hold that latter thought until next month…now, back to today’s patient…

The two sides are comparatively info-deficient:

The bottom marks a return to info-rich form:

While the top as usual never fails to elicit a chuckle from yours truly:

Let’s see what’s inside:

That’s quite a complex cardboard assemblage!

The first thing you’ll see when you flip up the top flap:

are our patient, currently swathed in protective opaque plastic, and a quick start guide that you can find in PDF form here, both as-usual accompanied in the photo by a 0.75″ (19.1 mm) diameter U.S. penny for size comparison purposes.

Below them, in the lower level of the cardboard assemblage, are the aforementioned remote control and a 1-meter (3.28 ft) HDMI cable:

Here’s the backside of the remote control; note the added sticker (versus its predecessor) above the battery compartment with re-pairing instructions, along with the differing information on the smaller sticker in the upper right corner within the battery compartment:

I realized after typing the previous words that since I hadn’t done a teardown of the remote control last time, I hadn’t taken a picture of its opened backside, either. Fortunately, it was still inhabiting my office, so…here you go!

Also originally located in the lower level of the cardboard assemblage are the AC adapter, an oval-shaped piece of double-sided adhesive for attaching the device to a flat surface, and a set of AAA batteries for the remote control:

Here’s the micro-USB jack that plugs into the on-device power connector:

And here are the power adapter’s specs:

which are comparable, “wall wart” form factor variances aside, with those of its predecessor:

Finally, here are some overview images of our patient, first from above:

Here’s the micro-USB side:

This side’s bare on this generation of the device:

but, as previously mentioned, contained the status LED and reset switch in the prior generation:

They’ve moved one side over this time, straddling the HDMI cable (I realized after taking this shot and subsequently moving in with the disassembly that the status LED was behind the penny; stand by for another look at it to come shortly!):

The last (left) side, in contrast, is bare in both generations:

Finally, here’s the device from below:

And here’s a closeup of the label, listing (among other things) the FCC ID, 2AYYS-8822K4VTG (no, I don’t know why there are 28 different FCC documents posted for this ID, either!):

Now to get inside. Ordinarily, I’d start out by peeling off that label and seeing if there are any screw heads visible underneath. But since last time’s initial focus on the gap between the two case pieces panned out, I decided to try going down that same path again:

with the same successful outcome (a reminder at the start that we’re now looking at the underside of the inside of the device):

Check out the hefty piece of metal covering roughly half of the interior and linked to the Faraday cage on the PCB, presumably for both thermal-transfer and cushioning purposes, via two spongy pieces still attached to the latter:

I’m also presuming that the metal piece adds rigidity to the overall assembly. So why doesn’t it cover the entirety of the inside? They’re not visible yet, but I’m guessing there are Bluetooth and Wi-Fi antenna somewhere whose transmit and receive potential would have been notably attenuated had there been intermediary metal shielding between them and the outside world:

See those three screws? I’m betting we can get that PCB out of the remaining top portion of the case if we remove them first:

Yep!

Before we get any further, let me show you that status LED that was previously penny-obscured:

It’s not the actual LED, of course; that’s on the PCB. It’s the emissive end of the light guide (aka, light pipe, light tube) visible in the upper left corner of the inside of the upper chassis, with its companion switch “plunger” at upper right. Note, too, that this time one (gray) of the “spongy pieces” ended up stuck to this side’s metal shielding, which once again covers only ~half of the inside area:

The other (pink) “spongy piece” is still stuck to one of the two Faraday cages on the top side of the PCB, now visible for the first time:

In the upper right corner is the aforementioned LED (cluster, actually). At bottom, as previously forecasted unencumbered by intermediary shielding thanks to their locations, are the 2.4 GHz and 5 GHz Wi-Fi antennae. Along the right edge is what I believe to be the PCB-embedded Bluetooth antenna. And as for those Faraday cages, you know what comes next:

They actually came off quite easily, leaving me cautiously optimistic that I might eventually be able to pop them back on and restore this device to full functionality (which I’ll wait to try until after this teardown is published; stay tuned for a debrief on the outcome in the comments):

Let’s zoom in and see what’s under those cage lids:

Within the upper one’s boundary are two notable ICs: a Samsung K4A8G165WC-BCTD DDR4-2666 8 Gbit SDRAM and, to its right, the system’s “brains”, an Amlogic S905Y4 app processor.

And what about the lower cage region?

This one’s an enigma. That it contains the Wi-Fi and Bluetooth transceivers, and other circuitry is pretty much a given, considering its proximity to the antennae (among other factors). And it very well could be one and the same as the Askey Computer 8822CS, seemingly with Realtek wireless transceiver silicon inside, that was in the earlier Android TV version of device. Both devices support the exact same Bluetooth (5.0) and Wi-Fi (2.4/5GHz 802.11 a/b/g/n/ac MIMO) protocol generations, and the module packaging looks quite similar in both albeit rotated 90° in one PCB layout versus the other:

That said, unfortunately, there’s no definitively identifying sticker atop the module this time, as existed previously. If it is the same, I hope the manufacturer did a better job with its soldering this time around!

Now let’s flip the PCB back over to the bottom side we’ve already seen before, albeit now freed from its prior case captivity:

I’ll direct your attention first to the now clearly visible reset switch at upper right, along with the now obscured light guide at upper left. I’m guessing that the black spongey material makes sure that as much of the light originating at the PCB on the other side makes it outside as possible, versus inefficiently illuminating the device interior instead.

Once again, the Faraday Cage lifts off cleanly and easily:

The Faraday cage was previously located atop the PCB’s upper outlined region:

Unsurprisingly, another Samsung K4A8G165WC-BCTD DDR4-2666 8 Gbit SDRAM is there, for 2 GBytes of total system memory.

The region below it, conversely, is another enigma of this design:

Its similar outline to the others suggests that a Faraday cage should have originally been there, too. But it wasn’t; you’ve seen the pictorial proof. Did the assembler forget to include it when building this particular device? Or did the manufacturer end up deciding it wasn’t necessary at all? Dunno. What I do know is that within it is nonvolatile storage, specifically the exact same Samsung KLM8G1GETF-B041 8 GByte eMMC flash memory module that we saw last time!

More generally, what surprises me the most about this design is its high degree of commonality with its predecessor despite its evolved operating system foundation:

• Same Bluetooth and Wi-Fi generations
• Same amount and speed bin of DRAM, albeit from different suppliers, and
• Same amount of flash memory, in the same form factor, from the same supplier

The SoCs are also similar, albeit not identical. The Amlogic S905Y2 seen last time dates from 2018, runs at 1.8 GHz and is a second-generation offering (therefore the “2” at the end). This time it’s the 2022-era Amlogic S905Y4, with essentially the same CPU (quad-core Arm Cortex-A53) and GPU (Mali-G31 MP2) subsystems, and fabricated on the same 12-nm lithography process, albeit running 200 MHz faster (2 GHz). The other notable difference is the 4th-gen (therefore “4” at the end) SoC’s added decoding support for the AV1 video codec, along with both HDR10 and HDR10+ high dynamic range (HDR) support.

Amlogic also offers the Amlogic S905X4; the fundamental difference between “Y” and “X” variants of a particular SoC involves the latter’s integration of wired Ethernet support. This latter chip is found in the high-end onn. Google TV 4K Pro Streaming Device, introduced last year, more sizeable (7.71 x 4.92 x 2.71 in.) than its predecessors, and now normally selling for $49.88, although I occasionally see it on sale for ~$10 less:

The 4K Pro software-exposes two additional capabilities of the 4th-generation Amlogic S905 not enabled in the less expensive non-Pro version of the device: Dolby Vision HDR and Dolby Atmos audio. It also integrates 50% more RAM (to 3 GBytes) and 4x the nonvolatile flash storage (to 32 GBytes), along with making wireless connectivity generational advancements (Wi Fi 6: 2.4/5GHz 802.11ax), embedding a microphone array and swapping out geriatric micro-USB for USB-C. And although it’s 2.5x the price of its non-Pro sibling, everything’s relative; since Google has now obsoleted the entire Chromecast line, including the HD and 4K versions of the Chromecast with Google TV, the only Google-branded option left is the $99.99 Google TV Streamer successor.

I’ve also got an onn. Google TV 4K Pro Streaming Device sitting here which, near term, I’ll be swapping into service in place of its Google Chromecast with Google TV (4K) predecessor. Near-term, stand by for an in-use review; eventually, I’m sure I’ll be tearing it down, too. And even nearer term, keep an eye out for my teardown of the “stick” form factor onn. Google TV Full HD Streaming Device, currently scheduled to appear at EDN online sometime next month:

For now, I’ll close with some HDMI and micro-USB end shots, both with the front:

and backsides of the PCB pointed “up”:

Along with an invitation for you to share thoughts on anything I’ve revealed and discussed here in the comments!

—Brian Dipert is the Editor-in-Chief of the Edge AI and Vision Alliance, and a Senior Analyst at BDTI and Editor-in-Chief of InsideDSP, the company’s online newsletter.

Related Content

• Walmart’s onn. UHD streaming device: Android TV at a compelling price
• Walmart’s onn. FHD streaming stick: Still Android TV, but less thick
• Google’s Chromecast with Google TV: Dissecting the HD edition
• Google’s Chromecast with Google TV: Car accessory similarity, and a post-teardown resurrection opportunity?
• Google’s Chromecast Ultra: More than just a Stadia consorta

The post Walmart’s onn. 4K streaming box: A Google TV upgrade doesn’t clobber its cost appeared first on EDN.

European AI4CI Master Artificial Intelligence for Connected Industries kpi пн, 04/21/2025 - 16:39

🖼️ Конкурс "Таланти - КПІ" 2025 - обирайте переможців!!! kpi пн, 04/21/2025 - 13:44

Designed for extreme environments and conditions, radiation-hardened MOSFETs are available from 100 Krad to 300 Krad Total Ionizing Dose

The JANS qualification represents the highest level of screening and acceptance requirements, ensuring the superior performance, quality and reliability of discrete semiconductors for aerospace, defense and spaceflight applications. Microchip Technology announced the completion of its family of radiation-hardened power MOSFETs to the MIL-PRF-19500/746 slash-sheet specification and the achievement of JANSF qualification for its JANSF2N8587U3, 100V N-channel MOSFET to 300 Krad (Si) Total Ionizing Dose (TID).

Microchip’s JANS series of rad-hard power devices are available in voltage ranges from 100–250V to 100 Krad (Si) TID, with the family expanding to higher Radiation Hardness Assurance levels, starting with the JANSF2N7587U3 at 300 Krad (Si) TID. The JANS RH MOSFET die is available in multiple package options including a plastic package using the MIL-qualified JANSR die, providing a cost-effective power device for New Space and Low Earth Orbit (LEO) applications. The ceramic package is hermetically sealed and developed for total dose and Single-Event-Environments.

The devices are designed to meet the MIL-PRF19500/746 standard with enhanced performance, making them excellent options for applications that demand high-reliability components capable of withstanding the harsh environments of space and extending the reliability of power circuitry.

“Meeting the stringent specifications required for rad-hard MOSFETs is extremely challenging, and Microchip is pleased to achieve this development milestone by leveraging its proprietary rad-hard by design process and technology,” said Leon Gross, corporate vice president of Microchip’s discrete products group. “Our advanced technology provides our aerospace and defense customers with highly reliable and cost-effective solutions that meet the growing demand of the market and their applications.”

The JANSF and JANSR RH power MOSFETs serve as the primary switching elements in power conversion circuits, including point-of-load converters, DC-DC converters, motor drives and controls, and general-purpose switching. With low RDS(ON) and a low total gate charge, these power MOSFETs offer improved energy efficiency, reduced heat generation and enhanced switching performance when compared to similar devices on the market.

The post Microchip Completes Radiation-Hardened Power MOSFET Family to MIL-PRF-19500/746 and Achieves JANSF 300 Krad Capability appeared first on ELE Times.

Major industries such as electric vehicles (EVs), Internet of Things (IoT), aeronautics, and railways have strict, well-established processes to ensure they can maintain high safety standards throughout their operations. This level of precision, compliance, and enforcement is particularly important for safety-critical industries such as avionics, energy, space and defense, where high emphasis is placed on the development and validation of embedded software that contemporary and newly developed vehicles and vessels rely on to ensure operational safety.

It’s rare for a software glitch on its own to cause a catastrophic event. However, as embedded software systems become more complex, so too does the onus on developers to make sure their software is able to operate within that complexity bug-free.

That’s because the increasing interconnectivity between multiple information systems has transformed the critical domains like medical devices, infrastructure, transportation, and nuclear engineering. Then there are issues like asset security, risk management, and security architecture that require safe and secure operation of equipment and systems. This necessity for safety is not only acute from operational safety perspectives, but also in terms of cybersecurity.

However, despite the application of rigorous testing processes and procedures that are already in place, subtle bugs are still missed by testing techniques that don’t provide full coverage and don’t embed themselves deeply within operational environments. They are unacceptable errors that cannot be allowed to remain undetected and potentially metastasize but finding them and rooting them out is still a major challenge for most.

While the software driving embedded compute systems becomes more complex and, therefore, more vulnerable, increasingly strict safety regulations designed to protect human lives are coming into force, which means that software development teams need to devise innovative solutions that enable them to proactively address safety and security issues. They should also be able to do so quickly to respond to demand without compromising test result integrity.

This need is particularly significant among critical software companies who depend heavily on traditional testing methods. Even when following highly focused, tried and true testing processes, there are for many software development engineers a nagging concern that a bug could have slipped through undetected.

That’s because they sometimes do, which leaves many quality assurance and product managers, especially in critical industries, to lose sleep over whether they have done enough to ensure software safety.

One major software supplier in the aerospace industry recently faced such a dilemma when it approached TrustInSoft with a problem.

A customer of the software supplier had discovered an undetected bug in one of several software modules that had been supplied to them, and the software was already fully operational. Once informed of the issue and being directed to resolve it, the supplier needed months to locate, understand, and ultimately rectify the bug, resulting in substantial costs for bug detection and software reengineering. The situation also had a negative impact on the supplier’s reputation and its business relationships with other customers.

That’s when they realized they needed a better, more conclusive way to ward off such incursions and do so confidently.

As a first step, the software supplier consulted TrustInSoft to see if it’s possible to confirm that the bug that had taken the software supplier months to identify was not only truly gone, but that no others were lurking undetected.

In just a few days, analysis revealed several previously undiscovered bugs in addition to what had caused the initial alarm. Each of these subtle bugs would have been extremely difficult, if not impossible, to detect using conventional methods, which is most likely why they were missed.

TrustInSoft Analyzer’s use of formal methods gives developers definitive proof that their source code is free from memory-safety issues, runtime errors, and security vulnerabilities. The analyzer’s technology is based on rigorously specified mathematical models that verify a software’s properties and behaviors against precisely defined specifications. It can, as a result, identify every potential security vulnerability within the source code.

The integration of formal methods enables users to conduct truly exhaustive analyses. What that means in practice is that complex formal method analysis techniques can be applied to—and keep pace with—increasingly sophisticated software packages. For many organizations, this intensive verification and validation process is now a requirement for safety and security-critical software development teams.

A significant advantage of formal method tools over traditional static analysis tools for both enterprise and open-source testing is the ability to efficiently perform the equivalent of billions of tests in a single run, which is unprecedented in conventional testing environments.

Critical industries provide essential services that have direct importance to our lives. But any defects in the software code at the heart of many of those industries can pose serious risks to human safety. TrustInSoft Analyzer’s ability to mathematically guarantee the absence of bugs in critical software is therefore essential to establish and maintain operational safety before it’s too late.

Caroline Guillaume is CEO of TrustInSoft.

 

 

Related Content

• Embedded Software Testing Basics
• Don’t Let Assumptions Wreck Your Code
• Software Testing Needs More Automation
• 5 Software Testing Challenges (and How to Avoid Them)
• Performance-Regression Pitfalls Every Project Should Avoid

The post How software testing guarantees the absence of bugs appeared first on EDN.

Microscopic image with $11 usb microscope submitted by /u/The_1King1 [link] [comments]

Nabbed a huge lot of parts at an estate auction. some fun transformers in there. gonna use some for my ghostbusters cosplay build. Still got lots of tubes to sort out submitted by /u/shittyretrocomps [link] [comments]

Found this interesting bit of kit at a thrift store. It's an 80s electronic bathroom scale. Measures weight by moving a piece of steel, wrapped in aluminum through a big inductor. Like a reverse solenoid. That then goes into a board with a TL081 and a CD4050 to generate an 11.68KHz square wave at rest (display reading 0.0lb/KG. When weight is put on the scale (or i move the metal under in the solenoid) the frequency of the square wave drops, and the display counts up. To a max of 136KG/300lb. This is confirmed by connecting my function generator to the white (signal wire) going to the 3 oin DIN and watching the display increase as I turn down the frequency. submitted by /u/aspie_electrician [link] [comments]

Tinkering around with an N555 and a handful of 4017 ic.s. simple Led chaser idea. N555 triggers the 1st 4017. This one controls 2 4017s wich at there turn controls the 10 4017s powering 10 leds each. Creating a chaser effect. Eventually the outputs wil control up to 10 leds per output. Still far from completed. Stil need to figure out how to get the rainbow leds to change colors. As the 4017 is on/of. And the leds are operating between 3 and 3.2volts for changing. What started ad a simple old-school project is now starting to get complicated 🤔 submitted by /u/MBB-M [link] [comments]

submitted by /u/Overall-Product-9565
[link] [comments]

I took apart quite a few microwaves over a year or so and i never saw a plastic HV fuse in them yet so i thought it would be good to share. These HV fuses are esentially built using the same principles of operation: during overcurrent the thin thin wire melts and the spring retracts completely (like, totaly completely back) as soon as that wire melts enough. That quick spring retraction helps to quench the arc as fast as possible. Rated for fast blow 700 mA at 5 kV if you cant read it. submitted by /u/Lovrinjo1 [link] [comments]

Ripped of the trace when pulling out the transistor that was in there so had to get cteative using solder as the new trace.... ugly but it will do the work. submitted by /u/Whyjustwhydothat [link] [comments]

submitted by /u/AutoModerator
[link] [comments]

submitted by /u/PhoenixfischTheFish [link] [comments]

I’ve been working on a modular IoT platform called Genesis, and wanted to share a fun offshoot of it — a single-port, battery-powered version I’m calling the “Pillar.” The port on top accepts various plug-in modules, since they all follow a mostly consistent pinout. The interface includes: 2x GPIO 1x ADC I2C, UART, and SPI It’s just one port, so it’s more of a fun side experiment — but it still supports a decent range of modules. Could be handy for throwing on a relay, sensor, or even a tiny display for field testing. Runs on a Li-Ion battery and has built-in charging via USB-C. submitted by /u/Polia31 [link] [comments]

Blue LED for ‘good’ (<600ppm), green LED for ‘average’ (<1000ppm) and red LED for ‘poor’ (>1000ppm). The board will also print the CO2 values, as they change, on the RTTViewer. submitted by /u/bleuio [link] [comments]

❤️ 3-місячний курс англійської для іноземців - це твій шанс опанувати мову! kpi пт, 04/18/2025 - 16:24

At the end of last year, the global software-defined vehicle (SDV) market size was valued at $49.3 billion. With a compound annual growth rate exceeding 25%, the industry is set to skyrocket over the next decade. But this anticipated growth hinges on automakers addressing fundamental architectural and organizational barriers. To me, 2025 will be a pivotal year for SDVs, provided the industry focuses on overcoming these challenges rather than chasing incremental enhancements.

Moving beyond the in-cabin experience

In recent years, innovations in the realm of SDVs have primarily focused on enhancing passenger experience with infotainment systems, high-resolution touchscreens, voice-controlled car assistance, and personalization features ranging from seat positions to climate control, and even customizable options based on individual profiles.

While enhancements of these sorts have elevated the in-cabin experience to essentially replicate that of a smartphone, the next frontier in the automotive revolution lies in reimagining the very architecture of vehicles.

To truly advance the future of SDVs, I believe OEMs must partner with technology companies to architect configurable systems that enable SDV features to be unlocked on demand, unified infrastructures that optimize efficiency, and the integration of software and hardware teams at organizations. Together, these changes signal a fundamental redefinition of what it means to build and operate a vehicle in the era of software-driven mobility.

1. Cost of sluggish software updates 

The entire transition to SDVs was built on the premise that OEMs could continuously improve their products, deploy new features, and offer better user experience throughout the vehicle’s lifecycle, all without having to upgrade the hardware. This has created a new business model of automakers depending on software as a service to drive revenue streams. Companies like Apple have shelved plans to build a car, instead opting to control digital content within vehicles with Apple CarPlay. As automakers rely on users purchasing software to generate revenue, the frequency of software updates has risen. However, these updates introduce a new set of challenges to both vehicles and their drivers.

When over-the-air updates are slow or poorly executed, it can cause delayed functionality in other areas of the vehicle by rendering certain features unavailable until the software update is complete. Lacking specific features can have significant implications for a user’s convenience but also surfaces safety concerns. In other instances, drivers could experience downtime where the vehicle is unusable while updates are installed, as the process may require the car to remain parked and powered off.

Rapid reconfiguration of SDV software

Modern users will soon ditch their car manufacturers who continue to deliver slow over-the-air updates that impair the use of their car, as seamless and convenient functionality remains a priority. To stay competitive, OEMs need to upgrade their vehicle architectures with configurable platforms to grant users access to features on the fly without friction.

Advanced semiconductor solutions will play a critical role in this transformation, by facilitating the seamless integration of sophisticated electronic systems like advanced driver-assistance systems (ADAS) and in-vehicle entertainment platforms. These technological advancements are essential for delivering enhanced functionality and connected experiences that define next-generation SDVs.

To support this shift, cutting-edge semiconductor technologies such as fully-depleted silicon-on-insulator (FD-SOI) and Fin field-effect transistor (FinFET) with magnetoresistive random access memory (MRAM) are emerging as key enablers. These innovations enable the rapid reconfiguration of SDVs, significantly reducing update times and minimizing disruption for drivers. High-speed, low-power non-volatile memory (NVM) further accelerates this progress, facilitating feature updates in a fraction of the time required by traditional flash memory. Cars that evolve as fast as smartphones, giving users access to new features instantly and painlessly, will enhance customer loyalty and open up new revenue streams for automakers, Figure 1.

Figure 1 Cars that evolve as fast as smartphones using key semiconductor technologies such as FD-SOI, FinFET, and MRAM will give users access to new features instantly and painlessly. Source: Getty Images

2. Inefficiencies of distinct automotive domains

The present design of automotive architecture also lends itself to challenges, as today’s vehicles are built around a central architecture that is split into distinct domains: motion control, ADAS, and entertainment. These domains function independently, each with their own control unit.

This current domain-based system has led to inefficiencies across the board. With domains housed in separate infrastructures, there are increased costs, weight, and energy consumption associated with computing. Especially as OEMs increasingly integrate new software and AI into the systems of SDVs, the domain architecture of cars presents the following challenges:

• Different software modules must run on the same hardware without interference.
• Software portability across different hardware in automotive systems is often limited.
• AI is the least hardware-agnostic component in automotive applications, complicating integration without close collaboration between hardware and software systems.

The inefficiencies of domain-based systems will continue to be amplified as SDVs become more sophisticated, with an increasing reliance on AI, connectivity, and real-time data processing, highlighting the need for upgrades to the architecture.

Optimizing a centralized architecture

OEMs are already trending toward a more unified hardware structure by moving from distinct silos to an optimized central architecture under a single house, and I anticipate a stronger shift toward this trend in the coming years. By sharing infrastructure like cooling systems, power supplies, and communication networks, this shift is accompanied by greater efficiency, both lowering costs and improving performance.

As we look to the future, the next logical step in automotive innovation will be to merge domains into a single system-on-chip (SoC) to easily port software between engines, reducing R&D costs and driving further innovation. In addition, chiplet technology ensures the functional safety of automotive systems by maintaining freedom of interference, while also enabling the integration of various AI engines into SDVs, paving the way for more agile innovation without overhauling entire vehicles (Figure 2).

Figure 2 Merge multiple domains into a singular, central SoC is key to realizing SDVs. This architectural shift inherently relies upon chiplet technology to ensure the functional safety of automotive systems. Source: Getty Images

3. The reorganization companies must face

Many of these software and hardware architectural challenges stem from the current organization of companies in the industry. Historically, automotive companies have operated in silos, with hardware and software development functioning as distinct, and often disconnected entities. This legacy approach is increasingly incompatible with the demands of SDVs.

Bringing software to the forefront

Moving forward, automakers must shift their focus from being hardware-centric manufacturers to becoming software-first innovators. Similar to technology companies, automakers must adopt new business models that allow for continuous improvement and rapid iteration. This involves restructuring organizations to promote cross-functional collaboration, bringing traditionally isolated departments together to ensure seamless integration between hardware and software components.

While restructuring any business requires significant effort, this transformation will also reap meaningful benefits. By prioritizing software first, automakers will be able to deliver vehicles with scalable, future-proofed architectures while also keeping customers satisfied as seamless over-the-air updates remain a defining factor of the SDV experience.

Semiconductors: The future of SDV architecture

The SDV revolution stands at a crossroads; while the in-cabin experience has made leaps in advancements, the architecture of vehicles must evolve to meet future consumer demands. Semiconductors will play an essential role in the future of SDV architecture, enabling seamless software updates without disruption, centralizing domains to maximize efficiency, and driving synergy between software and hardware teams.

Sudipto Bose, Senior Director of Automotive Business Unit, GlobalFoundries.

Related Content

• CES 2025: Wirelessly upgrading SDVs
• CES 2025: Moving toward software-defined vehicles
• Software-defined vehicle (SDV): A technology to watch in 2025
• Will open-source software come to SDV rescue?

The post Architectural opportunities propel software-defined vehicles forward appeared first on EDN.

Соціально важливий проєкт ФММ та Познанської політехніки kpi пт, 04/18/2025 - 13:49

Machine vision systems are becoming increasingly common across multiple industries. Manufacturers use them to streamline quality control, self-driving vehicles implement them to navigate, and robots rely on them to work safely alongside humans. Amid these rising use cases, design engineers must focus on the importance of reliable and cost-effective optical technologies.

While artificial intelligence (AI) algorithms may take most of the spotlight in machine vision, optical systems providing the data these models analyze are crucial, too. Therefore, by designing better camera and sensor arrays, design engineers can foster optimal machine vision on several fronts.

Optical systems are central to machine vision accuracy before the underlying AI model starts working. These algorithms are only effective when they have sufficient relevant data for training, and this data requires cameras to capture it.

Some organizations have turned to using AI-generated synthetic data in training, but this is not a perfect solution. These images may contain errors and hallucinations, hindering the model’s accuracy. Consequently, they often require real-world information to complement them, which must come from high-quality sources.

Developing high-resolution camera technologies with large dynamic ranges gives AI teams the tools necessary to capture detailed images of real-world objects. As a result, it becomes easier to train more reliable machine vision models.

Expanding machine vision applications

Machine vision algorithms need high-definition visual inputs during deployment. Even the most accurate model can produce inconsistent results if the images it analyzes aren’t clear or consistent enough.

External factors like lighting can limit measurement accuracy, so designers must pay attention to these considerations in their optical systems, not just the cameras themselves. Sufficient light from the right angles to minimize shadows and sensors to adjust the focus accordingly can impact reliability.

Next, video data and still images are not the only optical inputs to consider in a machine vision system. Design engineers can also explore a variety of technologies to complement conventional visual data.

For instance, lidar is an increasingly popular choice. More than half of all new cars today come with at least one radar sensor to enable functions like lane departure warnings. So, lidar is following a similar trajectory as self-driving features grow.

Complementing a camera with lidar sensors can provide these machine vision systems with a broader range of data. More input diversity makes errors less likely, especially when operating conditions may vary. Laser measurements and infrared cameras could likewise expand the roles machine vision serves.

The demand for high-quality inputs means the optical technologies in a machine vision system are often some of its most expensive components. By focusing on developing lower-cost solutions that maintain acceptable quality levels, designers can make them more accessible.

It’s worth noting that advances in camera technology have already brought the cost of such a solution from $1 million to $100,000 on the high end. Further innovation could have a similar effect.

Machine vision needs reliable optical technologies

AI is only as accurate as its input data. So, machine vision needs advanced optical technologies to reach its full potential. Design engineers hoping to capitalize on this field should focus on optical components to push the industry forward.

Ellie Gabel is a freelance writer as well as an associate editor at Revolutionized.

 

 

Related Content

• What Is Machine Vision All About?
• Know Your Machine Vision Components
• Video Cameras and Machine Vision: A Technology Overview
• How Advancements in Machine Vision Propel Factory Revolution
• Machine Vision Approach Addresses Limitations of Standard 3D Sensing Technologies

The post Why optical technologies matter in machine vision systems appeared first on EDN.