Feed aggregator

Espressif has announced the ESP32-E22, its first Wi-Fi 6E SoC designed as a radio co-processor for high-performance connected devices, featuring tri-band Wi-Fi 6E, Bluetooth dual-mode, and a dual-core RISC-V processor.

This article shows how to drive a large WS2812B LED ring with a Raspberry Pi Pico or Pico 2, creating festive light effects and even using the ring as a low-resolution display.

Discover Angelo, an open source portable audio amplifier designed to improve communication with elderly or hearing-impaired people. This project combines simple electronics with a human-centered approach, making it easy to build, customize, and use.

A antenna tuner circuit which incorporates the resistance of the panel meter light into the accuracy of the meter. One must wonder why they would do this. They no longer support this unit so the bulb is hard to find. It is an axial lead bulb much like a axial lead resistor. I could replace the bulb with a resistor that is the same ohms as the bulb, I suppose. No back lit meter then but at least the meter would work again. Dumb design. submitted by /u/RefrigeratorLess9786 [link] [comments]

Чеська компанія RSE відкрила в КПІ ім. Ігоря Сікорського Energy Resilience Lab з обладнанням MWM Київ, 27 серпня 2026 року KPI4U-2 пт, 08/28/2026 - 16:29

submitted by /u/Dr-Double-A [link] [comments]

A zonal power distribution network for cars offers many benefits, but how it affects finding problems is unclear.

In the few years, I’ve been seeing a lot of stories about zonal architecture, the next stage in the evolution of providing power to the many dispersed automotive-electronics functions. This architecture is increasingly being designed into cars for many solid technical reasons.

What is a zonal architecture? I won’t do a deep dive into details, as it has been discussed in detail in EDN and elsewhere. In short, it divides the car’s power distribution network (PDN) along geographic zones, each with a regional power controller, and all supplied by a central power controller and the car batteries. Each of these regional controllers provides power to the local regulators of individual modules in the car – cars now typically have over a hundred of these, permeating and managing every nook and cranny.

On the face of it, zonal makes a lot of sense with respect to weight, cabling complexity, power-systems management, and many other critical factors. This is especially the case as the siting and number of zones can be adjusted to fit the vehicle arrangement (Figure 1).

Figure 1 A zonal architecture assigns a controller (power manager) to different physical areas of the car, and the number and placement of these zones is flexible. (Image source: EV Engineering Online)

It is a radical departure from its predecessor, usually called a domain or centralized architecture (Figure 2). In that classic arrangement which has been used for decades, power distribution is not determined by the physical or spatial location of loads in the car, but rather the function of the module(s) being supported. For example, the four power windows might have a single power unit for all four windows (and maybe the trunk release) with DC rail cabling running to all these locations.

Figure 2 In the widely used domain architecture, controllers are assigned to cover one or more related functions (left); in the zonal approach, the controller division is by physical location the vehicle. (Image source: EETimes Asia)

The domain architecture was the second stage in this evolution. It was the successor to tried-and-true distributed power, which is conceptually the simplest and made a lot of sense in cars when there were relatively few electrical loads.

Distributed power is clear: each load, such as the radio, lights, starter motor, or dashboard, has a direct connection to the battery (regulators were largely non-existent) with a simple on/off switch for that loop (there might be an intermediate relay for higher-current loads). Each loop and load was physically and electrically separate and independent of all the others.

This arrangement made it easy to add loads or disconnect them. Even better, when the car was off – meaning the physical key was out of the ignition – there was zero vampire drain. The only drain on the battery was its self-drain of around a few percent per month.

Why I’m intrigued by the zonal architecture

I’ve been especially interested in the promised benefits of zonal control since I have had a run of electrical problems in my basic ICE 2019 Subaru Outback with 60,000 miles. This car predates zonal distribution, and even uses tangible buttons (networked, of course) for most functions such as A/C; the touch screen is only for secondary functions such as radio, map, and housekeeping (you can drive the car without problem even if that screen blanks out.)

