The title of this one says it all. There are problems with this Softrock based rig and unfortunately there are no simple “follow this guide” solutions out there to alleviate the problem quickly and simply.
From the research I’ve undertaken there’s a definite need for an understanding of this radio system from the ground up but I can safely say after the man hours invested in this to date, with no success on the transmission side, I could kill for a “do this and it will work” guide just to have the pleasure of seeing it work!
As such I plan to document this as clearly as possible with as much detail so that anyone else who finds themselves with this issue doesn’t have the same battle I’ve had!
That said there are a huge mountain of variables which will differ between individual setups but the main issue I’ve found with other articles on the Internet is the massive contradictions between them and the assumption of a knowledge level that unfortunately I don’t have and it will be a few more years before I do.
As such, what I publish is “what worked for me” and hopefully will help someone.
To put the problem into context before we move towards finding the solution, it may help to recap a few things for those of you joining the party late and to prevent you from having to read pages of previous posts.
The brief of my project is to build a software defined radio (SDR) based around a purpose built PC with a high end soundcard and a Softrock Ensemble RXTX.
The spec of the Radio PC is as follows –
Intel i5-4440 3.10GHz processor
ASRock H81M-ITX motherboard with an Intel chipset and on board Realtek ALC892 audio
16GB memory and a solid state hard drive
Xonar DX soundcard with driver version 126.96.36.1994
The PC is running Windows 7 Professional x64 SP1
Prebuilt Softrock Ensemble RXTX
The antenna setup and antenna tuning unit (ATU) don’t influence the problem I have with the setup at this time but are essential components to any rig.
I am utilising VAC virtual audio cable version 188.8.131.5211 and also have VB-Audio cables A&B version 184.108.40.206 installed.
The PC is mute, in that all Windows sounds are disabled along with any audio enhancements that Windows or vendor drivers provide. Check all the available sub menus as some of these features aren’t obvious and you don’t want any more spanners being thrown into the works!
The objective is to use HDSDR with Fldigi for transmission (Tx) and reception (Rx) of digimodes.
Since construction the rig has been working perfectly for Rx purposes with both my favoured SDR program SDRConsole and HDSDR.
Unfortunately HDSDR is the only package which supports Tx along with rig control, a nice spectral display, waterfall and so forth.
If anyone ever enables Tx support in SDRConsole I’ll be jumping ship, but we’ve got to work with HDSDR at the moment!
To identify the problem there needs to be a fundamental understanding of what a SDR radio is and how it works compared to a conventional radio that’s attached to a computer.
The following system diagram helps put that into context.
I would strongly recommend a read of RadCom’s article in the January 2015 issue (volume 91 number 01) entitled “Getting started in… software defined radio (SDR)” which really helps lay the foundations.
Naively I was hoping that this thing would work straight away but by the very nature of SDR in this guise there is so much more you need to have functioning correctly before the whole system becomes stable and reliable.
Hind sight is a very exact science! If I’d have bought a Yaesu 817, a Tigertronics SignaLink and a few cables and plugged them all together with a computer on the end running Fldigi I would have had a radio system running digimodes in about 15 minutes, something that a very helpful chap at Martin Lynch & Sons pointed out to me when I rang them last week to speak about conventional rigs.
The thing is I wouldn’t be able to have a remote hidden rig in the manner I want to achieve if I utilised conventional radio hardware. That said I’m now several months on without a fully functioning rig and if the world was my oyster…!
Just before Christmas my good friend Andy (G7UHN) lent me his time, his Elecraft K2 and Elecraft XG2 signal generator in exchange for copious cups of tea and chocolate biscuits, to help fine tune the rig prior to hitting the Tx key.
Despite calibrating the Softrock against the WWV time signals there was still a few Hz discrepancy in the system which is down to the ability of the human eye to read a graticule on a PC screen. That said I hadn’t done too badly but perfection is the name of the game and using a signal generator to provide the reference source pays dividends.
Learning points –
Changes to the Softrock’s configuration is via the application CFGSR which needs to be installed for the Softrock to function and is part of the PE0FKO driver package.
When you make changes to the crystal frequency for the Softrock the changes are written to the file ExtIO_Si570.dll which is saved within the folder C:\Program Files(x86)\CFGSR.
Any changes made here are not global in as much that HDSDR also needs a ExtIO_Si570.dll file within the directory C:\HDSDR. After calibrating CFGSR and being mightily impressed with the results in SDRConsole, when moving across to HDSDR there was a degree of head scratching as to why the calibration had been lost. As such, make sure all your copies of ExtIO_Si570.dll are the same.
With that all sorted, the long awaited TX button was pressed (while transmitting into a dummy load) within HDSDR.
Fldigi’s rig cat works very well and sending a PSK31 transmission was reflected in HDSDR but received very weakly on the Elecraft K2/Fldigi setup which was two foot away.
In addition the transmitted signal from the Softrock just didn’t look right. It was by no means clean and it wobbled around all over the place which was very odd.
The problem was initially suspected between HDSDR and Fldigi with the settings of the virtual audio cables (VACs).
This precipitated a lot of head scratching and Effing and Jeffing over the Christmas period where I tried altering sample rates on the virtual audio cables, within Windows and within HDSDR and Fldigi until I’d exhausted every conceivable combination all to no avail.
It’s at this point I was ready to launch the whole thing out the window but that’d be defeatist!
This rig will work, but conquering the issue preventing it from transmitting won’t be a 5 minute job.
I’ve read countless web articles, guides and so forth over the last few weeks trying to glean anything which could point to the source of the problem.
The guys at the Softrock40 forum and several site owners have been brilliant in answering my questions.
I’ve got to highlight the advice from Steve Arntz (KM5HT) and it’s around his suggestions that this problem solve is based.
The principle is reducing the radio system to its absolute basics and building upwards. At present the finished article doesn’t work and there are too many complications to allow the easy identification of the root cause.
As such, this is a phased approach problem solve where the blocks of the system diagram are “unplugged” and checked for functionality before being plugged back together –
1. Disregard any thoughts of Fldigi and digimode transmission on the Softrock/HDSDR side. This removes any potential issues around virtual audio cables and reduces the system to the “radio” component alone
2. Get the radio functioning and able to transmit a clean and stable CW signal
3. Add a microphone and achieve a clean and stable voice signal transmission
4. Add Fldigi to the system and achieve a clean and stable data mode signal transmission