[Discuss-gnuradio] I can't find my USRP N200.

[안병재]

Hi,
 
I am using USRP N200 with Ubuntu 12.04. This is my first experience for
USRP.
I installed GNU Radio and UHD according to

http://www.sbrac.org/files/build-gnuradio.
In the first try, I couldn’t find my USRP. But I could find it only when I
power on it while pressing button S2 in the USRP.
I always can’t find my USRP when I power on while not pressing button S2.
 
What kind of problems does my USRP have ?
 
Best regards,
Bejay
 
 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] if uhd_transmitter instantiated after receiver, TX works, otherwise RX works

[King Qiu]

hi George,
I noticed theses odd things several months ago. I am using USRP2s with
XCVR2450. Since my UHD was upgraded to 003.004.000 or newer version, my
USRP2s can't work in half duplex mode. When uhd_transmitter is
instantiated later than uhd_receiver, tx works well but rx can't receive
packets. When uhd_receiver is instantiated later than uhd_transmitter,
rx could receive packets, but tx works with abnormal spectrum.

Now I have to use an old version (003.003.002) UHD. With this version,
both tx and rx work well. So I doubt that there is a bug in version
003.004.xxx. Maybe Ettus can help us fix it.
King Qiu



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] I can't find my USRP N200.

[Nick Foster]

Bejay,

Try this documentation:

http://files.ettus.com/uhd_docs/manual/html/usrp2.html#setup-networking

In particular, make sure you have set the N200 to an IP address and netmask
from which your computer can find it. You can use the "usrp2_recovery.py"
script included with UHD to reset the N200 to 192.168.10.2 if you forget
the IP address it was set to. The N200 will always come up on 192.168.10.2
when it is booted into "safe mode" using S2.

--n

On Mon, Jun 18, 2012 at 2:28 AM, Bejay Ahn(안병재) wrote:

> Hi,
>
> ** **
>
> I am using USRP N200 with Ubuntu 12.04. This is my first experience for
> USRP.
>
> I installed GNU Radio and UHD according to *
> http://www.sbrac.org/files/build-gnuradio*
> .
>
> In the first try, I couldn’t find my USRP. But I could find it only when I
> power on it while pressing button S2 in the USRP.
>
> I always can’t find my USRP when I power on while not pressing button S2.*
> ***
>
> ** **
>
> What kind of problems does my USRP have ?
>
> ** **
>
> Best regards,
>
> Bejay
>
> ** **
>
> ** **
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] if uhd_transmitter instantiated after receiver, TX works, otherwise RX works

[Josh Blum]

On 06/18/2012 05:21 AM, King Qiu wrote:
> hi George,
> I noticed theses odd things several months ago. I am using USRP2s with
> XCVR2450. Since my UHD was upgraded to 003.004.000 or newer version, my
> USRP2s can't work in half duplex mode. When uhd_transmitter is
> instantiated later than uhd_receiver, tx works well but rx can't receive
> packets. When uhd_receiver is instantiated later than uhd_transmitter,
> rx could receive packets, but tx works with abnormal spectrum.
> 
> Now I have to use an old version (003.003.002) UHD. With this version,
> both tx and rx work well. So I doubt that there is a bug in version
> 003.004.xxx. Maybe Ettus can help us fix it.
> King Qiu
> 
> 
> 

Thanks for the tip. I think I figured it out.

The property to use an LO offset was true for TX and not RX. This would
mean that tuning an individual chain and using it would be fine; but
since there is a shared LO, the offset would not be compensated for by
the DSP on the chain in the other direction, hence, it not working.

If you dont mind trying, here is a simple 1 liner patch:
http://pastebin.com/KiR3e6j0

-josh

> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Large Sample Spikes after Each Packet in tx_bursts Example

[Jason Tran]

Hi All,

"If you are seeing transients at the beginning of a burst, thats probablythe 
half band filters. They are implemented in block ram and dont clear
between bursts."

I'm actually sending one burst of a very long length so I can emulate an 
always-on signal (i.e. I'm not letting tx_bursts actually send an EOB packet). 
However, I still get the large samples with suppressed samples around.  The 
number of samples between every large sample (363) is directly equal to the 
samples per buffer size. i.e. the size of buffs used when invoking 
tx_stream->send(buffs, samps_to_send, md, timeout);

Regards,
Jason





 From: Josh Blum 
To: discuss-gnuradio@gnu.org 
Sent: Thursday, June 14, 2012 7:57 PM
Subject: Re: [Discuss-gnuradio] Large Sample Spikes after Each Packet in 
tx_bursts Example
 

> You can see the magnitude hovers over 30 which is good (noise hovers
> around 5). But, as you can see, there are two spikes with suppressed
> samples around it. These are exactly spaced 363 samples apart (this
> changes as I change the samples per buffer at the transmitter). Does
> anyone have an idea where this is coming from? I'm running out of
> ideas of where to look to figure out the problem. Any ideas of what I
> can do to remove it (even manually)?
> 
> Regards, Jason T.
> 

If you are seeing transients at the beginning of a burst, thats probably
the half band filters. They are implemented in block ram and dont clear
between bursts.

On the other hand, if they are at the end, it might actually be that
mini EOB packet. Its supposed to be a zero length packet but its
actually sending a single sample (value zero). If this is the case, you
might try setting EOB on the last packet actually with sample data.

-josh

> 
> 
> 
> ___ Discuss-gnuradio
> mailing list Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] if uhd_transmitter instantiated after receiver, TX works, otherwise RX works

