Hacker News new | past | comments | ask | show | jobs | submit login
The Raspberry Pi 3B+ as an SDR, Without the SDR (hackaday.com)
116 points by okket on June 2, 2018 | hide | past | web | favorite | 29 comments



I work for the military, in which the labyrinth of acronyms and custom-made terms are extremely challenging to navigate. We constantly remind our peers to define acronyms when first used in document.

As I enter the computer science (CS) field, I find increasing number of pages (such as the subject page) riddled with acronyms that you have to search to define. I also find a host of improper terminology usage as well as "instructional" information that is simply incorrect.

As CS experts, trying to expand our mutual horizons, why do we torture ourselves like this?


It's not "torture", it's learning and efficiency. We could expand every single acronym and abbreviation every time, but that would quickly get in the way of understanding since it would just become needlessly verbose.

I also find a host of improper terminology usage as well as "instructional" information that is simply incorrect.

That's a different issue... and one that's pretty much unavoidable if you want freedom of speech.


The original poster (OP) was suggesting that acronyms should be written in expanded form once, like I did with OP at the start of the sentence, and then used by acronym for the rest of the article, like I did in the middle of this sentence. That way people who don't already know the acronym don't need to go look it up, and people who do know the acronym don't have to pause and think about it, and it still saves time and typing by the author.

Many writing style guides, like APA [1], suggest this form.

[1] https://owl.english.purdue.edu/owl/resource/560/21/


The problem lies in choosing where to draw the line. People often assume the acronyms they use every day are well known, and don't think it's necessary to expand them. Case in point, you don't define APA, because you (correctly) assume I know what it means.

This article doesn't look like it was written for newcomers to the field; it appears to be written for hobbyists interested in having yet another cheap SDR at their disposal. The target audience knows the acronyms, so the article doesn't bother to expand.


The criterion might reasonably be (a) acronyms that are terms of art in (b) an article for publication.

Thus acronyms that should be known to everyone within a field would be expanded on first use. This seems redundant but it's not actually a huge burden.


The author's PhD thesis on the framework he built to modify the Broadcom WiFi firmware looks really interesting, and presents several other ways to take advantage of the low-level control of the hardware.

http://tuprints.ulb.tu-darmstadt.de/7243/7/dissertation_2018...


You can also use RPi as FM stereo transmitter without additional hardware - https://github.com/Miegl/PiFmAdv


You can, but you definitely shouldn't.


Yeah I was able to easily jam my mobile phone with a Pi by transmitting on a fundamental with harmonics the phone’s band.

The range was pretty short but it nuked the signal. I used it to show my youngest what can happen if you aren’t careful with RF.


That’s a project with appeal - dangerous, but appealing.


Why not


It works by toggling a GPIO pin on and off. This results in a square wave carrier signal, which means you get an infinite stack of odd harmonics - 3f, 5f etc. This means you're not just transmitting on the frequency you meant to, but on every odd multiple of that frequency (with correspondingly decreasing amplitude of 1/3, 1/5 etc) all the way up the entire spectrum.

It's very easy to accidentally clobber something like that. The only reason regulators haven't come down like a ton of bricks is the amplitude on PiFM is really too small to be very harmful - you're unlikely to mess up anything beyond the range of your own home, maybe your neighbors. If someone with a little knowledge tried to hook it up to an amplifier however, they're gonna have a bad time real darn quick...


From the github repo readme:

> In most countries, transmitting radio waves without a state-issued licence specific to the transmission modalities (frequency, power, bandwidth, etc.) is illegal.


In practice, it's more like "if you get caught if it's illegal" --- and depending on what you're doing, getting caught can be very easy (e.g. broadcasting in an active band at enough power that your neighbours notice), or pretty much impossible (e.g. if you transmit inside a Faraday cage or at powers so low it doesn't reach the other side of the room).

Or as the old saying goes, "If no one else can hear you, they won't know you're saying anything."


The Nokia N900 had a FM transmitter, allowing you to stream to e.g. your car radio. Nowadays we got different solutions and this is mostly redundant (though still possibly of use in what we now call "older" cars). The transmitter was very short range, and therefore it was legal.


It might be easier to just link to the guy's github repository (https://github.com/seemoo-lab/mobisys2018_nexmon_software_de...) than the two click throughs to find it.


A better title would be something like 'Broadcom WiFi chip hack lets you use it as an SDR'. The raspberry pi isn't the interesting thing here, it's the raw low-level access to a wifi DSP.


The raspberry pi is the interesting bit because most people know if they have one hanging around.


This isn't showing off the Broadcom WiFi chip thing, that's been done a while ago [0]. Back then most of the posts and discussion was about using the Nexus 5's Broadcom chip, but this post is pointing out that it can (now?) be done with the broadcom chip built into another common hardware platform.

[0] https://news.ycombinator.com/item?id=16589703


Does this mean it would be possible to use Zigbee?


I think so, since they are on the same frequency. Which leads to some really interesting ideas I would like to try.


Are there SDR boards or plug-in components made specifically for Raspberry Pi?


Yes, Domoticz [1] is specialised for that.

"Domoticz is a very light weight home automation system that lets you monitor and configure miscellaneous devices, including lights, switches, various sensors/meters like temperature, rainfall, wind, ultraviolet (UV) radiation, electricity usage/production, gas consumption, water consumption and many more. Notifications/alerts can be sent to any mobile device.

Best of all, Domoticz is open source and completely free! You only need to invest in hardware."

See their HCL here [2]

[1] https://www.domoticz.com/wiki/Main_Page

[2] https://www.domoticz.com/wiki/Hardware


I've often wondered why someone doesn't design a daughterboard with a SDR chip for the RPi as this would let them do away with the embedded cpu/FPGA.

Plunk an rtl-sdr chip on a RPi board and Bob's your uncle...


Perhaps the IO bandwidth between the RPi and its peripherals isn't high enough to enable it to manage an SDR. (I don't imagine you could connect a modern GPU, or a video capture device, to an RPi either.)

Speaking of: are there any SBCs that have PCIe-based daughterboard support? Or Thunderbolt-3-based peripheral support?


Those based on the Zynq-7000 line from Xilinx usually have ample IO, but start at about 100$, going up. You might need to do something in the FPGA part of them to use the IO though.


There are the RTL-SDR usb dongles. One I’m currently looking at is the dAISy board. Turns your Pi into a marine AIS receiver.


I'd be extremely interested if this could be used to build a rudimentary Wi-Fi spectrum analyser / interference scanner. It doesn't even have to be very good—hazy and vague measurements are a million times better than no measurements.

The commercial option is Wi-Spy, a product that is so massively overpriced it's borderline absurd.


Been looking at this for a while, anyone who uses it to enable miracast on the raspi is going to be my hero.




Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: