GNU Radio 3.9
gnuradio.org
gnuradio.org
Like, I think it'd be fun to have something like an http server or whatever in my home that I could hit something like "streamer/99.9fm" and get an opus audio stream for that station.
First step for your desired use case would be, I think, to acquire an SDR module that can receive broadcast FM and then it would simply be a matter of having your server command the SDR to tune to 99.9 MHz and then stream the result to the network.
It used to be that you could download a GNU Radio livecd and that worked well - however it is no longer maintained. The latest release is from 2017 and I see it written that it is neither supported nor recommended.
Is loading the distro of my choice and then managing and installing GNU Radio, plus associated utilities/applications, and their dependencies my only choice in 2021 ?
On windoofs, `conda` got your back.
So, it's really gotten better. Yay!
javascript:var%20x%20=%20document.querySelectorAll("div,p,li,a,hr,em,font,strong,h1,h2,h3,td");var%20i;for%20(i%20=%200;%20i%20<%20x.length;%20i++)%20{%20%20%20%20x[i].style.backgroundColor%20=%20"white";x[i].style.color%20=%20"black";}undefined;//alert("Done");;
It changes the background to white and the text color to black. I use that on worse websites than the GNU Radio one.
To be clear, I use github often as well, but it seems odd to me that a GNU sponsored project would.
Lots of new GUI blocks in this release. I'm especially glad to see the new eye diagram.
Also the ability to load non-WAV audio files will be nice. OGG/Vorbis and FLAC are now supported. Plus a slew of minor conveniences such as a freq shift block and scaling options in the IShort to Complex block (useful for loading recorded samples from hardware).
If only it would compile easily on my Mac. (https://github.com/ktemkin/gnuradio-for-mac-without-macports has a prebuilt 3.8 version)
That's why BladeRF-wiphy ( https://news.ycombinator.com/item?id=25814237 ) implements the lower level phy on FPGA - there's no way to reply an IEEE 802.11 ACK frame within 10 microseconds of the end of the received frame, as required by the standard.
This is a problem for applications like time-of-flight measurement, so one way to account for this is to send a known signal on TX and look for it on RX