Збирач потоків

Build a scriptable USB keyboard using a Teensy board that emulates a standard keyboard and can be controlled over serial from a laptop or a Raspberry Pi, letting you interact with pre-boot menus and BIOS settings without a physical keyboard.

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

Be prepared to respond to “electrical overstress” claims from semiconductor suppliers by citing their own datasheet entries.

During my automotive embedded career, I was heading a product team controlling auxiliary functions of a diesel engine powertrain for passenger vehicles.

As you are likely already aware, a “Check Engine”  lamp illuminates on the driver dashboard in case of any malfunction with the engine or its control system. This activation alerts the driver, so that he or she can get the malfunction rectified before continuing the journey.

In one of our production batches, the vehicle assembly line technician started reporting “erratically and intermittently illuminating check engine lamp” as feedback. All of these vehicles were summarily rejected and blocked from further dispatch.

Do you have a memorable experience solving an engineering problem at work or in your spare time? Tell us your Tale

Tempers predictably flared all across the vehicle plant as the population of rejected vehicles grew rapidly. Curiously, our electronic control unit (ECU) associated with this function had been performing flawlessly for the last few years. It was a mystery to all of us why such a problem should crop up so suddenly.

When the failure was analyzed in our laboratory, it quickly became clear that the output driver IC pin used for driving the LED was pumping around 4 mA of current through the LED even in the “off” state! The datasheet had guaranteed a maximum leakage current value of around 0.5 mA. The output driver IC was apparently misbehaving, at least as far as the associated driving pin was concerned.

The IC semiconductor supplier’s application engineers were contacted and briefed about the problem. They later responded with a stock diagnosis of “electrical overstress” as the root cause.

“But what can ever ‘overstress’ your driver pin in such a simple circuit?,” we replied in attempting to counter the (lack of) logic behind their answer. “A simple short wire connects the ECU to the dashboard LED connector.”

“It must be electroshock discharge (ESD) events occurring during your electronic assembly, then,” they responded. “Sometimes ESD precautions are violated by the assembly technicians. We have faced such problems from a few customers in the past.”.

We clearly understood by this point that the semiconductor supplier team was trying to wriggle out of the situation without taking any responsibility or otherwise helping us. “How can so called ‘ESD events’ be partial only to a specific pin of your driver chip?,” we responded, in striving to alert them to the flaw in their reasoning. “It should have caused random failures across all units we’ve manufactured to date, and with all of the pins of your driver chip.” However, the supplier team clung to its reasoning, bringing the situation to an impasse.

Every passing day, our plant situation was getting more and more explosive, when I was struck by an idea. I asked our team to note down the alphanumeric production batch codes stamped on all of the culprit chips. To our surprise, all of them were identical! In contrast, the healthy chips all had other production batch codes.

We wrote an inquiry mail to the semiconductor company, asking them to decode the alphanumeric production batch code stamped on the culprit chips. Their answer was predictable: “It means: This chip was manufactured in country X and plant location Y, with month/year code as mm/yy.” Apparently, all of the culprit chips were manufactured at a specific plant location, where a production quality lapse was presumably leading to the disaster we were facing.

What was the way ahead? We pre-filtered out all of the culprit chips based on their production batch code, preventing them from being assembled on our boards. We also filtered them out of our supply chain by directing our distributors not to supply such chips to us. These steps solved the problem for once and all!

The lessons and insights behind this case are as follows:

• Be thorough with your circuit analysis. This means, among other things, completely understanding all datasheet entries for all key components.
• Prepare yourself to respond to “electrical overstress” responses from semiconductor suppliers by citing their own data sheet entries that support your design decisions.
• “Electrical overstress” can occur due to numerous possible causes, such as ESD, over voltage, over-current, excessive power dissipation etc. Your prior circuit analysis during design verification should rule out these possibilities. Encourage semiconductor supplier engineers to sign off your circuit analysis. This will reduce their chances of later claiming “electrical overstress” as a diagnosis.
• Be mindful of correlating production batch codes with culprit chips. During another of my experiences, this one more recent, I encountered randomly misbehaving CPU chips in one of the ECU failures I was analyzing. I was amazed to learn that all of these culprit CPUs also contained the same production batch codes. No semiconductor supplier will openly admit to quality issues in its own manufacturing plants, even if they’ll all hopefully take corrective action internally.
• Always keep in mind that a random root cause, such as ESD mishandling, cannot cause a consistent failure such the exact same pin misbehaving every single time.