[Josh Blum]

> Thanks for the tip. I think I figured it out.
> 
> The property to use an LO offset was true for TX and not RX. This would
> mean that tuning an individual chain and using it would be fine; but
> since there is a shared LO, the offset would not be compensated for by
> the DSP on the chain in the other direction, hence, it not working.
> 
> If you dont mind trying, here is a simple 1 liner patch:
> http://pastebin.com/KiR3e6j0
> 

Another quick way to test this without the patch would be to tell the
tune request to use an LO offset of 0. Example:

usrp_source/sink.set_center_frequency(uhd.tune_request(my_freq, 0))

-josh

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Large Sample Spikes after Each Packet in tx_bursts Example

[Josh Blum]

On 06/18/2012 10:51 AM, Jason Tran wrote:
> Hi All,
> 
> "If you are seeing transients at the beginning of a burst, thats
> probablythe half band filters. They are implemented in block ram and
> dont clear between bursts."
> 
> I'm actually sending one burst of a very long length so I can emulate
> an always-on signal (i.e. I'm not letting tx_bursts actually send an
> EOB packet). However, I still get the large samples with suppressed
> samples around.  The number of samples between every large sample
> (363) is directly equal to the samples per buffer size. i.e. the size
> of buffs used when invoking tx_stream->send(buffs, samps_to_send, md,
> timeout);
> 

Sounds like you made some modifications to the example: Maybe you are
seeing the result of an underflow, or the buffer isnt filled for all
nsamps, or something during the checking for burst ack code...?

Perhaps the tx_waveforms example will be a better demonstration of
continuous streaming for you.

Also, this is the gnuradio mailing list, so I am going to recommend the
gnuradio companion as a great way to get started w/ the hardware and get
a good feeling for its operation:
http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion

-josh

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] if uhd_transmitter instantiated after receiver, TX works, otherwise RX works

[George Nychis]

Hi Josh,

Thanks a bunch for these pointers/patches and looking in to it!  We are
currently testing them out, shouldn't take long.  However, we did verify
that reverting to the older version (003.003.002) did work for us as it did
for King (thanks!).

Stay tuned... we'll let you know ASAP.

- George


On Mon, Jun 18, 2012 at 1:51 PM, Josh Blum  wrote:

>
> > Thanks for the tip. I think I figured it out.
> >
> > The property to use an LO offset was true for TX and not RX. This would
> > mean that tuning an individual chain and using it would be fine; but
> > since there is a shared LO, the offset would not be compensated for by
> > the DSP on the chain in the other direction, hence, it not working.
> >
> > If you dont mind trying, here is a simple 1 liner patch:
> > http://pastebin.com/KiR3e6j0
> >
>
> Another quick way to test this without the patch would be to tell the
> tune request to use an LO offset of 0. Example:
>
> usrp_source/sink.set_center_frequency(uhd.tune_request(my_freq, 0))
>
> -josh
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Announcing the LiveUSB SDR Environment

[Matt Ettus]

Ettus Research has released the LiveUSB SDR Environment - a 16 GB
bootable USB 3.0 drive, which comes pre-installed with Ubuntu 11.10,
UHD (USRP Hardware Driver), GNU Radio, OpenBTS, and associated
documentation. The SDR Environment enables users to get up and running
with the USRP product family quickly and easily, and lets users
familiarize themselves with the included software before installing it
on their own.   Additionally, the portability of the LiveUSB file
system can be used to deploy standard configurations in classrooms,
R&D labs, or other USRP installations.

Features:
* Ubuntu 11.10, 64-bit
* Pre-installed Software: USRP Hardware Driver (UHD), GNU Radio, OpenBTS
* Documentation Included on Drive
* 16 GB
* USB 3.0 Read/Write Speeds - fast boot times and RF record/playback capability
* USB 2.0 Fallback
* Persistent File system - save files, configurations, and other customizations
* Portability - take your projects with you and boot on any PC

The LiveUSB includes the most recent release of UHD, GNU Radio, and
OpenBTS.  UHD is compatible with all USRP devices, and allows
applications to be easily ported across different USRP models.  The
UHD installation includes documentation and examples.  GNU Radio is an
easy-to-use, open-source, DSP toolbox that comes with GNU Radio
Companion, a graphical development tool.  OpenBTS is an open-source
GSM air-interface implementation, which can be used with the USRP
product family to assemble a fully functional cellular base station.

The LiveUSB Ubuntu OS is pre-configured to install UHD and GNU Radio
from the Ettus Research 'apt' repositories.  This allows users to
update the software without manually downloading, building, and
installing the source code.

This drive is compatible with USB 2.0 ports, but the system will take
longer to boot, load programs, and respond to user interaction.

Now, developing with the USRP product family is as easy as plugging in
the LiveUSB SDR Environment and booting up!


Matt Ettus

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] tunnel.py destination host unreachable

[Alex Zhang]

Weixian,

Here is a temp solution, not sure it works or not:

In the csma_mac.main_loop() of your tunnel.py, add a
time_sleep(fixed_delay) right after the payload is read from the OS. You
can set fixed_delay as 0.01 to 0.1 and test the result.

And also, please set the CSMA threshold carefully to avoid
possible collision.

Alex

On Mon, Jun 18, 2012 at 10:10 AM, Weixian Zhou  wrote:

