|
|
(3 intermediate revisions by one other user not shown) |
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]] 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!!
| + | |