Troubleshooting a circuit is easy, right? All you need is a couple of hands to hold the probes, another hand to twiddle the knobs, a pair of eyes to look at the schematic, another pair to look at the circuit board, and, for fancy work, X-ray vision to see through the board so you know what pads to probe. It’s child’s play!
In the real world, most of us don’t have all the extra parts needed to do the job right, which is where something like CircuitScout would come in mighty handy. [Fangzheng Liu] and [Thomas Juldo]’s design is a little like a small pick-and-place machine, except that instead of placing components, the dual gantries place probes on whatever test points you need to look at. The stepper-controlled gantries move independently over a fixture to hold the PCB in a known position so that the servo-controlled Z-axes can drive the probes down to the right place on the board.
As cool as the hardware is, the real treat is the software. A web-based GUI parses the PCB’s KiCAD files, allowing you to pick a test point on the schematic and have the machine move a probe to the right spot on the board. The video below shows CircuitScout moving probes from a Saleae logic analyzer around, which lets you both control the test setup and see the results without ever looking away from the screen.
CircuitScout seems like a brilliant idea that has a lot of potential both for ad hoc troubleshooting and for more formal production testing. It’s just exactly what we’re looking for in an entry for the Gearing Up round of the 2023 Hackaday Prize.
There are all kinds of old wives’ tales surrounding proper battery use floating around in the popular culture. Things like needing to fully discharge a battery every so often, unplugging devices when they’re fully charged, or keeping batteries in the fridge are all examples that have some kernel of truth to them but often are improperly applied. If you really want to know the truth about a specific battery, its behavior, and its features, it helps to dig in and actually take some measurements directly like [Tyler] has done with a vast array of embedded batteries in IoT devices.
[Tyler] is a firmware engineer by trade, so he is deeply familiar with this type of small battery. Battery performance can change dramatically under all kinds of scenarios, most important among them being temperature. But even the same type of battery can behave differently to others that are otherwise identical, which is why it’s important to have metrics for the batteries themselves and be able to measure them to identify behaviors and possible problems. [Tyler] has a system of best practices in place for monitoring battery performance, especially after things like firmware upgrades since small software changes can often have a decent impact on battery performance.
While working with huge fleets of devices, [Tyler] outlines plenty of methods for working with batteries, deploying them, and making sure they’re working well for customers. A lot of it is extremely useful for other engineers looking to develop large-scale products like this but it’s also good knowledge to have for those of us rolling out our own one-off projects that will operate under battery power. After all, not caring for one’s lithium batteries can have disastrous consequences.
The concept of Continuous Integration (CI) is a powerful tool in software development, and it’s not every day we get a look at how someone integrated automated hardware testing into their system. [Michael Orenstein] brought to our attention the Hardware CI Arena, a framework for doing exactly that across a variety of host OSes and microcontroller architectures.
Here’s the reason it exists: while in theory every OS and piece of hardware implements things like USB communications and device discovery in the same way, in practice that is not always the case. For individual projects, the edge cases (or even occasional bugs) are not much of a problem. But when one is developing a software product that aims to work seamlessly across different hardware options, such things get in the way. To provide a reliable experience, one must find and address edge cases.
The Hardware CI Arena (GitHub repository) was created to allow automated testing to be done across a variety of common OS and hardware configurations. It does this by allowing software-controlled interactions to a bank of actual, physical hardware options. It’s purpose-built for a specific need, but the level of detail and frank discussion of the issues involved is an interesting look at what it took to get this kind of thing up and running.
The value of automatic hardware testing with custom rigs is familiar ground to anyone who develops hardware, but tying that idea into a testing and CI framework for a software product expands the idea in a useful way. When it comes to identifying problems, earlier is always better.
When USB first came on the scene, one of the benefits was that essentially any four conductors could get you to the point where you could send information at 12 Mbps. Of course everything is faster these days, and reaching today’s speeds requires a little bit more fidelity in the cables. This simple tester makes sure that your modern cables are actually up to the task.
One of the design goals of this project is to automate away the task of testing cables or finding one that works, especially before thinking a problem with a device is somewhere in software, spending hours or days debugging, before realizing that it’s actually being caused by a hardware malfunction. The small PCB has two USB-C fittings to plug in both of the ends of a cable to, and between those connectors there is a number of LEDs. Each LED is paired to one the many conductors within the USB cable, and not only does it show continuity of these conductors but it can also show a high resistance connection via a dimly-lit or off-color display from an LED.
One of the other interesting facets of this build is the use of JITX, which is a software-defined electronics CAD tool which allows PCB design to be automated by writing out the requirements of the PCB into code, rather than drawing it manually. It’s worth a look, and a lot of the schematics of this particular project as well as some discussion on this software can be found on the project’s GitHub page. Incidentally, if this tester looks familiar, it’s probably because your’re thinking of the open source hardware USB tester created by [Álvaro Prieto].
Multimeters are indispensable tools when working on electronics. It’s almost impossible to build any but the most basic of circuits without one to test and troubleshoot potential issues, and they make possible a large array of measurement capabilities that are not easily performed otherwise. But when things start getting a little more complex it’s important to know their limitations, specifically around what they will tell you about circuits designed for high frequency. [watersstanton] explains in this video while troubleshooting an antenna circuit for ham radio.
The issue that often confuses people new to radio or other high-frequency projects revolves around the continuity testing function found on most multimeters. While useful for testing wiring and making sure connections are solid, they typically only test using DC. When applying AC to the same circuits, inductors start to offer higher impedance and capacitors lower impedance, up to the point that they become open and short circuits respectively. The same happens to transformers, but can also most antennas which often look like short circuits to ground at DC but can offer just enough impedance at their designed frequency to efficiently resonate and send out radio waves.
This can give some confusing readings, such as when testing to make sure that a RF connector isn’t shorted out after soldering it to a coaxial cable for example. If an antenna is connected to the other side, it’s possible a meter will show a short at DC which might indicate a flaw in the soldering of the connector if the user isn’t mindful of this high-frequency impedance. We actually featured a unique antenna design recently that’s built entirely on a PCB that would show this DC short but behaves surprisingly well when sending out WiFi signals.
For some problems the Goldilocks approach is the way to go. [Tommy] designed a small array of different LED cover options, and tested each to see what yielded the best results for his printed kit. Some of the biggest takeaways include:
100% infill is best for even results (although interesting shadows happen at less than 100% infill.)
Interesting things happen with 7 to 11 mm of top layers of clear PLA, when illuminated from below with a 5 mm high-brightness LED. An even diffusion of light starts to give way to a circular gradient as the upper layer gets thicker.
LEDs emit their light mainly upward in a round pattern. Corners will always be darker, even more so if the guide is not round. This effect becomes noticeably more pronounced as the light guide grows in size, putting a practical upper limit on its effective dimensions.
Of course, the usual ways to deal with an overly-bright LED are to limit its current or control its brightness by driving it with a PWM signal. The right approach depends on the application and the scale of the design, and there are actually quite a few ways to crack this nut. Luckily, our own [Inderpreet Singh] is here to tell you all about how best to control LED brightness.
One of the core features of the scientific community is the concept of “peer review” where any claims made by a scientist are open to be analyzed and reproduced by others in the community for independent verification. This leads to either rejection of ideas which can’t be reproduced, or strengthening of those ideas when they are. In this community we typically only feature the first step of this process, the original projects from various builders, but we don’t often see someone taking those instructions and “peer reviewing” someone’s build. This is one of those rare cases.
[oxullo] came across [Leo]’s original build for the ultimate continuity tester. This design is much more sensitive than the function which is built in to most multi-meters, and when building this tool specifically some other refinements can be built in as well. [oxullo] began by starting with the original designs, but made several small modifications. Most of these were changing to surface-mount parts, and switching some components for ones already available. Even then, there was still a mistake in the PCB which was eventually corrected. The case for this build is also 3D printed instead of being made out of metal, and with the original video to work from the rest fell into place easily.
[oxullo] is getting comparable results with this continuity tester, so we can officially say that this design is peer reviewed and tested to the highest of standards. If you’re in need of a more sensitive continuity sensor, or just don’t want to shell out for a Fluke meter when you don’t need the rest of its capabilities, this is the way to go. And don’t forget to check out our original write-up for this tester if you missed it the first time around.