SDR and Node.js Remote-Controlled Monster Drift

Most old-school remote controlled cars broadcast their controls on 27 MHz. Some software-defined radio (SDR) units will go that low. The rest, as we hardware folks like to say, is a simple matter of coding.

So kudos to [watson] for actually doing the coding. His monster drift project starts with the basics — sine and cosine waves of the right frequency — and combines them in just the right durations to spit out to an SDR, in this case a HackRF. Watch the smile on his face as he hits the enter key and the car pulls off an epic office-table 180 (video embedded below).

Continue reading “SDR and Node.js Remote-Controlled Monster Drift”

Raspberry Pi SDR

[Chris D] noticed that the excellent software defined radio (SDR) software gqrx will run on the Raspberry Pi now. So he married a Raspberry Pi 3, a touchscreen, an RTL-SDR dongle, and an upconverter to make a very nice receiver setup. You can see the receiver in action below.

The video is a little light on build details, but there is a shot of the setup with the pieces labeled, and you should be able to figure it out from there. Of course, gqrx works with lots of different SDR devices so you might have to make adjustments depending on what you use (for example, many of the supported dongles won’t need the upconverter that [Chris] uses).

Continue reading “Raspberry Pi SDR”

Ice, Ice, Radio Uses FPGA

Building a software defined radio (SDR) involves many trades offs. But one of the most fundamental is should you use an FPGA or a CPU to do the processing. Of course, if you are piping data to a PC, the answer is probably a CPU. But if you are doing the whole system, it is a vexing choice. The FPGA can handle lots of data all at one time but is somewhat more difficult to develop and modify. CPUs using software are flexible–especially for coding user interfaces, networking connections, and the like) but don’t always have enough horsepower to cope with signal processing tasks (and, yes, it depends on the CPU).

[Eric Brombaugh] sidestepped that trade off. He used a board with both an ARM processor and an ICE FPGA at the heart of his SDR design. He uses three custom boards: one is the CPU/FPGA board, another is a 10-bit converter that can sample at 40 MSPS (sufficient to decode to 20 MHz), and an I2S DAC to produce audio. Each board has its own page linked from the main project.

Continue reading “Ice, Ice, Radio Uses FPGA”

Cache Shortwave Signals for Later with this SDR Spectrum Grabber

Shortwave listening has always been a mainly nocturnal hobby. To get the real DX, one had to wait for favorable ionospheric conditions after sunset and spend hours twisting knobs while straining to pick voices from half a planet away out of the noise. But who has time for that in today’s world? And what of the poor city-dwelling SWL, with antenna limitations and often elevated noise floor in the urban jungle?
Continue reading “Cache Shortwave Signals for Later with this SDR Spectrum Grabber”

Building A LoRa PHY With SDR

The Internet of Things is terrible when it’s your toaster. The real fun happens when you have hundreds or thousands of sensors sending data back to a base station every day. That requires low power, and that means LPWAN, the Low Power Wide Area Network.

There are a lot of options for LPWAN, but few are a perfect fit. LoRa is one of the rare exceptions, offering years of operation on a single AA cell, and range measured in miles. Layers two and three of LoRa are available as public documentation, but until now layer one has been patented and proprietary. At the GNU Radio Conference, [Matt Knight] gave a talk on reverse engineering the LoRa PHY with a software defined radio. Now, LoRa is open to everyone, and anyone can decode the chirps transmitted from these tiny, low power devices.

Continue reading “Building A LoRa PHY With SDR”

Transmitting Analog TV, Digitally

If you want to really understand a technology, and if you’re like us, you’ll need to re-build it yourself. It’s one thing to say that you understand (analog) broadcast TV by reading up on Wikipedia, or even by looking at scope traces. But when you’ve written a flow graph that successfully transmits a test image to a normal TV using just a software-defined radio, you can pretty easily say that you’ve mastered the topic.

9944491474271463115_thumbnail[Marble] wrote his flow for PAL, but it should be fairly easy to modify it to work with NTSC if you’re living in the US or Japan. Sending black and white is “easy” but to transmit a full color image, you’ll need to read up on color spaces. Check out [marble]’s project log.

Hackaday has another hacker who’s interested in broadcasting to dinosaur TVs: [CNLohr]. Check out his virtuoso builds for the ATtiny and for the ESP8266.

(Yes, the headline image is one of his earlier trials with black and white from Wikipedia — we just like the look.)

Arduino + Software Defined Radio = Millions of Vulnerable Volkswagens

As we’ve mentioned previously, the integrity of your vehicle in an era where even your car can have a data connection could be a dubious bet at best. Speaking to these concerns, a soon-to-be published paper (PDF) out of the University of Birmingham in the UK, states that virtually every Volkswagen sold since 1995 can be hacked and unlocked by cloning the vehicle’s keyfob via an Arduino and software defined radio (SDR).

The research team, led by [Flavio Garcia], have described two main vulnerabilities: the first requires combining a cyrptographic key from the vehicle with the signal from the owner’s fob to grant access, while the second takes advantage of the virtually ancient HiTag2 security system that was implemented in the 1990s. The former affects up to 100 million vehicles across the Volkswagen line, while the latter will work on models from Citroen, Peugeot, Opel, Nissan, Alfa Romero, Fiat, Mitsubishi and Ford.

Continue reading “Arduino + Software Defined Radio = Millions of Vulnerable Volkswagens”