> The following is the messages of the transmitter after I ping. The
> packages of len(payload)=42 failed CRC check, but other packages succeed.
> *URx: ok = True  len(payload) =  101*
> *Tx: len(payload) =   90*
> *Tx: len(payload) =   54*
> *UTx: len(payload) =  220*
> *UTx: len(payload) =  326*
> *URx: ok = False  len(payload) =  326*
> *Tx: len(payload) =   81*
>  *UTx: len(payload) =  326*
> *UTx: len(payload) =  326*
> *UTx: len(payload) =  302*
> *URx: ok = False  len(payload) =  302*
> *Tx: len(payload) =   78*
> *UTx: len(payload) =  220*
> *URx: ok = False  len(payload) =  220*
> *Tx: len(payload) =   81*
> *UTx: len(payload) =  302*
> *URx: ok = False  len(payload) =  302*
> *Tx: len(payload) =   70*
> *UTx: len(payload) =  110*
> *UTx: len(payload) =  240*
> *URx: ok = False  len(payload) =  240*
> *Tx: len(payload) =  404*
>  *Tx: len(payload) =  201*
> *UTx: len(payload) =  101*
> *UTx: len(payload) =  404*
> *Tx: len(payload) =  201*
> *Tx: len(payload) =   54*
> *UTx: len(payload) =  404*
> *Tx: len(payload) =  201*
> *Tx: len(payload) =  114*
> *UTx: len(payload) =  380*
> *Tx: len(payload) =  189*
> *Rx: ok = False  len(payload) =  380*
> *UTx: len(payload) =  240*
> *UTx: len(payload) =  101*
> *UTx: len(payload) =  318*
> *UTx: len(payload) =   81*
> *UTx: len(payload) =  380*
> *Tx: len(payload) =  189*
> *Rx: ok = False  len(payload) =  380*
> *URx: ok = False  len(payload) =  189*
> *Tx: len(payload) =  302*
> *UTx: len(payload) =   90*
> *UTx: len(payload) =  350*
> *UTx: len(payload) =  101*
> *UTx: len(payload) =  380*
> *Tx: len(payload) =  189*
> *Rx: ok = False  len(payload) =  380*
> *UTx: len(payload) =   70*
>  *UTx: len(payload) =   81*
> *UTx: len(payload) =  101*
> *UTx: len(payload) =   70*
> *UTx: len(payload) =   42*
> *UTx: len(payload) =   42*
> *UTx: len(payload) =   42*
> *URx: ok = True  len(payload) =   81*
> *Tx: len(payload) =   42*
> *UTx: len(payload) =   42*
> *URx: ok = True  len(payload) =  101*
> *Tx: len(payload) =   42*
> *UTx: len(payload) =   81*
> *UTx: len(payload) =   42*
> *URx: ok = False  len(payload) =   42*
> *Tx: len(payload) =  101*
> *UTx: len(payload) =   42*
> *URx: ok = False  len(payload) =   42*
> *Tx: len(payload) =   42*
> *URx: ok = False  len(payload) =   42*
> *Tx: len(payload) =   42*
> *URx: ok = False  len(payload) =   42*
> *Tx: len(payload) =   42*
> *URx: ok = False  len(payload) =   42*
> *Tx: len(payload) =   42*
> *UTx: len(payload) =   42*
> *URx: ok = False  len(payload) =   42*
> *Tx: len(payload) =   42*
> *UTx: len(payload) =   42*
> *UTx: len(payload) =   42*
> *URx: ok = False  len(payload) =   42*
> *Tx: len(payload) =   42*
>  *UTx: len(payload) =   42*
> *UTx: len(payload) =   42*
> *UTx: len(payload) =   42*
> *URx: ok = False  len(payload) =   42*
> *Tx: len(payload) =   42*
> *URx: ok = False  len(payload) =   42*
> *Tx: len(payload) =   81*
> *UTx: len(payload) =  101*
> *URx: ok = True  len(payload) =   81*
> *Rx: ok = True  len(payload) =  101*
>
>
> On Mon, Jun 18, 2012 at 11:01 AM, Weixian Zhou  wrote:
>
>> Hi Alex,
>> After tried many times I found that the transmitter actually received
>> packages of len(payload)=42 from the receiver, but the the packages failed
>> CRC check (ok=false). I think some parameters need to be tuned, maybe
>> bitrate?
>>
>> On Mon, Jun 18, 2012 at 10:21 AM, Weixian Zhou  wrote:
>>
>>> Hi Alex,
>>> I tried it. The problem is the same. The transmitter only showed tx
>>> message of len(payload) = 42, and the receiver showed both tx/rx messages
>>> of len(payload) = 42.
>>>
>>>
>>> On Fri, Jun 15, 2012 at 6:43 PM, Alex Zhang wrote:
>>>
 Weixian,

 Could you please try the ping command like this (if you are working on
 linux):

 *sudo ping 192.168.200.2 -i 0.01*

 -i 0.01 means the time interval between pings is 0.01 second. And tell
 me what happened.
 You can try different time intervals.


 On Fri, Jun 15, 2012 at 5:37 PM, Alex Zhang wrote:

> I did the test by myself, and the most of the time ARP queries
> failed I met this problem when I do the OFDM link test, but that is
> because the physical layer is not robust. But for this narrow band (GMSK)
> modulation, I am not sure what the problem is.
>
> May Josh knows... :)
>
>
> On Fri, Jun 15, 2012 at 3:05 PM, Alex Zhang 
> wrote:
>
>> Something like discarded.
>>
>>
>> On Fri, Jun 15, 2012 at 11:59 AM, Weixian Zhou wrote:
>>
>>> What do you mean by "it may be consumed"?
>>>
>>>
>>> On Fri, Jun 15, 2012 at 12:4

