[hpsdr] USB-protocol 1.27

[Joe Martin K5SO]

Hi Alfred,

As I commented to you in an off-reflector message earlier, in the  
present FPGA code there is no distinction made as to whether the  
multiple receivers exist on a single Mercury board or on multiple  
Mercury boards.  This is an issue that I brought to Phil's attention  
recently, also in a private email, .

The short answer to your question is that in my Mercury v6.3 FPGA code  
two receivers are implemented in both receiver boards but only one  
receiver is actually used in each board.  So the interleaved byte data  
stream over the USB port from Ozy (Metis) to the PC consists of

sync, sync, sync, C1, C2, C3, C4, C5, I1c, I1b, I1a, Q1c, Q1b, Q1a,  
I2c, I2b, I2a, Q2c, Q2b, Q2c, mic-b, mica, I1c, I1b, I1a, etc. to fill  
a 512-byte block,

where sync= 0x7f,

C1-C5 are the command and control bytes,

I1c-I1a is the three byte (24-bit) I value from the first receiver on  
Mercury 1,

Q1c-Q1a is the three-byte Q value from the first receiver on Mercury 1,

I2c-I2a is the three-byte (24-bit) I value from the first receiver on  
Mercury 2,

Q2c-Q2a is the three byte (24-bit) Q value from the first receiver on  
Mercury 2,

mic-b and mic-a are the two-byte transmit audio (16-bit) value from  
Penelope to the PC.

IQ info from the second receivers on both Mercury boards are not used.

This current situation, of course, is very inefficient in terms of  
FPGA coding in the Mercury boards since the second receiver logic on  
each Mercury board is completely unused.  The situation becomes even  
worse when three receivers are implemented, as I'm presently doing  
with three Mercury boards for three-antenna diversity operation.   
Implementing three receivers with three Mercury boards results in  
coding nine total receivers with two receivers on each Mercury board  
not being used at all.  FYI, I am working on a scheme to remedy this  
current situation but perhaps the expert Verilog coders will address  
the issue formally soon to provide an "official" version that will be  
more acceptable for the community, now that the issue is becoming more  
and more relevant to folks.

In defense of the original coding, the initial Verilog programmers did  
not have multiple Mercury boards to work with and to test with when  
writing the original Verilog code and some of the issues involved are  
quite subtle (e.g., the synchronization of the IQ streams to each  
other, etc) and don't really show up until multiple Mercury boards are  
actually used.  The original code is a fine first effort, to be sure,  
even though it contains some unforeseen problems.  The existing  
Verilog code is an amazing effort with respect to implementing  
multiple receivers,  in my view, and I greatly appreciate the work  
done by them!   Their next iteration will be even better, I'm sure.

73,  Joe K5SO





 1295969294.0