Multi-Receiver
Contents
Multi-Receiver Options
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.
Stand-Alone
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 options is supported by KISS Konsole on Windows and ghpsdr3 on Linux and (Windows under developemnt).
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 on Windows and ghpsdr3 on Linux and (Windows under development).
"Multiple Mercury boards" is supported by Ozy v1.8 and later and by Mercury v3.0 and later FPGA/Verilog code. Note, however, that Ozy v1.8 does NOT sync the second Mercury board data stream properly so a new version that does sync the second stream properly is currently under development. K5S0 is successfully using a test version of Ozy FPGA code that does sync the second Mercury board data stream. K5SO will readily share this test version with any interested party as a temporary solution until a new Ozy version can be released (email: K5SO at valornet dot com).
COMMENTS ON THE USE OF MULTIPLE MERCURY BOARDS:
One of the principal uses of multiple Mercury boards is DIVERSITY RECEPTION. Diversity reception using dual Mercury boards is quite different from multiple-receivers on a single Mercury board. The primary difference is that more than one antenna input is used in diversity reception, one antenna input on each Mercury board, whereas only one antenna input is used in multiple receivers with a single board. With dual (or more) Mercury boards each Mercury board has its own independent antenna and so allows us to combine signals from independent sources that (likely/hopefully) have different signal fading characteristics from each other in order to create a combined signal that has less fading than would be the case if only a single antenna were used. The notion is that if one source is in a deep fade the other one(s) won't be.
Multiple Mercury boards can be used to achieve any of a variety of diversity modes, including (as examples) SPATIAL DIVERSITY in which spatially separated antennas are connected to the Mercury boards, POLARIZATION DIVERSITY in which orthogonal polarization antennas are connected to the the Mercury boards, and FREQUENCY DIVERSITY in which each Mercury board is connected to an antenna that receives a frequency that is different from the other antennas (on different bands, if desired).
The newest FPGA code for Mercury and Ozy generates a data stream of interleaved IQ values from all of the independent receivers that is then sent to the PC over the USB port for decoding in the PC. All of the operations from the antenna through to the USB port are independent of which PC operating system you use; that is, the same FPGA coding is used in the HPSDR boards regardless of whether the PC is running any of the variety of Windows operating systems, or Linux, or Mac OS-X, or any other operating system. The principal job of the program running on the PC is to receive the IQ data stream from Ozy and process it to produce the desired audio output data stream (which, in the HPSDR case is passed back to Ozy over the USB port and then on to Mercury, or Janus, for connection to the actual speaker). The USB path is bidirectional of course so that the PC also sends control information back to the HPSDR board set too but that fact is unimportant for this explanation.
In the case of diversity receive, the individual I values and Q values from each source must be combined appropriately before decoding (demodulating) the IQ values. There are several different ways to do the combining of the I values and, separately the Q values. An effective method for diversity operation is to use a simple "equal gain" combination where each independent, instantaneous I value is averaged with the other source(s) at that instant and then the "average" I value is passed along to the decoder code, same with the Q values.
Once combining of the independent I values, and Q values, is completed there is no difference between diversity operation and normal (single Mercury board) operation in the way the IQ stream is handled in the PC. Therefore, a program such as CW Skimmer or any other utility program that currently runs with PowerSDR or KISS Konsole, or whatever program is being used with HPSDR should also operate normally in a diversity mode (only with much less fading, presumably), after the HPSDR program has been modified to accept and combine the interleaved IQ values.
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:
GPIO pairs:
9,8 = Mercury ID bit 2,
7,6 = Mercury ID bit 1,
5,4 = Mercury ID bit 0,
3,2 = Channels_8_1 bit
1) When using multiple Mercury boards ALL of the Mercury boards must have GPIO pins 3,2 jumpered. This jumper specifies that the data from the board will be sent to a single, board-specific Atlas bus line that is associated with the address indicated on GPIO pins 9-8, 7-6, and 5-4; as opposed to sending its data to Ozy over eight Atlas bus lines as is the case when there is no jumper across GPIO pins 3-2.
2) 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).
3) Both (all) Mercury boards should use the same 122.88 MHz clock. There are several options to do this. For example, you can use the LVDS functions and header J1 on Mercury (using a twisted wire pair) for this between the Mercury boards and place the CLKSEL jumper in the "I" (internal) or "E" (external) position as appropriate for the board (master or slave relative to the 122.88 MHz Mercury oscillator) or, alternatively, simply remove the CLKSEL jumper entirely and run a twisted wire pair (one of the wires is ground) between the middle pin of CLKSEL on the slave Merc board(s) and the middle pin of CLKSEL on the master Mercury board (CLKSEL jumper installed, in "I" position). Also, it is a good idea to remove the jumper on JP9 on the slave Mercury board(s), removing power to the unused 122.88 MHz oscillators. The system will be a quieter system overall with the unused oscillators turned off.
4) In my view, although I haven't tried otherwise, both (all) Mercury boards should be using the same 10 MHz clock too. Atlas bus line C16 from Excalibur works well for this.
5) You need Mercury v3.0 or later FPGA code loaded in both (all) Mercury boards. The local parameter NR in the Mercury Verilog code should be set to 2 (or greater is okay, but not 1!) for dual Mercury board operations; v3.0 has NR=8, that's okay but not necessary...it takes much longer to compile if NR=8 (~1 hr) than if NR=2 (~6 minutes)!
6) In the case of two Mercury boards, command and control byte C4 to Ozy from the PC needs to be 0x08 (when C0 = 0x00, assuming no DUPLEX mode or ALEX relay info is selected), specifying 2 receivers so that Ozy knows to insert additional IQ data bytes, from the second Mercury board,into the USB data stream to the PC.
The sync problem mentioned earlier with regard to the data stream from the second Mercury board is fixed in a test FPGA code for Ozy (K5SO). Currently, the proposed fix is pending review, cleanup, and approval by Kirk and Phil. They will release a new Ozy code that fixes the additional-board sync problems generally.
COMMENTS ON KISS KONSOLE SOFTWARE FOR MULTIPLE MERCURY BOARDS:
A prototype KISS Konsole (Windows) RCV-ONLY version is now up and running successfully with two Mercury boards on the Atlas bus, providing spatial diversity reception (if two spatially separated antennas are connected to the Mercury boards) or polarization diversity (if two sources of different polarization orientations are connected), including an ability to sync time-domain acquisitions to an externally applied pulse to Atlas bus line A19 (for time-domain pulsar work, for example).
At the present time the two receivers are operating on the same frequency but it's straightforward (and is on the "to do" list) to add independent frequency control of the second Mercury in case frequency diversity is desired instead (even for two different bands).
The diversity option is front-panel selectable (RCVR1, DIVERSITY (BOTH), RCVR2) and should not be a problem to implement in the standard (Tx & Rx) version 1.0.6 of KISS Konsole.
It might be a while before there's a public release of KISS Konsole with these features but, of course, K5SO will be happy to share this test code with anyone who is interested (K5SO, email address above).
