View source for Multi-Reciever

===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.

==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 and ghpsdr3.

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 Mercury_ID =  
0, one of the Mercury boards needs this configuration to specify which  
Atlas bus line the communication will occur.

3) An additional jumper on GPIO pair 5,4 makes the board Mercury_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 (~1hr) than if NR=2 (~3minutes)!

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.

HOWEVER, I have recently discovered that the current FPGA code does  
not implement any kind of synchronization of the serial data stream  
from the second Mercury board, at the present time at least, so the  
insertion point is currently random (with respect to power up and data  
rate selection changes) for the data stream from the second Mercury.   
This causes havoc on the PC side, of course.  That's a problem that  
has been brought to Kirk's attention and is currently being reviewed  
by Kirk (as the heavyweight Verilog coder, and me as a lightweight  
helper, hihi) for a solution.

Fear not, this is simply a temporary glitch that won't last long.   
It'll get fixed shortly.  Or, of course, if you want to do some  
Verilog coding you're more than welcome to join in to help resolve  
this little issue!!