I’ve had these three problems, directly or indirectly related to “vampire drain”:

1. First, the car’s 3G transponder, formally called a Telematics Data Communication Module (TDCM or DCM), kept trying to connect to that service, thus killing the battery. The problem is that 3G is being “sunsetted”, so nearby towers were going dark, and it was trying to link up with a non-existent service (or what if it was in an underground garage?). It kept trying and trying, killing the battery since I didn’t start the car for a few days. The dealer replaced the module free of charge for this known but kept-quiet design flaw.
2. Then, a module that controls power flow to other modules when the car is nominally off malfunctioned and allowed too much vampire current to flow. Again, the module was replaced at no cost to me, but not until I had to jump-start the car.
3. Finally, the door-lock module malfunctioned, and I could only get into the car using the mechanical key that comes with the electronic key fob. While that would be a major annoyance, the added problem was that in this fault mode, the module continued to drain excessive power, again killing the battery.

Yet in all the talk about the zonal architecture, I have seen barely any mention of how it impacts electrical-system troubleshooting. Will it make it easier, harder, or very difficult?

Speaking as a car owner – not as a designer or manufacturer – that’s an important issue.  As cars get more complicated electrically with mandated features, enhanced drive-train control (where ICE, EV, or hybrid), ADAS functions, and more “smarts”, dealing with something that is no longer working can be an impressive challenge leading to quick, easy, and incorrect answers.

How so? When I brought my car to the dealer for each of the three problems with the symptom “dead battery,” the service tech checked the charging system, saw that was good, and so assumed it had to be a bad battery (each time replaced under warranty). Yet the real problems were those load modules drawing vampire current for various reasons.

What’s my user-side concern?

I’m not at all saying that the zonal architecture is a bad thing or a step backwards. I am only observing the extent to which its proponents – all very credible people – have focused almost entirely on its design/build impact and not discussed any in-the-field troubleshooting considerations.

I’ve been burned before by this scenario, and so I get a little worried when proponents of a new architecture or technology talk almost exclusively about its virtues but ignore discussion of any drawbacks. As engineers, we know that nearly every design decision involves pros and cons with respect to overall performance, weight, efficiency, manufacturability, and cost, and these have to be weighed against each other. Nearly every advance also has some downside ranging from trivial to a somewhat bigger deal.

This happened with USB-C and USB-PD (Power Delivery): whatever your requirements within its large power-range “envelope”, USB-C in conjunction with USB-PD is posited as the “universal” solution. Yet experience has shown that such broad, all-encompassing solutions can get a little too clever for themselves, as they try to accommodate so many use cases and scenarios. There are so many power-interconnect arrangements and possibilities, with so many variations, that many cannot be anticipated, tested, or validated despite a detailed standard. USB-C and USB-PD embed the opposite of the engineer’s top rule: keep it simple.

I expressed my concerns about USB-C and USB-PD in a recent EDN blog and received some supporting comments (USB-C and Power Delivery: Too much of a good thing?). As further confirmation, my colleague, EDN’s Associate and Contributing Editor Brian Dipert – who has much more hands-on experience in power interconnects and related – expressed similar concerns along with evidence (USB-C’s lingering incompatibilities and other complexities, part 1: Direct-connect complications and USB-C’s lingering incompatibilities and complexities, part 2: Splitter issues).

My question is simple: what’s the impact of the zonal architecture on troubleshooting? Will service technicians be further confused by its intricacies? Alternatively, is there evidence showing it will actually ease the troubleshooting problem, given the huge number of loads that the vehicle power subsystem must support along with their interconnection via various in-car networks?

I’m not an anti-advances person, but I do sometimes long wistfully for the early days of cars (and other products) when each load was on its own circuit from the battery, and you could troubleshoot most electrical problems with a schematic diagram and multimeter to read voltages, currents, and resistances. There’s a lot to be said for this type of directness and simplicity, that’s for sure, even though I know it’s not coming back.

