The Soft66Q on linux (and Mac at work)

I've played around with the simple RTL-SDR usb sticks for a while and it's been fun. I've decoded ADS-B from aircraft, even built a coaxial collinear antenna that gave a huge boost in range. I've decoded AIS and I've listened to repeaters and much more. But, I have not been able to use these sticks on hf. And, hf really is where the fun begins. At least for me :-).

An idea I had was to make a simple weather report receiver for my boat. Lets say I combine an RTL stick for hf with a raspberry pi and a simple antenna. That would enable me to get Navtex, RTTY weather from DWD, weather fax from Northwood and so on. I could have an apache server on the raspberry and serve up weather reports through a web interface. Excellent, just what I need.
But, I'll need a simple SDR receiver that can handle hf for starters.

So, I ordered a Soft66Q through ebay a few weeks ago. The asking price was fair, $46 plus shipping from Japan. I had it in the mail about a week after ordering. The Soft66Q is of course a product within the RTL-SDR universe and for those not familiar with it that means it's a software defined radio based upon the RTL2832U chip and the R820T2 tuner. In other terms its a very flexible radio receiver covering a huge frequency band, from 3 kHz all the way up to 1.7 GHz.

Its the metal box in the image above. I've placed on of my other USB sticks next to it for size comparison. Its not big at all really.

What I like about this particular stick is that it's built for hf use. For starters its equipped with a common mode choke. That means it tries to do something about all the RFI hash that can come from a pc (and the stick itself) on these lower frequencies (self jamming). It's also equipped with filters. The filters are manually selected on the box and cover 3 KHz to 1 MHz, 1 to 5 MHz, 5 to 15 MHz and 15 to 28.8 MHz. So why would you need filters? Well, the basic working principle for a radio receiver is to amplify the signal you want and not amplify the unwanted signals. This is called selectivity. Without these filters the very strong adjacent medium wave transmitters would seriously affect what I would be able to pick up. So, filters are good.

So, the first issue I encountered with this stick was the installation instructions. Not that they were poor or anything but they only refer to using the stick with HDSDR. That means Windows only. I really do not use Windows and a windows requirement would crash my raspberry pi idea for my boat.

Normally I use the Gqrx software package for the rtl sdr sticks. Both at home on linux and at work on a Mac. I like it a lot and it will even run on a raspberry pi 3 meaning my boat project could actually work.

So, I had to find a way to make Gqrx handle this stick on hf and it turned out that wasn't very hard. Gqrx was already capable of doing what I wanted. All that was required was to edit the I/O device setup within Gqrx and tell it do to direct sampling (just like HDSDR does with this stick).  That can be done easily by just adding direct_samp=2 to the device string. 

So, that was pretty much it. I started GqRX and I was off surfing the hf waves. As an added bonus I launched fldigi and had that listen to the audio generated by Gqrx. Fldigi is a software multimode modem and by using that I was within minutes receiving the weather, both as text report from Deutsche Wetterdienst (DDH7 on 7646 kHz) and looking at weather fax images sent from Northwood.

The above image is a screenshot where the top window is Gqrx and the bottom window is fldigi decoding the audio coming from Gqrx. So there, I have a very simple, but capable, setup that can accomplish what I want on my linux (and Mac) pc. For the next part I'll get this running on a raspberry pi 3, setup a web interface and install an hf antenna on my boat. But first I'll need some coffee.

Monitoring NAVTEX using fldigi

A few days/weeks ago I helped put a navtex receiver on a sailing yacht. I made sure I had it properly filtering through only the stations and messages that were wanted. Later it was obvious that filtering was a bit too tight or something was wrong with the receiver, just one message got through in a week. I started thinking I should listen to Navtex again at home and get a feel for the rhythm of the broadcasts and propagation. I just wanted to know what was on there now before I started to do something about that receiver on the yacht. So, how can I listen to Navtex when I currently have no receiver for it? Well, I have a few options in the junk box. There is the really crappy MFJ-1278 I may still have somewhere. But, that piece of Mighty Fine Junk is so bad that it really would be a waste of energy and I should throw it away or execute it a la the famous printer from the movie Office space. I mean this scene: [Original] Office Space: The Printer Scene
But, I just noticed that fldigi 3.21.49 has added Navtex reception and that could be fun to try out. In the shack I have an almost antique IBM Thinkpad 600x that I have running lubuntu 12.04 and it is still good for experiments like these. So, off to the fldigi website I went and got the latest fldigi binary. When later trying to execute fldigi it complained about a missing libjpeg62.so library and immediately died. So, I launched synaptic, got libjpeg62 and then it worked fine.

I am now running Navtex reception using fldigi, a homemade soundcard interface and get the audio from a Yaesu FT-897. The Yaesu is tuned to 516.50 kHz in USB, fldigi cursor frequency is at 1500 Hz and that has me listening to 518 kHz. A few impressions from using fldigi this way can be summarized as: Navtex reception is quite CPU intensive on the old laptop, fldigi uses about 70 % CPU and that can to a large degree be blamed on the old CPU of the laptop used (P3-600). Fldigi tries to identify the transmitting station by looking at the transmitter "callsign" (it's just a letter) and looking that up in a csv file. By default that file is named incorrectly in fldigi and you need to browse for it in settings. When that file is found then fldigi can log the messages to an Adif file where it spells out the name of the transmitting station (Cullercoats, Niton, Rogaland, Reykjavik etc). That csv file is a very nice idea but it needs some work, at the moment it has the wrong letters in there so it identifies Tallin as Cullercoats etc. I'll see if I can correct that and contribute an improved file. To summarize the experience it was fun to receive Navtex again, fldigi worked reasonably well when decoding the transmissions (it did have some issues with a fading signal but the mode can be like that). I can see some improvements with the obvious bugs and then add filtering of stations and messages. That way I could have the latest weather report available on my server at all times, that leads to other projects... :-)