Difference between revisions of "Multi-Receiver"

Revision as of 12:31, 1 August 2010

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 MERCURY boards plugged into a single ATLAS (this allows two 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 are supported by Ozy v1.8 and later and by Mercury v3.0 and greater 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. It is noted that K5S0 is successfully using a test version of Ozy that syncs the second board data stream properly and he will readily share his test version with any interested party until a new Ozy version can be released.

COMMENTS ON THE USE OF MULTIPLE MERCURY BOARDS:

The use of multiple Mercury boards is needed to achieve 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 with in multiple receiver operation 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 won't be.

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(s) 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, but 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 done there is no difference in diversity operation from normal (single Mercury board) operation in the way the IQ stream is handled in the PC, so 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 will/should operate normally (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 the unique address for that board. Each board will have a different, jumper selected, address. The address is specified by using 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 0,1. Without a jumper, the logic value 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 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 bus lines.

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.

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) and the 2nd Mercury card is set for Merc_ID = 001 (a jumper across the 5,4 pair).

3) Both 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 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, removing power to its 122.88 MHz osc. The system will be a quieter system overall with this unused oscillator turned off.

4) In my view, although I haven't tried otherwise, both 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 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) 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 my prototype FPGA code for Ozy. Currently, the proposed fix is pending review, cleanup, and approval by Kirk and Phil. They will release a new Ozy code that fixes the second board sync problem 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, I'd be happy to share this early-alpha-stage code with anyone that is interested.