Re: [Discuss-gnuradio] transmitter receiving its own packet

[Josh Blum]

On 04/09/2013 02:14 PM, M. Ranganathan wrote:
> This seems like a common scenario and it seems like it would make sense to
> push the behaviour as low as possible in the stack. Is there a
> configuration parameter for the USRP "device driver" that instructs the
> driver to drop self routed signals?
> 

So it would be possible to mute the ADC samples when the device is
transmitting. However, that might only be desirable in a couple of use
cases, and there are probably a dozen ways to solve this from all the
way down at the physical layer up the the MAC layer:

* mute the RX ADC when transmitting (probably an FPGA mod)
* tune RX and TX two different center frequencies
* mute the samples going into the demodulator block when transmitting
* use the issue_stream_command api to avoid receiving when transmitting
* use a different preamble on the packets so you cant correlate yourself
* use an identifier in the header of the packet to differentiate nodes

I believe precog addresses this issue by using the last option. Your MAC
layer has to be able to identify what a packet is and who it is destined
to after all: https://github.com/jmalsbury/pre-cog/wiki

-josh

> 
> On Tue, Apr 9, 2013 at 2:50 PM, Marcus D. Leech <address@hidden> wrote:
> 
>> **
>>
>>  Thanks Marcus for the explanation. Yes, we take care****
>>
>> of attenuating the signal along the RF-cable.****
>>
>> ** **
>>
>> Can you explain bit more****
>>
>> “So the best approach is to simply set a bit in your application for your
>>   RX chain to simply ignore the RX samples while you're transmitting”.****
>>
>> ** **
>>
>> can this be done in the python layer or do I have to touch the c++****
>>
>> layer? I am using ofdm as the physical layer (ofdm.py etc.).****
>>
>> ** **
>>
>> Sorry, if all this sounds incoherent; I am still a newbee in this****
>>
>> field.****
>>
>> ** **
>>
>> thanks and regards****
>>
>> ** **
>>
>> --Anirudh Sahoo****
>>
>> Advanced Network Technology Div.****
>>
>> National Institute of Standards and Technology (NIST)****
>>
>> 100 Bureau Drive,****
>>
>> Gaithersburg, MD - 20878****
>>
>> Room – B230, bldg.- 222****
>>
>> Phone- 301-975-4439****
>>
>> Well, assuming you have  TX thread and an RX thread, you can signal to the
>> RX thread, via a shared variable, or some such,
>>    that TX is currently in progress, and to please ignore any samples for
>> a while, or some such thing.
>>
>> I'll make the general comment that nobody can be really successful in SDR,
>> if the 'S' part of it is a bit of a mystery to them.
>>    Real-world signal-processing solutions require things beyond the
>> strictly-mathematical treatments of DSP you find in textbooks.
>>    In real systems, you need to implement algorithms that aren't
>> strictly-mathematical in nature, and require some non-trivial
>>    understanding of familiar topics in  CS and computer-programming
>> concepts.
>>
>>
>>
>>
>> --
>> Marcus Leech
>> Principal Investigator
>> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
> 
> 
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>