Fortunately, we hit upon the corrective solution to the seemingly intractable field issue quite early, which otherwise would have led to a substantive loss of business for our vehicles and company.

Vishwas Vaidya is a graduate of the Indian Institute of Technology in Delhi, India. Currently, he is self-employed as an engineering consultant and industry faculty member in the field of embedded systems for global automotive clients and high-repute academic institutions. Vishwas’ articles and research reports have appeared in many worldwide engineering publications.

Related Content

• Vehicle emissions: Issues and workarounds for various monitoring conditions
• Stress analysis
• Semiconductor Reliability and Quality Assurance–Failure Mode, Mechanism and Analysis (FMMEA)
• Design for reliability: You have the tools

The post Overstressed over an erratically flickering check-engine lamp appeared first on EDN.

Discover the ePaper smart journal, an open-source electronic notebook built with a Raspberry Pi Zero 2 W, a Waveshare ePaper display, and an M5Stack CardKB keyboard. It offers the simplicity of paper with the power of a computer, perfect for capturing ideas without distractions.

Autonomous systems are making the transition from controlled pilot operations to large-scale deployment across transportation and industrial environments. Additionally, AI training facilities are scaling up to host thousands of AI agents operating concurrently to execute various tasks and build extensive training sets for AI models.

As these systems scale, most of the attention has focused on advances in compute, model performance, and system intelligence. One equally critical but often overlooked constraint is the network infrastructure, which will be required to transport massive amounts of data.

That challenge becomes apparent in environments where many untethered systems operate in close proximity. For example, in a robotaxi depot or factory floor, large numbers of mobile, autonomous systems generate and transfer data at the same time.

Here, the limiting factor is not simply bandwidth, but the network’s ability to sustain multiple high-throughput data streams within a confined physical area—effectively a problem of data density.

Figure 1 Wireless environments such as robotaxi depot hosting many untethered systems in proximity can’t sustain multiple high-throughput data streams within a confined physical area. Source: Peraso

Edge AI and the 10K challenge

In the early 2000’s, we faced what was called the “1000x challenge” as the data communications industry considered how to upgrade fixed and wireless networks to support high-speed access to human customers. As edge AI evolves, data demand is scaling in localized areas by at least another order of magnitude, presenting the 10,000x challenge.

Unlike human-oriented connected devices, which send human-digestible amounts of traffic, these systems continuously produce large datasets as part of normal operation. Cameras, LiDAR, radar, and other sensors capture detailed information about the physical world, often accumulating terabytes of data over short periods of time.

At the same time, the models that power these systems continue to grow. It’s common for operating models to reach several gigabytes and need regular updates to reflect new data and performance improvements. This creates a steady cycle of uploading raw data and downloading updated intelligence.

The effect is a network demand model, which is very different from human-driven demand. Traffic is less sporadic and is heavily upload-biased as systems dump their accumulated experience data. With numerous systems operating in a defined area, demand is constantly high in volume.

Data density becomes the limiting factor

When many autonomous systems operate in close proximity, a supporting wireless network is needed not only to provide high link speeds, but to do so consistently for every client system in the operating space. The defining factors for the network are not only link speed but also data density.

The constraint shows up clearly in places like autonomous vehicle depots, robotics-heavy factories, and AI training facilities. These environments concentrate large numbers of systems into relatively small areas. Each one generates data during operation, uploads it for processing, and receives updated models in return. When many systems follow this cycle at the same time, demand becomes highly synchronized.

Where wireless approaches fall short

If all autonomous systems were stationary, then more cables, fiber, switches, and routers could be installed to provide each device with its own multi-gigabit connection to the network. Mobile systems require wireless connectivity, and the analogy is that more access points or distribution nodes are required to increase data density.

