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. Re: Crest factor for A/D (Matt Ettus)
2. Re: timed commands not tuning the device at the desired time
(Josh Blum)
3. Re: Crest factor for A/D (Sivan Toledo)
4. Simultaneous transmissions using 2 daughter boards (Jawad Seddar)
5. Synchronizing USRP N210 with WBX boards (Manu T S)
6. Re: Synchronizing USRP N210 with WBX boards (Marcus D. Leech)
----------------------------------------------------------------------
Message: 1
Date: Thu, 28 Feb 2013 09:39:03 -0800
From: Matt Ettus <[email protected]>
To: David Campbell <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Crest factor for A/D
Message-ID:
<CAN=1kn8bax+fvyxhjm6y7h8ms7oxxp75bw6d2asepi2z1fh...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
David,
One way to know if you are getting overload is to look for samples that are
at the max 14-bit 2's comp size, so +8191/-8192. This would need to be
done in the FPGA ahead of any of the other DSP. You could create a block
which just watches the stream, and reports back if/when you hit the max
amplitudes. This could come back as context packets.
Matt
On Tue, Feb 26, 2013 at 12:57 PM, David Campbell <[email protected]>wrote:
> Hi,
> I am wondering if there is a way to retrieve in realtime A/D loading
> data (i.e. crest factor) for the N210 et.al (so the RX path). This
> would be the loading of the 100 Msps A/D, before it goes into to the
> tuners. Otherwise, I may not be able to tell if my input is overloading
> the A/D.
> Thanks,
> David
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130228/24c6fa04/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 28 Feb 2013 11:53:55 -0600
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] timed commands not tuning the device at the
desired time
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 02/28/2013 12:48 AM, Birhane Alemayoh wrote:
> Dear all
>
> 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
>
Not sure if this is the problem. I have one suggestion, put a mutex lock
around the usrp->set/clear_command_time(tune_time); block, and around
control commands on the other thread. I am worried that the listening
thread may be using commands when the command time is set.
Also, what does this mean:
> 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
Is the unexpected time supposed to be at 3 seconds?
How are you reading the time? Is it from the RX samples metadata
How are you measuring the frequency? Are you parsing RX samples, reading
a spectrum analyzer.
Another warning, done use get_rx_freq to readback the actual frequency,
because you are scheduling the tune for the future, this call cannot
accurately reflect the frequency at any given time, it just holds the
last frequency set.
-josh
>
> 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!
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 3
Date: Thu, 28 Feb 2013 14:51:47 -0500
From: Sivan Toledo <[email protected]>
To: Matt Ettus <[email protected]>
Cc: David Campbell <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Crest factor for A/D
Message-ID:
<caol_ruhpy8w5fmnbyl5ozw1kajayl9mwbuscz5wkgijtstq...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Seems like a generally useful feature.
On Thu, Feb 28, 2013 at 12:39 PM, Matt Ettus <[email protected]> wrote:
>
> David,
>
> One way to know if you are getting overload is to look for samples that
> are at the max 14-bit 2's comp size, so +8191/-8192. This would need to be
> done in the FPGA ahead of any of the other DSP. You could create a block
> which just watches the stream, and reports back if/when you hit the max
> amplitudes. This could come back as context packets.
>
> Matt
>
>
> On Tue, Feb 26, 2013 at 12:57 PM, David Campbell
> <[email protected]>wrote:
>
>> Hi,
>> I am wondering if there is a way to retrieve in realtime A/D loading
>> data (i.e. crest factor) for the N210 et.al (so the RX path). This
>> would be the loading of the 100 Msps A/D, before it goes into to the
>> tuners. Otherwise, I may not be able to tell if my input is overloading
>> the A/D.
>> Thanks,
>> David
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130228/0c3f8243/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 1 Mar 2013 13:12:00 +0100
From: Jawad Seddar <[email protected]>
To: [email protected]
Subject: [USRP-users] Simultaneous transmissions using 2 daughter
boards
Message-ID:
<cae9wgf8hk5s7p1urza7+0xkbdcicbvgwrxo-hkuojbgpv_l...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello,
I have a flex900 and a flex2400 connected to a USRP1.
I would like to transmit packets using both cards simultaneously using
digital modulations.
So far I've been able to send the same packets on the two cards and it
works (I connected the output of the demodulator to both usrp_sink inputs).
I have then created a second modulator and linked the first one to the
first channel and the second modulator to the second channel.
If I send packets on the first channel, it doesn't work (nothing at the
receiver side) and the thread seems to stop at a certain point.
If I send packets on both channels it works but only if there are packets
to transmit on both channels.
It is a very odd behaviour, my implementation must be wrong...
I've had a look at the fm_tx_2_daughterboards file and it just doens't work
on my setup (one connection seems to be missing in the flow graph).
Any advice on this would be very much appreciated.
Thank you
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130301/0709c146/attachment-0001.html>
------------------------------
Message: 5
Date: Fri, 1 Mar 2013 20:50:12 +0530
From: Manu T S <[email protected]>
To: [email protected]
Subject: [USRP-users] Synchronizing USRP N210 with WBX boards
Message-ID:
<CACJh7QzOsm3do6MBPkZ7GATGb-4BA6b_oZx4-HV9Rqv3ZT4Z=w...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
As part of a project I have to synchronize the sampling time of two USRPs
used as transmitter, to jointly decode the symbols at a third Rx USRP.
I have N210s with WBX boards.
I don't have MIMO cable and GPSDO. I read the application notes about
synchronizing USRPs but could not gather much from it.
Can I do this without MIMO and GPSDO?
Thanks in advance
--
Manu T S
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130301/57c3eae9/attachment-0001.html>
------------------------------
Message: 6
Date: Fri, 01 Mar 2013 10:25:04 -0500
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Synchronizing USRP N210 with WBX boards
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> As part of a project I have to synchronize the sampling time of two
> USRPs used as transmitter, to jointly decode the symbols at a third Rx
> USRP.
>
> I have N210s with WBX boards.
>
> I don't have MIMO cable and GPSDO. I read the application notes about
> synchronizing USRPs but could not gather much from it.
>
> Can I do this without MIMO and GPSDO?
>
> Thanks in advance
>
> --
> Manu T S
You need some way of providing an external clock and 1PPS reference for
each N210 involved. Whether that's a laboratory 10MHz/1PPS
source, or a GSPDO or MIMO, doesn't matter much. What *does* matter
is that they have a common reference.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
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 31, Issue 1
*****************************************