Re: [Discuss-gnuradio] gr-trellis convolutional coder FSM

[Clemens Hopfer]

Hello Achilleas,

thanks for your reply,

On Tuesday 12 June 2012 19:53:10 Achilleas Anastasopoulos wrote:
> puncturing is not part of the FSM class.

ok, thanks for the clarification, that caused the biggest confusion.

> You can implement it as a simple memoryless device:
> eg, if i want to puncture every third bit, then the device
> accepts 3bits as inputs and outputs the first two.

Ok, I didn't really like to map each bit to a byte, but the data rate I want 
to use shouldn't be that high to get into performance problems.

> If you can give me more details on what exactly you want to
> implement i may be able to help you out.

I actually want to implement the inner coder used by DVB-S (ETSI EN 300 421, 
4.4.3).
But it's just a hobbyist project, so I'm not in a hurry implementing it.

> Similraly, if you let me know which part of the FSM/trellis documentation
> is hard to read, hopefully i will be able to help.

I'm currently working on my BSc and haven't really done a lot with state 
machines yet, so working with machine alphabets is pretty new for me, but I 
guess I figured it out by now.

Again, thanks for your reply.
I'm pretty busy right now, but in about 2 weeks I'll have enough time to work 
on it again.

Best regards,
Clemens


> 
> Hi,
> 
> I'm working on a modulator using a punctured (non-recursive) convolutional
> coder based on a 1/2 rate mother code with length 7.
> 
> However I find the documentation of gr-trellis pretty hard to read, I don't
> really understand how punctuation should actually be implemented.
> 
> Are there any additional documents or papers on designing the FSM of a
> convolutional coder?
> 
> Thanks,
> Clemens


signature.asc
Description: This is a digitally signed message part.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Basic question about filter

[signalswdm]

Hello everyone:
   You see in theory there should be a low-pass filter after ADC for 
eliminating the image. Also after DDC there should also be a 
filter. But in USRP there are not such things. So do the cic filter and half 
band filter implement that function besides decimation?


Best regards___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Basic question about filter

[Marcus D. Leech]

On 18/06/12 09:46 PM, signalswdm wrote:
> Hello everyone:
> You see in theory there should be a low-pass filter after ADC for
> eliminating the image. Also after DDC there should also be a
> filter. But in USRP there are not such things. So do the cic filter
> and half band filter implement that function besides decimation?
>
> Best regards
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>   
Actually, in typical architectures using I/Q, there are low-pass filters
*in front* of the ADC to eliminate aliasing prior
to sampling. So the CIC decimator "sees" a signal that has already been
band-limited appropriate to the sample
rate of the ADCs.

The CIC decimation process *is* filtering, so out-of-band products
appearing at the output are usually suppressed
by at least 80dB, and usually more.



-- 
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Basic question about filter

[Ian Buckley]

On Jun 18, 2012, at 6:54 PM, Marcus D. Leech wrote:

> On 18/06/12 09:46 PM, signalswdm wrote:
>> 
>> Hello everyone:
>>You see in theory there should be a low-pass filter after ADC for 
>> eliminating the image. Also after DDC there should also be a 
>> filter. But in USRP there are not such things. So do the cic filter and half 
>> band filter implement that function besides decimation?
>> 
>> Best regards
>> 
>> 
>>  
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>   
> Actually, in typical architectures using I/Q, there are low-pass filters *in 
> front* of the ADC to eliminate aliasing prior
>   to sampling.  So the CIC decimator "sees" a signal that has already been 
> band-limited appropriate to the sample
>   rate of the ADCs.
> 
> The CIC decimation process *is* filtering, so out-of-band products appearing 
> at the output are usually suppressed
>   by at least 80dB, and usually more.
> 
> 
> 

Indeed, to re-enforce Marcus's point with precise English terminology:
Downsampling is a process that reduces the sample rate of a digital signal by 
simply discarding samples.
Decimation is the compound operation that incorporates downsampling and an 
appropriate low-pass filter.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] tunnel.py destination host unreachable - Temporarily solution, due to too fast reply!

[Alex Zhang]

Hello Josh,

I have seen many guys complaining the tunnel.py failed in PING by the
"destination host unreachable", for both the OFDM and Narrowband.
This problem is caused by crushed ARP reply. I previously use the static
ARP table to work round this problem, but today I did some investigating
and test, and now I believe the too fast ARP reply from the destination
causes that the transmitter can not receive this reply or receive it with
corrupted packets.

For example, if the usrp A send the ARP request at time T, then usrp B send
back the ARP reply at time T+delta. If the delta is too small, then A will
definitely fails to receive it.

The  temp solution is as below (tunnel.py in csma_mac.main_loop), just add
a small delay for B  to send back the ARP reply. This solution works well.

..**

@@ -185,7 +185,10 @@ def main_loop(self):

185185**

 if not payload:

186186**

 self.tb.send_pkt(eof=True)

187187**

 break

188 **

-

 188**

+

 189**

+time.sleep(0.009) # delay 9ms before sending out the reply

 190**

+t2 = self.tb.source.u.get_time_now().get_real_secs()

 191**

+print 'reply at time ', t

189192**

 if self.verbose:

190193**

 print "Tx: len(payload) = %4d" % (len(payload),)


The root cause for this problem, I guess, should be that the duplex
switching time bwteen the TX and RX at USRP is not small enough. More
details should be about the duplex mechanism of the SBX daughter board. I
hope there are some other way to solve this problem. For example, I tried
to specify the TX and RX at different antennas (TX/RX for transmitter, RX2
for receiver) of the SBX, but unfortunately it seems impossible.