This is where real physical constraints enter the picture: a fixed amount of frequency spectrum and bounds on the amount of data, which can be transported within that frequency space. That translates into very high-density data service that requires reuse of the allocated frequency over a small physical area.

The frequency reuse capability of any wireless technology is determined by how well neighboring access points and clients can isolate their signal from neighboring systems using the same frequency. In other words, a frequency reuse metric is defined by the ability of each terminal to focus its transmission energy, defined as antenna directivity, and the tolerance of each receiver to interference created by its neighbors, which is defined as a signal-to-noise-and-interference-ratio (SNIR) threshold.

Wi-Fi technologies in the sub-7 GHz spectrum, such as multiple-input and multiple-output (MIMO) and 4096 QAM modulation, have done an amazing job at increasing the capacity of each channel, pushing capacity close to the Shannon bound. However, this capacity comes with constraints. Maximum throughput requires very high SNIR use of wide channels, which are in short supply within the allocated spectrum. Moreover, designers must maintain high space-time diversity in order to support multiple MIMO streams.

Furthermore, the realization of high antenna directivity in a phased array configuration, which allows beam steering, is determined by the number and spacing of antenna elements. These factors scale with the carrier frequency, so antenna arrays for higher frequencies are proportionally smaller than antenna arrays for lower frequencies.

Wi-Fi systems generally have one antenna element for each spatial stream. Top-tier Wi-Fi systems can support 16 spatial streams, but rather than setting the antenna spacing at a distance of ʎ/2 for optimal beamforming, antenna spacing is optimized to provide the spatial diversity needed for MIMO operation.

Given a wavelength of 5 cm for a 6-GHz carrier, a square array of 16 elements would typically be 15 cm (1ʎ spacing) to 45 cm (3ʎ spacing) per side. These larger dimensions increase beamwidth and reduce spatial directivity. Additionally, each antenna element will be on the order of 0.5 to 1 ʎ (2.5 to 5 mm).

Since the ability of sub-7 GHz Wi-Fi to scale for high data-density is limited by the carrier frequency and subsequent antenna dimensions, we are led to consider millimeter wave frequencies, which can reduce the antenna element and array sizes by an order of magnitude. Two frequency bands for consideration are 28 GHz, as supported by 3GPP FR2 standards, and 60 GHz, as supported by 5G FR2-2 (or U) and “WiGig” IEEE 802.11ad/ay.

Figure 2 The 60-GHz technology ensures zero interference while operating many wireless networks in the same space simultaneously. Source: Peraso

5G mmWave technology can provide high throughput and high directivity, but some practical limitations impact its suitability for many edge AI applications. First, when considering the 28-GHz band, which represents the primary deployment of 5G mmWave equipment, it’s important to understand that it is a licensed band and is often heavily subdivided. Operation in this band for private networks will be complicated by the need to lease spectrum from the primary holder.

This consideration would not apply to 5G systems designed for the 60-GHz unlicensed band, but in reality, very little hardware has been developed supporting 60 GHz, as few operators want to deal with unlicensed band operation when they have heavily invested in swaths of protected spectrum.

A second consideration for any 3GPP-based equipment is cost. Designed to meet the needs of major network operators, a small cell, indoor node may cost $10 to $15k, and an outdoor RU can easily double the cost. Compared with the economy of WiGig-based 60 GHz, 3GPP-based solutions cannot actively address the edge AI scaling challenge.

WiGig meets high-density edge AI challenge

From inception, IEEE 802.11ad and subsequent 802.11ay standards, commonly known as WiGig, were designed to provide high data density. Leveraging up to 14 GHz of contiguous spectrum with a carrier wavelength of about 5 mm, small high directivity antennas at the access points and client terminals realize multi-gigabit throughput per channel with high isolation from neighboring connections. Furthermore, with no interference from common Wi-Fi, 60-GHz networks can be implemented with high confidence in the availability of clear channels.

