The openHPSDR receiver can be run in several configurations. Stand-alone, multiple receivers on a single MERCURY (one common antenna), and two or more MERCURY boards plugged into a single ATLAS (this allows two or more antennas). Each of these configurations require different hardware and software support but all have been successfully accomplished using MERCURY boards.
The options is supported by all software and all versions of the verilog code.
Current verilog code is Mercury 2.9 and Ozy 1.7
Multiple Receivers on a single Mercury
This option is only supported by the Ozy 1.8 and Mercury 3.0 verilog code.
Multiple Mercury boards
This option is supported by KISS Konsole versions >1.0.6, PowerSDR v22.214.171.124.diversity20, and PowerSDR v126.96.36.199.directional1 on Windows and ghpsdr3 on Linux.
Dual Mercury board setups (Windows): Diversity operation using two coherent Mercury receivers is implemented in PowerSDR v188.8.131.52.diversity20 (K5SO 12MAY2011). This program is a modification of PSDR v184.108.40.206 and uses a radar-screen type display to adjust relative gain/phase of the non-reference IQ data stream to achieve diversity operation or selective nulling. Polarization diversity or spatial diversity are possible, depending upon what inputs are provided to the two Mercury boards. Mercury firmware v6.4 or v6.6 should be used with PowerSDR v220.127.116.11.diversity20, the firmware and PC program are available for download at http://k5so.com.
Triple Mercury board setups (Windows): Directional steering and selective nulling using three coherent Mercury receivers is implemented in PowerSDR v18.104.22.168.directional1 (K5SO 20JUN2011). This program is also a modification of PSDR v22.214.171.124. The program provides a large user display interface that allows the user to select the receive direction and independent phase/gain control of the two non-reference Mercury boards. Mercury firmware v6.6 should be used with PowerSDR v126.96.36.199.directional1. Using triple coherent Mercury receivers provides up to 4.8 dB of signal gain relative to a single Mercury board receiver and with careful phase adjustments can provide up to 70 dB of null on selected signals, depending on band conditions. The firmware and PC program are available for download at http://k5so.com.
Mercury v6.4 and Mercury v6.6 firmware are compatible with the current versions of Bill KD5TFD's PowerSDR v1.10.4, KISS Konsole, and W5WC's PowerSDR v188.8.131.52 therefore it is not necessary to change the FPGA firmware in the Mercury boards when switching among those programs. Power cycling the HPSDR board set (or alternatively, re-running initozy11.bat without power cycling) is all that is necessary to be able to switch between the programs in order to automatically load the proper Ozy/Magister FPGA code. Metis v1.3 may be used with multiple Mercury boards.
The second and third Mercury boards can remain on the Atlas bus while running the other programs with no ill effects, the second and third Mercury boards are simply ignored by single-Mercury programs.
Required Hardware Configurations To Use Multiple Mercury Boards
Each Mercury board must have jumpers in place to specify an address for the board. Each board will have a different jumper-selected address. The address is specified by placing jumpers on J5 (GPIO pins) on the Mercury board. Looking at the Mercury board with the Atlas bus connector down, the GPIO pins on J5 are arranged such that the lowest pair of pins (closest to F1) are GPIO pins 1,0. Without a jumper, the logic value for the GPIO pin pair is "0", with a jumper across the pins the logic value is "1". The Mercury board address is specified as a 3-bit address according to the jumpers placed on J5. The GPIO pins on J5 are assigned as follows:
9,8 = Mercury ID bit 2,
7,6 = Mercury ID bit 1,
5,4 = Mercury ID bit 0,
1) The address of the first Mercury board should be "000", selected by having no jumpers on GPIO pins 9-8, 7-6, or 5-4. The address of the second Mercury board should be "001", selected by having a jumper on GPIO pins 5-4; and so on for any additional Mercury boards present.
Therefore, for dual Mercury boards, the 3,2 GPIO jumper pair should be on both Mercury cards, the first Mercury board is set for Merc_ID = 000 (no jumpers on pins 9-8, 7-6, or 5-4) and the 2nd Mercury card is set for Merc_ID = 001 (a jumper across the 5,4 pair).
2) Configuring the 122.88MHz clocks on the Mercury boards:
2a) place a jumper on the CLKSEL "I" pins (lower two pins of the three CLKSEL pins) on one of the Mercury boards (this will be the "master" Mercury board), no such jumper is placed on the equivalent pins of the slave Mercury board,
2b) place a jumper on JP9 (enabling the 122.88MHz oscillator) on the master Mercury board but not on the (other) "slave" Mercury board
2c) place a jumper from the Atlas C16 pin to J8 (Aux Clk input) pin nearest the FPGA on both Mercury boards
2d) connect, with a twisted wire pair, pin 2 of JP1 (CLK SELECT) and a ground connection of the master Mercury board to pin 2 of JP1 (CLK SELECT) and a ground connection of the slave Mercury board, see photos at http://www.k5so.com/Clock%20connections.html.
2e) in PowerSDR, select Setup>Excalibur for the 10 MHz clock source and Mercury as the 122.88 MHz clock source. For three Mercury board operations, parallel the 122.88 MHz clock signal from Mercury 2 to Mercury 3 using a twisted wire pair as was done from Mercury 1 to Mercury 2 for dual Mercury operations and disable the on-board 10 MHz and 122.88 MHz oscillators on Mercury 3.
Now both (or all three, if using triple Mercury boards) Mercury boards will be operating from the single 122.88 MHz oscillator on the master Mercury board. The twisted-wire connection between the Mercury boards is required to achieve long-term coherent operation of the Mercury boards.
3) 10 MHz clock on Mercury: The 10MHz clock for the Mercury boards should be taken from Excalibur (or whatever external 10MHz source you use) via the Atlas C16 pin, with Mercury jumpered as noted in 3d above.
- Multiple independent receivers - how to set up on Windows - not the same as above, but related.