scottapotamas

Agreed. Tooling like this also needs far more careful structuring of the inputs than a thin wrapper like this.

It burnt a bunch of tokens and filled the context reading all datasheet files, whereas documentation should be queried to answer specific details connected to relevant netlist/sch nodes.

I'm your target market - averaging a few dozen board designs a year with complexity ranging from simple interposers to designs at density limits with large US+ FPGAs.

I'm always looking for workflow and automation improvements and the new wave of tooling has been useful for datasheet extraction/OCR, rubber-ducking calculations, or custom one-off scripts which interact with KiCAD's S-Expression file formats. However I've seen minimal improvements across my private suite of electronics reasoning/design tests since GPT4 so I'm very skeptical of review tooling actually achieving anything useful.

Testing with a prior version of a power board that had a few simple issues that were found and fixed during bringup. Uploaded the KiCAD netlist, PDFs for main IC's, and also included my internal design validation datasheet which _includes the answers to the problems I'm testing against_. There were three areas I'd expect easy identification and modelling on:

    - Resistor values for a non-inverting amplifier's gain were swapped leading to incorrect gain.
    - A voltage divider supplying a status/enable pin was drawing somewhat more current than it needed to.
    - The power rating of a current-sense shunt is marginal for some design conditions.

    - Just this single test consumed 100% of the chat's 330k token limit and 85% of free tier capacity, so I can't even re-evaluate the capability with a more reasonable/detailed prompt, or even giving it the solution.
    - A mid-step section calculates the UV/OV behaviour of a input protection device correctly, but mis-states the range in the summary.
    - There were several structural errors in the analysis, including assuming that the external power supply and lithium battery share the same input path, even though the netlist and components obviously have the battery 'inside' the power management circuit. As a result most downstream analysis is completely invalid.
    - The inline footnotes for datasheets output `4 [blocked]` which is a bare-minimum UI bug that you must have known about?
    - The problem and solution were in the context and weren't found/used.
    - Summary was sycophantic and incorrect.

In contrast, GPT5.1 API with a single relevant screenshot of the schematic, with zero developer prompt and the same starting user message:

    - Worked through each leg of the design and compared it's output to my annotated comments (and was correct).
    - Added commentary about possible leakage through a TVS diode, calculated time-constants, part tolerance, and pin loadings which are the kinds of details that can get missed outside of exhaustive review.
    - Hallucinated a capacitor that doesn't exist in the design, likely due to OCR error. Including the raw netlist and an unrelated in-context learning example in the dev-message resolved that issue.

    - Walk back your data collection terms, I don't feel they're viable for any commercial use in this space without changes.
    - An explicit listing of the downstream model provider(s) and any relevant terms that flow to my data.
    - I understand the technical side of "Some metadata or backup copies may persist for a limited period for security, audit, and operational continuity" but I want a specific timeline and what that metadata is. Do better and provide examples.
    - I'm not going to get into the strategy side of 'paying for tokens'. but your usage limits are too vague to know what I'm getting. If I'm paying for your value add, let me bring an API key (esp if you're not using frontier models).
    - My netlist includes PDF datasheet links for every part. You should be able to fetch datasheets as needed without upload.
    - Literally 5 minutes of thinking about how this tool is useful for fault-finding or review would have led you to a bare-minimum set of checklist items that I could choose to run on a design automatically.
    - Going further, a chat UX is horrible for this review use-case. Condensing it into a high level review of requirements and goals, with a list of review tasks per page/sub-circuit would make more sense. From there, then calculations and notes for each item can be grouped instead of spread randomly through the output summary. Output should be more like an annotated PDF.

Enjoyed the paper, thanks.

While there was brief discussion about environmental influence due to temperature and environmental EMI, it would be nice to get an idea of how this approach compares with regards to radiated emissions.

Fast edges and their wide spectral content are one of the earliest things to minimise/eliminate as part of compliance testing - other approaches aren't as active of an aggressor so getting to production may not be as easy given the stated goals for low cost/effort implementation.

The frequency domain data from the MXA shows the output during edge measurement, but there's no discussion about measuring how much these tones leak...

Mostly used for biological targets, laser induced ultrasound is pretty impressive.

