Difference between revisions of "Multi-Receiver"

From HPSDRwiki
Jump to: navigation, search
(Multiple Mercury boards)
(Multiple Mercury boards)
 
(156 intermediate revisions by 4 users not shown)
Line 1: Line 1:
===Multi-Receiver Options===
+
[[Image:dualmercury.jpg|thumb|400px|Example of the connection points on the mercury board (Click for a larger image)]]
 
+
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.
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==
 
==Stand-Alone==
Line 11: Line 10:
 
==Multiple Receivers on a single Mercury==
 
==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 supported by current versions of OpenHPSDR PowerSDR on Windows, cuSDR on Windows and Linux, KISS Konsole on Windows, and ghpsdr3 on Linux.
 
+
This option is only supported by the Ozy 1.8 and Mercury 3.0 verilog code.
+
  
 
==Multiple Mercury boards==
 
==Multiple Mercury boards==
  
This option is supported by [[KISS Konsole versions >1.0.6]] on Windows and [[ghpsdr3]] on Linux and (Windows under development).  
+
(Last updated 13FEB2014)
 +
 +
This option is supported by current versions of OpenHPSDR PowerSDR and cuSDR.  
  
Multiple Mercury board operations are supported by Ozy v1.8 and later and by Mercury v3.0 and greater Verilog codeNote, however, that Ozy v1.8 does NOT sync the second Mercury board data stream properly so a new version that does is currently under development. K5S0 is successfully using a prototype version of Ozy that does sync the second board data stream properly and he will readily share his prototype version with any interested party until a new Ozy version can be released. 
+
'''Dual Mercury board setups (Windows):''' 
 +
Diversity operation using two Mercury receiver boards is implemented in Open HPSDR PowerSDRPolarization diversity or spatial diversity are possible, depending upon what inputs are provided to the two Mercury boards.
  
----
+
==Required Hardware Configurations To Use Multiple Mercury Boards==
  
The following is from a list post by Joe Martin K5SO.
+
(last updated 13FEB2014)
  
There are things that need to be done in hardware to implement two Mercury boards.
+
Each Mercury board must have jumpers in place to specify a unique address for the board and a jumper in place to specify that the board is being used simultaneously with other Mercury boards. 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:
 
+
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:
 
GPIO pairs:
Line 44: Line 33:
 
7,6 = Mercury ID bit 1,
 
7,6 = Mercury ID bit 1,
  
5,4 = Mercury ID bit 0,
+
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
+
3,2 = MULTIPLE_MERC
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.
+
  
  
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).
+
All Mercury boards used in multiple-Mercury-board operations must have the MULTIPLE_MERC jumper (GPIO 3,2) in place.
  
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 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.  Photos of Mercury boards addressed for logical 0 (Merc1) and logical 1 (Merc2) are shown on the K5SO download site referenced above.
  
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.
+
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).
  
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.
+
==See also==
 +
* [[Multiple independent receivers - how to set up on Windows]] - not the same as above, but related.
  
----
+
[[Category:Hardware]]
[[Category:Configuration]]
+

Latest revision as of 13:43, 13 February 2014

Example of the connection points on the mercury board (Click for a larger image)

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 option is supported by current versions of OpenHPSDR PowerSDR on Windows, cuSDR on Windows and Linux, KISS Konsole on Windows, and ghpsdr3 on Linux.

Multiple Mercury boards

(Last updated 13FEB2014)

This option is supported by current versions of OpenHPSDR PowerSDR and cuSDR.

Dual Mercury board setups (Windows): Diversity operation using two Mercury receiver boards is implemented in Open HPSDR PowerSDR. Polarization diversity or spatial diversity are possible, depending upon what inputs are provided to the two Mercury boards.

Required Hardware Configurations To Use Multiple Mercury Boards

(last updated 13FEB2014)

Each Mercury board must have jumpers in place to specify a unique address for the board and a jumper in place to specify that the board is being used simultaneously with other Mercury boards. 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 = MULTIPLE_MERC


All Mercury boards used in multiple-Mercury-board operations must have the MULTIPLE_MERC jumper (GPIO 3,2) in place.

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. Photos of Mercury boards addressed for logical 0 (Merc1) and logical 1 (Merc2) are shown on the K5SO download site referenced above.

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

See also