[Discuss-gnuradio] Re: more inband channels

[George Nychis]

Hi Sanmi,

I'm going to CC this to the list.  Maybe someone else has some ideas.

When you say "meant to be transmitted on both channels" ... the simple 
fix for this would be to transfer it over the USB once, and feed it to 
both TX chains.

But, let me assume for a second that you mean two long packets that differ.

This is an overall architecture problem.  Think about how packets are
passed along.  There is one packet per m-block message, and then this
gets broken down into multiple USB blocks.  A block only processes 1
message at a time, so it can never infer that another long packet is
coming after it.... unless it wants to try and look in its queue which I 
don't think is the best idea.

To accomplish what you would want, you would need to change the way the 
messages are passed between the blocks so that multiple sets of data 
could be passed.  Then, usrp_server would need to interleave this data 
into a single series of USB packets with interleaved samples.  Then, the 
FPGA would need to un-interleave and go back and forth between channel 0 
and 1.  I think this is what the legacy code does?

This would also require a meta-data change per USB block that specifies 
have many samples are destined for channel 0 and how many are destined 
to channel 1... unless you want the restriction that they must be of 
equal length.  If the data is of equal length, you just need a flag in 
the USB block that says if its interleaved.

It's open source... I can't stop you from catering the in-band code to 
your MIMO needs... but there's no way you can get me to change it :)

But, maybe someone else has some cute ideas.

- George


sanmi wrote:
> Hi George,
>
>  
>
> I am not sure whether this is a question for the list or for you. Feel 
> free to refer me if needed.
>
>  
>
> I understand that all the inband code is all stream/channel addressed 
> for TX/RX i.e. no interpolation is done and you can call read/write with 
> a target channel.
>
>  
>
> We were discussing this today and we see some possible issues with this 
> scheme. We would also like more feedback/discussion.
>
>  
>
> For instance, if a really long packet is transmitted, and meant to be 
> transmitted on both channels simultaneously, buffer issues on the FPGA 
> will prevent channel 2 from receiving its packets using the current 
> scheme as the FPGA would have to wait for the buffer to clear before 
> receiving the proportionately long packet for channel 2.
>
>  
>
> On the RX size, it looks like the channel command means that data would 
> have to be aligned by the receiver code using RX timestamps especially 
> if packets from both channels don’t arrive at similar times (due to the 
> message structure and multi-thread processing on the host for instance). 
> This is not an issue with legacy code because of interleaving.
>
>  
>
> Any feedback?
>
>  
>
> Thanks,
>
> -Sanmi
>
>