In contrast to sub-7 GHz Wi-Fi, WiGig’s data capacity is not dependent on multi-stream MIMO, thus antenna elements can be spaced at ʎ/2 (about 2.5 mm) in order to provide optimal shaping of the antenna beam. With such a small wavelength, the number of antenna elements can also be reasonably scaled up to tailor the beamwidth for the required frequency reuse and resulting data density.

A new breed of integrated 60-GHz products demonstrates proven solutions to the data-density challenge. Providing RF and baseband ICs with compact PCB integrated antennas, these modules make it possible to develop and deploy systems where data density, reliable performance, and cost all matter.

From connectivity to data movement

As data density increases, we should not overlook the fact that it places greater demands not only on the wireless infrastructure, but also on the backend network resources and backhaul. That’s because datasets acquired by autonomous systems must be transported to the AI training engines, which will continuously evolve in terms of operating models and new models provided to the systems in the field.

Net capacity demand needs to be addressed throughout the network, which opens the opportunity for innovations in decentralized AI learning systems. That, in turn, places more learning resources close to the network edge. As this capability evolves, we envision a level of high integration between the wireless network and the local controller, which will ensure reliable data transfer for all domain clients.

Edge AI systems are increasing both the volume of data and the concentration of that data within physical environments. So, as deployments scale, performance will depend on how well networks handle these conditions.

Here, data density provides a useful way to think about the problem. It focuses attention on the limits that appear when many systems operate together, rather than looking at devices one at a time.

Wireless technologies that support high levels of spatial reuse and efficient short-range communication are well positioned to meet these demands. As edge AI continues to expand, those characteristics will matter more than incremental gains in peak speed alone.

Michael Hamilton is VP of business development at Peraso Inc.

Related Content

• Top 10 edge AI chips
• Designing edge AI for industrial applications
• Edge AI powers the next wave of industrial intelligence
• Why Connectivity Has Become an Edge AI Design Decision
• Edge AI Is Forcing a Rethink of Predictive Maintenance Architecture

The post Data density: The constraint reshaping wireless for edge AI appeared first on EDN.

Освітня конференція «Освітній хаб: точки доступу» kpi пт, 09/04/2026 - 12:26

Specialty semiconductor and performance materials producer 5N Plus Inc (5N+) of Montréal, Québec, Canada has been selected by the US Department of War to receive a US$7.3m award to establish domestic production of gallium arsenide components for US defence applications. This follows presentation of the firm’s proposal at the inaugural Defense Industrial Base Accelerator (DIBX) Pitch Competition in Philadelphia (25-27 August)...

A four-video series explores the analog-to-digital and digital-to-analog converters on the Arduino UNO R4, from basic concepts to building a practical electronic voice changer with just a few passive components and a dynamic microphone.

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

element14 Community has launched a new design challenge focused on smart home and healthcare projects, inviting engineers, makers, and tech enthusiasts to build innovative prototypes that improve everyday living and personal well-being.

L&T Technology Services, a global leader in Engineering Intelligence Solutions & ER&D Consulting Services, announced the launch of LTTS FARM, a startup engagement platform designed to accelerate the commercialization journey of deep-tech startups through Engineering Intelligence-led collaboration, co-innovation and market access.

Built on the philosophy of “Collaboration First, Commercialization Next”, LTTS FARM is targeted at startups with TRL 4+ technologies that have validated their technical feasibility and are ready to explore industry adoption. The program is focused on startups aligned with LTTS’ Technology Big Bets – Software Defined Mobility (SDM), Plant Buildout & Modernization, Energy & Industrial Automation, Digital Manufacturing, Next Gen Compute & Data Centers, Software Platforms & EI and MedTech – with the potential to further advance these strategic priorities through new technologies and solutions. By leveraging LTTS’ global presence, domain expertise and customer relationships, LTTS FARM seeks to create a structured launch pad for startups to progress from validated innovation to customer adoption and long-term growth.