Do you have any insight or thoughts about zonal architecture and eventual need for troubleshooting?

References:

• 48V zonal architecture made easy using power modules, Vicor Corp
• Zonal Electrical Architectures Cut Vehicle Wiring-System Cost, Complexity, TE Connectivity (via Tech Briefs)
• Zonal Architecture 101: Reducing Vehicle System Development Complexity, On Semiconductor
• Zonal Architecture vs. Domain Architecture: Modular Automotive Infrastructure Face Off, Molex LLC
• SDV Series Episode 2: From Domains to Zones , Keysight Technologies
• Zonal Wiring Architecture Will Make EVs Easier to Assemble, Assembly Magazine/BNP Media
• The hidden car revolution: zonal architecture, ST Microelectronics
• How a Zone Architecture Paves the Way to a Fully Software-Defined Vehicle, Texas Instruments

—Bill Schweber is a degreed senior EE who has written three textbooks, hundreds of technical articles, opinion columns, and product features. Prior to becoming an author and editor, he spent his entire hands-on career on the analog side by working on power supplies, sensors and signal conditioning, and wired and wireless communication links. His work experience includes many years at Analog Devices in applications and marketing, and he also developed significant mechanical-engineering insight while designing control electronics for large materials-testing systems.

Related Content

• Accelerating the shift to next-gen SDVs with zonal MCUs
• Automotive Architecture

The post How will zonal architecture impact automotive troubleshooting? appeared first on EDN.

For decades, semiconductor progress trained us to think about scaling in a particular way. Make the fundamental building block smaller, increase density, improve performance, and integrate more functionality into the same physical space. However, an optical interconnect doesn’t have an equivalent scaling mechanism.

There is no single optical knob that can simply be turned generation after generation to deliver the bandwidth required by future AI and HPC systems. Instead, optical systems have advanced by combining multiple dimensions:

• Higher baud rates
• More wavelengths
• More fibers
• More spatial channels
• Higher-order modulation
• Stronger DSP and FEC
• Better photonic integration
• Shorter electrical reach
• Co-packaged and near-package optics

Each contributes another part of the bandwidth equation. But increasingly, no single one appears capable of carrying the scaling trajectory alone. That changes the nature of the problem.

So, the next generation may be defined less by one component becoming dramatically faster and more by how many different scaling mechanisms can be made to work together in one physical system.

One channel can only be pushed so far

The most direct way to increase bandwidth is to increase the rate of a single channel. That approach has worked repeatedly. But higher serial rates progressively tighten nearly every part of the link, and as a result, electrical insertion loss becomes more difficult, jitter budgets shrink, and equalization becomes more aggressive.

Moreover, modulators require greater bandwidth, photodetectors must respond faster, and signal-to-noise margin becomes harder to preserve. Consequently, digital signal processing (DSP) complexity increases, power rises, and thermal density grows with it.

At some point, simply making one lane faster becomes increasingly expensive in power, margin, latency, or implementation complexity. So, another dimension is introduced: instead of one faster channel, use more channels.

When parallelism becomes difficult, add wavelengths. When wavelength count becomes constrained, add spatial paths. When raw signal quality becomes insufficient, add more sophisticated modulation, DSP, and coding. Each mechanism extends aggregate bandwidth, but each one also adds another architectural dependency.

Wavelength becomes a scaling dimension

Wavelength-division multiplexing (WDM) allows multiple optical carriers to share the same physical path. That is an extraordinarily powerful scaling mechanism. Instead of increasing fiber count every time capacity increases, multiple channels can be carried simultaneously on one fiber or waveguide.

However, wavelength scaling is not free bandwidth. Lasers must remain within controlled operating windows, and filters and resonant structures must maintain appropriate spectral relationships. Otherwise, temperature can shift wavelength and process variation can shift device behavior, so control and calibration may become necessary.

More channels increase characterization and test complexity. Therefore, WDM increases aggregate bandwidth while simultaneously introducing additional thermal, process, control, and manufacturing requirements. Therefore, while the optical capacity increases, so does the architectural requirements needed to sustain it.

