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:
Today I’m finishing the development of OpenWebRX.
It has been a fascinating 6 years, and I’d like to say thanks to everyone who supported me on my journey with this project.
I’d also like to say a special thanks to those who donated to support me.
A quick summary on the changes:
- OpenWebRX will not be further developed, but as promised, it will remain on GitHub to serve future amateur radio experiments. There are some known limitations of the last version though (including potentially reduced security as its dependency, Python 2.7 will be obsolete soon).
- My SDR.hu website and my CSDR project will still be maintained.
(Update 2020-05-31: the SDR.hu project is also finished.)
- For commercial enquiries, you can still contact me by e-mail.
- It’s important to emphasize that this post is not about the KiwiSDR. (KiwiSDR and OpenWebRX are two separate products, even though they share some code. I’m not involved in KiwiSDR development.)
I had very nice moments with OpenWebRX, a lot of things happened that I’d have never expected. I didn’t expect that my code would be used at ~480 receivers on 6 continents. I didn’t ever dream that CSDR would be used at NASA during a Mars landing attempt. I also feel extremely lucky that I had the opportunity to give some conference talks and publish some papers on my work on OpenWebRX and CSDR. I’m sure that these helped a lot in my recent admission to a PhD programme.
However, nowadays I’m more interested in exploring new ideas. My PhD has also brought me to a different field: my topic is on LPV system identification, related to control systems. This is a real challenge to me. Currently I’m putting a lot of effort into diving deeply into this topic, in the hope of being able to contribute to it later. Unfortunately, I cannot afford to spend enough time on OpenWebRX anymore.
In addition, over the years I had to deal with several conflicts regarding my open source projects, which I also want to put to an end. OpenWebRX was created for the amateur radio community, with a dual licensing possibility to sell it to companies that build radio communication products, in order to fund further development. However, this model did not work well. There were multiple attempts by others to fork the project and bring it to a different direction without me. Maybe some of you remember the case with the KiwiSDR, where luckily we ended up reaching an agreement, but there were other cases as well, and I expect that new ones would continue to appear in the future.
For me the conclusion is that open source does not work in every setting (for example, read this and this for large open source projects struggling to become sustainable), and in some cases giving away something to the public without being able to defend it might result in the public coming out poorer in the end, compared to the outcome of a more centralized / closed source way. With that I mean that these incidents and the low amount of funding I could gather gradually decreased my motivation to further develop the software. Forkers, if we worked together, I think we could have served the amateur radio community much better.
I feel that my PhD is a new beginning, with a “blank page”, where I can do everything better from the start. Nevertheless, even if everything wasn’t always happy with OpenWebRX, I think I have learnt a lot from this project, and I’ve also met some great people who I will never forget.
To everyone who joined my journey throughout this project, a big thanks!
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…
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.