Looking forward to your further comments.

Thanks,

Alex(Changchun) Zhang
Cognitive Radio Institute @ Tennessee Tech Univ.

-- Forwarded message --
From: Alex Zhang 
Date: Mon, Jun 18, 2012 at 4:53 PM
Subject: Re: [Discuss-gnuradio] tunnel.py destination host unreachable
To: Weixian Zhou 
Cc: j...@ettus.com, gnuradio mailing list 


Weixian,

Here is a temp solution, not sure it works or not:

In the csma_mac.main_loop() of your tunnel.py, add a
time_sleep(fixed_delay) right after the payload is read from the OS. You
can set fixed_delay as 0.01 to 0.1 and test the result.

And also, please set the CSMA threshold carefully to avoid
possible collision.

Alex

On Mon, Jun 18, 2012 at 10:10 AM, Weixian Zhou  wrote:

> The following is the messages of the transmitter after I ping. The
> packages of len(payload)=42 failed CRC check, but other packages succeed.
> *URx: ok = True  len(payload) =  101*
> *Tx: len(payload) =   90*
> *Tx: len(payload) =   54*
> *UTx: len(payload) =  220*
> *UTx: len(payload) =  326*
> *URx: ok = False  len(payload) =  326*
> *Tx: len(payload) =   81*
>  *UTx: len(payload) =  326*
> *UTx: len(payload) =  326*
> *UTx: len(payload) =  302*
> *URx: ok = False  len(payload) =  302*
> *Tx: len(payload) =   78*
> *UTx: len(payload) =  220*
> *URx: ok = False  len(payload) =  220*
> *Tx: len(payload) =   81*
> *UTx: len(payload) =  302*
> *URx: ok = False  len(payload) =  302*
> *Tx: len(payload) =   70*
> *UTx: len(payload) =  110*
> *UTx: len(payload) =  240*
> *URx: ok = False  len(payload) =  240*
> *Tx: len(payload) =  404*
>  *Tx: len(payload) =  201*
> *UTx: len(payload) =  101*
> *UTx: len(payload) =  404*
> *Tx: len(payload) =  201*
> *Tx: len(payload) =   54*
> *UTx: len(payload) =  404*
> *Tx: len(payload) =  201*
> *Tx: len(payload) =  114*
> *UTx: len(payload) =  380*
> *Tx: len(payload) =  189*
> *Rx: ok = False  len(payload) =  380*
> *UTx: len(payload) =  240*
> *UTx: len(payload) =  101*
> *UTx: len(payload) =  318*
> *UTx: len(payload) =   81*
> *UTx: len(payload) =  380*
> *Tx: len(payload) =  189*
> *Rx: ok = False  len(payload) =  380*
> *URx: ok = False  len(payload) =  189*
> *Tx: len(payload) =  302*
> *UTx: len(payload) =   90*
> *UTx: len(payload) =  350*
> *UTx: len(payload) =  101*
> *UTx: len(payload) =  380*
> *Tx: len(payload) =  189*
> *Rx: ok = False  len(payload) =  380*
> *UTx: len(payload) =   70*
>  *UTx: len(payload) =   81*
> *UTx: len(payload) =  101*
> *UTx: len(payload) =   70*
> *UTx: len(payload) =   42*
> *UTx: len(payload) =   42*
> *UTx: len(payload) =   42*
> *URx: ok = True  len(payload) =   81*
> *Tx: len(payload) =   42*
> *UTx: len(payload) =   42*
> *URx: ok = True  len(payload) =  101*
> *Tx: len(payload) =   42*
> *UTx: len(payload) =   81*
> *UTx: len(payload) =   42*
> *URx: ok = False  len(payload) =   42*
> *Tx: len(payload) =  101*
> *UTx: len(payload) =   42*
> *URx: ok = False  len(payload) =   42*
> *Tx: len(payload) =   42*
> *URx: ok = False  len(payload) =   42*
> *Tx: len(payload) =   42*
> *URx: ok = False  len(payload) =   42*
> *Tx: len(payload) =   42*
> *URx: ok = False  len(payload) =   42*
> *Tx: len(payload) =   42*
> *UTx: len(payload) =   42*
> *URx: ok = False  len(payload) =   42*
>

Re: [Discuss-gnuradio] Large Sample Spikes after Each Packet in tx_bursts Example

[Jason Tran]

Hi All,

After messing with the code, I think I figured out the problem. I think it's an 
issue of an underflow like Josh suggested.

tx_waveforms works just fine for me when I send a constant signal (the spikes 
disappear). However, when I add some extra lines to the loop that populates 
"buff" and sends it with things such as print statements or more counters, I 
start invoking underflows. After learning this, I cleared out as much overhead 
as I could in the packet sending loop in tx_bursts.cpp and found that the 
signal stabilized without the large sample spikes I posted about earlier. 

Maybe if I try to add high priority to the program, I can reduce underflow 
problems... 

-Jason 



 From: Josh Blum 
To: Jason Tran  
Cc: "discuss-gnuradio@gnu.org"  
Sent: Monday, June 18, 2012 11:57 AM
Subject: Re: [Discuss-gnuradio] Large Sample Spikes after Each Packet in 
tx_bursts Example
 