For two DRP (dual role) devices connected to each other, I believe in a default case the one that happens to advertise as a source first just becomes one.

The standard allows for a role swap at any point while connected, and if that’s triggered will be dependent on the firmware/config on one or both ends.

There’s probably more nuance hiding in the real world hardware too.

There’s a lot more to it, but I attribute a lot of ‘better in some way’ to microcontrast followed by how the lens handles the transition to out of focus detail.

Yep, variations have popped up in the DIY community over the years.

Slightly modifying/abusing the cheap DLP resin printers is more effective because they're essentially a controllable UV mask anyway.

This is all fairly normal in robotics, under a subset of (slightly overloaded naming sorry) “impedance control”

You might enjoy https://github.com/scottbez1/smartknob

The complexity of this approach (ignoring the display and flair) unfortunately means you won’t see this used too often due to cost.

Their single board computers intended for robotics/edge have had a history of being poorly supported and stuck on old kernel versions.

It’s less torturous with other brands of 2D printer.

Both my Brother laser and label printer have worked first time, every time with Linux, Windows and iOS AirPrint.

Some people have different views on what’s an embedded system, but hardware serial, USB and Ethernet are tablestakes for interfacing with any most industrial hardware or for robotics uses.

For some/smaller parts. Once you start going higher than Artix or the token Kintex parts you need to pay up.

Have a look at this (and other repos/website) https://github.com/30hours/blah2

That sound has a name - sibilance

You just buy the microcontrollers and put them on your custom PCB.

The devkits aren’t suitable for resale but there’s no additional licence when you buy an ARM micro from pretty much any manufacturer.

Just tacking some detail onto "promote open science".

CERN was/is a large early user and supporter of the open source KiCAD electronics CAD tooling. The downstream impact of improved accessibility to solid ECAD tooling has been a large contributing factor to the growing ecosystem of open electronics.