The initiative reflects LTTS’ commitment to fostering a thriving innovation ecosystem by bringing together startups, engineering talent and industry stakeholders to address real-world business and technology challenges. The journey will span across evaluation, onboarding, co-innovation, pilot development and commercialization opportunities for eligible startups. Suitable solutions will be considered for broader industry deployments aided by pilot projects, proof-of-concepts, customer demonstrations and diverse commercial engagements.

Amit Chadha, CEO & Managing Director, L&T Technology Services and Member of NASSCOM Executive Council, said, “Many promising technologies struggle because of limited access to customers, industry expertise and commercialization opportunities. Through LTTS FARM, we are creating a platform where startups can collaborate with our experts, gain exposure to global markets and customer requirements, validate real-world applications and accelerate their journey from solution readiness to market adoption. By nurturing innovations that align with and further our technology big bets, LTTS FARM will also expand our Engineering Intelligence ecosystem and help transform breakthrough ideas into industry-ready solutions that deliver measurable business impact”.

The post L&T Technology Services Launches LTTS FARM to Power Engineering Intelligence-led Deep-Tech Innovation from Lab to Market appeared first on ELE Times.

Why did some things happen? Why didn’t others…and what happened instead? To what extent (if at all) were the outcomes predestined? And what outcomes beg for further study?

Ten months back, as I’m writing these words in mid-August 2026, I never would have imagined the long and winding road that awaited me when I realized last October that a water hydrant replacement across the street had inadvertently led to a Comcast outage for my wife and I, along with our next-door neighbors.

The path from there to here has admittedly had no shortage of twists and turns, not to mention frustrations. But (fingers crossed that I don’t jinx myself by typing these words) we’re now at the point where we once again have stable service, thanks in no small part to the most recent technician interaction.

I’ve learned a lot along the way. And the combined fruits (hopefully not rotten) of my experiences and education will likely manifest in further editorial content for quite some time to come…

…starting today, with the latest (last?) entry in my recent series, which began with these pieces:

• Debugging intermittent Comcast, part 1: Scenario-setting
• Debugging intermittent Comcast, part 2: Remediation details

As I wrapped up part 2, I was three-plus weeks into my respite of resurrected broadband and television service stability. It’s now been exactly six weeks, and my connection has remained stable through weather both hot and moderate, and dry and rain-drenched, at least as far as I can tell. Brief outages that escape attention are always a possibility, although my Google Nest-based LAN, Blink cameras and TP-Link sensors, and QNAP NASs are generally quick to log and alert me to broadband drops. To that latter point, summer monsoon season is once again here with a heavy-lightning vengeance, so I’m also abundantly grateful for the newly added earth ground tether.

I’m going to subdivide this concluding (maybe) writeup into several main themed sections:

• Why did the most recent service visit’s technician tweaks seemingly do the trick?
• What’s with that mysterious Comcast-labeled box on the side of the house, not to mention the realtor’s mention of a second service feed put in by the prior owner?
• And why isn’t my broadband service even speedier than it already is?

Without further ado…

Hardware replacements, retirements, and most-likely effective candidates

As a brief reminder—read part 2 for the full details—the technician had swapped out an archaic (predating our home ownership) three-way splitter and 11-year-old (purchased and installed by me) MoCA PoE filter combo outside of our home.

The replacement hardware took the form of a filter-inclusive grounding block.

As I mentioned last time, the componentry inside either/both legacy pieces of gear could have degraded due to environmental extreme-temperature, moisture or other related exposure, and lightning EMP-induced damage. More likely, the splitter was inherently a culprit due to the unavoidable signal insertion loss through it. I realized after the technician left that he’d taken it with him, so I unfortunately can’t say whether it was a balanced or unbalanced splitter. This distinction is critical, both inherently and (in the latter case) depending on how it’s hooked up.

With a balanced splitter, each output “leg” incurs a symmetrical 4.77 dB (ideally, more in real life) per-output signal loss, per the decibel power ratio equation:

10log10(P2/P1)

Where P2 is the measured power and P1 is the reference power. In this case, the ratio is 3. Keep in mind, too, that real-life SNR loss varies across the operating frequency range, as well as being affected by overall non-ideal component behavior, vendor-to-vendor and splitter-to-splitter variability, and the like. Here, ~5.5 dB of per-“leg” loss for a balanced three-way splitter is therefore a more commonly quoted estimate.