Space becomes another dimension

When wavelength or serial scaling is insufficient, physical parallelism becomes another option. There are more fibers, fiber arrays, and waveguides. Then there are parallel optical engines, multicore fiber, and spatial-division multiplexing.

Again, capacity can increase significantly, but physical parallelism creates another set of challenges. For instance, alignment becomes more demanding while connector density increases. Also, fiber attach becomes more complex, and package escape becomes more difficult.

As a result, assembly tolerances tighten and test channel count increases. Furthermore, yield can become increasingly sensitive to the number of optical paths that must all operate correctly.

How modulation and coding extend the channel

When the raw physical channel cannot be improved enough, more information can be extracted from it. Here, higher-order modulation places more information into each symbol and DSP compensates for impairments. Next, forward error correction (FEC) allows operation in regimes that historically would have produced unacceptable error rates.

These techniques are remarkable examples of engineering overcoming physical constraints. But they also move complexity into other parts of the system. For instance, more DSP consumes power, more sophisticated modulation usually requires greater signal quality and control, and FEC can introduce latency.

Also, transmitters and receivers become more complex and characterization becomes more difficult. So, system performance becomes increasingly dependent on the combined behavior of optics, electronics, algorithms, power delivery, and thermal conditions. At that point, the link is no longer simply an optical-device problem; it’s an architectural issue.

Electrical and optical scaling getting coupled

This becomes especially important as optical engines move closer to compute. Traditional pluggable optics created a relatively clear boundary. The electrical system drives the module, the module performs electrical-to-optical conversion, and the fiber carries the signal.

As bandwidth rises, however, the electrical path between the processor, switch, or accelerator and the optical module becomes increasingly costly. Board loss rises, SerDes power increases, and equalization becomes more demanding. In short, electrical reach begins consuming a growing fraction of the system power budget.

That is one reason near-package optics (NPO) and co-packaged optics (CPO) are receiving so much attention. Shortening the electrical path can help substantially, but the interconnect problem does not disappear. It moves, so the package must now support:

• High-speed electrical I/O
• Optical coupling
• Laser deliver
• Fiber attachment
• Power delivery
• Thermal gradients
• Mechanical stress
• Alignment stability
• Test access
• Manufacturing yield
• Serviceability

As optical engines move closer to compute, component benchmarks become less meaningful in isolation. A faster laser, modulator, or detector creates system value only when its performance can be preserved through electrical drive, thermal conditions, optical coupling, alignment, packaging, manufacturing, and test.

The useful performance of the optical link is therefore increasingly determined by the architecture surrounding the device, not by the device alone. Moving optics closer to compute therefore does more than shorten an electrical connection. It changes where the system boundary must be closed.

Package becomes part of optical scaling strategy

At moderate bandwidth density, packaging can sometimes appear to be supporting infrastructure around the optical function. At extreme bandwidth density, that distinction becomes difficult to maintain.

The package determines how close the optical engine can be placed to compute. It influences electrical reach, determines fiber and optical access, and carries the power. Next, it establishes much of the thermal environment and influences mechanical stability and alignment. That affects manufacturability and yield and determines how the device can be inspected and tested.

That influences long-term optical performance through thermal expansion, stress, material movement, and aging. This means optical scaling can no longer be separated cleanly from advanced packaging. So, the relevant question is no longer how fast is the modulator or how many wavelengths can the fiber carry?

The more important question becomes: Can the optical, electrical, thermal, mechanical, packaging, and manufacturing architecture support the required bandwidth together? That is a system-level scaling problem.

Scaling mechanisms beginning to stack

This may define the next phase of optical interconnect. A future architecture may simultaneously use:

• Higher symbol rates
• Multiple wavelengths
• Spatial parallelism
• Advanced modulation
• DSP and FEC
• Co-packaged or near-package optical engines
• New fiber or waveguide structures
• More sophisticated thermal and control systems