On 06/18/2012 10:51 AM, Jason Tran wrote:
> Hi All,
> 
> "If you are seeing transients at the beginning of a burst, thats
> probablythe half band filters. They are implemented in block ram and
> dont clear between bursts."
> 
> I'm actually sending one burst of a very long length so I can emulate
> an always-on signal (i.e. I'm not letting tx_bursts actually send an
> EOB packet). However, I still get the large samples with suppressed
> samples around.  The number of samples between every large sample
> (363) is directly equal to the samples per buffer size. i.e. the size
> of buffs used when invoking tx_stream->send(buffs, samps_to_send, md,
> timeout);
> 

Sounds like you made some modifications to the example: Maybe you are
seeing the result of an underflow, or the buffer isnt filled for all
nsamps, or something during the checking for burst ack code...?

Perhaps the tx_waveforms example will be a better demonstration of
continuous streaming for you.

Also, this is the gnuradio mailing list, so I am going to recommend the
gnuradio companion as a great way to get started w/ the hardware and get
a good feeling for its operation:
http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion

-josh___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] tunnel.py destination host unreachable - Temporarily solution, due to too fast reply!

[Jason Tran]

I had a similar problem way back and found collided packets (corrupted packets 
with ok=False). I started digging and found that my gr_probe_mag_sqrd_X was not 
returning a high enough magnitude for the carrier sense to be tripped. This 
also had to do with an issue I was having getting the xcvr2450 to tune to the 
right tx/rx frequencies...

I suggest printing out the result of the magnitude squared to see if this is 
the case as well for you guys.

Regards,
Jason T.



 From: Alex Zhang 
To: j...@ettus.com 
Cc: Tom Rondeau ; gnuradio mailing list 
 
Sent: Monday, June 18, 2012 9:07 PM
Subject: [Discuss-gnuradio] tunnel.py destination host unreachable - 
Temporarily solution, due to too fast reply!
 

Hello Josh,

I have seen many guys complaining the tunnel.py failed in PING by the 
"destination host unreachable", for both the OFDM and Narrowband.
This problem is caused by crushed ARP reply. I previously use the static ARP 
table to work round this problem, but today I did some investigating and test, 
and now I believe the too fast ARP reply from the destination causes that the 
transmitter can not receive this reply or receive it with corrupted packets.

For example, if the usrp A send the ARP request at time T, then usrp B send 
back the ARP reply at time T+delta. If the delta is too small, then A will 
definitely fails to receive it.

The  temp solution is as below (tunnel.py in csma_mac.main_loop), just add a 
small delay for B  to send back the ARP reply. This solution works well.


... ... @@ -185,7 +185,10 @@ def main_loop(self): 
185 185  if not payload: 
186 186  self.tb.send_pkt(eof=True) 
187 187  break 
188   - 
  188 + 
  189 +time.sleep(0.009) # delay 9ms before sending out the reply 
  190 +t2 = self.tb.source.u.get_time_now().get_real_secs() 
  191 +print 'reply at time ', t 
189 192  if self.verbose: 
190 193  print "Tx: len(payload) = %4d" % (len(payload),) 
The root cause for this problem, I guess, should be that the duplex switching 
time bwteen the TX and RX at USRP is not small enough. More details should be 
about the duplex mechanism of the SBX daughter board. I hope there are some 
other way to solve this problem. For example, I tried to specify the TX and RX 
at different antennas (TX/RX for transmitter, RX2 for receiver) of the SBX, 
but unfortunately it seems impossible.

Looking forward to your further comments.
 
Thanks,

Alex(Changchun) Zhang
Cognitive Radio Institute @ Tennessee Tech Univ.


-- Forwarded message --
From: Alex Zhang 
Date: Mon, Jun 18, 2012 at 4:53 PM
Subject: Re: [Discuss-gnuradio] tunnel.py destination host unreachable
To: Weixian Zhou 
Cc: j...@ettus.com, gnuradio mailing list 


Weixian,

Here is a temp solution, not sure it works or not:

In the csma_mac.main_loop() of your tunnel.py, add a time_sleep(fixed_delay) 
right after the payload is read from the OS. You can set fixed_delay as 0.01 to 
0.1 and test the result.

And also, please set the CSMA threshold carefully to avoid possible collision.

Alex


On Mon, Jun 18, 2012 at 10:10 AM, Weixian Zhou  wrote:

The following is the messages of the transmitter after I ping. The packages of 
len(payload)=42 failed CRC check, but other packages succeed.
>URx: ok = True  len(payload) =  101
>Tx: len(payload) =   90
>Tx: len(payload) =   54
>UTx: len(payload) =  220
>UTx: len(payload) =  326
>URx: ok = False  len(payload) =  326
>Tx: len(payload) =   81
>UTx: len(payload) =  326
>UTx: len(payload) =  326
>UTx: len(payload) =  302
>URx: ok = False  len(payload) =  302
>Tx: len(payload) =   78
>UTx: len(payload) =  220
>URx: ok = False  len(payload) =  220
>Tx: len(payload) =   81
>UTx: len(payload) =  302
>URx: ok = False  len(payload) =  302
>Tx: len(payload) =   70
>UTx: len(payload) =  110
>UTx: len(payload) =  240
>URx: ok = False  len(payload) =  240
>Tx: len(payload) =  404
>Tx: len(payload) =  201
>UTx: len(payload) =  101
>UTx: len(payload) =  404
>Tx: len(payload) =  201
>Tx: len(payload) =   54
>UTx: len(payload) =  404
>Tx: len(payload) =  201
>Tx: len(payload) =  114
>UTx: len(payload) =  380
>Tx: len(payload) =  189
>Rx: ok = False  len(payload) =  380
>UTx: len(payload) =  240
>UTx: len(payload) =  101
>UTx: len(payload) =  318
>UTx: len(payload) =   81
>UTx: len(payload) =  380
>Tx: len(payload) =  189
>Rx: ok = False  len(payload) =  380
>URx: ok = False  len(payload) =  189
>Tx: len(payload) =  302
>UTx: len(payload) =   90
>UTx: len(payload) =  350
>UTx: len(payload) =  101
>UTx: len(payload) =  380
>Tx: len(payload) =  189
>Rx: ok = False  len(payload) =  380
>UTx: len(payload) =   70
>UTx: len(payload) =   81
>UTx: len(payload) =  101
>UTx: len(payload) =   70
>UTx: len(payload) =   42
>UTx: len(payload) =   42
>UTx: len(payload) =   42
>URx: ok = True  len(payload) =   81
>Tx: len(payload) =   42
>UTx: len(payload) =   42

