Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. usrp_spectrum_sense.py newer version (Gonzalo Flores De La Parra)
2. Re: Last packet corrupted on USRP1 (Jawad Seddar)
3. urspn210 help (Mohammed Ramadan)
4. timed commands (Nuria Ibrahim)
5. small feature request (Stefano Speretta)
----------------------------------------------------------------------
Message: 1
Date: Mon, 25 Feb 2013 11:52:57 -0600
From: Gonzalo Flores De La Parra <[email protected]>
To: [email protected]
Subject: [USRP-users] usrp_spectrum_sense.py newer version
Message-ID:
<CACWyxXCf8BQEVPn-y49PhHnwV6jDvyWm2y3=sonovswn6rf...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
i don't know what version of gnuradio or uhd are you using, but probably
you have both versions of usrp_spectrum_sense.py.
take a better look at
/home/user_name/..installation_path../gnuradio/gr-uhd/examples/python
there are several examples which works with uhd beside the name usrp..
Hope this is what you where asking and was helpful
--
Ing. Gonzalo Flores De La Parra
Electr?nica en Comunicaciones
Universidad Aut?noma Metropolitana
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130225/d9ca9c71/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 25 Feb 2013 19:31:10 +0100
From: Jawad Seddar <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Last packet corrupted on USRP1
Message-ID:
<cae9wgf8mmnckmqmrztfp9ofproapvvrvcfa_y8fr1nvuqbm...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
>
> 2013/2/23 Jawad Seddar <[email protected]>
>
>> Hello,
>>
>> I just started working with GNURadio 3 weeks ago.
>> I am currently using 2 USRP1 devices :
>> - The first one is equipped with a RFX900 daughter board and a RFX2400
>> - The second one is equipped with a RFX900 and a XCV2450
>>
>> I have installed the latest GNURadio version on two computers (using the
>> build_gnuradio script) and have started playing around with those devices.
>>
>> One of my first tests was to use the narrowband benchmark scripts in
>> order to check that I could send and receive on both devices and on any
>> daugther board. I could send and receive correctly (ok = true, no pktno
>> missing) using a variety of frequencies but not using the gmsk modulation
>> (It worked great using bpsk, dbpsk, dqpsk...).
>>
>> After that first step, I went on and tried the narrowband tunnel.py
>> example but noticed that I wasn't seeing any packets at the receiver side
>> though I configured both gr0 interfaces on both computers and could see
>> packets being transmitted at the transmitter side.
>>
>> After entering the arp tables manually on each computer, I still couldn't
>> ping any of the machines but oddly enough I could user iperf and send udp
>> packets from one machine to another. These packets were correctly received
>> but the answer got lost on the way back.
>>
>> This got me thinking, what if only large packets could be seen at the
>> receiver? So I tried pinging using large packets (1400 Bytes) still
>> entering the arp manually, still nothing at the receiver (sometimes a
>> ok=false). Then I tried pinging and flooding (-f) still using large packets
>> (1400 Bytes), I could see the packets arriving and passing the CRC check
>> (ok = true).
>>
>> So I went back to the benchmark scripts and played a bit with the
>> parameters. I noticed that when using the discontinuous mode (it sends 5
>> packets then stops for 1 second and repeats) I was receiving the 4 first
>> packets correctly but the last one failed the CRC check (ok = false). I
>> tried different packet sizes and different burst sizes (number of packets
>> in a row) and different sleeping times between emissions, I always get the
>> same results : the last packet doesn't pass the CRC check (sometimes the
>> first one as well).
>>
>> So I thought that maybe the last bits of the transmission were corrupted,
>> so I went to the crc.py file and added stuffing bytes after the CRC field
>> and removed them at the receiver side. I went up to 2048 bytes of stuffing
>> (starting at 1 byte first), but it didn't yield much success.
>>
>> Then I decided to send a dummy packet after each payload packet. I tried
>> different sizes for the dummy packet and got some results. For instance,
>> adding a 16 Byte dummy after an 8 Byte long payload did work but the size
>> of the dummy packet seems to be dependent on the size of the payload...
>>
>> I can't seem to figure out what is causing the problem in the first
>> place. I have been thinking about synchronisation issues (because sometimes
>> the first packet is lost as well as the last one), or maybe power issues
>> (the transmitter shuts down before the last bit is out) . The last cause
>> should have been fixed by the stuffing after the CRC...
>>
>> I thank everybody who has reached this point, I am currently looking for
>> any insights you might have on this issue.
>>
>> Thank you for your help.
>>
>> Jawad Seddar
>>
>>
> Is this a half duplex or full duplex operation? I think the tunnel.py
> type app has an issue switching the device out of TX mode because it
> doesnt set EOB, which messes things up like the arp reply on a half
> duplex system.
>
> I dont know if this project has ever been tried on USRP1, but its a good
> replacement for those benchmark* tunnel* examples in gnuradio:
> https://github.com/jmalsbury/pre-cog/wiki
>
> -josh
>
Thank you for the reply.
The benchmark_xx examples work in half-duplex i.e they either create a
source (benchmark_rx) or a sink (benchmark_tx) so no switching is required.
I think the problem comes from a lower layer but I don't know which one.
It is as if the emitter doesn't send the last packet entirely and that the
end of that packet is added at the beginning of the next packet causing the
first and the last packet of a burst to be corrupted.
I have checked the make_packet function inside the packet_utils.py file and
it seems to be padding the packets to 512 Bytes correctly.
I've had a look at the pre-cog project and used one of the provided
examples (simple_trx) but it doesn't seem to be working any better.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130225/a4494326/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 26 Feb 2013 00:37:06 -0800 (PST)
From: Mohammed Ramadan <[email protected]>
To: [email protected]
Subject: [USRP-users] urspn210 help
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
i am fresh with using USRPn210 Device, and i know python programming language.
and i want to do RF application using the USRPn210 (transmit signal
then?receive?it and?compare?the?amplitude?change in this signal) , so i must
use uhd in gnu-radio or i can use python?language?for managing any
applications, i need you help and how can i start with this device.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130226/453a3828/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 26 Feb 2013 06:11:20 -0800 (PST)
From: Nuria Ibrahim <[email protected]>
To: usrp users forum <[email protected]>
Subject: [USRP-users] timed commands
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Dear Mr Josh
P { margin-bottom: 0.08in; }
I have written a piece of code to test
timed-commands.
My application implements two threads
the first thread to tune USRP periodically every 1.5 seconds from
now and the second thread to display the overall receiving chain
frequency that is to observe whether the tuning takes place in the
desired time. below is the implementation of timed-command for timed
tuning of the USRP
P { margin-bottom: 0.08in; }
usrp->set_time_now(uhd::time_spec_t(0.0));
MAList=[3, 7,33, 45, 80, 85, 94,103]
usrp->set_rx_freq(936.4e6);
//setting beacon channel
while(i<8)
{
int MAIO =(i%8);
arfcn=MAList[MAIO];
if(arfcn>=1 &&
arfcn<=124)
{
hope_freq=(935+ .2*arfcn)*1e6 ;
}
//hopping from cord
uhd::tune_request_t
tune_req(hope_freq); //retune USRP
tune_req.rf_freq_policy=uhd::tune_request_t::POLICY_NONE;
const uhd::time_spec_t tune_time =
usrp->get_time_now() + uhd::time_spec_t(1.5);
usrp->set_command_time(tune_time);
tune_res =
usrp->set_rx_freq(tune_req);
usrp->clear_command_time();
while(usrp->get_time_now()<tune_time)
{
cout<<"do nothing
and wait to prevent premature tuning"<<endl;
}
i++;
}
now my expectation when I run this
program was, to get @ least 1.5 second time difference between
successive tune requests, unfortunately the result shows some early
tuning?
Actual RX Freq after hopping:
935.600000 Mhz...@time: 1.50161
Actual RX Freq after hopping:
935.600000 Mhz...@time: 1.50222
Actual RX Freq after hopping:
935.600000 Mhz...@time: 1.50258
Actual RX Freq after hopping:
936.400000 Mhz...@time: 1.50298 ->unexpected
Actual RX Freq after hopping:
936.400000 Mhz...@time: 3.00306
Actual RX Freq after hopping:
936.400000 Mhz...@time: 3.00352
Actual RX Freq after hopping:
941.600000 Mhz...@time: 3.00409 ->unexpected
Actual RX Freq after hopping:
941.600000 Mhz...@time: 4.50418
Actual RX Freq after hopping:
941.600000 Mhz...@time: 4.50488
Actual RX Freq after hopping:
941.600000 Mhz...@time: 4.50526
Actual RX Freq after hopping:
944.000000 Mhz...@time: 6.00517
Actual RX Freq after hopping:
944.000000 Mhz...@time: 6.00578
Actual RX Freq after hopping:
944.000000 Mhz...@time: 6.00615
Actual RX Freq after hopping:
951.000000 Mhz...@time: 6.00655 ->unexpected
Actual RX Freq after hopping:
951.000000 Mhz...@time: 7.50661
Actual RX Freq after hopping:
951.000000 Mhz...@time: 7.5071
Actual RX Freq after hopping:
951.000000 Mhz...@time: 7.50769
Actual RX Freq after hopping:
952.000000 Mhz...@time: 9.00758
Actual RX Freq after hopping:
952.000000 Mhz...@time: 9.00821
Actual RX Freq after hopping:
952.000000 Mhz...@time: 9.00858
Actual RX Freq after hopping:
953.800000 Mhz...@time: 9.00897 ->unexpected
Actual RX Freq after hopping:
953.800000 Mhz...@time: 10.5088
Actual RX Freq after hopping:
953.800000 Mhz...@time: 10.5093
Actual RX Freq after hopping:
953.800000 Mhz...@time: 10.5097
Actual RX Freq after hopping:
953.800000 Mhz...@time: 10.5101
Actual RX Freq after hopping:
955.600000 Mhz...@time: 10.5105 ->unexpected
Actual RX Freq after hopping:
955.600000 Mhz...@time: 12.0105
Actual RX Freq after hopping:
955.600000 Mhz...@time: 12.011
what do you think is the problem?
Please help me here cause in real-time
hopping such kind of premature tuning result in synchronization
problem with BTS
Thanks in advance!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130226/88bf7b6c/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 26 Feb 2013 15:25:42 +0100
From: Stefano Speretta <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] small feature request
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hello,
I am writing an application using uhd to access a usrp B100 ubnder
Linux. I noticed that when the user has not the permissions to
access the usb bus an exception is thrown by uhd::usrp::multi_usrp::make
stating "KeyError: No devices found for -----> Empty Device Address".
On a command line application there would be a message displayed, as for
example in uhd_usrp_probe:
UHD Error:
USB open failed: insufficient permissions.
See the application notes for your device.
Error: LookupError: KeyError: No devices found for ----->
Empty Device Address
but this is difficult to catch in GUI applications. Could it be possible
to throw a message that points to the insufficient permissions in case
of error?
Thanks
Stefano
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 30, Issue 26
******************************************