As a result, the scaling mechanisms begin to stack. That creates enormous potential bandwidth. But it also means that every generation depends on a larger number of interacting mechanisms functioning correctly at the same time. Theoretical aggregate bandwidth may be extremely high.

The realizable bandwidth is constrained by whether all of those mechanisms can coexist within acceptable mode:

• Power
• Latency
• Temperature
• Signal margin
• Alignment tolerance
• Manufacturing yield
• Testability
• Reliability
• Cost

The scaling limit therefore begins to move. It’s no longer determined only by the maximum capability of an individual optical device. It’s increasingly determined by the ability to integrate multiple scaling dimensions into a manufacturable system.

Architecture becomes multiplier

This leads to a broader distinction. Electronics historically extracted enormous value from repeatedly improving a fundamental building block. Make the transistor smaller and many system-level advantages followed. But optics has no single, equally-dominant scaling knob.

So, optical interconnect increasingly creates aggregate progress by combining several mechanisms at once. However, it doesn’t make device innovation less important.

• Better lasers matter
• Better modulators matter
• Better detectors matter
• Better fibers matter
• Better photonic platforms matter
• Better electronic interfaces matter

But the value of each technology increasingly depends on how successfully it participates in the larger system. A high-performance modulator may be difficult to scale if its thermal sensitivity requires excessive control. A fiber architecture may provide enormous theoretical capacity but struggles if connectorization and alignment become impractical.

A wavelength-rich design may lose its advantage if tuning and calibration consume too much power. An optical engine may achieve exceptional bandwidth density but fail economically if assembly yield is too low. A very fast lane may provide little system benefit if the electrical path required to drive it consumes too much power.

There is no isolated winner. Architecture determines how much of each technology can actually be used.

Metric is also changing

Optical progress has traditionally been summarized with headline numbers such as Gb/s per lane or Tb/s per module. Those metrics remain important, but architectural scaling demands broader measures.

• Bandwidth per watt
• Bandwidth per fiber
• Bandwidth per package edge
• Bandwidth per unit area
• Bandwidth per optical engine
• Bandwidth per dollar
• Bandwidth at acceptable manufacturing yield
• Bandwidth that remains stable across temperature, variation, and lifetime

Those metrics force physical realization into the discussion. A laboratory demonstration with extraordinary bandwidth is not automatically a scalable interconnect. A solution that achieves higher throughput by consuming excessive DSP power may simply move the system bottleneck into cooling.

A solution that increases channel density while making alignment intolerant to normal manufacturing variation may convert a bandwidth improvement into a yield problem. A design that performs at room temperature but shifts substantially across real operating conditions may not provide the usable bandwidth suggested by its nominal specification. Bandwidth alone is therefore not enough. The bandwidth must be realizable.

Next optical breakthrough may not be one device

The next major optical interconnect advance may therefore look different from historical semiconductor scaling. It may not arrive as one device or material that suddenly changes the entire trajectory. It may arrive as an architecture that combines several imperfect technologies unusually well.

• A little more baud rate
• More wavelengths
• More spatial parallelism
• Better modulation
• Better DSP
• Shorter electrical reach
• Better photonic integration
• More advanced packaging
• Better thermal control
• Better assembly
• Better test

Each contributes part of the answer. The breakthrough is making them coexist without losing the benefit to power, manufacturing complexity, yield, reliability, or cost. That is the architectural transition.

Optical scaling becoming system scaling

AI and HPC systems are creating extraordinary pressure on interconnect bandwidth. That pressure is unlikely to disappear, so individual optical and electronic devices will continue improving. But the bandwidth trajectory required by future systems may increasingly exceed what any single scaling mechanism can provide.

When that happens, architecture becomes the multiplier. The question changes from how fast can one optical link become to how many scaling dimensions can be combined into one manufacturable, power-efficient, reliable physical system? That is a different problem.

It’s also a much larger opportunity. The next optical scaling law may not belong to a single device. It may belong to the architecture that successfully combines multiple scaling dimensions into one realizable system.

