Difference between revisions of "Multi-Reciever"

From HPSDRwiki
Jump to: navigation, search
(Multi-Receiver Options)
(Multiple Receivers on a single Mercury)
Line 9: Line 9:
 
==Multiple Receivers on a single Mercury==
 
==Multiple Receivers on a single Mercury==
  
This options is supported by Kiss Konsole and ghpsdr3.
+
This options is supported by [[KISS Konsole]] and [[ghpsdr3]].
  
 
This option is only supported by the Ozy 1.8 and Mercury 3.0 verilog code.
 
This option is only supported by the Ozy 1.8 and Mercury 3.0 verilog code.

Revision as of 14:40, 27 July 2010

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

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