An unbalanced three-way splitter, conversely, is in effect a chained combination of two two-way splitters. The “low loss” leg only passes through the first two-way splitter stage, with a ratio of 2, leading to an injected signal loss of (mathematically) 3.01 dB or (real-life) ~3.5 dB. Conversely, both of the “high loss” legs, in each case with the signal passing through both two-way splitter stages between the input and output, incur 6.02 dB (mathematical) or ~7 dB (real-life) losses.

Perhaps obviously, therefore, the signal strength received at the cable modem in the furnace room (for example) notably varied, depending not only on the Comcast-fed source strength, which we already knew had been degraded by our location at the end of the neighborhood “loop”, not to mention the late-2025 repairs and mid-2026 amplifier recalibration. It was also varied by whether the three-way splitter was balanced or unbalanced, and in the latter case, where each output “leg” went.

And don’t forget about the final two-way input signal split within the furnace room, to the cable modem and networked CableCARD triple-tuner receiver. At least this specific situation is better than in the three-way splitter past, when a MoCA device was also in the mix!

This analysis assumes, by the way, that the coax cabling itself wasn’t egregiously lossy. I still think the greatest benefit came from eliminating the splitter itself, not from eradicating any degradation caused by the short cable runs originally connected to the splitter and feeding both downstairs bedrooms, particularly since I’d had a 75 ohm terminator installed at the end of each to prevent reflections and other signal distortions.

Regardless, I’ll need to keep all these factors in mind if/when I decide to reactivate any-to-all of the downstairs MoCA nodes in the future.

And if you’re wondering about potential signal loss through the PoE filter, per the specs for both original (Holland Electronics MPOE-TM) and new (PPC Broadband POEGB-1G70CW) devices, the passband injection loss is miniscule (~1 dB, frequency-dependent), assuming proper operation, that is! Stopband loss is a different matter—40 dB or 70 db—but that’s by design, of course.

Cracking the coax code

Next, let’s definitively sort out all the cable and other hardware running around outside of the house. Last time, I’d surmised that the plastic box on one wall was likely associated with the house’s legacy Comcast service, and I’d provided a glimpse of the four-way switch within it.

Here are some more views of it.

Where do its four outputs go? One heads straight up and into the attic, which baffled me until I remembered the female coax connector on an internal kitchen wall in the middle of the house’s upstairs level. I suspect (and could, I suppose, confirm by crawling around in the dusty, precarious attic) that’s where the first cable ends up.

Another cable runs both above- (presumably due to post-installation soil erosion) and under-ground to the rear of the house, where it snakes underneath the lower deck and, I’m guessing, ends up at a wall-mounted coax connector in the downstairs family room. The third traverses the outer walls, first to one side where it splits, with one output cable heading to the upstairs master bedroom. The splitter’s other output cable continues its lengthy journey to the upstairs living room on the house’s other side.

And the fourth? It’s currently disconnected and coiled up nearby the box. I suspect it was what originally fed the downstairs bedrooms, having subsequently been replaced by the newer service feed from the street mentioned earlier.

Speaking of which, what’s feeding the four-way splitter? I’d always wondered about a cut piece of coax jutting out of the ground nearby the box.

Until, that is, I learned about the earlier-mentioned tap serving our and a neighbor’s residences.

Next to it (in the background of the prior photo) is another enclosure that I’d also long wondered about.

Note the coil of coax at its base. That’s, I suspect, from the original service feed.

Remember me mentioning in part 1 that I was baffled by the two cable spans that had apparently gotten severed? I’m guessing this is why old and new taps, next to each other, with the old cabling and hardware, are not removed after being taken out of service. I did definitively confirm, by the way, that there’s no ongoing service associated with the original coax cable topology, first by unscrewing the four-way-splitter input and seeing that my service didn’t go down.