When one physical dimension cannot scale fast enough, the system must scale in many dimensions. That’s why optical scaling is becoming architectural scaling.

Dr. Moh Kolbehdari is senior director of IC/packaging at Socionext US.

Related Content

• AI Clusters Spur Optical Connectivity
• The 200G/lane CPO pushes optical interconnect boundaries
• Where co-packaged optics (CPO) technology stands in 2026
• Photonics: A Foundational Scaling Layer for AI-Era Computing
• From Co-Packaged Optics to Nanolasers, Photonics Moves Inward

The post Optical scaling turning into an architectural challenge appeared first on EDN.

Iteration3D is a French web platform that generates customizable 3D models for printing, using a parametric engine to create models on demand based on user specifications.

i had one mechanical keyboard after getting bored i tried to reverse engineer it but i couldn't send any usb data or i could not see much on the terminal when i tried to see if it listens to the data and after opening i saw that it only takes +5v and gnd plus the processor something like BYK.. was a hard coded chip that doesnt listen notes i was newbie to hardware and really scared to try anything. so i gave up but seeing my brother have a kreo rgb keyboard it gave me some boost to open it up and i learned so much and burnt my hand while trying to solder. heck i even burnt the solder iron's wire itself (sniff sniff whats that smell). so the plane was that i would use a mcu as esp 32 or pico that listen to my command and can do anything that i want . first month really .... i bought a mulitmeter and did the traces of all the rows and col sicne there was no pcb and other design files there i didnt know how keyboard matrix works at all i went rhough whole thing.. after getting all the traces and nothing them i was really soul scattered by the fact how this whole thing worked but then i got to know this was a common thing everyone knew this. after this i took pico as the main mcu why... it was small it has higher clock speed. it was one sale since the esp was on boom and the price of pico was dropped it has more computer power that i needed for Fourier transform for disco light that i wanted for the custom rgbs i would put there quickly after that i ran into a problem of less gpio also after that i took a longer time to solder since i was learning and it was very scarry to solder on the pcb but as i did i grew more confident .. after burning my finger prints. i bought a io expander because of 6 rows and 17 cols it got burnt and again tried that was jittering the one signal was affecting other signal. so i gave up 3-4 cols and went for the gpio full on. The RGBs... Hardest the rgb i had to cut each rgb strip stick them all on each keys then use the single core wired without the cover and solder each joints aroung 300 small pieces of them total 600 joints appx and it was tough because heating one end would make other end heat up also. but since i cascaded 100 of them the voltage kept decreasing and it was 0.5v at the end so i just provided supply from both of rows and it worked and there was no deeming and jitters. thats it... if u want to know about the logic behind it then u can ask me i will add it most of things and testing and all the stuff is in the video submitted by /u/shiv20242028 [link] [comments]

Learn how to set up a virtual machine with VirtualBox and install Ubuntu or Kubuntu safely, from downloading the software to enabling Guest Additions and optimizing performance.

I had a lego pack sitting around that I has sorta messed up years ago for somthing, desided see if I could jam a 9v to 5v converter in it, to say the least I sorta went way smaller than I actually needed, in theory it can take 1.5 amps, I wont get even close to that using it, to help with the heat it has some copper sheet attached the sits against the AA to help spread heat from it, parts used are two 10UF caps, ceramic 0.47UF on 9v side and a ceramic 0.1UF on the 5v side, the souldering is a little rough, but this is the smallest thing Ive ever made by far, Im sure it would be better if I did it a few times. submitted by /u/dronko_fire_blaster [link] [comments]

📌 Сесія професорсько-викладацького складу kpi чт, 08/27/2026 - 21:39

BluGlass Ltd of Silverwater, Australia — which develops and manufactures gallium nitride (GaN) visible laser diodes based on its proprietary low-temperature, low-hydrogen remote-plasma chemical vapor deposition (RPCVD) technology — has appointed Yam Rubenstein as a non-executive director to support its growing global operations...

