|
|
| (6 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!!
| + | |
| − | | + | |
| − | Hope this info helps!
| + | |
| − | | + | |
| − | Joe K5SO
| + | |