A lot of really impressive test and measurement equipment to support their research is developed in the open (see https://ohwr.org/project). People on HN are probably most likely to have heard of the White Rabbit timing project, but there's fantastic voltmeter designs, a lot of FPGA projects for carriers, gateware, fun RF designs.

As CAD tools go SW is on the lower end of the scale. Though the price increases have been feeling pretty abusive in the recent years.

Creo has come down relative to it's ProE days and is priced similarly to SW(?), and I believe NX still starts at double to triple per seat.

ANSYS (specifically Fluent) and similar simulation tools have eyewatering per-seat prices, though I'm a little out of date to know if they're less horrible about multicore licences etc.

Also in the more recent ‘Light and Magic’ ILM doc series.

While it’s probably not perfect for everyone, I know hyprland exposes the events you’d need for this, accessible via IPC.

I’ve been bitten before but the risk/reward is probably worth it for parts like that.

Thanks for your write-ups btw, been following glScope development for a while.

That's low-end Zynq and Artix and I'm thinking more >676 Kintex, though I appreciate any discussion on sourcing.

In the way that that Aliexpress vendor lists the 7010 parts at 1/10th the price of LCSC, some of their $20-60 listings are also shockingly cheap in comparison.

Will do. Not too worried about trying low cost parts to gain some minimal confidence in a possible source, they're compelling for weekend side-projects at least.

I've previously struggled to roll the dice for higher end parts as the cost difference isn't as extreme and had some obvious reballed parts a few years ago. If they're OK then their $20 XC7K325T will be at the top of my list...

I was interested to see, or at least what state they're in so I grabbed a couple. Might try to compare them against some genuine ones with CT and destructive inspection.

On the chance they're half reasonable, thanks for the link.

Bigger number better, obviously!

I am also annoyed by most modern tech marketing using percentages incorrectly and inconsistently. But 150% is a bigger number than 1.5x so I suppose their hands are tied.

Great writeup. Always a treat to see more high quality FPGA project postmortems, even if they aren’t using accessible parts/toolchains.

I only dabble with recreationally reverse engineering industrial/consumer grade HW and following blogs/conferences, so I can only provide a rough shotgun of search terms to try and hit something you're interested in:

- The Glasgow interface explorer is an example of a smaller FPGA making interface level RE tooling more accessible.

- The Chipwhisperer hardware has a focus on power supply glitching, side-channel attacks and general hardware security education/testing.

- There's a handful of FPGA-based implementations intended for high-speed protocol sniffing/MiTM (TCP/IP, USB and CANBus are both pretty common) on github etc, Cynthion is one example.

- Some recent projects have been trying to implement and improve the FOSS ARM Cortex programming and trace experience, Orbuculum ORBTrace probe is an example though the benefits aren't fully realised yet.

- In an odd use-case for an FPGA, I've personally seen hardware that enforces brutal/paranoid DRM/licencing via customised downloaded bitstreams to guards against reverse-engineering/copy efforts, all to most likely run a soft-CPU. I've read (unsubstantiated) that this approach appears on some military hardware.

- Slightly adjacent to specific FPGA projects, but the SDR tooing ecosystem has lots of cool stuff to play with for wireless signal identification/spoofing/re-implementation. HackRF, LimeSDR, GNUradio etc. If you want to get deep then there's lots of overlap with custom FPGA implementations.

Reasonably experienced and 'a week' can mean vastly different things... It's certainly easier to keep the cost down with longer time-frames.

For a focus on electronics rather than implementing some kind of toy 'algorithm accelerator', I find low-hanging/interesting projects where the combination of requirements exceed a micro's peripheral capabilities - i.e. multiple input/output/processing tasks which could be performed on a micro individually, but adding synchronisation or latency requirements makes it rather non-trivial.

- Very wide/parallel input/output tasks: ADC/DACs for higher samplerate/bitdepth/channel count than typically accessible with even high-end micros

- Implementing unique/specialised protocols which would have required bit-banging, abuse of timer/other peripherals on a micro (i.e. interesting things people achieve with PIO blocks on RP2040 etc)

- Signal processing: digital filters and control systems are great because you can see/hear/interact with the output which can help build a sense of achievement.

When starting out, it's also less overwhelming to start with smaller parts and allocate the budget to the rest of the electronics. They're still incredibly capable and won't seem as under-utilised. Some random project ideas:

- Driving large frame-buffers to display(s) or large sets of LED matrices at high frame rate - https://gregdavill.com/posts/d20/

- Realtime audio filters - the Eurorack community might have some inspiration.

- Multi-channel synchonous detection, lock-in amplifiers, distributed timing reference/control,

- Find a sensing application that's interesting and then take it to the logical extreme - arrays of photo/hall-effect sensors sampled at high speed and displayed, accelerometers/IMU sensor fusion

- Laser galvanometers and piezo actuators are getting more accessible

- Small but precise/fast motion stages for positioning or sensing might present a good combination of input, output, filtering and control systems.

- With more time/experience you could branch into more interesting (IMO) areas like RF or imaging systems.

With more info about your interest areas I can give more specific suggestions.

As someone who works in embedded/digital design, I don't quite get this post. Can someone explain if I'm missing something obvious here?

- There's a huge range of great lab supplies between random $50 bulk regulator and a 10k supply from R&S/Keithley/Keysight which have OVP, OCP, SCPI, and other monitoring.

- The preface would probably be better posed if it were comparing a low/medium cost lab supply with load, against a higher end supply.

- There was no discussion on performance or capability of this approach, i.e. the load isn't going to be responsive enough to help reject any CM/DM noise, and would likely add some of it's own.

- If you really need to monitor the DUT, then the integrated monitoring in these kinds of supplies/loads are not going to be up to the task, and again, low-cost 'correct' tools will massively outperform this 'hack'.

- One feature that low-cost loads do hold over similarly priced lab PSU's is the ability to program relatively high speed transient tests, but this wasn't discussed. The obvious follow-on would then be trying to justify the lack of waveform control over using a cheap sig-gen.

- What class of security/reverse engineering tasks call for 4-quadrant SMU?

Also, if you're doing this for 'precision at low cost', shouldn't you be putting the sense leads on the DUT rather than the supply?

I nearly did, but the write-up was getting pretty long.

I'll try to find something for the planned range/interference tests. Morse Micro is also an Australian company so I'll probably look into their parts first unless there's any recommendation?