📰 Газета "Київський політехнік" № 27-28 за 2026 (.pdf) Інформація КП чт, 08/27/2026 - 15:54

КПІ ім. Ігоря Сікорського відвідав віцепрезидент і керівник апарату президента американської компанії Lockheed Martin — Річард «Оттер» Б’ю KPI4U-2 чт, 08/27/2026 - 15:13

While updating and streamlining the hardware setup improved the situation, why it achieved this welcome outcome was less clear. And then there was the truly “shocking” discovery…

Last time, in part 1 of this series, I gave a historical overview of my longstanding broadband and television relationship with Comcast (aka Xfinity, the company’s brand for consumer products and services), focusing on the service in my most recent (and current) Colorado residence.

Specifically, I discussed the increasing frequency and severity of service “drop” issues my wife and I experienced subsequent to inadvertent cabling damage consecutively done by our community’s water and sanitation service provider last October and our power company earlier this summer.

At last week’s writeup’s conclusion, I was awaiting the arrival of yet another Comcast technician, subsequent to a recent service issues-escalation to a near-daily cadence (a particular problem given that my wife and I both work from home), an on-site visit which I’d insisted on sticking with in spite of the service’s as-usual temporary resurrection later that same evening. The on-site technician visit wasn’t scheduled until the next afternoon, but he called me mid-morning that (next) day and asked if he could arrive early, a rare deviation from the “late arrival” norm.

Competence is the best

Appreciative of his promptness and hopeful that I could still persuade him into making the debug session gratis for us, I asked him to delay his arrival only 45 minutes until my wife and I had both wrapped up a few work to-dos. He happily obliged, subsequently pulling up on the street in front of our house right on time. I’m not sure whether he was an “official” Comcast employee or a contractor, not that it really matters; his vehicle was a minivan with no corporate markings on it, albeit filled with Xfinity-branded tools, cabling, and other equipment.

I identified myself as a “techie” and asked if I could follow him around, periodically picking his brain and more generally absorbing through observation at least a bit of his conceptual plus experience-accumulated knowledge. He was happy to oblige: “this’ll be fun” were his exact words. And indeed he was smart and nimble of mind, not to mention enthusiastic; a delightful experience, all in all. But he also was in a hurry, so I strove to practice appropriate question-cadence restraint.

The first notable thing I learned from him was that the strand of coax coming out of the ground around the back of the house was completely unrelated to the plastic box labeled “Comcast” attached to the wall on the other (front corner) end of the house, first mentioned and pictorially shown in part 1 of this series.

This cable ran straight to the tap near the street. I assumed it was the mysterious “other line of service that the prior owner had installed” mentioned by the realtor more than a decade earlier.

Speaking of taps, not to mention the RF amplifiers I mentioned last time, along with other constituent building blocks of a hybrid fiber-coax system such as Comcast’s, check out this block diagram from Wikipedia’s as-always thorough, accurate and otherwise excellent entry on the topic.

I don’t know, by the way, where the fiber-to-coax conversion node(s) is/are located in our community, either in general or to what degree of proximity to my residence location.

MIA (not to mention obligatory)

The second thing the technician immediately noticed and I learned, to our mutual great dismay, was that this length of coax was nowhere properly earth-grounded nearby where it entered my home. The plastic box, which I was now realizing was likely associated with the legacy Comcast service likely stretching back to the original owners, was grounded.

As was the tap near the street.

But here? Nothing. Thereby representing not only potentially serious fire and electrocution danger for the home and its occupants but also suggestive of why I’ve endured multiple bouts of electrical shock-induced equipment destruction in my so-far time here (ironically, by the way, there’s a summer-monsoon lightning storm underway as I type this).

Then he saw the three-way splitter attached to the outer wall, which predated (by how long I have no idea) the initiation of my home ownership. Attached to the input end was the PoE (which stands for point-of-entry in this particular case, not power over Ethernet) filter I’d subsequently added for network security purposes back when I was experimenting with MoCA, and which I’d neglected to remove afterwards.