Re: [Discuss-gnuradio] Basic question about filter

[signalswdm]

Thank you 
To make it clear, I use  USRP1. Does that  mean in common the signals that 
come out of ADC chips (in USRP case it is the signals come out of AD9862 before 
processed in FPGA)  is already filtered and  aliasing prior is partly 
eliminated ? In the datasheet I do not see anything about that. If I am wrong 
please correct me.


Best regards



At 2012-06-19 09:54:11,"Marcus D. Leech"  wrote:
On 18/06/12 09:46 PM, signalswdm wrote:
Hello everyone:
   You see in theory there should be a low-pass filter after ADC for 
eliminating the image. Also after DDC there should also be a 
filter. But in USRP there are not such things. So do the cic filter and half 
band filter implement that function besides decimation?


Best regards




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Actually, in typical architectures using I/Q, there are low-pass filters *in 
front* of the ADC to eliminate aliasing prior
  to sampling.  So the CIC decimator "sees" a signal that has already been 
band-limited appropriate to the sample
  rate of the ADCs.

The CIC decimation process *is* filtering, so out-of-band products appearing at 
the output are usually suppressed
  by at least 80dB, and usually more.




-- 
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] if uhd_transmitter instantiated after receiver, TX works, otherwise RX works

[George Nychis]

Your attached patch also fixes the problem!  Thanks a bunch for helping
narrow down this issue :)

On Mon, Jun 18, 2012 at 3:59 PM, George Nychis  wrote:

> Hi Josh,
>
> Thanks a bunch for these pointers/patches and looking in to it!  We are
> currently testing them out, shouldn't take long.  However, we did verify
> that reverting to the older version (003.003.002) did work for us as it
> did for King (thanks!).
>
> Stay tuned... we'll let you know ASAP.
>
> - George
>
>
> On Mon, Jun 18, 2012 at 1:51 PM, Josh Blum  wrote:
>
>>
>> > Thanks for the tip. I think I figured it out.
>> >
>> > The property to use an LO offset was true for TX and not RX. This would
>> > mean that tuning an individual chain and using it would be fine; but
>> > since there is a shared LO, the offset would not be compensated for by
>> > the DSP on the chain in the other direction, hence, it not working.
>> >
>> > If you dont mind trying, here is a simple 1 liner patch:
>> > http://pastebin.com/KiR3e6j0
>> >
>>
>> Another quick way to test this without the patch would be to tell the
>> tune request to use an LO offset of 0. Example:
>>
>> usrp_source/sink.set_center_frequency(uhd.tune_request(my_freq, 0))
>>
>> -josh
>>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] tunnel.py destination host unreachable - Temporarily solution, due to too fast reply!

[Alex Zhang]

Jason,

Thanks for information.
If I am not wrong,  I think your problem is from the CSMA threshold. In the
single link case of my mail, A and B shoule always send packet at different
time.

In addition, I am using SBX board. The duplex detail is still devil for me.
:<

On Mon, Jun 18, 2012 at 11:17 PM, Jason Tran  wrote:

> I had a similar problem way back and found collided packets (corrupted
> packets with ok=False). I started digging and found that my
> gr_probe_mag_sqrd_X was not returning a high enough magnitude for the
> carrier sense to be tripped. This also had to do with an issue I was having
> getting the xcvr2450 to tune to the right tx/rx frequencies...
>
> I suggest printing out the result of the magnitude squared to see if this
> is the case as well for you guys.
>
> Regards,
> Jason T.
>
>   --
> *From:* Alex Zhang 
> *To:* j...@ettus.com
> *Cc:* Tom Rondeau ; gnuradio mailing list <
> discuss-gnuradio@gnu.org>
> *Sent:* Monday, June 18, 2012 9:07 PM
> *Subject:* [Discuss-gnuradio] tunnel.py destination host unreachable -
> Temporarily solution, due to too fast reply!
>
> Hello Josh,
>
> I have seen many guys complaining the tunnel.py failed in PING by the
> "destination host unreachable", for both the OFDM and Narrowband.
> This problem is caused by crushed ARP reply. I previously use the static
> ARP table to work round this problem, but today I did some investigating
> and test, and now I believe the too fast ARP reply from the destination
> causes that the transmitter can not receive this reply or receive it with
> corrupted packets.
>
> For example, if the usrp A send the ARP request at time T, then usrp B
> send back the ARP reply at time T+delta. If the delta is too small, then A
> will definitely fails to receive it.
>
> The  temp solution is as below (tunnel.py in csma_mac.main_loop), just add
> a small delay for B  to send back the ARP reply. This solution works well.
>
>  ... ...**
>
> @@ -185,7 +185,10 @@ def main_loop(self):
>
> 185 185**
>
>  if not payload:
>
> 186 186**
>
>  self.tb.send_pkt(eof=True)
>
> 187 187**
>
>  break
>
> 188  **
>
> -
>
>   188**
>
> +
>
>   189**
>
> +time.sleep(0.009) # delay 9ms before sending out the reply
>
>   190**
>
> +t2 = self.tb.source.u.get_time_now().get_real_secs()
>
>   191**
>
> +print 'reply at time ', t
>
> 189 192**
>
>  if self.verbose:
>
> 190 193**
>
>  print "Tx: len(payload) = %4d" % (len(payload),)
>
>
> The root cause for this problem, I guess, should be that the duplex
> switching time bwteen the TX and RX at USRP is not small enough. More
> details should be about the duplex mechanism of the SBX daughter board. I
> hope there are some other way to solve this problem. For example, I tried
> to specify the TX and RX at different antennas (TX/RX for transmitter, RX2
> for receiver) of the SBX, but unfortunately it seems impossible.
>
> Looking forward to your further comments.
>
> Thanks,
>
> Alex(Changchun) Zhang
> Cognitive Radio Institute @ Tennessee Tech Univ.
>
> -- Forwarded message --
> From: *Alex Zhang* 
> Date: Mon, Jun 18, 2012 at 4:53 PM
> Subject: Re: [Discuss-gnuradio] tunnel.py destination host unreachable
> To: Weixian Zhou 
> Cc: j...@ettus.com, gnuradio mailing list 
>
>
> Weixian,
>
> Here is a temp solution, not sure it works or not:
>
> In the csma_mac.main_loop() of your tunnel.py, add a
> time_sleep(fixed_delay) right after the payload is read from the OS. You
> can set fixed_delay as 0.01 to 0.1 and test the result.
>
> And also, please set the CSMA threshold carefully to avoid
> possible collision.
>
> Alex
>
> On Mon, Jun 18, 2012 at 10:10 AM, Weixian Zhou  wrote:
>
> The following is the messages of the transmitter after I ping. The
> packages of len(payload)=42 failed CRC check, but other packages succeed.
> *URx: ok = True  len(payload) =  101*
> *Tx: len(payload) =   90*
> *Tx: len(payload) =   54*
> *UTx: len(payload) =  220*
> *UTx: len(payload) =  326*
> *URx: ok = False  len(payload) =  326*
> *Tx: len(payload) =   81*
>  *UTx: len(payload) =  326*
> *UTx: len(payload) =  326*
> *UTx: len(payload) =  302*
> *URx: ok = False  len(payload) =  302*
> *Tx: len(payload) =   78*
> *UTx: len(payload) =  220*
> *URx: ok = False  len(payload) =  220*
> *Tx: len(payload) =   81*
> *UTx: len(payload) =  302*
> *URx: ok = False  len(payload) =  302*
> *Tx: len(payload) =   70*
> *UTx: len(payload) =  110*
> *UTx: len(payload) =  240*
> *URx: ok = False  len(payload) =  240*
> *Tx: len(payload) =  404*
>  *Tx: len(payload) =  201*
> *UTx: len(payload) =  101*
> *UTx: len(payload) =  404*
> *Tx: len(payload) =  201*
> *Tx: len(payload) =   54*
> *UTx: len(payload) =  404*
> *Tx: len(payload) =  201*
> *Tx: len(payload) =  114*
> *UTx: len(payload) =  380*
> *Tx: len(payload) =  189*
> *Rx: ok = False  len(payload) =  380*
> *UTx: len(payload) =  240*
> *UT

Re: [Discuss-gnuradio] Basic question about filter

[Ian Buckley]

In general that is correct, analog filtering has been applied to the signal 
chain prior to the ADC to prevent significant spectral folding.
Specifically, the individual radio daughter cards provide filters of 
appropriate bandwidth for each design, there is no analog filtering circuit in 
the actual USRP1 motherboard. The BasicRX and TX boards are the sole exception 
to this, they provide no on board filtering.


On Jun 18, 2012, at 9:18 PM, signalswdm wrote:

> Thank you 
> To make it clear, I use  USRP1. Does that  mean in common the signals 
> that come out of ADC chips (in USRP case it is the signals come out of AD9862 
> before processed in FPGA)  is already filtered and  aliasing prior is partly 
> eliminated ? In the datasheet I do not see anything about that. If I am wrong 
> please correct me.
> 
> Best regards
> 
> 
> At 2012-06-19 09:54:11,"Marcus D. Leech"  wrote:
> On 18/06/12 09:46 PM, signalswdm wrote:
>> 
>> Hello everyone:
>>You see in theory there should be a low-pass filter after ADC for 
>> eliminating the image. Also after DDC there should also be a 
>> filter. But in USRP there are not such things. So do the cic filter and half 
>> band filter implement that function besides decimation?
>> 
>> Best regards
>> 
>> 
>>  
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>   
> Actually, in typical architectures using I/Q, there are low-pass filters *in 
> front* of the ADC to eliminate aliasing prior
>   to sampling.  So the CIC decimator "sees" a signal that has already been 
> band-limited appropriate to the sample
>   rate of the ADCs.
> 
> The CIC decimation process *is* filtering, so out-of-band products appearing 
> at the output are usually suppressed
>   by at least 80dB, and usually more.
> 
> 
> 
> -- 
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
> 
> 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio