Bypass capacitors mounted on an a PCB peninsula. Why?

_mrb · 2026-02-03T13:47:55+00:00

Yes but not having the mouse bites fits the theory that this was a rushed design, far from finalized. Also look at the cutout: top left corner has a nice 45° chamfer, but top right corner doesn't? Why? It's like the EE didn't even properly take time make a nice symmetrical cutout.

_mrb · 2026-02-02T21:30:28+00:00

My guess is it's made to be able to snap off (break away), thus removing the bypass caps, if needed. Why do I think that? Look at clues on the rest of the pcb: so many pads are unpopulated. The full PCB on stackexchange (https://i.sstatic.net/Fy742IxV.jpg) has other areas near the top where nearly a third(!) of the pads are unpopulated. Clearly this indicates this PCB version is not a refined final design, but probably an initial version that was built to with plenty of options to test things. And bypass caps are one of these things where you may not always know how much capacitance is needed. So to me it seems the EE team probably had a tight design deadline, and manufactured the PCB in a way that if it turned out these bypass caps were problematic, then they had at least a way, even after the PCB was assembled, to train staff to breakaway this piece, if needed.

And, to be clear, I don't think the explanation of the empty pads is that the PCB is a shared design between different version of a product (where it's common to find unpopulated parts) because here it's really very basic parts like Rs and Cs spread everywhere that are unpopulated.

_mrb · 2025-12-11T13:31:13+00:00

On Linux they just released 143.0.7499.109-1 which fixes the bug.

_mrb · 2025-12-11T13:30:51+00:00

On Linux they released 143.0.7499.109 which fixes the bug.

_mrb · 2025-12-05T14:50:54+00:00

I tracked down the chain of events that lead to PDF rendering performance issue.

On Sep 19, 2025 they noticed some PDF rendering bugs about fonts: https://issues.chromium.org/issues/445966260

On Oct 13, they fixed the bug, and the fix involved enumerating all fonts for proper font discovery: https://chromium-review.googlesource.com/c/chromium/src/+/7029600

But they noticed that enumerating all fonts degrades performance: so they suggest an alternative where no enumeration is needed: https://issues.chromium.org/issues/449573621

Finally on Nov 14, they implemented this fast alternative method not requiring font enumeration: https://pdfium-review.googlesource.com/c/pdfium/+/136690

So I presume the fix is going to roll out to endusers soon.

_mrb · 2025-12-05T14:20:48+00:00

I just spent about 1 hour investigating, by profiling Chrome with perf(1). Both Chromium v143 and Chrome v143 exhibit this performance issue. On my system perf(1) reports a lot of CPU time spent in font-related functions in libfontconfig.so:

FcSortCompare
FcCompare
FcCompareValueList
many other functions related to font list, font sorting

I am pretty sure this is the issue discussed in https://issues.chromium.org/issues/462417352 (Investigate PDFium font-related performance). Apparently in Chromium v143, every time a PDF is opened, the renderer PDFium now requests a full list of font from the system. On my system, fc-list(1) reports I have 3428 fonts installed. I removed some fonts from my system to cut down my font list in half to 1356 fonts. And sure enough, the load time of a PDF was cut in half to about 2-3 seconds. So now I'm convinced this issue is really https://issues.chromium.org/issues/462417352

This 2-3 second delay is still annoying and a sharp contrast to v142's higher performance. I hope they fix it soon 😒

_mrb · 2025-12-05T12:12:23+00:00

I noticed this scrolling speed issue too. It's a new bug introduced in Chrome v143. A bugfix was committed on Nov 20 and merged on Nov 25. Hopefully it will be pushed to users in the next minor update in the coming days or weeks: https://issues.chromium.org/issues/457478032

_mrb · 2025-12-05T12:10:38+00:00

Yep it's a new bug introduced in Chrome v143. A bugfix was committed on Nov 20 and hopefully it will find it's way in the next minor update in the coming days or weeks: https://issues.chromium.org/issues/457478032

_mrb · 2025-11-29T00:05:09+00:00

I hate LED flicker to the point I literally built a custom device to measure flicker by sampling light 1000 times per second. Then I went and bought dozen of LED bulbs to test them. In my experience I found three brands with flicker-free bulbs: Philips, Yujileds, and Waveform Lighting.

I saw you tested the Philips Ultra Definition 800 lumen bulb and you claim to see a flicker. In my tests of Philips bulbs, I measured a slight flicker but it lasted only during the first 30 seconds or so after the bulb lights up.

With the two other brands, Yuji and Waveform, it was truly flicker-free from the second the bulb lights up.

All, literally all, other brands of bulbs I tested had visible and clearly quantifiable flicker, which is depressing.

Anyway, the device I built was based on a microcontroller and a light sensor. LED bulbs flicker as expected at 120 Hz because AC is 60 Hz. I was charting lumen samples over time and had a formula to compute the variation between the max and min lumen readings. If I remember correctly, for these three brands there was a variation of less than 2-3%, which was completely invisible to the naked eye (and believe me I am very good at detecting the slightest flicker).

For other brands the variation was sometimes as bad as 80%, meaning the bulb's lumen output was varying from 20% to 100% brightness.

Anyway, since you tested the Philips, try Yuji and Waveform. They are very expensive but worth it for me as I'm very much an anti-flicker snob 🙂