I then attached the now-disconnected coax to a spare cable modem to confirm that it didn’t detect a valid service signal. Hitron Technologies makes, or maybe more accurately used to make, a portable battery-operated device that claims to more conveniently implement this valid service-or-not function. But I can’t find it anywhere at retail any longer, and the company is non-responsive to my outreach. That said, I’d still love to get my hands on one somehow!

Last mystery, at least for this section; what about the realtor’s aside at some point during the residence purchase process that the prior owner “had another line of service installed”? Comcast doesn’t (commonly, at least, more likely at all) grant customer requests for multiple from-street feeds for a single service account, specifically to preclude the otherwise-possible scenario of multiple concurrent in-use broadband modems. But keep in mind that this all happened more than a decade ago, when corporate policies may have been different (and mind you also involved a prior owner who’s now deceased and I therefore can’t ask).

What if only one of the two feeds had a modem connected to it? And what if the customer was pugnacious (as the prior owner was reputed to be)? Particularly given that the house was at the end of the “loop”, with associated degraded signal strength, did he convince Comcast to run a second line, feeding subsets of the house’s total TV service sockets from each?

From lingering past-history evidence, I’m pretty sure that the cable modem and tethered router were originally located in one of the downstairs bedrooms. But I’m aware from various neighborhood anecdotal factoids that the prior owner had active television service in multiple upstairs rooms, too. Maybe he set up the second line of service through a fictitious business listed at that same address. Or maybe he was just (impressively) pugnacious.

Regardless, although I’d initially theorized that the realtor had meant not “had another line of service installed” but “had a replacement other line of service installed”, I’m now more inclined to take her wording literally, although the newer feed is the only one now still “live”.

Next time: DOCSIS 3.1 and MoCA 2.5

Nearing 2,000 words, I realize I haven’t yet gotten (surprise! not…) to the originally planned “why didn’t my service get better” portion of this treatise. For now, I’ll concisely cut to the chase. Even though the technician had wrapped up his early-July visit with an excited prediction, “wait until you see how fast your Internet access will be now!”, I eventually realized that Comcast’s speed tier options at my location only extended to a high-end “1.2 Gbps” downstream option.

I’m currently on the next-highest tier, the “Gigabit Plus” plan, with maximum documented downstream bandwidth of 1.3 Gbps and peak upstream bandwidth of 35 Mbps.

Earlier, I showed you a fairly typical bandwidth test result: ~850 Mbps down and ~42 Mbps up (the latter higher than promised, I’ll note). My router more generally does an automated speed test every few days, and scanning back over a month’s worth of data, the highest seen downstream bandwidth was 890 Mbps, along with a 43.3 Mbps upstream measurement.

To be clear, this speed is plenty fast for our needs. What I’m most happy about, of course, is its now-resurrected “dial tone” permanence. And given that both my current cable modem and router offer “only” 1 GbE inter-device connections, I’ll never see anything more than ~950 Mbps downstream (accounting for Ethernet protocol overhead) anyway.

That all said, being an engineer, I’m prone to tinkering regardless. Prior to doing sobering account research and fueled by technician enthusiasm, I did a bunch of testing rounds and learned a bunch in the process, all of which I’ll plan to pass along next time. Until then, and as always, I welcome your thoughts in the comments!

—Brian Dipert is the associate editor, as well as a contributing editor, at EDN.

Related Content

• Debugging intermittent Comcast, part 1: Scenario-setting
• Debugging intermittent Comcast, part 2: Remediation details
• Will a location change improve my MoCA?
• The whole-house LAN: Achilles-heel alternatives, tradeoffs, and plans
• A quest for faster upstream bandwidth

The post Debugging intermittent Comcast, part 3: Retrospective analysis appeared first on EDN.

Sivers Semiconductors AB of Kista, Sweden (which supplies RF beam-former ICs and lasers for AI data-center, SATCOM, defense and telecom applications) has announced a $30m strategic investment to significantly expand its indium phosphide (InP) manufacturing facility in Glasgow, Scotland, UK as it prepares for anticipated customer production ramps driven by growing AI data-center and optical networking demand...

🏦 Заявка - пропозиція про розміщення на депозитному рахунку! kpi чт, 09/03/2026 - 14:06

