Difference between revisions of "Multi-Receiver"

Revision as of 14:11, 6 October 2010

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

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 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 options is supported by KISS Konsole on Windows and ghpsdr3 on Linux and (Windows under development).

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 most recently by a modified test version of PowerSDR v1.19.3.1 on Windows, called PowerSDR v1.19.3.1.diversity9 (K5SO 5OCT2010), that simultaneously supports the multiple receivers option mentioned above and dual Mercury boards (HPSDR downloads page at http://k5so.com).

"Multiple Mercury boards" is supported by Ozy v1.8 and later and by Mercury v3.0 and later FPGA/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. K5S0 is successfully using a test version of Ozy FPGA code that does sync the second Mercury board data stream. The test version is available at the website of K5SO mentioned above as a temporary solution until a new Ozy version can be released.

For dual Mercury boards on Atlas it is necessary to use Mercury v3.0 or later in the Mercury FPGAs. Mercury v3.0 code is compatible with the current versions of Bill KD5TFD's (7May2010) PowerSDR v1.10.4, KISS Konsole, and PowerSDR v1.19.3.1 therefore it is not necessary to reload the FPGAs in the Mercury boards when switching between these programs and PowerSDR v1.19.3.1.diversity9. Simply power cycling the HPSDR board set (or alternatively, re-running initozy11.bat without power cycling) is all that is necessary to be able to switch between the programs.

Also, the second Mercury board can remain on the Atlas bus while running the other programs with no ill effects; the second Mercury board is simply ignored by the other programs.

REQUIRED HARDWARE CONFIGURATIONS TO USE MULTIPLE MERCURY BOARDS:

Each Mercury board must have jumpers in place to specify an address for the board. 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 = 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, board-specific 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 Atlas bus lines as is the case when there is no jumper across GPIO pins 3-2.

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

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

3) Connecting the 122.88MHz clocks on Mercury (photos at http://k5so.com/Clock%20connections.html):

3a) place a jumper on the CLKSEL "I" pins (lower two pins of the three CLKSEL pins) on each of the Mercury boards,

3b) place a jumper on JP9 (enabling the 122.88MHz oscillator) on each Mercury board

3c) place a jumper from the Atlas C16 pin to J8 (Aux Clk input) pin nearest the FPGA

3d) in PowerSDR, select Setup>Excalibur, then on the Mercury boards

Now both Mercury board 122.88 MHz oscillators will be phased locked to the 10MHz clock on Atlas C16 coming from Excalibur (or whatever external 10 MHz source you use). No jumpers between the Mercury boards is necessary in this configuration.

4) 10 MHz clock on Mercury: The 10MHz clock for the Mercury boards should be taken from Excalibur (or whatever external 10MHz source you use) via the Atlas C16 pin, with Mercury jumpered as noted in 3d above.

COMMENTS ON PowerSDR v1.19.3.1.diversity9 (K5SO 5OCT2010)

The program has inherited some known bugs from PowerSDR v1.19.3.1 including:

- KNOWN BUG: Should you exit the program while in FULL SCREEN mode you will be "trapped" in full screen mode thereafter when trying to run the program. To recover from this condition you must replace the database.xml file in your C:\Documents and Settings\<your user name>\Application Data\FlexRadio Systems\PowerSDR v1.19.3 folder with the database.xml file provided in this distribution package. To avoid this condition for the time being do not exit the program when in FULL SCREEN display mode, return to NORMAL view first then exit the program.

- KNOWN BUG: When in FULL SCREEN display mode the Pan control is stretched horizontally and if the control is set beyond mid range the slider will not be visible when returning to NORMAL screen display.

-KNOWN BUG: The band edge position (upper band edge marker anyway) does not appear on the panadapter display when the "Zoom" control scale is set to "0.5x".