[hpsdr] USB-protocol 1.27

[Phil Harman]

Hi Joe,

Thanks for your comments.  I'm not quite sure that I understand your concern 
regarding having multiple receivers in one Mercury board but not using them 
all.
As long as the code will fit in the FPGA, and it meets timing requirements, 
then the unused code has no effect. Well I guess the additional, unused 
receivers, will draw more power than a single receiver.

>From the work that I've done on Metis there is a way we can now load 
different code into the FPGA at power on.  By placing a jumper on the Metis 
board we can  either run the Normal or Boot Loader code.  A combined image 
is held in the flash memory on Metis and the jumper really selects the 
starting address to load from.

We could potentially do the same with Mercury, have jumper(s) select one, 
two or three receivers etc. at power on.

The advantage our architecture gives us (e.g. Atlas bus, individual boards 
for each function etc ) is tremendous flexibility. Making changes to 
accommodate new ideas, fix bugs etc is just what we thrive on!

All of the protocols are set in jelly - if folks can see an improvement, or 
want a new feature, then we will do our best to accommodate them. You are 
doing pioneering work with multiple receivers, which we all appreciate,  and 
I trust you don't feel I am inhibiting you in any way.

73 Phil....VK6APH


----- Original Message ----- 
From: "Joe Martin K5SO" <k5so at valornet.com>
To: <hpsdr at lists.openhpsdr.org>
Sent: Tuesday, January 25, 2011 11:28 PM
Subject: Re: [hpsdr] USB-protocol 1.27


> ***** High Performance Software Defined Radio Discussion List *****
>
> 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
>
>
>
>
> _______________________________________________
> HPSDR Discussion List
> To post msg: hpsdr at openhpsdr.org
> Subscription help: 
> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org
> HPSDR web page: http://openhpsdr.org
> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/
>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1202 / Virus Database: 1435/3402 - Release Date: 01/25/11
> 


 1296018015.0