PenEcho is an open-source digital canvas where you can write, draw, and annotate equations while receiving AI responses placed right next to your marks. This article explores its features, configurable AI backends, and licensing.

Followed this guide from Würth and made an RF current probe for analyzing conducted emissions. You can measure both common-mode and differential-mode noise by passing the power and ground cables through the loop differently (see the guide). If you don't have their WE-TS shielding tape on hand, you can probably use regular copper tape. Just don't forget to leave the gap! submitted by /u/liamkinne [link] [comments]

Нові горизонти біоенергетики для України: стажування в Німеччині науковиць з КПІ Інформація КП чт, 09/03/2026 - 13:00

Epiwafer and substrate maker IQE plc of Cardiff, Wales, UK has announced a purchase agreement with Quintessent Inc of Santa Barbara, CA, USA — which specializes in heterogeneous integration of quantum dot lasers and silicon photonic integrated circuits (PICs) — for the supply of quantum dot laser (QDL) epitaxy...

У День знань КПІшники зустрілися із заступником Міністра освіти і науки України Миколою Трофименком KPI4U-2 чт, 09/03/2026 - 12:49

Magnetoresistive RAM (MRAM) memory—which combines RAM-like access with non-volatility to help simplify design architectures—is making headway in aerospace, defense, and other demanding systems. Take the case of Teledyne HiRel Semiconductors, part of Teledyne Aerospace & Defense Electronics, which has added Everspin’s PERSYST STT-MRAM to its non-volatile memory portfolio for aerospace, defense, and industrial applications.

The Chandler, Arizona-based Everspin Technologies is a supplier of commercially available MRAM solutions. Its 256-Mb PERSYST spin-transfer torque MRAM (STT-MRAM) is a non-volatile memory that combines RAM-like speed with the ability to retain data through power loss, system resets, and unexpected interruptions.

Spin-transfer torque (STT) technology manipulates the spin of electrons with a polarizing current to establishe the desired magnetic state of a magnetic tunnel junction (MTJ). Source: Everspin Technologies

Teledyne HiRel will initially offer Everspin’s 256-Mb PERSYST STT-MRAM as part of its memory offerings for military and aerospace systems, targeting applications such as avionics, VPX and single-board computer platforms, radar and electronic warfare payloads, satellite electronics, and autonomous systems. The tie-up will eventually expand to other PERSYST STT-MRAM products, including 64-Mb and 128-Mb options.

Teledyne HiRel will back these MRAMs with product guidance, screening flows, qualification documentation, procurement support, and obsolescence management. This will allow the collaboration to provide design engineers with screening expertise and supply continuity, ensuring availability, lifecycle planning, and long-term supply.

Why MRAM in aerospace and defense

MRAM can replace or complement NOR flash in applications that need faster updates or power-loss-safe storage. It can also reduce a design’s reliance on battery-backed SRAM, hold-up power, or capacitor-backed memory schemes.

In other words, it helps simplify architectures that would otherwise require separate volatile memory, non-volatile storage, backup power, wear-leveling strategies, or complex data-protection circuitry. “PERSYST MRAM delivers a unique combination of endurance, instant-on data retention, and high-performance operation,” said Sanjeev Aggarwal, president and CEO of Everspin Technologies.

That’s critical in aerospace and defense designs, which require memory solutions that can sustain long operating lifecycles and provide reliable performance in harsh environments. So, this partnership between MRAM supplier Everspin and Teledyne HiRel could help lower barriers to adopting MRAM in mission-critical systems for aerospace and defense applications.

Teledyne HiRel will start shipping PERSYST MRAM products from its Milpitas, California, facility in the fourth quarter of 2026.

Related Content

• MRAM Gets Its Own SIG
• STT Structure Turbocharges MRAM
• The Rise of MRAM in the Automotive Market
• MRAM, ReRAM Eye Automotive-Grade Opportunities
• Making the case for MRAM in software-defined vehicles

The post MRAMs accelerate adoption in aerospace and defense designs appeared first on EDN.