Article about the Frequency Xlating FIR Filter block in GNU Radio
I’ve written an article on a GNU Radio Companion block, and published here:
Today I’m happy to announce a new version of OpenWebRX with a BPSK31 demodulator built-in. On the video below, I’m using OpenWebRX with a HackRF to monitor the 20m band and demodulate a BPSK31 QSO:
OpenWebRX now also has a 3D waterfall diagram, featured in the video below, which in addition also shows how the secondary waterfall diagram of the BPSK31 demodulator can be zoomed by moving the filter edges around:
I’m also happy to say I’ve just graduated from university, earning a Master’s degree in electronic engineering. I’m now looking for new opportunities related to Software Defined Radio. I am also thinking about continuing my studies in this field for PhD degree.
My Master’s thesis about “Integrating digital demodulators into OpenWebRX” can be downloaded here. It covers:
On 15 July, I’m going to have a talk about these topics at SDRA-2017, a conference organized at HAMRADIO Friedrichshafen.
I also have good news about SDR.hu: the server has been moved to a DigitalOcean VPS for better reliability.
I’d like to say thanks to everyone who uses OpenWebRX and CSDR, and also everyone who helped me with this project:
Thank you everyone for your support!
I’ve written an article on a GNU Radio Companion block, and published here:
What happens if you really try to add some CFLAGS to cmake from command-line…
I was invited to talk at Software Defined Radio Academy 2016 at HAM RADIO, Friedrichshafen. I had a talk about my work on OpenWebRX and csdr carried out during the last year.
While things like this are not the most important in an SDR application, the OpenWebRX UI has been improved with some 3D animations:
I’ve created a python script that can read the I/Q samples from a HPSDR Atlas + Metis + Mercury receiver, and write them to the standard output. The code is available on GitHub:
After writing my previous blog post, John has changed his mind, and he contacted me about resolving the situation. He made a Memorandum of Understanding about Valent F(x) giving a part of the profit of KiwiSDR to me and Andrew Holme (the author of the GPS receiver code used in KiwiSDR).
I would like to say a big thanks to a lot of people, for your amazing support! It was not possible without you!
After writing this article, John has changed his mind, and he contacted me about resolving the situation. He made a Memorandum of Understanding about Valent F(x) giving a part of the profit of KiwiSDR to me and Andrew Holme (the author of the GPS receiver code used in KiwiSDR).
During the last month, I’ve got a lot of mails from a lot of people. Thanks everyone for your amazing support! It was not possible without you!
While developing OpenWebRX, I always wanted to make it available to hams who have various hardware, instead of supporting a specific board that you have to buy in order to use the software. The idea of a full HF receiver is very good, and I imagined if anyone could have one, not just those who buy a specific board of a specific manufacturer.
I’ve stumbled upon this: if we fork()
a process, its standard input and output file descriptors remain the same for both processes. It means that the forked process can read()
from stdin, and then the read data is taken away, and the original process can’t read it.
You can find my article on Github.
I’ve got continuous underruns and overruns, clicks with Audio Sink in GNU Radio, so I used the Execute External Process Sink in gr-ha5kfu, with csdr
, and the mplayer
command line tools.
One of my friends needed this for doing his work, so I compiled it for him:
The screenshot was made of a VirtualBox VM running Ubuntu 14.04 on a Linux MINT 17 host.
rtl_sdr
tool works inside the guest OS, after sharing the USB dongle with the guest under the Devices, USB Devices menu.
This is an absolute quick guide to install OpenWebRX, an SDR receiver software with a web UI. If you need more information or have a problem, please look at the GitHub page of the project.
It was quite easy, but I’d like to highlight some information:
I’ve recently had difficulty installing GitHub Atom on my PC as only an amd64 package was available on the official site. Here I’ll provide an i386 build:
This small script prints overall CPU usage in a Linux system. You can use the get_cpu() function to get the CPU usage between 0.0 and 1.0 (all CPU cores were taken into consideration, so the maximal value is also 1.0 on a multi-core system).
Based on the discussion over here, I’ve created a simple code sample.
I’ve just written a shift_table_cc
function for libcsdr.
You will need to do something like this (note that I have xorg-edgers
and you may have to replace 346 with the actual version number):
ShinySDR is a bit similar to my OpenWebRX project.
I could not find any good screenshots on the Internet about ShinySDR, so here is one:
OpenWebRX serving 10 clients simultaneously (and also running the browser windows on the same machine), without audio underruns.
If you have zero signal coming out of the Rational Resampler block in GNU Radio, or such strange signal as on the top right:
I liked this python recipe and I’ve extended it a bit, to make this class also iterable.
While running Raspbian on my Raspberry Pi (Model B), the SD card repeatedly got corrupted when I removed the +5V power without properly halting the system.
First question: why would anyone want to set up GNU Radio on a virtual machine?
Because you can connect to an rtl_tcp
server to get I/Q samples from there, and do actual processing on the VM.
I’ve implemented a power spectrum display to demonstrate a way to postprocess the data gathered from GNU Radio in python.
Having watched Balint Seeber’s SDRDF presentation, I and HA1OP had some interesting ideas.
I’ve made an interface between the popular RTL-SDR compatible hardware and NI LabVIEW. It’s not complete, but just got it working. It’s a set of SubVIs that can be used to connect to an rtl_tcp
server. I’ve also implemented a WFM demodulator, so I could listen to some FM broadcast in LabVIEW.
I’ve just installed a tool called iperf, that can actually determine the real available network bandwith between two nodes in your network. The result listed below might not be the most accurate, as I was connected to the Pi with a Linksys 8 port switch in between.
I’ve recently made some experiments with the great WSPR software, which can dig out and process so weak signals that you can’t even hear. Along with the software, there’s a great web interface on which you can see the contacts on a map.