Random thought: are there any techniques similar to carbon dating with a much shorter half life?

Like if I wantes to know how long ago an apple on the shelf in a store was picked and had access to whatever lab equipment I wanted, what would be the go-to technique for dating on the order of days to months?

Two board layouts. Three stencil layouts. Two stencil mounting styles. Five solder pastes. Multiple oven process parameters.

SMT process tuning, here we come!

Wishing again for an opamp with like a 60 GHz GBP lol.

Is there a technical reason why this isn't doable? All of the opamps and differential amplifiers I see look to be pretty low bandwidth by comparison, and I can find RF amplifiers with many dB of gain well into microwave frequencies but they're all single ended.

Why can't I get (inP - inN) * 30 dB as an off the shelf part?

Got my power bill and... ouch. $947.05 for 4.303 MWh at the meter (not counting the ~400 kWh of solar generation I wasn't billed for.

My rate is up 1% from last month and about 20% from this time last year. Despite having solar and my recent aggressive demand reduction measures, I'm still paying more than this time last year.

November 30 bill (due date) this year: $947.05 for 4303 net kWh, effective rate after taxes/fees $0.220/kWh

December 1 bill last year: $920.16 for 4896 net kWh, effective rate $0.188/kWh.

Throw in colder weather and there's a good chance I'll break the $1K barrier over the winter. Lovely.

If you rewrite an application in rust is that a form of carcinization?

Going from reversing a target made on TSMC 28HPL to Atmel 350nm back to back is quite the whiplash.

No HKMG with visibly distinct gate metal stacks so you have to infer transistor types from sizing again. Poly at all kinds of crazy angles, I've this cell library has transistors that look like a shepherd's crook and poly even used for local routing within a cell as a jumper when M1 is busy doing something else

I think it'll work!

So here's my bench setup. If i wanted to fit a micro hot air station here, where TF can it go?

The thorlabs curing controller can maybe get stacked on top of the soldering iron power stations to buy a bit of space but I'll need somewhere to store the hand piece and probably move the tip cleaner elsewhere

Ooh https://www.jbctools.com/jtse-power-hot-air-station-product-1261.html

This looks nice. Smaller than the aoyue and also has suction for placing parts, accessories look good too.

I really want a Hakko FR-850 micro hot air station (https://hakkousa.com/fr-850-micro-hot-air-station.html).

It looks like it would be so much better for really small under-microscope work than a normal full-sized hot air system, but unfortunately would not replace it, i.e. I'd still need to keep the full sized one around.

And there lies the problem: My bench is *very* full. I'm not sure how I could possibly fit another piece of equipment in the soldering arc around the microscope.

Hmmm. So it looks like the ngscopeclient FFT test fails on my work laptop (Intel CML GT2 on an i9-108985H) if I select the integrated GPU rather than the nvidia card.

Which is the same bug I've seen in the CI environment and had thought was a coffee lake quirk but now I'm seeing it on a second intel igpu. This might be a real issue.

Just upgraded the MacOS node on the ngscopeclient CI environment from UTM 4.x to UTM 5, which enables proper paravirtualized Vulkan in Linux guests and also adds long-overdue proper snapshotting rather than having to clone and delete VMs every time I wanted to set up an ephemeral runner.

Not much changed for the MacOS runner (other than faster provisioning time due to lack of a deep copy of the disk): this was always an apple PV GPU, finishing the 128K point FFT benchmark in the test cases in about 800 μs.

But the Debian aarch64 runner saw massive improvements, e.g. 2.2 ms to 870 us for the same benchmark.

Interestingly, the FFT test as a whole takes about 90 seconds to run on the aarch64 runner and the GPU upgrade doesn't seem to significantly impact this. I have no idea why... every other test takes <2 seconds, the CPU-side FFT takes about 1.2 ms for each of ten iterations, and the GPU-side takes ~800 μs.

Why only this test? Why only on aarch64? I don't know.

The other thing that I saw change, besides most tests seeing ~5x better performance from GPU offload rather than software emulation, is the eye pattern filter is no longer failing.

I never did root cause that issue; it seems to only affect aarch64 llvmpipe which is such a vanishingly small percentage of our userbase that I never spent time on it. It'll be easy to reconfigure the CI to keep that configuration alive if I want to, the Debian runner still has llvmpipe installed it just prefers to use virtio-venus if available.