Difference between revisions of "Multi-Reciever"

From HPSDRwiki
Jump to: navigation, search
(Two Mercury boards)
(Redirecting to Multi-Receiver)
 
Line 1: Line 1:
===Multi-Receiver Options===
+
#redirect [[Multi-Receiver]]
 
+
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]] 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 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 for a solution.
+

Latest revision as of 10:59, 11 April 2011

Redirect to: