Scrolling the above image (it is very wide) you will see the controlling shells for the running flradios/flcontrols on the left screen. The middle screen shows the transmit flradio (K3) and the 3 flcontrols. The right screen shows:
Hydra implements a many-to-one connection scheme between running instances of flradio. One copy runs in the "transmit role", controlling any transceiver that fldigi can run including an SDR rig. Multiple copies run in the "receive role". They can be attached to any of the available alex dsps. You can also run multiple copies of flradio on the same dsp, using different modems to simultaneously decode different modes. When you are decoding a signal of interest on any of these receive flradios you click a Hydra macro button to send meta-data to the transmit flradio. This meta-data includes the dial frequency, the signal offset in the waterfall, the mode, etc. The transmit flradio will then tune to that frequency/mode and be ready for a qso. If you capture the callsign before clicking the Hydra macro button, it will also be transferred.
Start ONE copy of flcontrol for each dsp. It will control all the flradios running on that dsp.
Each receive flradio will need a hydra macro button setup. Use the macro editor to to assign the hydra macro:
I use this macro file on my receivers.
You will find that there is a frequency offset between you transceiver and the hpSDR receivers. This will result in a mismatch between the signal location on the waterfall of the receive flradio and that on the transmit waterfall after it uses the meta-data for the setup. This difference will only be a few parts per million, but at 14 MHz that adds up. At 14.070 there is a difference of about 65 Hz between my K3 and the mercury. To handle this I have a frequency offset variable in both flradio and flcontrol. This is a "parts-per-million" offset. The details are here
Managing the flradio/flcontrol config dirs can be challenging when running a half dozen or more instances of each. I am still playing around with various mappings. Using desktop launchers in combination with shell scripts can help. In general you will want a dedicated config dir for the transmit flradio, as well as a separate config dir for each receive flradio. You can run multiple flradios on any one dsp with the same config dir as the important variables (dsp #, etc.) will be the same, but there can be "edge cases" making this a less desirable method. I would be interested in reports of any useful setups.
There are other details in setting up the modified version of flradio/flcontrol that are addressed on their respective pages, please read them carefully.
All additional flradios now participate in XML-RPC communications!
After the meta-data is sent to tune the transmit flradio, I want to send all the decoded text in the receiver's window to the transmit flradio, and continue to stream decoded text from receiver to transmitter. The theory is that the SDR receiver will do a better job of decoding than the transmit rig. I base this on several assumptions. First the receiver will probably be setup with a receive optimized antenna. Secondly using something like the anan-100/200 with phase coherent receivers a digital diversity reception model will be possible. This should out-perform any traditional receiver. Third, it is possible that the receive data is coming from a remote site via the internet, and that none of the local receivers can read it.
The skimmers would cover a much broader portion of a band, hopefully the digital half of any typical ham band. Multiple mode-specific skimmers could attach to the same dspserver. This is strictly half-baked theory on my part...
The data aggregater would sit between the one transmit flradio and the many receive flradios/skimmers. It would display one line of decoded text for each connection, along with the meta-data. Clicking that line's button would send the meta-data/data to the transmit flradio in a fashion similar to the existing hydra implementation. Think View in fldigi or supersweeper in hrd.