Multi-Receiver

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.

Two Mercury boards

This options is supported by KISS Konsole on Windows and ghpsdr3 on Linux and (Windows under development).

---

The following is from a list post by Joe Martin K5SO.

There are things that need to be done in hardware to implement two Mercury boards.

1) A jumper on GPIO pair 3,2 (Channels_8_1) on J5 needs to be placed on both Mercury boards to specify that the board will use only one Atlas bus line for communication with Ozy (not eight bus lines).

2) No additional jumpers on J5 makes the board logically Merc_ID = 0, one of the Mercury boards needs this configuration to specify which Atlas bus line the communication will occur.

John Melton has described the J5 Mercury board addressing scheme in the following way: "To use multiple Mercury cards the following GPIO are used

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

without the jumper the logic value for the pair is 0, with the jumper on it will be 1

Therefore, for multiple cards, the 3,2 GPIO jumper pair should be on both Mercury cards, the first Mercury card set for ID = 000 (no jumpers) and the 2nd Mercury card set for ID = 001 which means a jumper needs to be on the 5,4 pair.

Looking at the Mercury card, the bottom pair of pins (nearest F1) on J5 are GPIO pairs 1,0."

3) An additional jumper on GPIO pair 5,4 makes the board Merc_ID = 1, the second Mercury board needs this configuration to specify that it will use a different Atlas bus line from the first board for its communication with Ozy.

4) 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, I remove the jumper on JP9 on the slave Mercury board, removing power to its 122.88 MHz osc. This is probably not necessary but it will be a quieter system overall with this unused oscillator turned off so I did it.

5) 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.

6) 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)!

7) 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. The fix involved a change in the Ozy FPGA code, which is pending review, cleanup, and approval by Kirk and Phil.

---