Signals and systems theory is a tough topic. Terms like convolution and impulse response can be hard to understand on a visceral level and most books that talk about these things emphasize math over intuition. [Discretised] has a YouTube channel that already has several videos that promise to tackle these topics with “minimum maths, maximum intuition.” We particularly noticed the talks on convolution and impulse response.
We think that often math and intuition don’t always come together. It is one thing, for example, to know that E=I times R, and power is I times E, but it is another to realize that a half-watt transmitter delivers 5V into a 50Ω load and that one watt will take just over 7V into that same load.
The example used is computing how much smoke you can expect to create by setting off fireworks. We presume the math models are notional since we imagine a real model would be pretty complex and involve things like wind data. But it still makes a nice example.
If you don’t know anything about the topic, these might not be the right ones to try to learn the basics. But we do applaud people sharing their intuition on these complex subjects.
Once you graduate beyond development boards like the Arduino or Wemos D1, you’ll find yourself in the market for a dedicated programmer. In most cases, your needs can be met with a cheap USB to serial adapter that’s not much bigger than a flash drive. The only downside is that you’ve got to manually wire it up to your microcontroller of choice.
Unless you’re [Roey Benamotz], that is. He’s recently created the LEan Mean Programming mAchine (LEMPA), an add-on board for the Raspberry Pi that includes all the sockets, jumpers, and indicator LEDs you need to successfully flash a whole suite of popular MCUs. What’s more, he’s written a Python tool that handles all the nuances of getting the firmware written out.
After you’ve configured the JSON file with the information about your hardware targets and firmware files, they can easily be called up again by providing a user-defined ID name. This might seem overkill if you’re just burning the occasional hex, but if you’re doing small scale production and need to flash dozens of chips, you’ll quickly appreciate a little automation in your process.
Measuring the performance of antennas in absolute terms that can involve a lot of expensive equipment and specialized facilities. For practical applications, especially when building antennas, comparing performance in relative terms is more practical. Using cheap RTL-SDR dongles and Python, [Eric Urban] was able to compare the performance of two shortwave/HF antennas, and documented the entire process.
The two antennas in question was a single band inverted-L and smaller broadband T3FD antenna. [Eric] first gathered performance data for each over few days, connected to separate PCs with RTL-SDRs via low-pass filters. These were set up to receive FT8 transmissions, a popular digital ham radio mode, which allowed [Eric] to automate data collection completely. GQRX, a software receiver, converted the signals to audio, which was then piped into WSJT-X for demodulation.
Data for each received FT8 transmission was recorded to a log file. [Eric] also modified GQRX and WSJT-X to give him all the remote control features he needed to automatically change frequencies. Between the two antenna setups, more than 100,000 FT8 transmissions were logged. Using the recorded data and Python he compared the number of received transmissions, the distance, and the heading to the transmitters, using the location information included in many FT8 transmissions. Where the same transmission was received by both antennas, the signal-to-noise ratios was compared.
From all this data, [Eric] was able to learn that the inverted-L antenna performed better than the T3FD antenna on three of the four frequency bands that were tested. He also discovered that the inverted-L appeared to be “deaf” in one particular direction. Although the tests weren’t perfect, it is impressive how much practical data [Eric] was able to gather with low-cost hardware. Continue reading “Comparing Shortwave Antennas With RTL-SDR And Python”→
“Keep it simple” sounds like such good advice, but what exactly is the “it”; what parts of a project should you try to keep simple? You can’t always make everything simple, can you? Are all kinds of “simplicity” equally valuable, or are there aspects of a design where simplicity has multiplier effects on the rest of the project?
I ran into two seemingly different, but surprisingly similar, design problems in the last couple weeks, and I realized that focusing on keeping one aspect of the project simple had a multiplier effect on the rest — simplifying the right part of the problem made everything drastically easier.
The first example was a scratch-built airplane design. I’d made a few planes over the summer, focusing on plans on the Interwebs that emphasize simplicity of the actual build. Consequently, the planes were a bit heavy, maybe not entirely aerodynamic, and probably underpowered. And this is because the effort you expend building the plane doesn’t fundamentally have anything to do with flight. Keeping the build simple doesn’t necessarily get you a good plane.
Weight, on the other hand, is central. Wings produce lift, whether measured in grams or ounces, and anything heavier just isn’t gonna fly. But reducing weight has a multiplier effect. Less weight means smaller and lighter motors and batteries. Structures don’t need to be as stiff if they’re not subject to heavier bending forces. And, important to the noob pilot, planes with less weight per wing area fly slower, giving me (ahem, the noob pilot) more reaction time when something goes sideways. Trying to simplify the design by trimming weight has knock-on effects all around.
My latest fully-DIY design threw out anything that brought weight along with it, including some parts I thought were necessary for stiffness or crash resistance. But with the significantly lowered weight, these problems evaporated without needing me to solve them — in a way, the complexity of design was creating the problems that the complexity of design was supposed to solve. Ditching it meant that I had a slow plane, with simple-to-build wings, that’s capable of carrying a lightweight FPV camera. Done and done! Simply.
Nope. Too complex.
At the same time, I’m building a four-axis CNC foam cutter. I’ve built many 3D printers, and played around with other folks’ DIY CNC machines, so I had a few design ideas in my head starting out. My first iteration of an XY axis for the machine runs on metal angle stock with a whopping eight skate bearings per axis. It’s strong and rigid, and clumsy and overkill, in a bad way for this machine.
3D printers want to move a relatively light tool head around a small volume, but relatively quickly. CNC mills need to be extremely rigid and shoulder heavy side loads, subject to some speed constraints. A foam cutter has none of these needs. The hot wire melts the foam by radiation, so there are no loads on the machine because it doesn’t even contact the workpiece. And because it cuts by melting, it has to go slow. These are the places in the design where simplification will bear the most fruit.
I write this in retrospect, or at least from the perspective of a second prototype. I wanted the first design to hold the cutting filament taut, hence the rigid frame. But separating the tension from the motion, by using a lightweight external bow to keep the filament tight, meant that the machine could be dead simple. I could use smaller plastic sliders instead of complex bearings, on thin rods instead of bulky rails. In a day after having this realization, I got twice as far as I had on the previous machine design in a week, and it takes up a lot less space in my basement.
So take your KISS to the next level. Brainstorm a while about the binding constraints on your design, and what relaxing any of them can do. Do any particular simplifications enable further simplifications? Those are the ones that you want to start with. Keep it simple, smartly. And because it’s not always easy to find these multiplier effects, tell your friends!
This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter.
Want this type of article to hit your inbox every Friday morning? You should sign up!
If you’re developing a performant IP-KVM based on the Raspberry Pi, an HDMI capture device that plugs into the board’s CSI port would certainly be pretty high on your list of dream peripherals. Turns out such devices actually exist, and somewhat surprisingly, are being sold for reasonable prices. Unfortunately the documentation for the chipset they use is a bit lacking, which is a problem if you’re trying to wring as much performance out of them as possible.
As the creator of Pi-KVM, [Maxim Devaev] needed to truly understand how the Toshiba TC358743 chip used in these capture devices worked, so he decided to build his own version from scratch. In the name of expediency, he didn’t have a proper breakout board made and instead decided to hand-solder the tiny BGA chip directly to some parts bin finds. The resulting perfboard capture device is equal parts art and madness, but more importantly, actually works as expected even with 1080p video signals.
Ultimately, the lessons learned during this experiment will lead to a dedicated KVM board that will plug into the Pi’s expansion header and provide all the necessary hardware in one shot. As [Maxim] explains in the Pi-KVM docs, the move to the CSI connected Toshiba TC358743 cuts latency in half compared to using a USB capture device. That said, USB capture devices will remain fully supported for anyone who just needs a quick way to get things working.
This DIY capture card is a perfect example of how the skills demonstrated while working on a project can be just as impressive as the end result. [Maxim] didn’t set out to hand-solder a BGA HDMI capture chip, it was merely one step in the process towards creating something better. Those intermediary achievements are often lost in the rush to document the final project, so we’re always glad when folks take the time to share them.
There are many different single board computers that are general purpose, but there’s another breed targeted at specific applications. One such is the Clockworkpi, a handheld Game Boy-style games console, which may be aimed at gamers but has just as much ability to do all the usual SBC stuff. It’s something [UncannyFlanigan] has demonstrated, by turning the Clockworkpi into a multimeter. And it’s not just a simple digital multimeter either, it’s one that sports graphing as well as instantaneous readings.
At its heart is an Arduino board that supplies the analogue to digital conversion, with opto-couplers for isolation between the two boards. A simple three-way switch selects voltage, current, and resistance ranges, and the ClockworkPi interface is written in Python. We can see that this could easily be extended using the power of the Arduino to deliver more functionality, for which all the code is handily available in a GitHub repository. It’s not a perfect multimeter yet because it lacks adequate input protection, but it shows a lot of promise.
Computer hardware is by and large compromised out of the box. Whether it’s sloppy factory code, or government-installed backdoors, it’s difficult to trust anything. A great example is that of color laser printers, the vast majority of which place hidden watermarks on printed pages. It’s a somewhat forgotten issue these days, but back in 2005, [bunnie] set out to modify a scanner to help better image and investigate these watermarks.
The watermarks in question have been investigated by the EFF, and often, but not always, consist of tiny yellow dots printed on the page. They can store data such as the name of the computer that printed the document, as well as the serial number and model of the printer used. With this functionality baked into the firmware, all prints made on such a printer are compromised.
The easiest way to see these watermarks is with blue light, which is reflected by the white paper, but causes yellow dots to show up as dark spots. To make scanning affected documents quick and easy, [bunnie] whipped up a linear LED light array, installing it in a spare slot in his scanner’s light assembly, next to the stock white CCFL. Usage is a little more complex, with the scanner’s automatic calibration getting confused if the blue LEDs are left on at the start of a scan. Instead, the LEDs must be turned off initially, and then powered up once the calibration is complete.
