Thanks to a tip from @blackthorne I have the gr-qtgui component of GNU Radio working on Mac OS X Snow Leopard as well. As reported earlier, previous installations worked well except the Qt GUI part which gave errors like the one reported in my email.
Video recording of the HO-68 / XW-1 Chinese amateur radio satellite in linear transponder mode on November 9, 2010. Recorded using the Universal Software Radio Peripheral (USRP) with RFX400 daughterboard and GNU Radio software receiver.
The gqrx software receiver implemented with GNU Radio and Qt GUI is now taking shape and becoming useful. Yesterday evening I went to OZ7SAT and had the USRP+WBX connected to a real antenna tracking amateur radio satellites. The video below shows reception of the evening pass of HO-68, aka. XW-1.
Last night, while I was preparing for the AMSAT-OZ satellite weekend, I noticed that my gqrx receiver didn’t work very well on my laptops. Every time I tried to change operating mode the receiver stopped with a runtime error:
audio_alsa_sink[hw:0,0]: snd_pcm_hw_params failed: File descriptor in bad state
terminate called after throwing an instance of 'std::runtime_error'
what(): check topology failed on audio_alsa_sink(1) using ninputs=1, noutputs=0
This happened on both my Acer and my MacBook Pro; both running the lates git of GNU Radio v3.3.1git-96-g1fa9a8ea. This was bad news because I was hoping to show off my new software receiver with Qt GUI during the weekend. Fortunately, there is an easy workaround that eliminates the problem. Continue reading “A patch to fix audio_alsa_sink[hw:0,0]: snd_pcm_hw_params failed”
As I mentioned in my previous post, my “optimizations” of the multi-mode receiver code caused a sudden loss in performance.This was a big surprise because what I did was to replace two filters with only one, which I would expected to yield a performance gain and certainly not a loss. What happened at the same time was that the sample rate in the demodulators went from 50 ksps to 250 ksps and it was the responsibility of the demodulators to downsample this to 50 ksps. I suspected that this might have cause the increased CPU load and I have set up a simple experiment to confirm it.
I have been a bit quiet over the last few weeks but don’t you worry, it is only because I have been busy and I can now present you what I have been tinkering with during the last few weeks: An AM, FM, SSB and CW receiver implemented using GNU Radio (python) and Qt graphical user interface.
A few APT images received from NOAA 18 and NOAA 19 yesterday. THe setup I used was the very same that I have described earlier. Click on images to see full resolution and image details.
I have now tried the USRP on Mac OS X using the MacPorts installation and I am happy to report that it works very well. Indeed, the USRP is really plug and play on OS X and there is no need to configure udev or anything like it is the case on e.g. Ubuntu Linux. The video below shows the FM receiver listening on the local APRS frequency.
Few days ago Michael Dickens announced that the GNU Radio packages on MacPorts have now been updated to 3.3.0 and so I took this opportunity to try it. I didn’t have MacPorts installed so I had to start from scratch; however, installation was quite straightforward because the dependencies are resolved automatically. All I had to do was to download the latest MacPorts dmg and then execute the command
sudo port install gnuradio
then let it run overnight. It takes a long time since MacPorts builds everything from source. On my iMac it took more than 6 hours. Note that gnuradio is a meta packages that depends on all GNU Radio components.
Yesterday I have been testing the DVB setup using Theora encoded video in Ogg container instead of the H.264/MPEG-TS I have been using so far. Initial tests looked promising, but at the end the link was rather choppy and broken.
On this first screen shot I am running the simulator (i.e. no USRP) with a test pattern as video source. This setup was very stable and I was surprised to see that mplayer got synced much faster than when using H.264/MPEG-TS.
The second screen shot shows the setup running with the GMSK transceiver and again using a video test pattern as source. I have let it run for over 2 hours during which it was very stable. Of course, I was playing with the RF settings while it was running to make it loose the signal and force it to resync – no problems there.
Finally, I replaced the video test pattern with the Logitech Webcam Pro 9000 as video source and this is when things have started to become bad. The video came up all right but already after a few minutes, the playback becomes choppy and mplayer starts spitting “Ogg: bad packet in stream 0” messages out in the console. At the same time, the frame rate drops to about 1 fps. So this is not very useful.
For now, I will stick to H.264/MPEG-TS.