[Discuss-gnuradio] USRP2 with a Switch
Dear all, We have 12 USRP2 boards which we would like to synchronise and run in a phase array system as an expansion of the 4 element system we currently have running using the VRT branch of GNURadio. Currently we use a 4 port PCIe Gb Ethernet Card to connect the USRP2 boards to the host computer. Our Communications group suggested that we could use an Ethernet switch to support 12 boards instead of trying to find a computer we can stuff that many Ethernet cards in to. Data from all 4 boards should get streamed into a data buffer on the switch and then be accessed sequentially by the host computer at a rate to avoid the over-run of the buffers. Switches work on the ethernet layer and hence the protocol should be compatible. We have read about some problems on the forums regarding using a switch for the USRP2's. Does anybody know if it is a realistic task to be able to use a switch to stream data in from multiple boards in this manner and how one might start in creating a system which can do this? Does a new protocol for sending packets to the computer need to be created. If so then where is the current protocol specified? Best regards, Valentin. -- View this message in context: http://old.nabble.com/USRP2-with-a-Switch-tp28003797p28003797.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 with a Switch
Dear all, We have 12 USRP2 boards which we would like to synchronise and run in a phase array system as an expansion of the 4 element system we currently have running using the VRT branch of GNURadio. Currently we use a 4 port PCIe Gb Ethernet Card to connect the USRP2 boards to the host computer. Our Communications group suggested that we could use an Ethernet switch to support 12 boards instead of trying to find a computer we can stuff that many Ethernet cards in to. Data from all 4 boards should get streamed into a data buffer on the switch and then be accessed sequentially by the host computer at a rate to avoid the over-run of the buffers. Switches work on the ethernet layer and hence the protocol should be compatible. We have read about some problems on the forums regarding using a switch for the USRP2's. Does anybody know if it is a realistic task to be able to use a switch to stream data in from multiple boards in this manner and how one might start in creating a system which can do this? Does a new protocol for sending packets to the computer need to be created. If so then where is the current protocol specified? Best regards, Marc. -- View this message in context: http://old.nabble.com/USRP2-with-a-Switch-tp28003772p28003772.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP synchronization
Hi Matt, hope you had a good trip. We've managed to work around the ambiguity using calibration, but we are still interested in that other technique that you've mentioned earlier. Also we have trouble understanding the meanings of the phase ambiguities we are observing. We use a centre frequency of 2.45G which implies a 2-way ambiguity, doesn't this mean that 2 boards should have a phase of 0 or 180 with respect to each other? But we don't observe this... Kind regards, Valentin Matt Ettus wrote: > > > I'll be away until the 22nd, but will give you an update on the possible > improved method when I get back. > > Matt > > > On 03/11/2010 12:28 PM, ValentinG wrote: >> >>> It depends where you are measuring. The main 100 MHz clock should >>> always come up with the same phase. >> >> Ok we've found the problem, we were measuring a 10MHz signal on the test >> pins which is derived from 100MHz, therefore has a 10-way ambiguity, >> hence >> different phases after power cycling... Checked the actual clock and it's >> fine. >> >>> Basically, divisions produce ambiguity, multiplications remove it. To >>> take an example -- assume you are using a 10 MHz reference and your >>> final LO frequency is 2450 MHz. The 10 MHz reference is multiplied up >>> to 100 MHz, and will have no phase ambiguity. The 100 MHz is sent to >>> each daughterboard where it is divided by 16 to create the 6.25 MHz >>> compare frequency. This will have a 16-way ambiguity. This is then >>> multiplied up by 392 to get 2450. 16 is not a factor of 392, but 8 is. >>> So 16/8 = 2 and you get a 2-way ambiguity. >> >>> If, on the other hand, you choose 2456.25 MHz for your LO frequency, the >>> multiplication factor is 393, which shares no common factors with 16, >>> and so you have 16-way ambiguity. By judiciously choosing your R >>> divider and LO frequency, you can often get rid of the ambiguity. >> >> In the example above you use the factor of 16 at the very start, where >> does >> it come from? Is it the decimation rate we use or it can be arbitrary? >> >>> I actually just thought of another possible way to do this which might >>> be even better, so let me think about that and I'll get back to you. >> >> Great!:) >> >> We have modified our c++ code to send all the configuration commands to >> the >> USRP2 boards (frequency, decimation, etc.) at the very start and pause. >> Then >> we perform 4 fetches of data, pausing after each one. 3 of those are then >> used to get calibration data, which is then used to refine the results of >> the 4th fetch. Is this a correct approach? >> >> We have also tried sending all the configuration commands using a >> separate >> c++ script and then using a different script to perform the fetches, but >> that doesn't seem to work. Is that because every time the usrp2:make >> command >> is called it resets the configuration of the board? >> >> Regards, >> Valentin >> >> >> >> >> >> >> >> Matt Ettus wrote: >>> >>> On 03/10/2010 06:39 AM, ValentinG wrote: >>>> >>>> Thanks a lot for the answers! >>>> >>>> Yes all of our boards are USRP2s. >>>> >>>> We do have a common PPS signal provided by the external signal >>>> generator. >>>> We >>>> use code from the VRT branch and call set_time_at_next_pps for all 4 >>>> boards >>>> to reset their times. Then we call start streaming for all 4 boards >>>> some >>>> seconds later. This as we understand ensures the alignment of the >>>> samples >>>> received. >>> >>> OK, then you just have the RF phase issues. >>> >>>> >>>> We use RFX2400 daughterboards. >>>> >>>> There are a few other questions we wanted to ask: >>>> >>>> 1.) We observe a phase shift between MB clocks on different USRP2 >>>> MotherBoards which changes each time the USRP2 is reset. Is there a >>>> finite >>>> number of possibilities for that phase difference due to its PLL? How >>>> many >>>> are there? >>> >>> It depends where you are measuring. The main 100 MHz clock should >>> always come up with the same phase. >>> >>>> 2.) Does the PLL on the daughterboards uses the clock, generated on the >>>> MBs >>>>
Re: [Discuss-gnuradio] USRP synchronization
> It depends where you are measuring. The main 100 MHz clock should >always come up with the same phase. Ok we've found the problem, we were measuring a 10MHz signal on the test pins which is derived from 100MHz, therefore has a 10-way ambiguity, hence different phases after power cycling... Checked the actual clock and it's fine. >Basically, divisions produce ambiguity, multiplications remove it. To >take an example -- assume you are using a 10 MHz reference and your >final LO frequency is 2450 MHz. The 10 MHz reference is multiplied up >to 100 MHz, and will have no phase ambiguity. The 100 MHz is sent to >each daughterboard where it is divided by 16 to create the 6.25 MHz >compare frequency. This will have a 16-way ambiguity. This is then >multiplied up by 392 to get 2450. 16 is not a factor of 392, but 8 is. > So 16/8 = 2 and you get a 2-way ambiguity. >If, on the other hand, you choose 2456.25 MHz for your LO frequency, the >multiplication factor is 393, which shares no common factors with 16, >and so you have 16-way ambiguity. By judiciously choosing your R >divider and LO frequency, you can often get rid of the ambiguity. In the example above you use the factor of 16 at the very start, where does it come from? Is it the decimation rate we use or it can be arbitrary? >I actually just thought of another possible way to do this which might >be even better, so let me think about that and I'll get back to you. Great!:) We have modified our c++ code to send all the configuration commands to the USRP2 boards (frequency, decimation, etc.) at the very start and pause. Then we perform 4 fetches of data, pausing after each one. 3 of those are then used to get calibration data, which is then used to refine the results of the 4th fetch. Is this a correct approach? We have also tried sending all the configuration commands using a separate c++ script and then using a different script to perform the fetches, but that doesn't seem to work. Is that because every time the usrp2:make command is called it resets the configuration of the board? Regards, Valentin Matt Ettus wrote: > > On 03/10/2010 06:39 AM, ValentinG wrote: >> >> Thanks a lot for the answers! >> >> Yes all of our boards are USRP2s. >> >> We do have a common PPS signal provided by the external signal generator. >> We >> use code from the VRT branch and call set_time_at_next_pps for all 4 >> boards >> to reset their times. Then we call start streaming for all 4 boards some >> seconds later. This as we understand ensures the alignment of the samples >> received. > > OK, then you just have the RF phase issues. > >> >> We use RFX2400 daughterboards. >> >> There are a few other questions we wanted to ask: >> >> 1.) We observe a phase shift between MB clocks on different USRP2 >> MotherBoards which changes each time the USRP2 is reset. Is there a >> finite >> number of possibilities for that phase difference due to its PLL? How >> many >> are there? > > It depends where you are measuring. The main 100 MHz clock should > always come up with the same phase. > >> 2.) Does the PLL on the daughterboards uses the clock, generated on the >> MBs >> as a reference to lock the VCO signal used for downconversion? Or does it >> use the external 10MHz clock as the reference? > > It uses the clock from the motherboard, not the 10 MHz reference. > >> 3.) If there is a finite number for the phase differences (N) between MB >> clocks and these are used to produce the down-converter signal, which can >> also have a finite number of phase differences (M), this would imply that >> we >> can have NxM different phases, correct? > > Basically, divisions produce ambiguity, multiplications remove it. To > take an example -- assume you are using a 10 MHz reference and your > final LO frequency is 2450 MHz. The 10 MHz reference is multiplied up > to 100 MHz, and will have no phase ambiguity. The 100 MHz is sent to > each daughterboard where it is divided by 16 to create the 6.25 MHz > compare frequency. This will have a 16-way ambiguity. This is then > multiplied up by 392 to get 2450. 16 is not a factor of 392, but 8 is. > So 16/8 = 2 and you get a 2-way ambiguity. > > If, on the other hand, you choose 2456.25 MHz for your LO frequency, the > multiplication factor is 393, which shares no common factors with 16, > and so you have 16-way ambiguity. By judiciously choosing your R > divider and LO frequency, you can often get rid of the ambiguity. > > I actually just thought of another possible way to do this which might > be even better, so let me think about that and I'
Re: [Discuss-gnuradio] USRP synchronization
Thanks a lot for the answers! Yes all of our boards are USRP2s. We do have a common PPS signal provided by the external signal generator. We use code from the VRT branch and call set_time_at_next_pps for all 4 boards to reset their times. Then we call start streaming for all 4 boards some seconds later. This as we understand ensures the alignment of the samples received. We use RFX2400 daughterboards. There are a few other questions we wanted to ask: 1.) We observe a phase shift between MB clocks on different USRP2 MotherBoards which changes each time the USRP2 is reset. Is there a finite number of possibilities for that phase difference due to its PLL? How many are there? 2.) Does the PLL on the daughterboards uses the clock, generated on the MBs as a reference to lock the VCO signal used for downconversion? Or does it use the external 10MHz clock as the reference? 3.) If there is a finite number for the phase differences (N) between MB clocks and these are used to produce the down-converter signal, which can also have a finite number of phase differences (M), this would imply that we can have NxM different phases, correct? 4.) Do the PLL's on the daugherboard tune every time a C++ or Python program is run or every time the board is powered on? i.e. for phased arrays will we just need to calibrate every time the board is powered on or every time we take a given stream of data? 5.) How can we change the number of possible phases for the daughterboard? 6.) Does reducing this number increase lock time? 7.) How can we tune so there is no ambiguity in the phase of the boards like you suggested? Thanks, Valentin Matt Ettus wrote: > > On 03/09/2010 09:20 AM, ValentinG wrote: >> >> Hi All, >> >> We are trying to use 4 USRPs to extract the phase information due to >> differences in positions of the antennas. >> >> In a standard communications system an internally generated carrier is >> locked IN PHASE with the incoming signal to perform downconversion (see >> Figure 1.). >> http://old.nabble.com/file/p27838821/Fig%2B1%2BUSRP%2Bv2.jpg >> >> As mentioned above we are using 4 USRPs to receive a signal from a single >> source. We wish to retain the phase information of this signal between >> boxes >> due to the different positions of the antennas. We feed all 4 boxes with >> a >> clock reference signal (10MHz, 1.5Vpk-pk), so that their internal clocks >> should be locked in phase with respect to each other. Are the internally >> generated carriers generated using this clock as a phase reference, i.e. >> is >> it correct, that this should also make all the internally generated >> carriers >> have zero phase difference between the boxes instead of locking to the >> phases of the incoming signals (see Figure 2.)? >> http://old.nabble.com/file/p27838821/Fig%2B2%2BUSRP%2Bv2.jpg >> >> However, when we observe the internal clocks of 4 USRPs they are phase >> locked with respect to one another, but THERE IS A PHASE DIFFERENCE >> BETWEEN >> THEM, which is constant for a given power cycle. Does this imply that the >> phases of the internally generated carriers are locked to one another, >> but >> also with some NON 0 PHASE difference, i.e. that our actual system looks >> like Figure 3? >> http://old.nabble.com/file/p27838821/Fig%2B3%2BUSRP%2Bv3.jpg >> >> Thanks, >> Valentin. > > > I assume you are using all USRP2s. There are multiple sources of > ambiguity here. > > First, unless you are using a common PPS signal to all systems, using > sync_on_pps, your time samples won't be aligned. Think of it this way > -- everyone's watch is running at the same speed, but everybody thinks > the time is different because you haven't coordinated. That's what the > PPS is for > > Second, and this is what Eric mentioned, the PLLs on the daughterboards > will all be locked to the same reference, but they can have an arbitrary > offset which will change every time you tune. The important thing is > that the relative phases don't change with time. This means you can do > MIMO operations, but phased-arrays will require you to calibrate every > time. You can use the TX side of the RFX-series as a signal generate to > do this, but it will take some software. > > You didn't tell us what daughterboards you are using. The ones with the > integer-N PLLs (DBSRX, RFX-series) will have a finite number of > possibilities for that phase difference, usually less than 25, and you > can tune in such a way that there is no ambiguity if you are careful. > The fractional-N ones (XCVR2450, WBX) will have an effectively infinite > number of possibilities, but you can still measure
[Discuss-gnuradio] USRP synchronization
Hi All, We are trying to use 4 USRPs to extract the phase information due to differences in positions of the antennas. In a standard communications system an internally generated carrier is locked IN PHASE with the incoming signal to perform downconversion (see Figure 1.). http://old.nabble.com/file/p27838821/Fig%2B1%2BUSRP%2Bv2.jpg As mentioned above we are using 4 USRPs to receive a signal from a single source. We wish to retain the phase information of this signal between boxes due to the different positions of the antennas. We feed all 4 boxes with a clock reference signal (10MHz, 1.5Vpk-pk), so that their internal clocks should be locked in phase with respect to each other. Are the internally generated carriers generated using this clock as a phase reference, i.e. is it correct, that this should also make all the internally generated carriers have zero phase difference between the boxes instead of locking to the phases of the incoming signals (see Figure 2.)? http://old.nabble.com/file/p27838821/Fig%2B2%2BUSRP%2Bv2.jpg However, when we observe the internal clocks of 4 USRPs they are phase locked with respect to one another, but THERE IS A PHASE DIFFERENCE BETWEEN THEM, which is constant for a given power cycle. Does this imply that the phases of the internally generated carriers are locked to one another, but also with some NON 0 PHASE difference, i.e. that our actual system looks like Figure 3? http://old.nabble.com/file/p27838821/Fig%2B3%2BUSRP%2Bv3.jpg Thanks, Valentin. -- View this message in context: http://old.nabble.com/USRP-synchronization-tp27838821p27838821.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP synchronization
Hi All, We are trying to use 4 USRPs to extract the phase information due to differences in positions of the antennas. In a standard communications system an internally generated carrier is locked IN PHASE with the incoming signal to perform downconversion (see Figure 1.). http://old.nabble.com/file/p27838729/Fig%2B1%2BUSRP%2Bv2.jpg As mentioned above we are using 4 USRPs to receive a signal from a single source. We wish to retain the phase information of this signal between boxes due to the different positions of the antennas. We feed all 4 boxes with a clock reference signal (10MHz, 1.5Vpk-pk), so that their internal clocks should be locked in phase with respect to each other. Are the internally generated carriers generated using this clock as a phase reference, i.e. is it correct, that this should also make all the internally generated carriers have zero phase difference between the boxes instead of locking to the phases of the incoming signals (see Figure 2.)? http://old.nabble.com/file/p27838729/Fig%2B2%2BUSRP%2Bv2.jpg However, when we observe the internal clocks of 4 USRPs they are phase locked with respect to one another, but THERE IS A PHASE DIFFERENCE BETWEEN THEM, which is constant for a given power cycle. Does this imply that the phases of the internally generated carriers are locked to one another, but also with some NON 0 PHASE difference, i.e. that our actual system looks like Figure 3? http://old.nabble.com/file/p27838729/Fig%2B3%2BUSRP%2Bv3.jpg Thanks, Valentin. -- View this message in context: http://old.nabble.com/USRP-synchronization-tp27838729p27838729.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Possible bug in the vrt branch firmware?
There was a gap in our understanding what those commands exactly do, and the problem was caused by telling the USRPs to start streaming in the past... Inserting sleep (1) did work. Thanks for the explanations! Valentin Josh Blum-2 wrote: > > If you just re-powered the device, time_spec_t(2, 1) is always a > time in the past (by the time you get to run a usrp2 app) because of the > time it takes for hardware/firmware initialization. If you need to rely > on a specific time to be in the usrp2, use the set_time_now. If you need > to use set_time_at_next_pps, give yourself 1 second to be sure that the > time is latched into the registers before starting to stream. > > In the example you posted, there is no sleep time between the > u2->set_time_at_next_pps(usrp2::time_spec_t(0, 0) and the > u2->start_rx_streaming(0, usrp2::time_spec_t(2, 1). Therefore, > set_time_at_next_pps will not take effect in time for the > start_rx_streaming. And, start_rx_streaming will see a time in the > registers that is unknown and very likely to be larger than > time_spec_t(2, 1). As I said before, I believe there is a bug > related to telling it to start streaming in the past. > > I could be wrong, but try to add the sleep just to remove the issue of > telling it to start to stream with a time in the past. In general, you > will always want to wait at least one second after set_time_at_next_pps > before streaming so you can guarantee known values in the timestamps. > > -Josh > > On 03/08/2010 11:58 AM, ValentinG wrote: >> >> How u2->start_rx_streaming(0, usrp2::time_spec_t(2, 1)) is start >> streaming in the PAST? Isn't it 2 seconds later than the time we reset to >> which is (0,0)? Also we have tried changing the start streaming time to >> (5,1) which didn't help, hence I'm not sure if sleep(1) is going to >> make >> a difference... >> >> >> >> Josh Blum-2 wrote: >>> >>> There have been no recent changes to the images posted at >>> http://www.ettus.com/usrp2_vrt >>> >>> I believe that there is a problem when you tell usrp2 to start streaming >>> at a time in the past. I cannot verify this at the moment. >>> >>> Try putting a sleep(1) after the set time at next pps. By nature, set >>> time at nest pps could take a second (worst case scenario) to latch in >>> new values. >>> >>> -Josh >>> >>> On 03/08/2010 10:12 AM, ValentinG wrote: >>>> >>>> Hi All, >>>> >>>> We've tried editing the rx_timed_samples.cc to set the time on the >>>> USRPs >>>> on >>>> the next pps and then start streaming data some time after, by >>>> inserting >>>> the >>>> following code (instead of the existing one) between rx_handler >>>> my_handler(nsamples) and the while loop: >>>> >>>> >>>> //create a new usrp2 object, set some properties >>>> usrp2::usrp2::sptr u2 = usrp2::usrp2::make(interface, >>>> mac_addr_str); >>>> u2->set_rx_decim(16); >>>> >>>> //set the system time to the usrp2 >>>> u2->set_time_at_next_pps(usrp2::time_spec_t(0, 0)); >>>> >>>> //begin streaming in the future >>>> u2->start_rx_streaming(0, usrp2::time_spec_t(2, 1)); >>>> >>>> this code used to work in the middle of last week. We had to reflash >>>> our >>>> SD >>>> cards on Friday, so we downloaded the firmware from >>>> http://www.ettus.com/usrp2_vrt and flashed our cards with it. After >>>> doing >>>> that the above code just stopped working. Was there an update of >>>> firmware >>>> some time last week? >>>> >>>> Strangely enough it works if we set the time of the usrps to 200,0 >>>> instead >>>> of 0,0 and start streaming at 202, 1. But this fix only works for >>>> one >>>> acquisition, i.e. if we run the code one more time it just freezes and >>>> doesn't do anything, so to run it again we have to reset the usrps. >>>> >>>> We're using 1Hz TTL PPS as required by the USRP2 spec. >>>> >>>> Any ideas? >>>> >>>> Valentin >>>> >>>> >>> >>> >>> ___ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://old.nabble.com/Possible-bug-in-the-vrt-branch-firmware--tp27825201p27833980.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Possible bug in the vrt branch firmware?
How u2->start_rx_streaming(0, usrp2::time_spec_t(2, 1)) is start streaming in the PAST? Isn't it 2 seconds later than the time we reset to which is (0,0)? Also we have tried changing the start streaming time to (5,1) which didn't help, hence I'm not sure if sleep(1) is going to make a difference... Josh Blum-2 wrote: > > There have been no recent changes to the images posted at > http://www.ettus.com/usrp2_vrt > > I believe that there is a problem when you tell usrp2 to start streaming > at a time in the past. I cannot verify this at the moment. > > Try putting a sleep(1) after the set time at next pps. By nature, set > time at nest pps could take a second (worst case scenario) to latch in > new values. > > -Josh > > On 03/08/2010 10:12 AM, ValentinG wrote: >> >> Hi All, >> >> We've tried editing the rx_timed_samples.cc to set the time on the USRPs >> on >> the next pps and then start streaming data some time after, by inserting >> the >> following code (instead of the existing one) between rx_handler >> my_handler(nsamples) and the while loop: >> >> >>//create a new usrp2 object, set some properties >>usrp2::usrp2::sptr u2 = usrp2::usrp2::make(interface, mac_addr_str); >>u2->set_rx_decim(16); >> >>//set the system time to the usrp2 >>u2->set_time_at_next_pps(usrp2::time_spec_t(0, 0)); >> >>//begin streaming in the future >>u2->start_rx_streaming(0, usrp2::time_spec_t(2, 1)); >> >> this code used to work in the middle of last week. We had to reflash our >> SD >> cards on Friday, so we downloaded the firmware from >> http://www.ettus.com/usrp2_vrt and flashed our cards with it. After doing >> that the above code just stopped working. Was there an update of firmware >> some time last week? >> >> Strangely enough it works if we set the time of the usrps to 200,0 >> instead >> of 0,0 and start streaming at 202, 1. But this fix only works for one >> acquisition, i.e. if we run the code one more time it just freezes and >> doesn't do anything, so to run it again we have to reset the usrps. >> >> We're using 1Hz TTL PPS as required by the USRP2 spec. >> >> Any ideas? >> >> Valentin >> >> > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://old.nabble.com/Possible-bug-in-the-vrt-branch-firmware--tp27825201p27826670.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Possible bug in the vrt branch firmware?
Hi All, We've tried editing the rx_timed_samples.cc to set the time on the USRPs on the next pps and then start streaming data some time after, by inserting the following code (instead of the existing one) between rx_handler my_handler(nsamples) and the while loop: //create a new usrp2 object, set some properties usrp2::usrp2::sptr u2 = usrp2::usrp2::make(interface, mac_addr_str); u2->set_rx_decim(16); //set the system time to the usrp2 u2->set_time_at_next_pps(usrp2::time_spec_t(0, 0)); //begin streaming in the future u2->start_rx_streaming(0, usrp2::time_spec_t(2, 1)); this code used to work in the middle of last week. We had to reflash our SD cards on Friday, so we downloaded the firmware from http://www.ettus.com/usrp2_vrt and flashed our cards with it. After doing that the above code just stopped working. Was there an update of firmware some time last week? Strangely enough it works if we set the time of the usrps to 200,0 instead of 0,0 and start streaming at 202, 1. But this fix only works for one acquisition, i.e. if we run the code one more time it just freezes and doesn't do anything, so to run it again we have to reset the usrps. We're using 1Hz TTL PPS as required by the USRP2 spec. Any ideas? Valentin -- View this message in context: http://old.nabble.com/Possible-bug-in-the-vrt-branch-firmware--tp27825201p27825201.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] rx_timed_samples.cc doesn't stop streaming of samples
And the offset seems to be positive, i.e. the packet timestamp is the time of the first sample in the packet and not of the last one (referring to my previous calculation: for the sample number 300 in the first packet the timestamp is 35564266+300*16=35569066). I've come up to this conclusion by applying a PPS signal to the boards and calling u2->set_time_at_next_pps(5,0) and the output was: ... Got packet: 212 secs, 12258426 ticks Got packet: 212 secs, 12264266 ticks Got packet: 5 secs, 2244 ticks Got packet: 5 secs, 8084 ticks ... where 2244 is not divisible by 16, hence represents some sort of delay before the first sample gets received after the clock reset. Or am I missing something? Valentin Josh Blum-2 wrote: > >> Couple more questions if you don't mind: >> 1) Where does the number of items per packet (which is 365 in my case) >> comes >> from? Or is it the format USRP2 always uses to send the data to the host? >> > > Its probably the MTU (1500 bytes) minus the ip/udp/ethernet headers > sizes minus the size of the vrt headers. Basically, the maximum number > of samples per frame. > >> 2) After specifying -N as 1000 I got the following output: >> >> Got packet: 1267693414 secs, 35564266 ticks >> Got packet: 1267693414 secs, 35570106 ticks >> Got packet: 1267693414 secs, 35575946 ticks >> >> So the number of ticks between the packets is 5840, dividing by 365 we >> get >> 16-the number of ticks per sample, and the decimation is 16 which is >> consistent. My question is: if I want to extract the timestamps for each >> sample individually I would need to take the timestamp of the packet and >> subtract the required number of 16*N (e.g. for the sample number 300 in >> the >> first packet the timestamp is 35564266-65*16=35563226) or is there a >> different way the get hold of timestamps for individual samples? > > That's correct: > The Nth sample will be N*usrp2_clock_rate/samp_rate ticks offset from > the timestamp or in this case N*16 ticks offset. Each sample has a > temporal ambiguity equal to the width of 16 clock ticks. > > -Josh > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://old.nabble.com/rx_timed_samples.cc-doesn%27t-stop-streaming-of-samples-tp27771324p27785768.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] rx_timed_samples.cc doesn't stop streaming of samples
Thanks a lot Josh! Adding return not done() instead of return true did work. I'm running Ubuntu in virtualbox, hence the lack of resources. Couple more questions if you don't mind: 1) Where does the number of items per packet (which is 365 in my case) comes from? Or is it the format USRP2 always uses to send the data to the host? 2) After specifying -N as 1000 I got the following output: Got packet: 1267693414 secs, 35564266 ticks Got packet: 1267693414 secs, 35570106 ticks Got packet: 1267693414 secs, 35575946 ticks So the number of ticks between the packets is 5840, dividing by 365 we get 16-the number of ticks per sample, and the decimation is 16 which is consistent. My question is: if I want to extract the timestamps for each sample individually I would need to take the timestamp of the packet and subtract the required number of 16*N (e.g. for the sample number 300 in the first packet the timestamp is 35564266-65*16=35563226) or is there a different way the get hold of timestamps for individual samples? Thank you very much for your help. Valentin Josh Blum-2 wrote: > > >> 1) I've just installed the usrp2_vrt branch and tried running >> rx_timed_samples.cc. No matter what number of samples i specify in the >> options, the program just keeps running and printing out the >> timestamps... >> Even after i press Ctrl+C the computer still continues to receive data >> through the ethernet port implying that the u2->stop_rx_streaming doesn't >> get called. Does anyone know what the problem could be? >> > > Its possible that your machine is slow enough such that it always has > samples in the packet ring and no lag time for the CPU. In this case, > the rx_samples call does not get a chance to return and therefore the > while loop cannot get a chance to check the done condition. > > A remedy could be to change line 54: return true; with the following > return not done(); This will cause the callback to return false when > done, so that rx_samples with exit and the loop condition will be checked. > > This is due to a false assumption on my part, let me know if that change > fixes it for you. > >> 2) Could anyone please clarify what nitems means in the following line of >> the handler in rx_timed_samples.cc: >> operator()(const uint32_t *items, size_t nitems, const >> vrt::expanded_header *vrt_header) > > Its a callable object. An instance of it gets created and passed into > u2->rx_samples(&my_handler); > >> As far as I can see from the code, d_num_samples gets incremented by >> nitems >> every time rx_samples is called and then is comparared whith >> d_max_samples >> implying that nitems is the number of samples received. But nitems is >> always >> 365,hence d_num_samples gets incremented in step of 365, therefore is it >> correct that one can receive only a number of samples which is a multiple >> of >> 365? Hence what's the point in specifying 1000 as a number of samples to >> receive? >> > > 1000 is an arbitrary number. If the actual number of items per packet is > 365, then it should take 3 receives to have more than 1000 samples, and > the program should be done. > > -Josh > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://old.nabble.com/rx_timed_samples.cc-doesn%27t-stop-streaming-of-samples-tp27771324p27780844.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] rx_timed_samples.cc doesn't stop streaming of samples
Hi All, 1) I've just installed the usrp2_vrt branch and tried running rx_timed_samples.cc. No matter what number of samples i specify in the options, the program just keeps running and printing out the timestamps... Even after i press Ctrl+C the computer still continues to receive data through the ethernet port implying that the u2->stop_rx_streaming doesn't get called. Does anyone know what the problem could be? 2) Could anyone please clarify what nitems means in the following line of the handler in rx_timed_samples.cc: operator()(const uint32_t *items, size_t nitems, const vrt::expanded_header *vrt_header) As far as I can see from the code, d_num_samples gets incremented by nitems every time rx_samples is called and then is comparared whith d_max_samples implying that nitems is the number of samples received. But nitems is always 365,hence d_num_samples gets incremented in step of 365, therefore is it correct that one can receive only a number of samples which is a multiple of 365? Hence what's the point in specifying 1000 as a number of samples to receive? Thanks Valentin -- View this message in context: http://old.nabble.com/rx_timed_samples.cc-doesn%27t-stop-streaming-of-samples-tp27771324p27771324.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
