How hard is it to create a synthesizer to generate frequencies between 35 MHz to 4.4 GHz? [OpenTechLab] noticed a rash of boards based on the ADF4351 that could do just that priced at under $30. He decided to get one and try it out and you can find his video results below.
At that price point, he didn’t expect much from it, but he did want to experiment with it to see if he could use it as an inexpensive piece of test gear. The video is quite comprehensive (and weighs in at nearly an hour and a half). It covers not just the device from a software and output perspective but also talks about the theory behind these devices. [OpenTechLab] even sniffed the USB connection to find the protocol used to talk to the device. He wasn’t overly impressed with the performance of the board but was happy enough with the results at the price and he plans to make some projects with it.
Continue reading “4.4 GHz Frequency Synthesis Made Easy”
There is one man whose hour-long sessions in my company give me days of stress and worry. He can be found in a soundless and windowless room deep in the bowels of an anonymous building in a town on the outskirts of London. You’ve probably driven past it or others like it worldwide, without being aware of the sinister instruments that lie within.
The man in question is sometimes there to please the demands of the State, but there’s nothing too scary about him. Instead he’s an engineer and expert in electromagnetic compatibility, and the windowless room is a metal-walled and RF-proof EMC lab lined with ferrite tiles and conductive foam spikes. I’m there with the friend on whose work I lend a hand from time to time, and we’re about to discover whether all our efforts have been in vain as the piece of equipment over which we’ve toiled faces a battery of RF-related tests. As before when I’ve described working on products of this nature the specifics are subject to NDAs and in this case there is a strict no-cameras policy at the EMC lab, so yet again my apologies as any pictures and specifics will be generic.
There are two broadly different sets of tests which our equipment will face: RF radiation, and RF injection. In simple terms: what RF does it emit, and what happens when you push RF into it through its connectors and cables? We’ll look at each in turn as a broad overview pitched at those who’ve never seen inside an EMC lab, sadly there simply isn’t enough space in a Hackaday article to cover every nuance.
Continue reading “An Overview Of The Dreaded EMC Tests”
We don’t think [VK4FFAB] did himself a favor by calling his seven-part LTSpice tutorial LTSpice for Radio Amateurs. Sure, the posts do focus on radio frequency analysis, but these days lots of people are involved in radio work that aren’t necessarily hams.
Either way, if you are interested in simulating RF amplifiers and filters, you ought to check these posts out. Of course, the first few cover simple things like voltage dividers just to get your feet wet. The final part even covers a double-balanced mixer with some transformers, so there’s quite a range of material.
Continue reading “LTSpice for Radio Amateurs (and Others)”
In a previous episode of Hackaday, [Rich Olson] came up with a new no-etch circuit board fabrication method. And now, he’s put it to the test: building an nRF52 Bluetooth reference design, complete with video, embedded below.
The quick overview of [Rich]’s method: print out the circuit with a laser printer, bake a silver-containing glue onto the surface, repeat a few times to get thick traces, glue the paper to a substrate, and use low-temperature solder to put parts together. A potential drawback is the non-negligible resistance for the traces, but a lot of the time that doesn’t matter and the nRF52 reference design proves it.
The one problem here may be the trace antenna. [Rich] reports that it sends out a weaker-than-expected signal. Any RF design folks want to speculate wildly about the cause?
Continue reading “No-Etch: The Proof in the Bluetooth Pudding”
Far too much stuff is wireless these days. Home security systems have dozens of radios for door and window sensors, thermostats aren’t just a wire to the furnace anymore, and we are annoyed when we can’t start our cars from across a parking lot. This is a golden era for anyone who wants to hack RF. This year at Shmoocon, [Marc Newlin] and [Matt Knight] of Bastille Networks gave an overview of how to get into hacking RF. These are guys who know a few things about hacking RF; [Marc] is responsible for MouseJack and KeySniffer, and [Matt] reverse engineered the LoRa PHY.
In their talk, [Marc] and [Matt] outlined five steps to reverse engineering any RF signal. First, characterize the channel. Determine the modulation. Determine the symbol rate. Synchronize a receiver against the data. Finally, extract the symbols, or get the ones and zeros out of the analog soup.
From [Marc] and [Matt]’s experience, most of this process doesn’t require a radio, software or otherwise. Open source intelligence or information from regulatory databases can be a treasure trove of information regarding the operating frequency of the device, the modulation, and even the bit rate. The pertinent example from the talk was the FCC ID for a Z-wave module. A simple search revealed the frequency of the device. Since the stated symbol rate was twice the stated data rate, the device obviously used Manchester encoding. These sorts of insights become obvious once you know what you’re looking for.
In their demo, [Marc] and [Matt] went through the entire process of firing up GNU Radio, running a Z-wave decoder and receiving Z-wave frames. All of this was done with a minimum of hardware and required zero understanding of what radio actually is, imaginary numbers, or anything else a ham license will hopefully teach you. It’s a great introduction to RF hacking, and shows anyone how to do it.
We’ve learned a lot by watching the talks from the Hackaday Superconferences. Still, it’s a rare occurrence to learn something totally new. Microwave engineer, professor, and mad hacker [Toshiro Kodera] gave a talk on some current research that he’s doing: replacing natural magnetic gyrotropic material with engineered metamaterials in order to make two-way beam steering antennas and more.
If you already fully understood that last sentence, you may not learn as much from [Toshiro]’s talk as we did. If you’re at all interested in strange radio-frequency phenomena, neat material properties, or are just curious, don your physics wizard’s hat and watch his presentation. Just below the video, we’ll attempt to give you the Cliff’s Notes.
Continue reading “Toshiro Kodera: Electromagnetic Gyrotropes”
When you have a large software development team working on a project, monitoring the build server is an important part of the process. When a message comes in from your build servers, you need to take time away from what you’re doing to make sure the build’s not broken and, if it’s broken because of something you did, you have to stop what you’re doing, start fixing it and let people know that you’re on it.
[ridingintraffic]’s team uses Jenkins to automatically build their project and if there’s a problem, it sends a message to a Slack channel. This means the team needs to be monitoring the Slack channel, which can lead to some delays. [ridingintraffic] wanted immediate knowledge of a build problem, so with some software, IoT hardware, and a rotating hazard warning light, the team now gets a visible message that there’s a build problem.
An Adafruit Huzzah ESP8266 board is used as the controller, connected to some RF controlled power outlets via a 434MHz radio module. To prototype the system, [ridingintraffic] used an Arduino hooked up to one of the RF modules to sniff out the codes for turning the power outlets on and off from their remotes. With the codes in hand, work on the Huzzah board began.
An MQTT broker is used to let the Huzzah know when there’s been a build failure. If there is, the Huzzah turns the light beacon on via the power outlets. A bot running on the Slack channel listens for a message from one of the developers saying that problem is being worked on, and when it gets it, it sends the MQTT broker a message to turn the beacon off.
There’s also some separation between the internal network, the Huzzahs, and the Slack server on the internet, and [ridingintraffic] goes over the methods used to communicate between the layers in a more detailed blog post. Now, the developers in [ridingintraffic]’s office don’t need to be glued to the Slack channel, they will not miss the beacon when it signals to start panicking!