While things like this are not the most important in an SDR application, the OpenWebRX UI has been improved with some 3D animations:
You can check out my talk here (the YouTube video will autoplay in the corner):
The YouTube video can also be viewed here on its own.
I would like to say thanks to Markus, DL8RDS and Michael, DK5HH and all other organizers for their hard work. I again met great people at the conference, and had a great time!
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.