If there’s anything more viscerally pleasing than seeing an eight-digit instrument showing a measurement with all zeroes after the decimal point, we’re not sure what it could. Maybe rolling the odometer over to another 100,000 milestone?
Regardless, getting to such a desirable degree of accuracy isn’t always easy, especially when the instrument in question is a handheld frequency counter that was built from a kit 23 years ago. That’s the target of [Petteri Aimonen]’s accuracy upgrade, specifically by the addition of a custom frequency reference module. The instrument is an ELV FC-500, which for such an old design looks surprisingly modern. Its Achille’s heel in terms of accuracy is the plain crystal oscillator it uses as a frequency standard, which has no temperature compensation and thus drifts by about 0.2 ppm per degree.
For a mains-powered lab instrument, the obvious solution would be an oven-controlled crystal oscillator. Those are prohibitive in terms of space and power for a handheld instrument, so instead a VCTCXO — voltage-controlled, temperature-compensated crystal oscillator — was selected for better stability. Unfortunately, no such oscillators matching the original 4.096-MHz crystal spec could be found; luckily, a 16.384-MHz unit was available for less than €20. All that was required was a couple of flip-flops to divide the signal by four and a bit of a bodge to replace the original frequency standard. A trimmer allows for the initial calibration — the “VC” part — and the tiny PCB tucks inside the case near the battery compartment.
We enjoyed the simplicity of this upgrade — almost as much as we enjoyed seeing all those zeroes. When you know, you know.
Digital modes are all the rage these days in amateur radio — hams are using protocols like WSPR to check propagation patterns, FT8 to get quick contacts on many bands with relatively low power, and MSK144 to quickly bounce a signal off of a meteor. There’s also digital voice, which has a number of perks over analog including improved audio quality. However, the major downside of most digital voice modes, at least those in use on UHF and VHF, is that they are proprietary with various radio brands having competing digital standards. To get above the noise a more open standard can be used instead.
The M17 standard, originally created by [Wojciech Kaczmarski] aka [SP5WWP], uses Codec 2 to convert voice into a digital format before it is broadcast over the air. Codec 2 is an open standard unlike other audio codecs. M17 also supports reflectors, which can link individual radios or entire repeaters together over the Internet. While you can make purpose-built modules that will interface with most standard radio inputs, it’s also possible to modify existing hardware to support this standard as well. The video below from [Tech Minds] shows this being done to a radio with only a few hardware modifications and the installation of a new firmware.
In our technologically complex world, standards are a double-edged sword. While they clearly make it possible for widgets and doodads to interoperate with each other, they also tend to drift away from their original intention over time, thanks to the march of progress or even market forces. If there’s one thing you can expect about standards, it’s that they beget other standards.
One standard that has stood the test of time, with modification of course, is the Musical Instrument Digital Interface, or MIDI. It’s hard to overstate the impact MIDI has had on the music world since it was first dreamed up in the early 1980s. Started amid a Wild West of competing proprietary synchronization standards, MIDI quickly became the de facto interface for connecting electronic musical instruments together. And as it did, it moved from strictly pro-grade equipment down the market to prosumer and home users, fueled in part by the PC revolution.
Click that speech bubble to the right, and you’ll be taken directly to the Hack Chat group on Hackaday.io. You don’t have to wait until Wednesday; join whenever you want and you can see what the community is talking about. Continue reading “MIDI All The Things Hack Chat”→
Given an unknown PCBA with an ARM processor, odds are good that it will have either the standard 10 pin 0.05″ or 20 pin 0.1″ debug connector. This uncommon commonality is a boon for an exploring hacker, but when designing a board such headers require board space in the design and more components to be installed to plug in. The literally-named Debug Edge standard is a new libre attempt to remedy this inconvenience.
The name “Debug Edge” says it all. It’s a debug, edge connector. A connector for the edge of a PCBA to break out debug signals. Card edge connectors are nothing new but they typically either slot one PCBA perpendicularly into another (as in a PCI card) or hold them in parallel (as in a mini PCIe card or an m.2 SSD). The DebugEdge connector is more like a PCBA butt splice.
It makes use of a specific family of AVX open ended card edge connectors designed to splice together long rectangular PCBAs used for lighting end to end. These are available in single quantities starting as low as $0.85 (part number for the design shown here is 009159010061916). The vision of the DebugEdge standard is that this connector is exposed along the edge of the target device, then “spliced” into the debug connector for target power and debug.
Right now the DebugEdge exists primarily as a standard, a set of KiCAD footprints, and prototype adapter boards on OSHPark (debugger side, target side). A device making use of it would integrate the target side and the developer would use the debugger side to connect. The standard specifies 4, 6, 8, and 10 pin varieties (mapping to sizes of available connector, the ‘010’ in the number above specifies pincount) offering increasing levels of connectivity up to a complete 1:1 mapping of the standard 10 pin ARM connector. Keep in mind the connectors are double sided, so the 4 pin version is a miniscule 4mm x 4.5mm! We’re excited to see that worm its way into a tiny project or two.
If you have an opinion about C++, chances are you either love it for its extensiveness and versatility, or you hate it for its bloated complexity and would rather stick to alternative languages on both sides of the spectrum. Either way, here’s your chance to form a new opinion about the language. The C++ standard committee has recently gathered to work on finalizing the language standard’s newest revision, C++20, deciding on all the new features that will come to C++’s next major release.
After C++17, this will be the sixth revision of the C++ standard, and the language has come a long way from its “being a superset of C” times. Frankly, when it comes to loving or hating the language, I haven’t fully made up my own mind about it yet. My biggest issue with it is that “programming in C++” can just mean so many different things nowadays, from a trivial “C with classes” style to writing code that will make Perl look like prose. C++ has become such a feature-rich and downright overwhelming language over all these years, and with all the additions coming with C++20, things won’t get easier. Although, they also won’t get harder. Well, at least not necessarily. I guess? Well, it’s complex, but that’s simply the nature of the language.
Anyway, the list of new features is long, combining all the specification proposals is even longer, and each and every one of these additions could fill its own, full-blown article. But to get a rough idea about what’s going to come to C++ next year, let’s have a condensed look at some of these major new features, changes, and additions that will await us in C++20. From better type checking and compiler errors messages to Python-like string handling and plans to replace the #include system, there’s a lot at play here!
Sure, we all love fixing stuff, but there’s often a fine line between something that’s worth repairing and something that’s cheaper in the long run to just replace. That line gets blurred, though, when there’s something to be learned from a repair.
This wonky temperature-compensated crystal oscillator is a good example of leaning toward repair just for the opportunity to peek inside. [Kerry Wong] identified it as the problem behind a programmable frequency counter reading significantly low. A TCXO is supposed to output a fixed frequency signal that stays stable over a range of temperatures by using a temperature sensor to adjust a voltage-controlled oscillator that corrects for the crystal’s natural tendency to vary its frequency as it gets hotter or colder. But this TCXO was pretty old, and even the trimmer capacitor provided was no longer enough to nudge it back in range. [Kerry] did some Dremel surgery on the case and came to the conclusion that adding another trim cap between one of the crystal’s leads and ground would help. This gave him a much wider adjustment range and let him zero in on the correct 10-MHz setting. [Mr. Murphy] still runs the show, though – after he got the TCXO buttoned up with the new trimmer inaccessible, he found that the frequency was not quite right. But going from 2 kHz off to only 2 Hz is still pretty good.
The NASA workmanship standards are absolutely beautiful. I mean that in the fullest extent of the word. If I had any say in the art that goes up in the Louvre, I’d put them up right beside Mona. They’re a model of what a standard should be. A clear instruction for construction, design, and inspection all at once. They’re written in clear language and contain all the vernacular one needs to interpret them. They’re unassuming. The illustrations are perfectly communicative. It’s a monument to the engineer’s art.
Around five years ago I had a problem to solve. Every time a device went into the field happily transmitting magic through its myriad connectors, it would inevitably come back red tagged, dusty, and sad. It needed to stop. I dutifully traced the problem to a connector, and I found the problem. A previous engineer had informed everyone that it was perfectly okay to solder a connector after crimping. This instruction was added because, previously, the crimps were performed with a regular pair of needle nose pliers and they came undone… a lot. Needless to say, the solder also interfered with their reliable operation, though less obviously. Stress failures and intermittent contact was common.