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:
- how CSDR can be used to demodulate BPSK31, BPSK63 and RTTY from the command line, and also to derive new digital modes from existing ones by changing the commands,
- how CSDR can be used as a general purpose FSK/PSK demodulator, demonstrated with decoding FSK signals sent by a YARD Stick One.
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:
- Starting from last February, a lot of people donated to support OpenWebRX development.
- Mike Ossmann from Great Scott Gadgets donated a HackRF and a YARD Stick One that I used for development and testing while implementing digital mode support.
- My supervisor, Dr. Péter Horváth taught me a lot about digital signal processing, and he always knew where should I look after the hard to understand topics that I encountered.
Thank you everyone for your support!
What happens if you really try to add some CFLAGS to cmake from command-line…
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.
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):
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.