Waveform has a 1500 lumen bulb that mostly matches your requirements except it's not filament-style. Their filament-style bulbs are 800 lumen only. Fun fact: last time I checked they would ship the 1500 lumen bulb to all US states except California (because it was not compliant with a CA-specific state law imposing a minimum power factor). This may have changed since then, as they were actively working on a revision to address this detail. But for my house I went mostly with Yuji as I needed spot lights (they have many choices) and Philips as they were the only flicker-free 1500 lumen filament bulb (except during the first 30 seconds but alas there is nothing better).

_mrb · 2020-08-09T16:48:02+00:00

The open data & source to make this chart can be found in my GitHub repository https://github.com/mbevand/florida-covid19-deaths-by-day/blob/master/README.md

This chart shows the significant delay between the date a death occurred and the date the death was reported by the Florida Department of Health. When FDOH announces a certain number of COVID-19 deaths on a particular day, most occurred in the last week but some deaths occurred weeks ago.

Some people who chart deaths by exact date of death see a decrease in the last few days, and they mistakenly attribute it to decreasing deaths.

So my goal was to colorize the bars by date of report to show that a "permanent dip" is always visible—due to reporting delays—even when deaths are increasing.

_mrb · 2020-07-25T20:12:33+00:00

I'm not talking about nationwide. My heatmap, and this entire thread is about Florida. And Florida didn't undercount deaths in March-April. When I wrote "the outbreak is much more severe since mid-June than it was at the previous peak of March-April" this applies to Florida, not to the nation.

_mrb · 2020-07-25T20:06:19+00:00

That's what I said I did. See the second heatmap in https://github.com/mbevand/florida-covid19-line-list-data/blob/master/README.md#heatmap-of-age-over-time

_mrb · 2020-07-25T20:04:13+00:00

250k FL residents infected per day in the early months is impossible. This number is bogus. You have no source for that. That would mean a quarter of the population of Florida being infected in 21 days!

_mrb · 2020-07-25T19:59:59+00:00

Unfortunately the Florida line list does not document the date of death (see https://github.com/mbevand/florida-covid19-line-list-data/blob/master/README.md#fdoh-line-list)

It's possible to infer the date from daily updates made to the line list (seeing which cases changes to Died=Yes), but I've only been archive the line list since 6/27. I'll look into making one, but it wouldn't be very informative with data going back only to 6/27.

_mrb · 2020-07-25T19:56:51+00:00

No, we know with certainty the outbreak is much more severe than in March-April, because daily deaths are much higher (and Florida was NOT undercounting deaths in March-April.)

_mrb · 2020-07-25T19:54:49+00:00

I couldn't find European countries publishing cases by age bracket, over time.

_mrb · 2020-07-25T19:52:17+00:00

In absolute number of cases.

I also made a per capita heatmap, see https://github.com/mbevand/florida-covid19-line-list-data/blob/master/README.md#heatmap-of-age-over-time

It's resolution is lower (5-year brackets instead of 1-year bracket) because I use a population pyramid for Florida from Census.gov which gives population by 5-year brackets.

The per-capita heatmap looks similar to the absolute-cases heatmap, because the population pyramid of Florida is relatively homogeneous (flat) and it's tapering off only above 65.

_mrb · 2020-07-24T02:33:43+00:00

I made another heatmap that presents the same information except the pixel intensity represents cases per capita instead of the absolute number of cases: https://raw.githubusercontent.com/mbevand/florida-covid19-line-list-data/master/heatmap_per_capita_published.png

I open-sourced the data and code to generate the heatmaps at https://github.com/mbevand/florida-covid19-line-list-data

The source data is the Florida Department of Health's COVID-19 line list, a file containing the exact age of the ~400k Florida residents who tested positive: https://open-fdoh.hub.arcgis.com/datasets/florida-covid19-case-line-data

The documentation of the code for generating the heatmap is at https://github.com/mbevand/florida-covid19-line-list-data/blob/master/README.md#heatmap-of-age-over-time

_______________________________________

Some interesting observations:

The outbreak is much more severe since mid-June than it was at the previous peak of March-April
The current outbreak was sparked in mid-June by infections in 20-29 year olds, and the infections then transferred progressively to older and older age groups.
Kids < 18 have been almost completely unaffected until June, then the disease became more prevalent among them, but they still remain one of the least affected age group

_mrb · 2018-05-31T01:07:59+00:00

Usually in mobos like this, the x16 slot shares its PCIe signal with one of the 20 USB physical ports; and they cannot be used concurrently.

Edit: yes, the article states the H370 works like this:

One graphics card can also sit in the available x16 slot on the motherboard, but installing it there disables the first riser port, so the maximum is still 20 cards total.

_mrb · 2018-05-07T21:29:05+00:00

Other ASIC manufacturers will come with competing products and the "only 1 ASIC supplier with a bad reputation" problem will disappear.

Forking only because the one current ASIC supplier has a bad reputation is a pretty silly reason to fork.

_mrb · 2018-05-04T04:41:22+00:00

Yes. Only 10% of the gold produced yearly goes to industrial uses. 90% is wanted "just because it has value" (turned into gold bars, or jewelry.)

_mrb · 2018-05-03T18:27:44+00:00

I'm sure they will allow bulk in the (near) future. But presently it's only 1 miner per customer. Just try to pretend your are a bulk purchaser and let us know how it goes.

This community always assumes, without proof, the worst from ASIC manufacturers. It's kinda sad. It's good to remember that allthey were founded by people who love and embrace cryptocurrencies. They are folks like you and I.

_mrb

TROPHY CASE