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: GPSO Vita timestamp (Josh Blum)
2. Re: Using multiple RX DDC chains on USRP2 (Roy Thompson)
3. Re: [Discuss-gnuradio] SBX TX/RX RX leakage (gang li)
4. Re: [Discuss-gnuradio] SBX TX/RX RX leakage (Marcus D. Leech)
5. Re: GPSO Vita timestamp (A Bose)
6. Re: Using multiple RX DDC chains on USRP2 (Josh Blum)
7. Re: [Discuss-gnuradio] SBX TX/RX RX leakage (gang li)
8. Re: Using multiple RX DDC chains on USRP2 (Roy Thompson)
9. TX/RX protections (Jeff Scaparra)
10. Re: Using multiple RX DDC chains on USRP2 (Josh Blum)
11. Re: Using multiple RX DDC chains on USRP2 (Roy Thompson)
----------------------------------------------------------------------
Message: 1
Date: Fri, 08 Feb 2013 13:30:58 -0600
From: Josh Blum <[email protected]>
To: A Bose <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] GPSO Vita timestamp
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 02/04/2013 12:44 PM, A Bose wrote:
> For the record I am running 32-bit windows xp, with UHD 3_4_3 Release and
> using Visual Studio 10.
>
> Awaiting your test results,
>
> Thanks,
> A Bose
Well, I changed this example to lock to gps time and stream at gps time
+ some delta: http://pastebin.com/TKm6dm1B
This was the output (which looks ok):
http://pastebin.com/f9nkZPBe
I am curious how it works for you
-josh
>
> On 02/04/2013 11:40 AM, A Bose wrote:
>>> Does your system have a 32 bit or 64 bit time_t?
>> I cannot compile with #define _USE_32BIT_TIME_T so I think I have 64
> time_t.
>>
>> I verified the wireshark packets and the vita time map correctly into
>> info.ifpi.tsf and info.ifpi.tsi in get_and_process_single_packet
>> function of super_recv_packet_handler.cpp
>>
>> The next call populates info.time via a translation function, and I
>> think this could be my problem.
>>
>> In the same function should the following line be:
>> info.time = time_spec_t::from_ticks(info.ifpi.tsf, _tick_rate);
>> -OR-
>> info.time = time_spec_t(time_t(info.ifpi.tsi), size_t(info.ifpi.tsf),
>> _tick_rate);
>>
>
> The packets used to have integer seconds and fractional ticks. They now just
> have 64 bits of tick counts for absolute time -- which is much easier to
> deal with. So, anyway, thats the reason for the change.
>
>> I have seen both in the file history, and I am not sure if they are
>> the same.
>>
>> Is this a Windows issue, because I am sure this timestamp is working
>> on your end?
>>
>
> Its possible that there is an issue when time_t is 64 bits, which might be
> only on the x64 window binary. I am trying to replicate this.
>
> For the curious, the conversion from 64 bit tick count to fractional and
> full seconds happens here:
>
> http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master
> /entry/host/lib/types/time_spec.cpp#L71
>
> http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master
> /entry/host/lib/types/time_spec.cpp#L103
>
> I am placing my suspicions either on the imaxdiv function, or the
> time_spec_init macro
>
> -josh
>
> -josh
>
>> Thanks,
>> A Bose
>>
>> On 02/01/2013 03:48 PM, A Bose wrote:
>>> md.has_time_spec = true
>>> md.error_code = ERROR_CODE_NONE
>>> md.time_spec.get_full_secs() = 56935896589
>>
>> I agree, these full seconds count look kind of like random junk.
>>
>> That number is larger than 32 bits.
>> Does your system have a 32 bit or 64 bit time_t?
>>
>> -josh
>>
>>> md.time_spec.get_frac_secs() = 0.74093313000000005
>>>
>>> md.timespec = UTC "2004-Nov-24 18:42:21"
>>>
>>> -----------------------------------------------------------------
>>> If I run the code a couple more time again I get:
>>> md.time_spec = {_full_secs=-31005044168
>>> _frac_secs=0.65193984000000005 } md .time_spec =
>>> {_full_secs=-20673319605
>>> _frac_secs=0.40310016000000004 } md .time_spec =
>>> {_full_secs=-52058959422 _frac_secs=0.74874366999999997 } md
>>> .time_spec = {_full_secs=-29287266028 _frac_secs=0.69364738999999997
>>> } power cycle md .time_spec = {_full_secs=19686160971
>>> _frac_secs=0.20780288000000000 } md .time_spec =
>>> {_full_secs=89173861499 _frac_secs=0.37283071000000001 } md.time_spec
>>> = {_full_secs=-46045442223 _frac_secs=0.46386945999999996 } md
>>> .time_spec = {_full_secs=-53333033252 _frac_secs=0.32941052000000004
>>> } md.time_spec = {_full_secs=-87239595147
>>> _frac_secs=0.76753658000000002 }
>>>
>>>
>>> Thanks for any input,
>>> A Bose
>>>
>>> -----Original Message-----
>>> From: Josh Blum [mailto:[email protected]] On Behalf Of Josh Blum
>>> Sent: Friday, February 01, 2013 3:55 PM
>>> To: A Bose
>>> Cc: [email protected]
>>> Subject: Re: [USRP-users] GPSO Vita timestamp
>>>
>>>
>>>
>>> On 02/01/2013 01:36 PM, A Bose wrote:
>>>> Hello,
>>>>
>>>> I am using a N200 and UHD in windows, and I am trying to set the
>>>> VITA frame timestamp to the GPS time. The
>>>> md.time_spec.get_full_secs() seems to go positive and negative and
>>>> is just random and is the same at the super_recv_packet_handler.hpp
> after the packet receive.
>>>>
>>>> Here is my code:
>>>>
>>>> usrp->set_clock_source("external");
>>>> //set_time_source allows the FPGAs internal tick counter to be
>>>> synchronized by a PPS pulse coming into the external SMA
>>>> usrp->set_time_source("external");
>>>> ...
>>>> //setup the VITA frame time to gps_time uhd::sensor_value_t gps_time
>>>> =
>>>> usrp->get_mboard_sensor("gps_time");
>>>> uhd::time_spec_t gpsTime = uhd::time_spec_t(1.0)
>>>> +uhd::time_spec_t((double)gps_time.to_int());
>>>>
>>>> //set the gps time
>>>> usrp->set_time_next_pps(gpsTime);
>>>> boost::this_thread::sleep(boost::posix_time::seconds(1.5)); //wait
>>>> for pps sync pulse uhd::time_spec_t last_pps_time2 =
>>>> usrp->get_time_last_pps();
>>>>
>>>> boost::posix_time::ptime tpps(date(1970,1,1),
>>>> boost::posix_time::seconds(last_pps_time2.get_full_secs()));
>>>> std::string testLastPPS = to_simple_string(tpps); //THIS IS GOOD
>>>>
>>>> //setup streaming
>>>> uhd::stream_cmd_t stream_cmd((num_requested_samples == 0)?
>>>> uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS:
>>>> uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE
>>>> );
>>>> stream_cmd.num_samps = num_requested_samples;
>>>> stream_cmd.stream_now = true;
>>>> stream_cmd.time_spec = uhd::time_spec_t();
>>>>
>>>> usrp->issue_stream_cmd(stream_cmd);
>>>>
>>>> while(not stop_signal_called and (num_requested_samples !=
>>>> num_total_samps or num_requested_samples == 0)){
>>>> size_t num_rx_samps = rx_stream->recv(&buff.front(),
>>>> buff.size(), md, 3.0);
>>>> ...
>>>> //error checking
>>>> ...
>>>> num_total_samps += num_rx_samps;
>>>> outfile.write((const char*)&buff.front(),
>>>> num_rx_samps*sizeof(samp_type));
>>>> }
>>>>
>>>> boost::posix_time::ptime t0(date(1970,1,1),
>>>> boost::posix_time::seconds(md.time_spec.get_full_secs()));
>>>> std::string test0 = to_simple_string(t0); //THIS IS BAD
>>>
>>> OK I see what the test is doing.
>>> So, can you tell me, what is the value of:
>>>
>>> md.has_time_spec
>>> md.error_code
>>> md.time_spec.get_full_secs()
>>> md.time_spec.get_frac_secs()
>>>
>>> -josh
>>>
>>>>
>>>> //get pps time again to check
>>>> uhd::time_spec_t last_pps_time3 = usrp->get_time_last_pps();
>>>> boost::posix_time::ptime tpps3(date(1970,1,1),
>>>> boost::posix_time::seconds(last_pps_time3.get_full_secs()));
>>>> std::string testLastPPS3 = to_simple_string(tpps); //THIS IS GOOD
>>>>
>>>>
>>>> The Vita Frame timestamp just doesn't seem to be set to the internal
>> time.
>>>>
>>>> Any ideas?
>>>>
>>>> Thanks,
>>>> A Bose
>>>>
>>>> -----Original Message-----
>>>> From: USRP-users [mailto:[email protected]] On
>>>> Behalf Of Josh Blum
>>>> Sent: Friday, February 01, 2013 11:24 AM
>>>> To: [email protected]
>>>> Subject: Re: [USRP-users] GPSO 1PSS
>>>>
>>>>
>>>>
>>>> On 02/01/2013 10:09 AM, A Bose wrote:
>>>>> I am having the exact same problem and I found this discrepancy:
>>>>>
>>>>>
>>>>>
>>>>> The latest
>>>>>
>>>>> http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisio
>>>>> n
>>>>> s
>>>>> /
>>>>> fac15d
>>>>> b5d77c5196badb4a06f2f5fec34eb57337/entry/host/lib/transport/super_r
>>>>> e c v _packe t_handler.hpp has fixed the meta time to include
>>>>> seconds:
>>>>>
>>>>> info.time = time_spec_t(time_t(info.ifpi.tsi),
>>>>> size_t(info.ifpi.tsf), _tick_rate); //assumes has_tsi and has_tsf
>>>>> are true
>>>>>
>>>>>
>>>>>
>>>>> but the 003.005.001 release has the old code bug with no seconds:
>>>>>
>>>>> info.time = time_spec_t::from_ticks(info.ifpi.tsf, _tick_rate);
>>>>> //assumes has_tsf is true
>>>>>
>>>>
>>>> The time is always parsed from the packet, even if the fields may
>>>> not have been populated. The time is qualified with the
>>>> has_time_spec which is also parsed from the packet. So time is only
>>>> valid if the boolean field says true.
>>>>
>>>>>
>>>>>
>>>>> I am running with an old FPGA rev and this fix doesn't work for me,
>>>>> so I am assuming there is/was something wrong on the FPGA side as well?
>>>>> If so does anyone know what exactly was fixed (what rev)?
>>>>>
>>>>
>>>> Sorry I am unsure, but what exactly is the issue?
>>>>
>>>> -josh
>>>>
>>>>>
>>>>>
>>>>> From: USRP-users [mailto:[email protected]] On
>>>>> Behalf Of Damien Serant
>>>>> Sent: Thursday, January 31, 2013 8:31 PM
>>>>> To: Nick Foster
>>>>> Cc: USRP List
>>>>> Subject: Re: [USRP-users] GPSO 1PSS
>>>>>
>>>>>
>>>>>
>>>>> Thanks Nick for your kick answer.
>>>>>
>>>>>
>>>>>
>>>>> "We just recently fixed a bug relating to this."
>>>>>
>>>>> I know. I am using UHD 003.005.001 (from installer) which contains
>>>>> the patch according to the repository. May be the installer does
>>>>> not have the
>>>> patch ?
>>>>> I will try tomorrow to build from source.
>>>>>
>>>>>
>>>>>
>>>>> "Can you cut and paste the relevant section of code?"
>>>>>
>>>>> From memory (i don't have access to my code right now) :
>>>>>
>>>>>
>>>>>
>>>>> For the stream command config:
>>>>>
>>>>> uhd::stream_cmd_t
>>>>> stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
>>>>>
>>>>> stream_cmd.stream_now = false;
>>>>>
>>>>> stream_cmd.time_spec = get_time_last_pps()+1;
>>>>>
>>>>> usrp->issue_stream_cmd(stream_cmd);
>>>>>
>>>>> cout<<fixed<<setprecision(9)<<get_time_last_pps().get_real_secs()<<
>>>>> e
>>>>> n
>>>>> d
>>>>> l;
>>>>> //Not full sec
>>>>>
>>>>>
>>>>>
>>>>> For the receiving part:
>>>>>
>>>>> nbSamp = 0;
>>>>>
>>>>> timeout = 3;
>>>>>
>>>>> while(nbSamp<nbSampTot){
>>>>>
>>>>> num_rx_samps = rx_stream->recv(&buff.front(), buff.size(), md,
>>>>> timeout);
>>>>> //buff.size() about 100000
>>>>>
>>>>> if(nbSamp == 0){
>>>>>
>>>>>
>>>>> cout<<fixed<<setprecision(9)<<md.time_spec.get_real_secs()<<endl;
>>>>> //Not full sec
>>>>>
>>>>> }
>>>>>
>>>>> timeout = 0.1;
>>>>>
>>>>> nbSamp+=num_rx_samps;
>>>>>
>>>>> ...
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> May be i don't use the right method to extract the time from the
>>>>> time spec
>>>> ?
>>>>>
>>>>> Since i wrote this from memory it is possible that there is an
>>>>> error in my actual code and not here...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Damien
>>>>>
>>>>>
>>>>>
>>>>> 2013/2/1 Nick Foster <[email protected]>
>>>>>
>>>>> On 01/31/2013 04:00 PM, Damien Serant wrote:
>>>>>
>>>>> Hi list,
>>>>>
>>>>>
>>>>>
>>>>> Two small issues about 1PPS signal with the GPSDO:
>>>>>
>>>>> 1) When i run the query_gpsdo_sensors util i obtain : "GPS
>>>>> locked",
>>>>> "10 MHz" locked but always "GPS and UHD Device time are NOT aligned"
>>>>> (I triple checked the 1PPS connection)
>>>>>
>>>>> We just recently fixed a bug relating to this. The PPS
>>>>> functionality is fine; the query_gpsdo_sensors program wasn't
>>>>> waiting long enough to be sure the PPS had been latched in. It's
>>>>> checked into master, but I don't think a release has been cut since
> then.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2) I my program the time get from the "get_time_last_pps()"
>>>>> function is surprisingly never a full second (about 500 ns before
>>>>> or after a full second). In the same way, when i set the time spec
>>>>> of a receiver stream with get_time_last_pps() + 1, i never get a
>>>>> full second in the time spec field of the metadata of the first
>>>>> received
>>> packet .
>>>>>
>>>>> This is a normal behavior and if yes why ?
>>>>>
>>>>> Can you cut and paste the relevant section of code?
>>>>>
>>>>> --n
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Configuration; win XP, USRP N200 r4 with SBX daughterboard, UHD 351.
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>>
>>>>> Damien
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>
>>
>
------------------------------
Message: 2
Date: Fri, 8 Feb 2013 15:53:02 -0500
From: Roy Thompson <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] Using multiple RX DDC chains on USRP2
Message-ID:
<caozutchdafuca6txdqrwfkzqlbr+f1mm_z3hnfzpzwxp-ow...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Is there any way to stream both channels with different rates into the
same flowgraph in GNURadio (i.e. 2 sources)? From what I can tell,
the answer is no but I figured I'd ask before trying to come up with a
hack for it.
Thanks,
Roy
On Thu, Feb 7, 2013 at 4:41 PM, Josh Blum <[email protected]> wrote:
>
>
> On 02/07/2013 03:30 PM, Roy Thompson wrote:
>> Thanks, will that work if the chains have different sample rates?
>> There is a comment in multi_usrp.hpp stating that all channels must
>> have the same rate, but it's not clear what causes the limitation
>> since it looks like it is possible to set the rate for individual
>> channels with set_rx_rate().
>
> Yes, all the api calls take a channel number. So in this case, you would
> want a different rx_streamer for each channel, since they are at
> different rates.
>
> -josh
>
>>
>> -Roy
>>
>> On Thu, Feb 7, 2013 at 4:17 PM, Josh Blum <[email protected]> wrote:
>>>
>>>
>>> On 02/07/2013 02:49 PM, Roy Thompson wrote:
>>>> I am starting to look through some of the FPGA code for the USRP2 and
>>>> I noticed that there are 2 RX DDC chains. I would like to be able to
>>>> use one of the chains to do standard DDC processing, and I would like
>>>> to modify the second chain to do custom processing on the same A/D
>>>> channel. The output sample rate for the second chain will be
>>>> different from the first. Is it possible to configure the UHD driver
>>>> to support this configuration and allow for receiving from both
>>>> chains?
>>>>
>>>
>>> The rx_multi_samples example can show you how to use two DDC chains. If
>>> you had a WBX for example with frontend (named 0), this would map
>>> frontend 0 located on the first and only daughterboard (named A) to DSP0
>>> and DSP1 --subdev="A:0 A:0"
>>>
>>> see the --help for more.
>>>
>>>> std::cout <<
>>>> " This is a demonstration of how to receive aligned data from
>>>> multiple channels.\n"
>>>> " This example can receive from multiple DSPs, multiple
>>>> motherboards, or both.\n"
>>>> " The MIMO cable or PPS can be used to synchronize the
>>>> configuration. See --sync\n"
>>>> "\n"
>>>> " Specify --subdev to select multiple channels per
>>>> motherboard.\n"
>>>> " Ex: --subdev=\"0:A 0:B\" to get 2 channels on a Basic RX.\n"
>>>> "\n"
>>>> " Specify --args to select multiple motherboards in a
>>>> configuration.\n"
>>>> " Ex: --args=\"addr0=192.168.10.2, addr1=192.168.10.3\"\n"
>>>> << std::endl;
>>>
>>>
>>> See this readme, there is a place where it should be convenient to
>>> replace the DDC with custom logic:
>>>
>>> http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/fpga/README.txt
>>>
>>> -josh
>>>
>>>> Thanks,
>>>> Roy
>>>>
>>>> _______________________________________________
>>>> 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: Fri, 8 Feb 2013 16:10:40 -0500
From: gang li <[email protected]>
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: [USRP-users] [Discuss-gnuradio] SBX TX/RX RX leakage
Message-ID:
<CAKro2L1oixE8M9WccoGy9UzskGzvD=guwbpmw7xrvvk1cek...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
When the signal received on RF2 port has a very weak strength, the
energy leaked from TX to RX will dominate in the total received
energy. I have observed this in my experiments. Are there any ways to
measure the leaked signal so i can compensate it? I am thinking a way
of by connecting the RF1 and RF2 ports with a long cable and 60db
attenuators. And then i record the received signal. I assume it is the
leaked signal from TX. Are there any better ways? Thanks for your
reply.
Best,
Gang
On Thu, Feb 7, 2013 at 2:22 PM, <[email protected]> wrote:
> On 07 Feb 2013 11:31, gang li wrote:
>
> Hi, guys, I am doing full duplex on SBX. Is there any leakage from TX
> to RX? Is that much?
>
> Best,
> Gang
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> There's roughly 40dB isolation TX/RX on these cards.
>
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
------------------------------
Message: 4
Date: Fri, 08 Feb 2013 16:26:26 -0500
From: "Marcus D. Leech" <[email protected]>
To: gang li <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: [USRP-users] [Discuss-gnuradio] SBX TX/RX RX leakage
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 02/08/2013 04:10 PM, gang li wrote:
> When the signal received on RF2 port has a very weak strength, the
> energy leaked from TX to RX will dominate in the total received
> energy. I have observed this in my experiments. Are there any ways to
> measure the leaked signal so i can compensate it? I am thinking a way
> of by connecting the RF1 and RF2 ports with a long cable and 60db
> attenuators. And then i record the received signal. I assume it is the
> leaked signal from TX. Are there any better ways? Thanks for your
> reply.
>
> Best,
> Gang
Are you TX/RX on the same frequency, or different frequencies?
The usual way to deal with this on different-frequency setups is to use
a duplexor, or a deep notch filter on the RX port, and probably boost your
antenna signal a bit with an external amplifier.
But if this is *same-frequency* duplex, the on-board leakage is really
minor compared to the coupling between your antennae.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 5
Date: Fri, 8 Feb 2013 16:41:37 -0500
From: "A Bose" <[email protected]>
To: <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] GPSO Vita timestamp
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Josh,
Seconds are still bad:
http://imgshr.com/grxRX4
On 02/04/2013 12:44 PM, A Bose wrote:
> For the record I am running 32-bit windows xp, with UHD 3_4_3 Release
> and using Visual Studio 10.
>
> Awaiting your test results,
>
> Thanks,
> A Bose
Well, I changed this example to lock to gps time and stream at gps time
+ some delta: http://pastebin.com/TKm6dm1B
This was the output (which looks ok):
http://pastebin.com/f9nkZPBe
I am curious how it works for you
-josh
>
> On 02/04/2013 11:40 AM, A Bose wrote:
>>> Does your system have a 32 bit or 64 bit time_t?
>> I cannot compile with #define _USE_32BIT_TIME_T so I think I have 64
> time_t.
>>
>> I verified the wireshark packets and the vita time map correctly into
>> info.ifpi.tsf and info.ifpi.tsi in get_and_process_single_packet
>> function of super_recv_packet_handler.cpp
>>
>> The next call populates info.time via a translation function, and I
>> think this could be my problem.
>>
>> In the same function should the following line be:
>> info.time = time_spec_t::from_ticks(info.ifpi.tsf, _tick_rate);
>> -OR-
>> info.time = time_spec_t(time_t(info.ifpi.tsi), size_t(info.ifpi.tsf),
>> _tick_rate);
>>
>
> The packets used to have integer seconds and fractional ticks. They
> now just have 64 bits of tick counts for absolute time -- which is
> much easier to deal with. So, anyway, thats the reason for the change.
>
>> I have seen both in the file history, and I am not sure if they are
>> the same.
>>
>> Is this a Windows issue, because I am sure this timestamp is working
>> on your end?
>>
>
> Its possible that there is an issue when time_t is 64 bits, which
> might be only on the x64 window binary. I am trying to replicate this.
>
> For the curious, the conversion from 64 bit tick count to fractional
> and full seconds happens here:
>
> http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/
> master
> /entry/host/lib/types/time_spec.cpp#L71
>
> http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/
> master
> /entry/host/lib/types/time_spec.cpp#L103
>
> I am placing my suspicions either on the imaxdiv function, or the
> time_spec_init macro
>
> -josh
>
> -josh
>
>> Thanks,
>> A Bose
>>
>> On 02/01/2013 03:48 PM, A Bose wrote:
>>> md.has_time_spec = true
>>> md.error_code = ERROR_CODE_NONE
>>> md.time_spec.get_full_secs() = 56935896589
>>
>> I agree, these full seconds count look kind of like random junk.
>>
>> That number is larger than 32 bits.
>> Does your system have a 32 bit or 64 bit time_t?
>>
>> -josh
>>
>>> md.time_spec.get_frac_secs() = 0.74093313000000005
>>>
>>> md.timespec = UTC "2004-Nov-24 18:42:21"
>>>
>>> -----------------------------------------------------------------
>>> If I run the code a couple more time again I get:
>>> md.time_spec = {_full_secs=-31005044168
>>> _frac_secs=0.65193984000000005 } md .time_spec =
>>> {_full_secs=-20673319605
>>> _frac_secs=0.40310016000000004 } md .time_spec =
>>> {_full_secs=-52058959422 _frac_secs=0.74874366999999997 } md
>>> .time_spec = {_full_secs=-29287266028 _frac_secs=0.69364738999999997
>>> } power cycle md .time_spec = {_full_secs=19686160971
>>> _frac_secs=0.20780288000000000 } md .time_spec =
>>> {_full_secs=89173861499 _frac_secs=0.37283071000000001 }
>>> md.time_spec = {_full_secs=-46045442223
>>> _frac_secs=0.46386945999999996 } md .time_spec =
>>> {_full_secs=-53333033252 _frac_secs=0.32941052000000004 }
>>> md.time_spec = {_full_secs=-87239595147
>>> _frac_secs=0.76753658000000002 }
>>>
>>>
>>> Thanks for any input,
>>> A Bose
>>>
>>> -----Original Message-----
>>> From: Josh Blum [mailto:[email protected]] On Behalf Of Josh Blum
>>> Sent: Friday, February 01, 2013 3:55 PM
>>> To: A Bose
>>> Cc: [email protected]
>>> Subject: Re: [USRP-users] GPSO Vita timestamp
>>>
>>>
>>>
>>> On 02/01/2013 01:36 PM, A Bose wrote:
>>>> Hello,
>>>>
>>>> I am using a N200 and UHD in windows, and I am trying to set the
>>>> VITA frame timestamp to the GPS time. The
>>>> md.time_spec.get_full_secs() seems to go positive and negative and
>>>> is just random and is the same at the super_recv_packet_handler.hpp
> after the packet receive.
>>>>
>>>> Here is my code:
>>>>
>>>> usrp->set_clock_source("external");
>>>> //set_time_source allows the FPGAs internal tick counter to be
>>>> synchronized by a PPS pulse coming into the external SMA
>>>> usrp->set_time_source("external");
>>>> ...
>>>> //setup the VITA frame time to gps_time uhd::sensor_value_t
>>>> gps_time =
>>>> usrp->get_mboard_sensor("gps_time");
>>>> uhd::time_spec_t gpsTime = uhd::time_spec_t(1.0)
>>>> +uhd::time_spec_t((double)gps_time.to_int());
>>>>
>>>> //set the gps time
>>>> usrp->set_time_next_pps(gpsTime);
>>>> boost::this_thread::sleep(boost::posix_time::seconds(1.5)); //wait
>>>> for pps sync pulse uhd::time_spec_t last_pps_time2 =
>>>> usrp->get_time_last_pps();
>>>>
>>>> boost::posix_time::ptime tpps(date(1970,1,1),
>>>> boost::posix_time::seconds(last_pps_time2.get_full_secs()));
>>>> std::string testLastPPS = to_simple_string(tpps); //THIS IS GOOD
>>>>
>>>> //setup streaming
>>>> uhd::stream_cmd_t stream_cmd((num_requested_samples == 0)?
>>>> uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS:
>>>> uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE
>>>> );
>>>> stream_cmd.num_samps = num_requested_samples;
>>>> stream_cmd.stream_now = true;
>>>> stream_cmd.time_spec = uhd::time_spec_t();
>>>>
>>>> usrp->issue_stream_cmd(stream_cmd);
>>>>
>>>> while(not stop_signal_called and (num_requested_samples !=
>>>> num_total_samps or num_requested_samples == 0)){
>>>> size_t num_rx_samps = rx_stream->recv(&buff.front(),
>>>> buff.size(), md, 3.0);
>>>> ...
>>>> //error checking
>>>> ...
>>>> num_total_samps += num_rx_samps;
>>>> outfile.write((const char*)&buff.front(),
>>>> num_rx_samps*sizeof(samp_type));
>>>> }
>>>>
>>>> boost::posix_time::ptime t0(date(1970,1,1),
>>>> boost::posix_time::seconds(md.time_spec.get_full_secs()));
>>>> std::string test0 = to_simple_string(t0); //THIS IS BAD
>>>
>>> OK I see what the test is doing.
>>> So, can you tell me, what is the value of:
>>>
>>> md.has_time_spec
>>> md.error_code
>>> md.time_spec.get_full_secs()
>>> md.time_spec.get_frac_secs()
>>>
>>> -josh
>>>
>>>>
>>>> //get pps time again to check
>>>> uhd::time_spec_t last_pps_time3 = usrp->get_time_last_pps();
>>>> boost::posix_time::ptime tpps3(date(1970,1,1),
>>>> boost::posix_time::seconds(last_pps_time3.get_full_secs()));
>>>> std::string testLastPPS3 = to_simple_string(tpps); //THIS IS GOOD
>>>>
>>>>
>>>> The Vita Frame timestamp just doesn't seem to be set to the
>>>> internal
>> time.
>>>>
>>>> Any ideas?
>>>>
>>>> Thanks,
>>>> A Bose
>>>>
>>>> -----Original Message-----
>>>> From: USRP-users [mailto:[email protected]] On
>>>> Behalf Of Josh Blum
>>>> Sent: Friday, February 01, 2013 11:24 AM
>>>> To: [email protected]
>>>> Subject: Re: [USRP-users] GPSO 1PSS
>>>>
>>>>
>>>>
>>>> On 02/01/2013 10:09 AM, A Bose wrote:
>>>>> I am having the exact same problem and I found this discrepancy:
>>>>>
>>>>>
>>>>>
>>>>> The latest
>>>>>
>>>>> http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisi
>>>>> o
>>>>> n
>>>>> s
>>>>> /
>>>>> fac15d
>>>>> b5d77c5196badb4a06f2f5fec34eb57337/entry/host/lib/transport/super_
>>>>> r e c v _packe t_handler.hpp has fixed the meta time to include
>>>>> seconds:
>>>>>
>>>>> info.time = time_spec_t(time_t(info.ifpi.tsi),
>>>>> size_t(info.ifpi.tsf), _tick_rate); //assumes has_tsi and has_tsf
>>>>> are true
>>>>>
>>>>>
>>>>>
>>>>> but the 003.005.001 release has the old code bug with no seconds:
>>>>>
>>>>> info.time = time_spec_t::from_ticks(info.ifpi.tsf, _tick_rate);
>>>>> //assumes has_tsf is true
>>>>>
>>>>
>>>> The time is always parsed from the packet, even if the fields may
>>>> not have been populated. The time is qualified with the
>>>> has_time_spec which is also parsed from the packet. So time is only
>>>> valid if the boolean field says true.
>>>>
>>>>>
>>>>>
>>>>> I am running with an old FPGA rev and this fix doesn't work for
>>>>> me, so I am assuming there is/was something wrong on the FPGA side as
well?
>>>>> If so does anyone know what exactly was fixed (what rev)?
>>>>>
>>>>
>>>> Sorry I am unsure, but what exactly is the issue?
>>>>
>>>> -josh
>>>>
>>>>>
>>>>>
>>>>> From: USRP-users [mailto:[email protected]] On
>>>>> Behalf Of Damien Serant
>>>>> Sent: Thursday, January 31, 2013 8:31 PM
>>>>> To: Nick Foster
>>>>> Cc: USRP List
>>>>> Subject: Re: [USRP-users] GPSO 1PSS
>>>>>
>>>>>
>>>>>
>>>>> Thanks Nick for your kick answer.
>>>>>
>>>>>
>>>>>
>>>>> "We just recently fixed a bug relating to this."
>>>>>
>>>>> I know. I am using UHD 003.005.001 (from installer) which contains
>>>>> the patch according to the repository. May be the installer does
>>>>> not have the
>>>> patch ?
>>>>> I will try tomorrow to build from source.
>>>>>
>>>>>
>>>>>
>>>>> "Can you cut and paste the relevant section of code?"
>>>>>
>>>>> From memory (i don't have access to my code right now) :
>>>>>
>>>>>
>>>>>
>>>>> For the stream command config:
>>>>>
>>>>> uhd::stream_cmd_t
>>>>> stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
>>>>>
>>>>> stream_cmd.stream_now = false;
>>>>>
>>>>> stream_cmd.time_spec = get_time_last_pps()+1;
>>>>>
>>>>> usrp->issue_stream_cmd(stream_cmd);
>>>>>
>>>>> cout<<fixed<<setprecision(9)<<get_time_last_pps().get_real_secs()<
>>>>> <
>>>>> e
>>>>> n
>>>>> d
>>>>> l;
>>>>> //Not full sec
>>>>>
>>>>>
>>>>>
>>>>> For the receiving part:
>>>>>
>>>>> nbSamp = 0;
>>>>>
>>>>> timeout = 3;
>>>>>
>>>>> while(nbSamp<nbSampTot){
>>>>>
>>>>> num_rx_samps = rx_stream->recv(&buff.front(), buff.size(), md,
>>>>> timeout);
>>>>> //buff.size() about 100000
>>>>>
>>>>> if(nbSamp == 0){
>>>>>
>>>>>
>>>>> cout<<fixed<<setprecision(9)<<md.time_spec.get_real_secs()<<endl;
>>>>> //Not full sec
>>>>>
>>>>> }
>>>>>
>>>>> timeout = 0.1;
>>>>>
>>>>> nbSamp+=num_rx_samps;
>>>>>
>>>>> ...
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> May be i don't use the right method to extract the time from the
>>>>> time spec
>>>> ?
>>>>>
>>>>> Since i wrote this from memory it is possible that there is an
>>>>> error in my actual code and not here...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Damien
>>>>>
>>>>>
>>>>>
>>>>> 2013/2/1 Nick Foster <[email protected]>
>>>>>
>>>>> On 01/31/2013 04:00 PM, Damien Serant wrote:
>>>>>
>>>>> Hi list,
>>>>>
>>>>>
>>>>>
>>>>> Two small issues about 1PPS signal with the GPSDO:
>>>>>
>>>>> 1) When i run the query_gpsdo_sensors util i obtain : "GPS
>>>>> locked",
>>>>> "10 MHz" locked but always "GPS and UHD Device time are NOT aligned"
>>>>> (I triple checked the 1PPS connection)
>>>>>
>>>>> We just recently fixed a bug relating to this. The PPS
>>>>> functionality is fine; the query_gpsdo_sensors program wasn't
>>>>> waiting long enough to be sure the PPS had been latched in. It's
>>>>> checked into master, but I don't think a release has been cut
>>>>> since
> then.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2) I my program the time get from the "get_time_last_pps()"
>>>>> function is surprisingly never a full second (about 500 ns before
>>>>> or after a full second). In the same way, when i set the time spec
>>>>> of a receiver stream with get_time_last_pps() + 1, i never get a
>>>>> full second in the time spec field of the metadata of the first
>>>>> received
>>> packet .
>>>>>
>>>>> This is a normal behavior and if yes why ?
>>>>>
>>>>> Can you cut and paste the relevant section of code?
>>>>>
>>>>> --n
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Configuration; win XP, USRP N200 r4 with SBX daughterboard, UHD 351.
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>>
>>>>> Damien
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>
>>
>
------------------------------
Message: 6
Date: Fri, 08 Feb 2013 16:15:17 -0600
From: Josh Blum <[email protected]>
To: Roy Thompson <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Using multiple RX DDC chains on USRP2
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 02/08/2013 02:53 PM, Roy Thompson wrote:
> Is there any way to stream both channels with different rates into the
> same flowgraph in GNURadio (i.e. 2 sources)? From what I can tell,
> the answer is no but I figured I'd ask before trying to come up with a
> hack for it.
Now that I am thinking about it. You could have two source blocks with
the same device address, because its the same underlying device object.
We just need a way to select different channels when the source block
creates the rx streamer. The rest of the properties should map ok.
So, we have a way to specify the streamer args from python, I just dont
think GRC brings it out. Basically the stream args.channels is a list of
channels. So for one usrp source this is going to be [0], and the other [1]
http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/include/gr_uhd_usrp_source.h#n88
http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1stream__args__t.html
I would see how grc generates the python code for 1 channel.
-josh
>
> Thanks,
> Roy
>
> On Thu, Feb 7, 2013 at 4:41 PM, Josh Blum <[email protected]> wrote:
>>
>>
>> On 02/07/2013 03:30 PM, Roy Thompson wrote:
>>> Thanks, will that work if the chains have different sample rates?
>>> There is a comment in multi_usrp.hpp stating that all channels must
>>> have the same rate, but it's not clear what causes the limitation
>>> since it looks like it is possible to set the rate for individual
>>> channels with set_rx_rate().
>>
>> Yes, all the api calls take a channel number. So in this case, you would
>> want a different rx_streamer for each channel, since they are at
>> different rates.
>>
>> -josh
>>
>>>
>>> -Roy
>>>
>>> On Thu, Feb 7, 2013 at 4:17 PM, Josh Blum <[email protected]> wrote:
>>>>
>>>>
>>>> On 02/07/2013 02:49 PM, Roy Thompson wrote:
>>>>> I am starting to look through some of the FPGA code for the USRP2 and
>>>>> I noticed that there are 2 RX DDC chains. I would like to be able to
>>>>> use one of the chains to do standard DDC processing, and I would like
>>>>> to modify the second chain to do custom processing on the same A/D
>>>>> channel. The output sample rate for the second chain will be
>>>>> different from the first. Is it possible to configure the UHD driver
>>>>> to support this configuration and allow for receiving from both
>>>>> chains?
>>>>>
>>>>
>>>> The rx_multi_samples example can show you how to use two DDC chains. If
>>>> you had a WBX for example with frontend (named 0), this would map
>>>> frontend 0 located on the first and only daughterboard (named A) to DSP0
>>>> and DSP1 --subdev="A:0 A:0"
>>>>
>>>> see the --help for more.
>>>>
>>>>> std::cout <<
>>>>> " This is a demonstration of how to receive aligned data from
>>>>> multiple channels.\n"
>>>>> " This example can receive from multiple DSPs, multiple
>>>>> motherboards, or both.\n"
>>>>> " The MIMO cable or PPS can be used to synchronize the
>>>>> configuration. See --sync\n"
>>>>> "\n"
>>>>> " Specify --subdev to select multiple channels per
>>>>> motherboard.\n"
>>>>> " Ex: --subdev=\"0:A 0:B\" to get 2 channels on a Basic
>>>>> RX.\n"
>>>>> "\n"
>>>>> " Specify --args to select multiple motherboards in a
>>>>> configuration.\n"
>>>>> " Ex: --args=\"addr0=192.168.10.2, addr1=192.168.10.3\"\n"
>>>>> << std::endl;
>>>>
>>>>
>>>> See this readme, there is a place where it should be convenient to
>>>> replace the DDC with custom logic:
>>>>
>>>> http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/fpga/README.txt
>>>>
>>>> -josh
>>>>
>>>>> Thanks,
>>>>> Roy
>>>>>
>>>>> _______________________________________________
>>>>> 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: 7
Date: Fri, 8 Feb 2013 17:47:14 -0500
From: gang li <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: [USRP-users] [Discuss-gnuradio] SBX TX/RX RX leakage
Message-ID:
<cakro2l1qhnkwi9ikhazggrte6sprfhfpsd0ehk29upa7m5x...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Yes. I am doing full duplex on the same frequency, transmitting from
TX/RX and receiving on RX2 at the same time. When I put the antennas
far way from each other, the received signal amplitude is very low.
And when I change the distance between them, i found the received
signal amplitude is kind of stable. So i think maybe the leakage takes
the major. Am I right?
On Fri, Feb 8, 2013 at 4:26 PM, Marcus D. Leech <[email protected]> wrote:
> On 02/08/2013 04:10 PM, gang li wrote:
>>
>> When the signal received on RF2 port has a very weak strength, the
>> energy leaked from TX to RX will dominate in the total received
>> energy. I have observed this in my experiments. Are there any ways to
>> measure the leaked signal so i can compensate it? I am thinking a way
>> of by connecting the RF1 and RF2 ports with a long cable and 60db
>> attenuators. And then i record the received signal. I assume it is the
>> leaked signal from TX. Are there any better ways? Thanks for your
>> reply.
>>
>> Best,
>> Gang
>
> Are you TX/RX on the same frequency, or different frequencies?
>
> The usual way to deal with this on different-frequency setups is to use a
> duplexor, or a deep notch filter on the RX port, and probably boost your
> antenna signal a bit with an external amplifier.
>
> But if this is *same-frequency* duplex, the on-board leakage is really minor
> compared to the coupling between your antennae.
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
------------------------------
Message: 8
Date: Fri, 8 Feb 2013 18:55:51 -0500
From: Roy Thompson <[email protected]>
To: "[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Using multiple RX DDC chains on USRP2
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Thanks, I was able to get it working by creating a new GRC XML file that sets
the channels parameter in the stream args as you suggested. I also had to
update gr_uhd_usrp_source to allow for specifying a channel to set_samp_rate().
-Roy
On Feb 8, 2013, at 5:15 PM, Josh Blum <[email protected]> wrote:
>
>
> On 02/08/2013 02:53 PM, Roy Thompson wrote:
>> Is there any way to stream both channels with different rates into the
>> same flowgraph in GNURadio (i.e. 2 sources)? From what I can tell,
>> the answer is no but I figured I'd ask before trying to come up with a
>> hack for it.
>
> Now that I am thinking about it. You could have two source blocks with
> the same device address, because its the same underlying device object.
> We just need a way to select different channels when the source block
> creates the rx streamer. The rest of the properties should map ok.
>
> So, we have a way to specify the streamer args from python, I just dont
> think GRC brings it out. Basically the stream args.channels is a list of
> channels. So for one usrp source this is going to be [0], and the other [1]
>
> http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/include/gr_uhd_usrp_source.h#n88
>
> http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1stream__args__t.html
>
> I would see how grc generates the python code for 1 channel.
>
> -josh
>
>>
>> Thanks,
>> Roy
>>
>> On Thu, Feb 7, 2013 at 4:41 PM, Josh Blum <[email protected]> wrote:
>>>
>>>
>>> On 02/07/2013 03:30 PM, Roy Thompson wrote:
>>>> Thanks, will that work if the chains have different sample rates?
>>>> There is a comment in multi_usrp.hpp stating that all channels must
>>>> have the same rate, but it's not clear what causes the limitation
>>>> since it looks like it is possible to set the rate for individual
>>>> channels with set_rx_rate().
>>>
>>> Yes, all the api calls take a channel number. So in this case, you would
>>> want a different rx_streamer for each channel, since they are at
>>> different rates.
>>>
>>> -josh
>>>
>>>>
>>>> -Roy
>>>>
>>>> On Thu, Feb 7, 2013 at 4:17 PM, Josh Blum <[email protected]> wrote:
>>>>>
>>>>>
>>>>> On 02/07/2013 02:49 PM, Roy Thompson wrote:
>>>>>> I am starting to look through some of the FPGA code for the USRP2 and
>>>>>> I noticed that there are 2 RX DDC chains. I would like to be able to
>>>>>> use one of the chains to do standard DDC processing, and I would like
>>>>>> to modify the second chain to do custom processing on the same A/D
>>>>>> channel. The output sample rate for the second chain will be
>>>>>> different from the first. Is it possible to configure the UHD driver
>>>>>> to support this configuration and allow for receiving from both
>>>>>> chains?
>>>>>
>>>>> The rx_multi_samples example can show you how to use two DDC chains. If
>>>>> you had a WBX for example with frontend (named 0), this would map
>>>>> frontend 0 located on the first and only daughterboard (named A) to DSP0
>>>>> and DSP1 --subdev="A:0 A:0"
>>>>>
>>>>> see the --help for more.
>>>>>
>>>>>> std::cout <<
>>>>>> " This is a demonstration of how to receive aligned data from
>>>>>> multiple channels.\n"
>>>>>> " This example can receive from multiple DSPs, multiple
>>>>>> motherboards, or both.\n"
>>>>>> " The MIMO cable or PPS can be used to synchronize the
>>>>>> configuration. See --sync\n"
>>>>>> "\n"
>>>>>> " Specify --subdev to select multiple channels per
>>>>>> motherboard.\n"
>>>>>> " Ex: --subdev=\"0:A 0:B\" to get 2 channels on a Basic
>>>>>> RX.\n"
>>>>>> "\n"
>>>>>> " Specify --args to select multiple motherboards in a
>>>>>> configuration.\n"
>>>>>> " Ex: --args=\"addr0=192.168.10.2, addr1=192.168.10.3\"\n"
>>>>>> << std::endl;
>>>>>
>>>>>
>>>>> See this readme, there is a place where it should be convenient to
>>>>> replace the DDC with custom logic:
>>>>>
>>>>> http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/fpga/README.txt
>>>>>
>>>>> -josh
>>>>>
>>>>>> Thanks,
>>>>>> Roy
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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: 9
Date: Fri, 8 Feb 2013 20:32:16 -0500
From: Jeff Scaparra <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] TX/RX protections
Message-ID:
<CALWgEa2+ze=8sxfdtxhzvttzdek3ugccxnmnmpvd8z83qta...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
What protections if any do I need to ensure I have in place to allow for TX
and RX on the same antenna.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130208/424bd20d/attachment-0001.html>
------------------------------
Message: 10
Date: Fri, 08 Feb 2013 19:42:24 -0600
From: Josh Blum <[email protected]>
To: Roy Thompson <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Using multiple RX DDC chains on USRP2
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 02/08/2013 05:55 PM, Roy Thompson wrote:
> Thanks, I was able to get it working by creating a new GRC XML file
> that sets the channels parameter in the stream args as you suggested.
> I also had to update gr_uhd_usrp_source to allow for specifying a
> channel to set_samp_rate().
Thats great. Can you send the patch in?
I think the sample rate part can be fixed without changing any of the
external interface or wrappers, inside the source cc file we can use the
stream args channels are the argument to setting the samp rate.
So I think just the xml file needs a new parameter to specify the
desired channel
-josh
>
> -Roy
>
>
>
> On Feb 8, 2013, at 5:15 PM, Josh Blum <[email protected]> wrote:
>
>>
>>
>> On 02/08/2013 02:53 PM, Roy Thompson wrote:
>>> Is there any way to stream both channels with different rates
>>> into the same flowgraph in GNURadio (i.e. 2 sources)? From what
>>> I can tell, the answer is no but I figured I'd ask before trying
>>> to come up with a hack for it.
>>
>> Now that I am thinking about it. You could have two source blocks
>> with the same device address, because its the same underlying
>> device object. We just need a way to select different channels when
>> the source block creates the rx streamer. The rest of the
>> properties should map ok.
>>
>> So, we have a way to specify the streamer args from python, I just
>> dont think GRC brings it out. Basically the stream args.channels is
>> a list of channels. So for one usrp source this is going to be [0],
>> and the other [1]
>>
>> http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/include/gr_uhd_usrp_source.h#n88
>>
>>
>>
http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1stream__args__t.html
>>
>> I would see how grc generates the python code for 1 channel.
>>
>> -josh
>>
>>>
>>> Thanks, Roy
>>>
>>> On Thu, Feb 7, 2013 at 4:41 PM, Josh Blum <[email protected]>
>>> wrote:
>>>>
>>>>
>>>> On 02/07/2013 03:30 PM, Roy Thompson wrote:
>>>>> Thanks, will that work if the chains have different sample
>>>>> rates? There is a comment in multi_usrp.hpp stating that all
>>>>> channels must have the same rate, but it's not clear what
>>>>> causes the limitation since it looks like it is possible to
>>>>> set the rate for individual channels with set_rx_rate().
>>>>
>>>> Yes, all the api calls take a channel number. So in this case,
>>>> you would want a different rx_streamer for each channel, since
>>>> they are at different rates.
>>>>
>>>> -josh
>>>>
>>>>>
>>>>> -Roy
>>>>>
>>>>> On Thu, Feb 7, 2013 at 4:17 PM, Josh Blum <[email protected]>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> On 02/07/2013 02:49 PM, Roy Thompson wrote:
>>>>>>> I am starting to look through some of the FPGA code for
>>>>>>> the USRP2 and I noticed that there are 2 RX DDC chains.
>>>>>>> I would like to be able to use one of the chains to do
>>>>>>> standard DDC processing, and I would like to modify the
>>>>>>> second chain to do custom processing on the same A/D
>>>>>>> channel. The output sample rate for the second chain
>>>>>>> will be different from the first. Is it possible to
>>>>>>> configure the UHD driver to support this configuration
>>>>>>> and allow for receiving from both chains?
>>>>>>
>>>>>> The rx_multi_samples example can show you how to use two
>>>>>> DDC chains. If you had a WBX for example with frontend
>>>>>> (named 0), this would map frontend 0 located on the first
>>>>>> and only daughterboard (named A) to DSP0 and DSP1
>>>>>> --subdev="A:0 A:0"
>>>>>>
>>>>>> see the --help for more.
>>>>>>
>>>>>>> std::cout << " This is a demonstration of how to
>>>>>>> receive aligned data from multiple channels.\n" " This
>>>>>>> example can receive from multiple DSPs, multiple
>>>>>>> motherboards, or both.\n" " The MIMO cable or PPS can
>>>>>>> be used to synchronize the configuration. See --sync\n"
>>>>>>> "\n" " Specify --subdev to select multiple channels
>>>>>>> per motherboard.\n" " Ex: --subdev=\"0:A 0:B\" to
>>>>>>> get 2 channels on a Basic RX.\n" "\n" " Specify --args
>>>>>>> to select multiple motherboards in a configuration.\n" "
>>>>>>> Ex: --args=\"addr0=192.168.10.2, addr1=192.168.10.3\"\n"
>>>>>>> << std::endl;
>>>>>>
>>>>>>
>>>>>> See this readme, there is a place where it should be
>>>>>> convenient to replace the DDC with custom logic:
>>>>>>
>>>>>> http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/fpga/README.txt
>>>>>>
>>>>>>
>>>>>>
-josh
>>>>>>
>>>>>>> Thanks, Roy
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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: 11
Date: Fri, 8 Feb 2013 21:22:43 -0500
From: Roy Thompson <[email protected]>
To: [email protected]
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Using multiple RX DDC chains on USRP2
Message-ID:
<caozutcgzej6xhcvfnsg8bdcsyro8yd1aot1jhsoetlexrjw...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Sure, I created Issue #515 and will send a patch in once I update it
to work how you suggested (i.e. no API changes).
-Roy
On Fri, Feb 8, 2013 at 8:42 PM, Josh Blum <[email protected]> wrote:
>
>
> On 02/08/2013 05:55 PM, Roy Thompson wrote:
>> Thanks, I was able to get it working by creating a new GRC XML file
>> that sets the channels parameter in the stream args as you suggested.
>> I also had to update gr_uhd_usrp_source to allow for specifying a
>> channel to set_samp_rate().
>
> Thats great. Can you send the patch in?
>
> I think the sample rate part can be fixed without changing any of the
> external interface or wrappers, inside the source cc file we can use the
> stream args channels are the argument to setting the samp rate.
>
> So I think just the xml file needs a new parameter to specify the
> desired channel
>
> -josh
>
>>
>> -Roy
>>
>>
>>
>> On Feb 8, 2013, at 5:15 PM, Josh Blum <[email protected]> wrote:
>>
>>>
>>>
>>> On 02/08/2013 02:53 PM, Roy Thompson wrote:
>>>> Is there any way to stream both channels with different rates
>>>> into the same flowgraph in GNURadio (i.e. 2 sources)? From what
>>>> I can tell, the answer is no but I figured I'd ask before trying
>>>> to come up with a hack for it.
>>>
>>> Now that I am thinking about it. You could have two source blocks
>>> with the same device address, because its the same underlying
>>> device object. We just need a way to select different channels when
>>> the source block creates the rx streamer. The rest of the
>>> properties should map ok.
>>>
>>> So, we have a way to specify the streamer args from python, I just
>>> dont think GRC brings it out. Basically the stream args.channels is
>>> a list of channels. So for one usrp source this is going to be [0],
>>> and the other [1]
>>>
>>> http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/include/gr_uhd_usrp_source.h#n88
>>>
>>>
>>>
> http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1stream__args__t.html
>>>
>>> I would see how grc generates the python code for 1 channel.
>>>
>>> -josh
>>>
>>>>
>>>> Thanks, Roy
>>>>
>>>> On Thu, Feb 7, 2013 at 4:41 PM, Josh Blum <[email protected]>
>>>> wrote:
>>>>>
>>>>>
>>>>> On 02/07/2013 03:30 PM, Roy Thompson wrote:
>>>>>> Thanks, will that work if the chains have different sample
>>>>>> rates? There is a comment in multi_usrp.hpp stating that all
>>>>>> channels must have the same rate, but it's not clear what
>>>>>> causes the limitation since it looks like it is possible to
>>>>>> set the rate for individual channels with set_rx_rate().
>>>>>
>>>>> Yes, all the api calls take a channel number. So in this case,
>>>>> you would want a different rx_streamer for each channel, since
>>>>> they are at different rates.
>>>>>
>>>>> -josh
>>>>>
>>>>>>
>>>>>> -Roy
>>>>>>
>>>>>> On Thu, Feb 7, 2013 at 4:17 PM, Josh Blum <[email protected]>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 02/07/2013 02:49 PM, Roy Thompson wrote:
>>>>>>>> I am starting to look through some of the FPGA code for
>>>>>>>> the USRP2 and I noticed that there are 2 RX DDC chains.
>>>>>>>> I would like to be able to use one of the chains to do
>>>>>>>> standard DDC processing, and I would like to modify the
>>>>>>>> second chain to do custom processing on the same A/D
>>>>>>>> channel. The output sample rate for the second chain
>>>>>>>> will be different from the first. Is it possible to
>>>>>>>> configure the UHD driver to support this configuration
>>>>>>>> and allow for receiving from both chains?
>>>>>>>
>>>>>>> The rx_multi_samples example can show you how to use two
>>>>>>> DDC chains. If you had a WBX for example with frontend
>>>>>>> (named 0), this would map frontend 0 located on the first
>>>>>>> and only daughterboard (named A) to DSP0 and DSP1
>>>>>>> --subdev="A:0 A:0"
>>>>>>>
>>>>>>> see the --help for more.
>>>>>>>
>>>>>>>> std::cout << " This is a demonstration of how to
>>>>>>>> receive aligned data from multiple channels.\n" " This
>>>>>>>> example can receive from multiple DSPs, multiple
>>>>>>>> motherboards, or both.\n" " The MIMO cable or PPS can
>>>>>>>> be used to synchronize the configuration. See --sync\n"
>>>>>>>> "\n" " Specify --subdev to select multiple channels
>>>>>>>> per motherboard.\n" " Ex: --subdev=\"0:A 0:B\" to
>>>>>>>> get 2 channels on a Basic RX.\n" "\n" " Specify --args
>>>>>>>> to select multiple motherboards in a configuration.\n" "
>>>>>>>> Ex: --args=\"addr0=192.168.10.2, addr1=192.168.10.3\"\n"
>>>>>>>> << std::endl;
>>>>>>>
>>>>>>>
>>>>>>> See this readme, there is a place where it should be
>>>>>>> convenient to replace the DDC with custom logic:
>>>>>>>
>>>>>>> http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/fpga/README.txt
>>>>>>>
>>>>>>>
>>>>>>>
> -josh
>>>>>>>
>>>>>>>> Thanks, Roy
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
------------------------------
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 9
*****************************************
