[hpsdr] Metis functionality

[Jeremy McDermond]

On May 17, 2011, at 7:02 AM, Alberto I2PHD wrote:

> ***** High Performance Software Defined Radio Discussion List *****
> 
> On 5/17/2011 2:52 PM, Lyle Johnson wrote:
>> I think the whole point here is that this is OPEN source project, 
>> including in many cases the hardware design.  Certainly including the 
>> FPGA code which intentionally uses no-cost development tools.
>> 
>> Please modify it to suit your needs and share the results with others.
>> 
>> It's all about learning and sharing, as many have done.
>> 
>> Don't wait for Phil or Bill or John or ...
>> 
>> 
> Lyle,
> 
>    yes, I am fully aware of this, I just expressed my desires together with the regret of not knowing enough
> of FPGA programming to do that myself.... 
> My message was mainly meant to give a possible input to those fluent in FPGA coding... it wasn't a request to
> you or Phil or Bill or John or...    to implement that.
> 
> My new SDR program (still many months away) could take advantage of such a possibility. The code in Winrad 
> is already capable of storing on disk an I/Q stream of a few MB/sec, and to playback/filter/demodulate it 
> without stuttering, and that code will be used in the new program. What is missing is just that I/Q stream....   :-) 

I think it's definitely a case of "it's coming eventually."  The thing about how things are right now is it's really an evolutionary thing.  The sample rates essentially came from the common sound card rates that were available and allowed us to construct computer software that would be relatively simple to adapt from things we already knew worked.  This is one of the reasons why the Metis on-net format is really just two Ozy packets in a wrapper.  I expect as the hardware is verified and we get working setups people will start adapting things to be more flexible on sample rates and bandwidths.  To a certain extent we're still trying to figure out how Metis should work on basic things like IP addressing and such.

In the meantime it might not be that hard to add an additional sample rate to the FPGA code.  I haven't looked at it and even if I did I probably wouldn't understand it, but in theory it's just some settings in how far you decimate and what the bandwidth of the FIR is.  There's room for one more "speed" bit in C1 of the command/control header and you could maintain compatibility by using this and assigning it to some suitably large sample rate/bandwidth.

It's on my ever-growing list of things to do to see if I can wrap my head around FPGA programming, but that's not something that's going to be coming in the near future.  There are a lot of things on my plate with Heterodyne.

> -- 
> 73 Alberto I2PHD

--
Jeremy McDermond (NH6Z)
Xenotropic Systems
mcdermj at xenotropic.com




 1305641796.0