A common joke in electronics is that every piece of wire and PCB trace is an antenna, with the only difference being whether this was intentional or not. In practical terms, low-frequency wiring is generally considered to be ‘safe’, while higher frequency circuits require special considerations, including impedance (Z) matching. Where the cut-off is between these two types of circuits is not entirely clear, however, with various rules-of-thumb in existence, as [Sebastian] over at Baltic Lab explains.
A popular rule is that no impedance matching between the trace and load is necessary if the critical length of a PCB trace (lcrit) is 1/10th of the wavelength (λ). Yet is this rule of thumb correct? Running through a number of calculations it’s obvious that the only case where the length of the PCB trace doesn’t matter is when trace and load impedance are matched.
According to these calculations, the 1/10 rule is not a great pick if your target is a mismatch loss of less than 0.1 dB, with 1/16 being a better rule. Making traces wider on the PCB can be advisable here, but ultimately you have to know what is best for your design, as each project has its own requirements. Even when the calculations look good, that’s no excuse to skip the measurement on the physical board, especially with how variable the dielectric constant of FR4 PCB material can be between different manufacturers and batches.
Heading image: Input impedance plotted as a function of trace impedance for trace lengths of 1/10, 1/16, and 1/20 of a wavelength. (Credit: Baltic Labs)
Though Hackaday scribes have been known to imbibe a few glasses in their time, it’s fair to say that we are not a wine critic site. When a news piece floated by about a company getting into trouble for illegally submerging crates of wine though, our ears pricked up. Why are vintners dumping their products in the sea?
Making wine, or indeed any alcoholic beverage, starts with taking a base liquor, be it grape juice, apple juice, barley malt solution, or whatever, and fermenting it with a yeast culture to produce alcohol. The result is a drink that’s intoxicating but rough, and the magic that turns it into a connoisseur’s tipple happens subsequently as it matures. The environment in which the maturation happens has a huge influence on this, which is one of many reasons why wine from the cellar of a medieval chateau tastes better than that from an industrial unit in southern England. The Californian company was attempting to speed up this process by leaving the bottles beneath the waves. Continue reading “The Briny Depths Give Wine An Edge, But How?”→
We mentioned last week how robotaxi provider Cruise was having a no-good, very bad week, after one of their driverless taxis picked a fight with a semi, and it was revealed that amorous San Franciscans were taking advantage of the privacy afforded by not having a driver in the front seat. It appears that we weren’t the only ones to notice all the bad news, since California’s Department of Motor Vehicles issued an order to the company to cut its robotaxi fleet in half. The regulatory move comes after a recent Cruise collision with a fire truck, which injured a passenger in the taxi. Curiously, the DMV order stipulates that Cruise can only operate 50 vehicles during the day, while allowing 150 vehicles at night. We’d have thought the opposite would make more sense, since driving at night is generally more difficult than during daylight hours. But perhaps the logic is that the streets are less crowded at night, whereas daytime is a more target-rich environment.
Of all the electrical signals generated by the human body, those coming from the heart are probably the most familiar to the average person. And because it’s also quite simple to implement the required sensors, it makes sense that electrocardiogram (ECG) machines are a popular choice among introductory medical electronics projects. [Dániel Buga], for instance, designed a compact ECG system the size of a credit card, cleverly dubbed Card/IO, that clearly demonstrates how to implement a single-lead ECG.
Although obviously not a medical-grade instrument, it still contains all the basic components that make up a proper biosignal sensing system. First, there are the sensing pads, which sense the voltage difference between the user’s two thumbs and simultaneously cancel their common-mode voltage with a technique called Right Leg Driving (RLD). The differential signal then goes through a low-pass filter to remove high-frequency noise, after which it enters an ADS1291 ECG analog front-end chip.
The ADS1291 contains a delta-sigma analog-to-digital converter as well as an SPI bus to communicate with the main processor. [Dániel] chose an ESP32-S3, programmed in Rust, to interface with the SPI bus and drive a 1″ OLED display that shows the digitized ECG signal. It also runs the user interface, which is operated using the ECG sensing pads: if you touch them for less than five seconds, the device goes into menu mode and the two pads become buttons to scroll through the different options.
All source code, as well as KiCad files for the board, can be found on the project’s GitHub page. If you’re just getting started in the biosensing field, you might also want check out this slightly more advanced project that includes lots of relevant safety information.
It used to be that memory and storage space were so precious and so limited of a resource that handling nontrivial amounts of text was a serious problem. Text compression was a highly practical application of computing power.
Today it might be a solved problem, but that doesn’t mean it doesn’t attract new or unusual solutions. [Fabrice Bellard] released ts_zip which uses Large Language Models (LLM) to attain text compression ratios higher than any other tool can offer.
LLMs are the technology behind natural language AIs, and applying them in this way seems effective. The tradeoff? Unlike typical compression tools, the lossless decompression part isn’t exactly guaranteed when an LLM is involved. Lossy compression methods are in fact quite useful. JPEG compression, for example, is a good example of discarding data that isn’t readily perceived by humans to make a smaller file, but that isn’t usually applied to text. If you absolutely require lossless compression, [Fabrice] has that covered with NNCP, a neural-network powered lossless data compressor.
Do neural networks and LLMs sound far too serious and complicated for your text compression needs? As long as you don’t mind a mild amount of definitely noticeable data loss, check out [Greg Kennedy]’s Lossy Text Compression which simply, brilliantly, and amusingly uses a thesaurus instead of some fancy algorithms. Yep, it just swaps longer words for shorter ones. Perhaps not the best solution for every need, but between that and [Fabrice]’s brilliant work we’re confident there’s something for everyone who craves some novelty with their text compression.
Sometimes you find something that looks really cool but doesn’t work, but that’s an opportunity to give it a new life. That was the case when [Davis DeWitt] got his hands on a weird Soviet-era box with four original Nixie tubes inside. He tears the unit down, shows off the engineering that went into it and explains what it took to give the unit a new life as a clock.
A lot can happen over decades of neglect. That was clear when [Davis] discovered every single bolt had seized in place and had to be carefully drilled out. But Nixie tubes don’t really go bad, so he was hopeful that the process would pay off.
The unit is a modular display of some kind, clearly meant to plug into a larger assembly. Inside the unit, each digit is housed in its own modular plug with a single Nixie tube at the front, a small neon bulb for a decimal point, and a bunch of internal electronics. Bringing up the rear is a card edge connector.
To try out a filter, you just need to select one from the window on the left and it will pop up in the central workspace. Here, the input, output, and any enabled filters will show up as boxes that can be virtually “wired” together. Selecting a filter will populate its options on the right hand side, with sliders and input boxes that allow you to play around with their parameters. When you want to see the final result, just click “Render Preview” and wait a bit.
If there was any downside, it seems like whatever box the site is running on the overhead of running in the browser doesn’t provide it a lot of horsepower. Even with the relatively low resolution of the demo videos available, the console output at the top of the page shows FFmpeg sometimes flirts with a processing speed measured in single-digit frames per second. Still, for a filter playground, it gets the job done. Perhaps the best part of the whole tool is that you can then copy your properly formatted command right out of the browser window and into your terminal so you can put it to work on your local files.