And attached to the splitter outputs were short spans of coax that ended up at wall connectors in two downstairs bedrooms (one each), along with a longer third coax span that also ended up inside, this time in the furnace room, where it split one more time and fed both the CableCARD receiver and cable modem.

After shaking his head and muttering “I don’t know how you even have any broadband service at all” under his breath, he fired up his smartphone, on which was installed a Comcast-proprietary (presumably) app that enabled him to live-monitor my cable modem’s statistics over its WAN connection. Once again, this time louder and more emphatically, he said (and this time also gestured), “I don’t know how you even have any broadband service at all” and invited me to look at the phone display for myself.

I noticed that the upstream transmission power ratings for the various in-use channels were all in the upper 50 dBmV range. I didn’t know much (and still don’t know as much as I’d like) about cable systems, but I knew enough to realize that this wasn’t a good thing.

Swaps and simplifications

Again, I realized he was in a hurry, so I refrained from asking a bunch more questions. He indicated that he thought the existing splitter was left over from a long-past satellite television system installation. I don’t quite buy that theory; although the DC power pass-through support and broader top-end frequency afforded by such a splitter (2.4 GHz vs 1 GHz, with a common 5-MHz bottom end of the range), the latter theoretically allowing for neighbors’ latest-generation MoCA signals to “leak” into my setup, might destructively interfere with my DOCSIS 3.1 modem. So, the PoE filter I’d inadvertently left installed would (or at least should) have alternatively blocked neighborhood noise.

That said, the splitter and filter were admittedly ancient, both also containing passive RF circuitry. So, perhaps something inside either or both had gone awry with advancing age and longstanding lightning, moisture, temperature, and other ambient environmental exposure.

He asked if I was currently using the downstairs bedrooms’ splitter outputs. When I replied in the negative, he wholesale-replaced the splitter with a grounding block (and wire) containing an integrated PoE filter, leaving the other two previous splitter-supplied coax feeds detached.

He also swapped out the connectors on both ends of the new grounding block-plus-PoE filter combo. Then he revisited his smartphone app and happily reported that the data he was seeing was “still not great, but much better now, and good enough”. Again, I got only a brief glimpse of the screen, but enough to confirm that the upstream channels’ power measurements were all now comfortably in the lower end of the 50s dBmV range.

I wish they were even lower than that, but again, we’re at the end of the neighborhood “loop” line. And it’s been more than three weeks (as I write this) since his visit, with not a single service drop, so in the spirit of “perfect is the enemy of good”…I’m good!

In case you were wondering, by the way, I immediately ordered, and subsequently installed as soon as it arrived, a grounding rod to attach to the other end of the grounding block-and-wire he’d generously given me.

The sticker on the side of the rod’s snug plastic packaging was awesome.

When I walked him back to his car (passing by the mysterious plastic box marked Comcast on the way, of which he had no knowledge and no spare time to further explore that day), he gifted me a bunch of extra hardware—MoCA filters, grounding blocks, 2- and 3-way splitters, and a 10’ span of high-quality coax cable with connectors on both ends—all of which I’ll be discussing more in next week’s finale (as planned, but who knows for sure) to this series.

In the upcoming concluding post(s), I’ll suggest some possible theories as to why (and to what degree, straight from my cable modem’s logs) his efforts bore fruit. I’ll also share the results of my subsequent sleuthing regarding the aforementioned mysterious plastic Comcast box and the various cables running into and out of it, as well as what was within it. Stay tuned for that and more; for now, please continue to share 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
• Will a location change improve my MoCA?
• The whole-house LAN: Achilles-heel alternatives, tradeoffs, and plans
• A quest for faster upstream bandwidth
• Lightning strikes…thrice???!!!

The post Debugging intermittent Comcast, part 2: Remediation details appeared first on EDN.

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

Почути звук із 13 століття завдяки науковцям ФЕЛ kpi чт, 08/27/2026 - 11:00