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. Fwd: N200 stability (Dan Sego)
2. Re: Timed transmission after U/L errors (Marcus D. Leech)
3. Re: N200 stability (Marcus D. Leech)
4. Re: Errors 0x8 and 0xf when capturing with b210. (Weaver, Tyler)
5. Re: Fwd: N200 stability (Nick Foster)
6. Re: Errors 0x8 and 0xf when capturing with b210. (Marcus D. Leech)
7. Re: Errors 0x8 and 0xf when capturing with b210. (Weaver, Tyler)
8. Re: Errors 0x8 and 0xf when capturing with b210. (Marcus D. Leech)
9. Re: Receive two channels on the B210 with different sample
rates (Marcus D. Leech)
10. Re: Solution to get data from 2 RX channels from X310 with
the difference sample rate? (Marcus M?ller)
11. Re: Errors 0x8 and 0xf when capturing with b210. (Tyler Weaver)
12. Re: Real-time streaming input (Marcus M?ller)
13. Re: x310 Master clock rate (Ian Buckley)
14. Re: Receive two channels on the B210 with different sample
rates (Marcus D. Leech)
15. B200 Broadcast FM and other signals on airband (Paul B)
16. Can't Find USRP N200 (Carlos Quiroga)
17. Re: Can't Find USRP N200 (Martin Braun)
18. Re: Can't Find USRP N200 (Neel Pandeya)
19. Re: Receive two channels on the B210 with different sample
rates (Michael West)
20. Time of arrival of first sample in a 2 Rx setup (siva sankar)
21. Re: Time of arrival of first sample in a 2 Rx setup
(Marcus M?ller)
22. Re: Time of arrival of first sample in a 2 Rx setup (siva sankar)
23. Re: Time of arrival of first sample in a 2 Rx setup
(Marcus M?ller)
24. Re: Time of arrival of first sample in a 2 Rx setup (LOUF Laurent)
25. Re: Timed transmission after U/L errors (Dario Fertonani)
26. Re: Timed transmission after U/L errors ([email protected])
----------------------------------------------------------------------
Message: 1
Date: Wed, 22 Apr 2015 09:05:54 -0700
From: Dan Sego <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Fwd: N200 stability
Message-ID:
<CALGEVjvXCq39fTnHKpZUsacQ6RpLXhCrsnt9ULEtFr0zKg-=j...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Resending the question below. With an addition. Operating both units,
laptop and signal generator off a single power strip, I changed from lab
power to an inverter (looking at/for any degradation that might result from
noisy power). The inverter could not supply sufficient power, the signal
gen tripped off line as did the laptop. Measurements made subsequently show
an order of magnitude degradation
Question: is the GPSDO susceptible to damage in low voltage/low power
instance? If so is there a repair option from Ettus (emails to Ettus tech
support have not been returned)
vr. Dan
thank you
---------- Forwarded message ----------
From: Dan Sego <[email protected]>
Date: Fri, Apr 17, 2015 at 6:08 AM
Subject: N200 stability
To: [email protected]
Good morning the list.
I have 2 N200s w/ WBX connected via MIMO cable with an internal GPSDO on
the master. I have attached calculated intra-channel and inter-channel
phase stability calculations on from a tone generator. The results over
approximately 100 seconds demonstrate about 0.15 radians of drift with
a fair amount of low frequency noise. The low frequency noise (1 Hz-ish) is
common to both channels.
Are these results consistent with expectations? I have also attached the
two channel code as I'm still not completely sure that I have configured
the clock correctly (and by coincidence just seeing hanwen's posted query,
in particular the option of GPSDO or? MIMO).
Any and all advice is appreciated. Thanks
Dan Sego
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150422/565d4dd3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Stability Measurements.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 107193 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150422/565d4dd3/attachment-0001.pptx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dual_chan_development.cpp
Type: text/x-c++src
Size: 12925 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150422/565d4dd3/attachment-0001.cpp>
------------------------------
Message: 2
Date: Wed, 22 Apr 2015 12:06:59 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Timed transmission after U/L errors
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 04/10/2015 02:18 PM, Dario Fertonani via USRP-users wrote:
> We are seeing a weird behavior that hints at a problem in recovering
> from U/L transmit errors. I wonder if we are using the timed send API
> and tx_metadata_t properly.
>
> We call send within a loop, so that every time the transmission is
> timed and that the interval between two consecutive transmissions is
> equal to the desired chunk duration. Essentially, all is done with
> txMetaData.time_spec += ChunkDuration_s;
> with the loop.
>
> All goes well until an error U/L occurs. Soon after that, a few chunks
> later (1-3 ms), the transmit stream appears to be misaligned. Still
> nice and strong, but not aligned with the original timing.
> All we want is that, after a packet doesn't get transmitted properly
> (U/L errors), the stream can go on as if nothing happened. Any special
> care that should be taken to achieve this behavior?
>
> Thanks,
> Dario
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
You description sounds like continuous transmission--if that's the case,
then why not just use continuous streaming?
Also, "L" means 'late', which means that by the time the USRP went to
send the frame of samples, the time given in the header has already passed.
If you're you're doing very-tight timing, not accounting for average
latency through the stack, and you're getting underruns, I can imagine
things
starting to go badly off the rails. My suggestion would be to, when
you get an 'L' or 'U' indication, hold-off on transmitting for a while,
and restart
your stream several time-slots into the future.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150422/c91b7632/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 22 Apr 2015 12:16:23 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] N200 stability
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 04/17/2015 09:08 AM, Dan Sego via USRP-users wrote:
> Good morning the list.
>
> I have 2 N200s w/ WBX connected via MIMO cable with an internal GPSDO
> on the master. I have attached calculated intra-channel and
> inter-channel phase stability calculations on from a tone generator.
> The results over approximately 100 seconds demonstrate about 0.15
> radians of drift with a fair amount of low frequency noise. The low
> frequency noise (1 Hz-ish) is common to both channels.
>
> Are these results consistent with expectations? I have also attached
> the two channel code as I'm still not completely sure that I have
> configured the clock correctly (and by coincidence just
> seeing hanwen's posted query, in particular the option of GPSDO or? MIMO).
>
> Any and all advice is appreciated. Thanks
> Dan Sego
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
I don't see anywhere in your code where you're setting the master-side
clock source to "gpsdo" or "external" -- also on the N210, those two are
conceptually the same, with a hardware jumper selecting whether the
"external" clock comes from the front-panel or the on-board GPSDO.
There's a jumper block on the mainboard, J510, which selects between the
front-panel 10MHz in, or the 10MHz provided by the on-board GPSDO--make
sure that's in the correct position, selecting connector J507 instead
of J501.
How are you connecting the signal generator to the two N210s? Is it
conceivable that mutual phase-drift is a temperature effect of the way the
signals are being distributed?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150422/37af73b6/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 22 Apr 2015 16:24:26 +0000
From: "Weaver, Tyler" <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Errors 0x8 and 0xf when capturing with b210.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
This is not through a VM in either case. All of the following tests were
performed on the Dell.
The initial messages say that it?s operating over USB3, clock rate of 32 MHz,
all tests pass and the reference is internal GPSDO. Device is connected to
included external power supply. 850 band antenna is connected to RF-A RX2.
using rx_samples_to_file
output was set to /dev/null
duration was 60 seconds
frequency was set to 800 MHz
D = bad packet
O = overflow error
wirefmt/rate
sc8/32e6: DO x5
sc8/16e6: DO x2
sc8/8e6: DO x2
sc8/4e6: DO
sc16/32e6: O x5
sc16/16e6: O x2
sc16/8e6: O
sc16/4e6: O
I ran several of these multiple times and saw different numbers of errors but
not more than +/- 2 of what I showed above. I determined the bad packet occurs
when the format is set to signed complex 8 bit. Where the overflow error rate
seems to happen even at very low data rates and more at high data rates. The
error printed by rx_samples_to_file relating to the overflow indicates that the
medium (hard drive or ram?) has to sustain a rate of a certain amount for this
to be avoided. What?s confusing is that I?ve never seen either of these errors
when running the N210 I have on the same computer at a sample rate of 40 MS/s.
It is content to a usb3-to-ethernet dongle and performs just fine.
Are there any other tests you?d suggest? Does this tell you anything more
about my configuration? Could it have to do with the usb?s buffering? Is
there anyway to increase the size of the buffer? Is the medium mentioned the
hard drive or ram. In either case they should be fast enough, this computer
has a high end ssd that I?ve been able to stream to at 40 MS/s (sc16) off the
pci buss with a different company?s radio with no problems.
thank you,
tyler
> On Apr 22, 2015, at 8:39 AM, Marcus D. Leech <[email protected]> wrote:
>
> On 04/21/2015 01:41 PM, Weaver, Tyler wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>
>> Sample rates:
>> I have tried various sample rates and the errors occur at > 8 MHz. For my
>> application I need something > 20 MHz. Preferably I want to sample at 30.72
>> MHz.
>>
>> Hardware:
>> dell: i7-4800MQ, 16gb ram, radion 8790M, SSD hd.
>> mac: i704980HQ, 16gb ram, nvidia gt 750M, SSD hd.
>>
>>
>> Clock rate:
>>
>> I?ve tried 30.72 and 61.44 MHz. Neither have gotten rid of the errors.
>>
>>
> What happens if you do something super-simple, like using rx_samples_to_file,
> and specifying /dev/null for the output file, and then try your
> various sample rates. Leaving the master clock at the default 32MHz, I'd
> try 4, 8, and 16 msps.
>
> If this is through a VM, then you can expect potentially-horrible USB
> performance...
>
>
------------------------------
Message: 5
Date: Wed, 22 Apr 2015 09:26:57 -0700
From: Nick Foster <[email protected]>
To: Dan Sego <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Fwd: N200 stability
Message-ID:
<CA+JMMq8zzQ=fqMg=hk+i4_ot2xuvyfdigfz1mueyokm-qnk...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
How long was the GPSDO operating before, and then after, the power
interruption, when the measurements were made? GPSDOs require some time to
settle in and lock their clocks.
--n
On Apr 22, 2015 9:09 AM, "Dan Sego via USRP-users" <
[email protected]> wrote:
> Resending the question below. With an addition. Operating both units,
> laptop and signal generator off a single power strip, I changed from lab
> power to an inverter (looking at/for any degradation that might result from
> noisy power). The inverter could not supply sufficient power, the signal
> gen tripped off line as did the laptop. Measurements made subsequently show
> an order of magnitude degradation
>
> Question: is the GPSDO susceptible to damage in low voltage/low power
> instance? If so is there a repair option from Ettus (emails to Ettus tech
> support have not been returned)
>
>
> vr. Dan
>
>
> thank you
> ---------- Forwarded message ----------
> From: Dan Sego <[email protected]>
> Date: Fri, Apr 17, 2015 at 6:08 AM
> Subject: N200 stability
> To: [email protected]
>
>
> Good morning the list.
>
> I have 2 N200s w/ WBX connected via MIMO cable with an internal GPSDO on
> the master. I have attached calculated intra-channel and inter-channel
> phase stability calculations on from a tone generator. The results over
> approximately 100 seconds demonstrate about 0.15 radians of drift with
> a fair amount of low frequency noise. The low frequency noise (1 Hz-ish) is
> common to both channels.
>
> Are these results consistent with expectations? I have also attached the
> two channel code as I'm still not completely sure that I have configured
> the clock correctly (and by coincidence just seeing hanwen's posted query,
> in particular the option of GPSDO or? MIMO).
>
> Any and all advice is appreciated. Thanks
> Dan Sego
>
>
> _______________________________________________
> 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/20150422/953133c5/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 22 Apr 2015 12:37:57 -0400
From: "Marcus D. Leech" <[email protected]>
To: "Weaver, Tyler" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Errors 0x8 and 0xf when capturing with b210.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 04/22/2015 12:24 PM, Weaver, Tyler wrote:
> This is not through a VM in either case. All of the following tests were
> performed on the Dell.
>
> The initial messages say that it?s operating over USB3, clock rate of 32 MHz,
> all tests pass and the reference is internal GPSDO. Device is connected to
> included external power supply. 850 band antenna is connected to RF-A RX2.
>
> using rx_samples_to_file
> output was set to /dev/null
> duration was 60 seconds
> frequency was set to 800 MHz
>
> D = bad packet
> O = overflow error
>
> wirefmt/rate
> sc8/32e6: DO x5
> sc8/16e6: DO x2
> sc8/8e6: DO x2
> sc8/4e6: DO
> sc16/32e6: O x5
> sc16/16e6: O x2
> sc16/8e6: O
> sc16/4e6: O
>
> I ran several of these multiple times and saw different numbers of errors but
> not more than +/- 2 of what I showed above. I determined the bad packet
> occurs when the format is set to signed complex 8 bit. Where the overflow
> error rate seems to happen even at very low data rates and more at high data
> rates. The error printed by rx_samples_to_file relating to the overflow
> indicates that the medium (hard drive or ram?) has to sustain a rate of a
> certain amount for this to be avoided. What?s confusing is that I?ve never
> seen either of these errors when running the N210 I have on the same computer
> at a sample rate of 40 MS/s. It is content to a usb3-to-ethernet dongle and
> performs just fine.
>
> Are there any other tests you?d suggest? Does this tell you anything more
> about my configuration? Could it have to do with the usb?s buffering? Is
> there anyway to increase the size of the buffer? Is the medium mentioned the
> hard drive or ram. In either case they should be fast enough, this computer
> has a high end ssd that I?ve been able to stream to at 40 MS/s (sc16) off the
> pci buss with a different company?s radio with no problems.
>
> thank you,
> tyler
>
>> On Apr 22, 2015, at 8:39 AM, Marcus D. Leech <[email protected]> wrote:
>>
>> On 04/21/2015 01:41 PM, Weaver, Tyler wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA512
>>>
>>> Sample rates:
>>> I have tried various sample rates and the errors occur at > 8 MHz. For my
>>> application I need something > 20 MHz. Preferably I want to sample at
>>> 30.72 MHz.
>>>
>>> Hardware:
>>> dell: i7-4800MQ, 16gb ram, radion 8790M, SSD hd.
>>> mac: i704980HQ, 16gb ram, nvidia gt 750M, SSD hd.
>>>
>>>
>>> Clock rate:
>>>
>>> I?ve tried 30.72 and 61.44 MHz. Neither have gotten rid of the errors.
>>>
>>>
>> What happens if you do something super-simple, like using
>> rx_samples_to_file, and specifying /dev/null for the output file, and then
>> try your
>> various sample rates. Leaving the master clock at the default 32MHz, I'd
>> try 4, 8, and 16 msps.
>>
>> If this is through a VM, then you can expect potentially-horrible USB
>> performance...
>>
>>
Are you using the USB cable that Ettus provided, or something else?
Also, you might try experimenting with some of the USB transport
parameters here:
http://files.ettus.com/manual/page_transport.html#transport_usb
When rx_samples_to_file talks about "medium" it's talking about whatever
is storing your bytes. It has now way of knowing definitively that the
cause of
any overruns is your filesystems inability to "keep up" it's just
making a guess.
Also, not sure how you're getting 40Msps out of an N2xx, since that's a
rate that would require fractional resampling in the N200. Rates must be
an integer fraction of whatever the master clock rate is, and on the
N2xx, that is fixed at 100MHz.
Also, a single overrun at startup is not-uncommon, as the kernels
buffering system "ramps up". Overruns after that are an indication that
the average
ability of the system, overall, to "keep up" is somewhat less than
the offered load. USB uses shorter transactions "over the wire" than
ethernet, and
is thus subject to higher overheads in things like IRQ processing.
Also, the low-level USB3 drivers in the kernel may not be as optimized as
ethernet drivers. USB3 is still somewhat immature in the market.
------------------------------
Message: 7
Date: Wed, 22 Apr 2015 17:03:03 +0000
From: "Weaver, Tyler" <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Errors 0x8 and 0xf when capturing with b210.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
I am using the cable that was provided with the B210. I misspoke on the N210,
I?m sampling at 50 MS/s with a bandwidth of 40 MHz.
Thank you for the link. I?ll change these and report if it affects anything.
What do you think is causing the bad packet errors? How could I debug that?
It seems to correlate with selecting 8bit samples. I would think 8bit samples
would tax the system less, yet it seems to have no affect on the number of
overflows.
Is there a known good set of USB hardware I could purchase to avoid these
problems?
thank you,
tyler
> On Apr 22, 2015, at 10:37 AM, Marcus D. Leech <[email protected]> wrote:
>
> On 04/22/2015 12:24 PM, Weaver, Tyler wrote:
>> This is not through a VM in either case. All of the following tests were
>> performed on the Dell.
>>
>> The initial messages say that it?s operating over USB3, clock rate of 32
>> MHz, all tests pass and the reference is internal GPSDO. Device is
>> connected to included external power supply. 850 band antenna is connected
>> to RF-A RX2.
>>
>> using rx_samples_to_file
>> output was set to /dev/null
>> duration was 60 seconds
>> frequency was set to 800 MHz
>>
>> D = bad packet
>> O = overflow error
>>
>> wirefmt/rate
>> sc8/32e6: DO x5
>> sc8/16e6: DO x2
>> sc8/8e6: DO x2
>> sc8/4e6: DO
>> sc16/32e6: O x5
>> sc16/16e6: O x2
>> sc16/8e6: O
>> sc16/4e6: O
>>
>> I ran several of these multiple times and saw different numbers of errors
>> but not more than +/- 2 of what I showed above. I determined the bad packet
>> occurs when the format is set to signed complex 8 bit. Where the overflow
>> error rate seems to happen even at very low data rates and more at high data
>> rates. The error printed by rx_samples_to_file relating to the overflow
>> indicates that the medium (hard drive or ram?) has to sustain a rate of a
>> certain amount for this to be avoided. What?s confusing is that I?ve never
>> seen either of these errors when running the N210 I have on the same
>> computer at a sample rate of 40 MS/s. It is content to a usb3-to-ethernet
>> dongle and performs just fine.
>>
>> Are there any other tests you?d suggest? Does this tell you anything more
>> about my configuration? Could it have to do with the usb?s buffering? Is
>> there anyway to increase the size of the buffer? Is the medium mentioned
>> the hard drive or ram. In either case they should be fast enough, this
>> computer has a high end ssd that I?ve been able to stream to at 40 MS/s
>> (sc16) off the pci buss with a different company?s radio with no problems.
>>
>> thank you,
>> tyler
>>
>>> On Apr 22, 2015, at 8:39 AM, Marcus D. Leech <[email protected]> wrote:
>>>
>>> On 04/21/2015 01:41 PM, Weaver, Tyler wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA512
>>>>
>>>> Sample rates:
>>>> I have tried various sample rates and the errors occur at > 8 MHz. For my
>>>> application I need something > 20 MHz. Preferably I want to sample at
>>>> 30.72 MHz.
>>>>
>>>> Hardware:
>>>> dell: i7-4800MQ, 16gb ram, radion 8790M, SSD hd.
>>>> mac: i704980HQ, 16gb ram, nvidia gt 750M, SSD hd.
>>>>
>>>>
>>>> Clock rate:
>>>>
>>>> I?ve tried 30.72 and 61.44 MHz. Neither have gotten rid of the errors.
>>>>
>>>>
>>> What happens if you do something super-simple, like using
>>> rx_samples_to_file, and specifying /dev/null for the output file, and then
>>> try your
>>> various sample rates. Leaving the master clock at the default 32MHz, I'd
>>> try 4, 8, and 16 msps.
>>>
>>> If this is through a VM, then you can expect potentially-horrible USB
>>> performance...
>>>
>>>
> Are you using the USB cable that Ettus provided, or something else?
>
> Also, you might try experimenting with some of the USB transport parameters
> here:
>
> http://files.ettus.com/manual/page_transport.html#transport_usb
>
> When rx_samples_to_file talks about "medium" it's talking about whatever is
> storing your bytes. It has now way of knowing definitively that the cause of
> any overruns is your filesystems inability to "keep up" it's just making a
> guess.
>
> Also, not sure how you're getting 40Msps out of an N2xx, since that's a rate
> that would require fractional resampling in the N200. Rates must be
> an integer fraction of whatever the master clock rate is, and on the N2xx,
> that is fixed at 100MHz.
>
> Also, a single overrun at startup is not-uncommon, as the kernels buffering
> system "ramps up". Overruns after that are an indication that the average
> ability of the system, overall, to "keep up" is somewhat less than the
> offered load. USB uses shorter transactions "over the wire" than ethernet,
> and
> is thus subject to higher overheads in things like IRQ processing. Also,
> the low-level USB3 drivers in the kernel may not be as optimized as
> ethernet drivers. USB3 is still somewhat immature in the market.
>
>
------------------------------
Message: 8
Date: Wed, 22 Apr 2015 14:02:35 -0400
From: "Marcus D. Leech" <[email protected]>
To: "Weaver, Tyler" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Errors 0x8 and 0xf when capturing with b210.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 04/22/2015 01:03 PM, Weaver, Tyler wrote:
> I am using the cable that was provided with the B210. I misspoke on the
> N210, I?m sampling at 50 MS/s with a bandwidth of 40 MHz.
>
> Thank you for the link. I?ll change these and report if it affects anything.
>
> What do you think is causing the bad packet errors? How could I debug that?
> It seems to correlate with selecting 8bit samples. I would think 8bit
> samples would tax the system less, yet it seems to have no affect on the
> number of overflows.
Well, 'D' is dropped packet. The question is where that dropped packet
is happening. Once a packet in a flow of packets gets dropped, the overall
"syntax" of the flow gets out-of-sync.
Making this worse is that there's a long-standing bug in the FX3 USB-3
chip, that Ian talked about a few days ago, where when 'O' happens, the
DMA machinery in the FX3 gets confused. This doesn't always happen,
and happens on some systems on not others (there are subtle
USB-land interactions between the host controller and FX3 that are
largely 'invisible' to the Ettus code). Ettus R&D are really busy
trying to figure
this out. But again, on some systems, it's fine, on others, you get
this weirdness.
In terms of USB 3 controllers, the Intel 8 series, which is what, as I
recall, you have, is generally regarded as one of the better ones.
>
> Is there a known good set of USB hardware I could purchase to avoid these
> problems?
>
> thank you,
> tyler
>
>> On Apr 22, 2015, at 10:37 AM, Marcus D. Leech <[email protected]> wrote:
>>
>> On 04/22/2015 12:24 PM, Weaver, Tyler wrote:
>>> This is not through a VM in either case. All of the following tests were
>>> performed on the Dell.
>>>
>>> The initial messages say that it?s operating over USB3, clock rate of 32
>>> MHz, all tests pass and the reference is internal GPSDO. Device is
>>> connected to included external power supply. 850 band antenna is connected
>>> to RF-A RX2.
>>>
>>> using rx_samples_to_file
>>> output was set to /dev/null
>>> duration was 60 seconds
>>> frequency was set to 800 MHz
>>>
>>> D = bad packet
>>> O = overflow error
>>>
>>> wirefmt/rate
>>> sc8/32e6: DO x5
>>> sc8/16e6: DO x2
>>> sc8/8e6: DO x2
>>> sc8/4e6: DO
>>> sc16/32e6: O x5
>>> sc16/16e6: O x2
>>> sc16/8e6: O
>>> sc16/4e6: O
>>>
>>> I ran several of these multiple times and saw different numbers of errors
>>> but not more than +/- 2 of what I showed above. I determined the bad
>>> packet occurs when the format is set to signed complex 8 bit. Where the
>>> overflow error rate seems to happen even at very low data rates and more at
>>> high data rates. The error printed by rx_samples_to_file relating to the
>>> overflow indicates that the medium (hard drive or ram?) has to sustain a
>>> rate of a certain amount for this to be avoided. What?s confusing is that
>>> I?ve never seen either of these errors when running the N210 I have on the
>>> same computer at a sample rate of 40 MS/s. It is content to a
>>> usb3-to-ethernet dongle and performs just fine.
>>>
>>> Are there any other tests you?d suggest? Does this tell you anything more
>>> about my configuration? Could it have to do with the usb?s buffering? Is
>>> there anyway to increase the size of the buffer? Is the medium mentioned
>>> the hard drive or ram. In either case they should be fast enough, this
>>> computer has a high end ssd that I?ve been able to stream to at 40 MS/s
>>> (sc16) off the pci buss with a different company?s radio with no problems.
>>>
>>> thank you,
>>> tyler
>>>
>>>> On Apr 22, 2015, at 8:39 AM, Marcus D. Leech <[email protected]> wrote:
>>>>
>>>> On 04/21/2015 01:41 PM, Weaver, Tyler wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA512
>>>>>
>>>>> Sample rates:
>>>>> I have tried various sample rates and the errors occur at > 8 MHz. For
>>>>> my application I need something > 20 MHz. Preferably I want to sample at
>>>>> 30.72 MHz.
>>>>>
>>>>> Hardware:
>>>>> dell: i7-4800MQ, 16gb ram, radion 8790M, SSD hd.
>>>>> mac: i704980HQ, 16gb ram, nvidia gt 750M, SSD hd.
>>>>>
>>>>>
>>>>> Clock rate:
>>>>>
>>>>> I?ve tried 30.72 and 61.44 MHz. Neither have gotten rid of the errors.
>>>>>
>>>>>
>>>> What happens if you do something super-simple, like using
>>>> rx_samples_to_file, and specifying /dev/null for the output file, and then
>>>> try your
>>>> various sample rates. Leaving the master clock at the default 32MHz,
>>>> I'd try 4, 8, and 16 msps.
>>>>
>>>> If this is through a VM, then you can expect potentially-horrible USB
>>>> performance...
>>>>
>>>>
>> Are you using the USB cable that Ettus provided, or something else?
>>
>> Also, you might try experimenting with some of the USB transport parameters
>> here:
>>
>> http://files.ettus.com/manual/page_transport.html#transport_usb
>>
>> When rx_samples_to_file talks about "medium" it's talking about whatever is
>> storing your bytes. It has now way of knowing definitively that the cause
>> of
>> any overruns is your filesystems inability to "keep up" it's just making a
>> guess.
>>
>> Also, not sure how you're getting 40Msps out of an N2xx, since that's a rate
>> that would require fractional resampling in the N200. Rates must be
>> an integer fraction of whatever the master clock rate is, and on the N2xx,
>> that is fixed at 100MHz.
>>
>> Also, a single overrun at startup is not-uncommon, as the kernels buffering
>> system "ramps up". Overruns after that are an indication that the average
>> ability of the system, overall, to "keep up" is somewhat less than the
>> offered load. USB uses shorter transactions "over the wire" than ethernet,
>> and
>> is thus subject to higher overheads in things like IRQ processing. Also,
>> the low-level USB3 drivers in the kernel may not be as optimized as
>> ethernet drivers. USB3 is still somewhat immature in the market.
>>
>>
------------------------------
Message: 9
Date: Wed, 22 Apr 2015 14:05:35 -0400
From: "Marcus D. Leech" <[email protected]>
To: Hunter DeJarnette <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Receive two channels on the B210 with
different sample rates
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 03/17/2015 01:55 PM, Hunter DeJarnette wrote:
> Marcus,
>
> Thanks for your quick reply. Is this supported on other USRP models?
> Are there any plans for this to be supported on the B210?
>
> Hunter
No, there's no support for this in other models, either. While it's
conceptually possible, it isn't actually implemented, partially because
there's
no way to setup the master clock (on, for example, the X310) in cases
where there's no common master-clock rate that can produce both
sample rates.
The best approach is to bring both streams in at the same rate, and
resample the lower-rate stream. If you use Gnu Radio, there are various
resamplers, including a rational and fractional resampler.
>
> On Tue, Mar 17, 2015 at 12:51 PM, <[email protected]
> <mailto:[email protected]>> wrote:
>
> This is not a supported configuration on the B210.
>
> If you need different sample-rates on the two streams, you'll have
> to re-sample in software.
>
> On 2015-03-17 12:12, Hunter DeJarnette via USRP-users wrote:
>
>> I'm working on an application with the B210 where I would like to
>> use both rx dsp's, but at different sample rates. I understand
>> that each of the channels attached to a single rx_streamer must
>> have the same sample rate. So to get around this issue I tried
>> instantiating two usrp sources each with a different channel like
>> so:
>>
>> self.uhd_usrp_source_0 = uhd.usrp_source(
>> ",".join(("type=b200", "")),
>> uhd.stream_args(
>> cpu_format="fc32",
>> channels=[0],
>> ),
>> )
>> self.uhd_usrp_source_1 = uhd.usrp_source(
>> ",".join(("type=b200", "")),
>> uhd.stream_args(
>> cpu_format="fc32",
>> channels=[1],
>> ),
>> )
>> self.uhd_usrp_source_0.set_subdev_spec("A:A A:B", 0)
>> self.uhd_usrp_source_0.set_samp_rate(samp_rate_0)
>> self.uhd_usrp_source_1.set_samp_rate(samp_rate_1)
>>
>> I found that when the sample rates for the two sources are the
>> same I get similar performance to the using two channels on a
>> single usrp_source. However, when I try to use different sample
>> rates I start dropping samples. Am I setting this up right?
>>
>> Thanks,
>>
>> Hunter
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[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/20150422/65ea1c6e/attachment-0001.html>
------------------------------
Message: 10
Date: Wed, 22 Apr 2015 20:09:13 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Solution to get data from 2 RX channels from
X310 with the difference sample rate?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi LTP,
Ben just told me that yes, Ettus has tested things, and they work as
expected: you can have arbitrary combinations of sampling rates on both
Streamers, but if you do that, you can't use a single multi_usrp object
to handle things -- you'll need to use two multi_usrp, but that's not
really a problem, since you don't lose any relevant functionality this way.
Best regards,
Marcus
On 04/22/2015 12:28 PM, Marcus M?ller wrote:
> Hi LTP,
>
> have a look at what RF NoC can do; it's still beta, but maybe it
> enables you to solve your problems!
>
> Generally, you must use the same master clock rate on both
> Daughterboards, but I don't think you must use the same sampling rate
> on both channels on X300 -- but I'm not totally sure. Maybe someone
> else could confirm, but since on the FPGA side, both radio units are
> rather independent, you should be able to request one streamer with
> rate X for your first channel, and one streamer with rate Y for your
> second channel.
>
> I did not really understand the error you mentioned; is it something
> that UHD says? Where? Would you please paste the whole error?
>
> Best regards,
> Marcus
>
>
> On 04/22/2015 12:20 PM, Luong Tan Phong via USRP-users wrote:
>> Hi list,
>>
>> I desire to use X310 as a base platform for my application so I must
>> add my HDL routine signal processing module after DDC module in two
>> radio modules. So that, the data rate output from two radios are not
>> the same, and I can't receive them on PC (because the data not align
>> error).
>>
>>
>> Could you please point out a solution ( about fpga, host, firmware)
>> for me?
>>
>> I look forward to hearing from you.
>>
>> With best regards,
>>
>> LTP
>>
>>
>> _______________________________________________
>> 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/20150422/8c7bc5d4/attachment-0001.html>
------------------------------
Message: 11
Date: Wed, 22 Apr 2015 12:14:10 -0600
From: Tyler Weaver <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Errors 0x8 and 0xf when capturing with b210.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
I don't know if this is useful but here is the specific errors generated
by my code when trying to do many captures. I'm outputting some
debugging messaging to show what sort of scans are causing the error,
yet it happens in either case. In between captures I'm asking for
different center frequencies:
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_START_CONTINUOUS, 8 bits, 2.8e+07fs,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_START_CONTINUOUS, 16 bits, 7e+06fs,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_START_CONTINUOUS, 16 bits, 1.4e+07fs,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_START_CONTINUOUS, 8 bits, 2.8e+07fs,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_START_CONTINUOUS, 8 bits, 2.8e+07fs,
UHD Error:
The receive packet handler caught an exception.
ValueError: bad vrt header or packet fragment
Wed Apr 22 12:02:24 2015
: Capture failed with UHD error 15: ERROR_CODE_BAD_PACKET
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_START_CONTINUOUS, 8 bits, 2.8e+07fs,
UHD Error:
The receive packet handler caught an exception.
ValueError: bad vrt header or packet fragment
Wed Apr 22 12:02:25 2015
: Capture failed with UHD error 15: ERROR_CODE_BAD_PACKET
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_START_CONTINUOUS, 8 bits, 2.8e+07fs,
UHD Error:
The receive packet handler caught an exception.
ValueError: bad vrt header or packet fragment
Wed Apr 22 12:02:25 2015
: Capture failed with UHD error 15: ERROR_CODE_BAD_PACKET
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_START_CONTINUOUS, 8 bits, 2.8e+07fs,
UHD Error:
The receive packet handler caught an exception.
ValueError: bad vrt header or packet fragment
Wed Apr 22 12:02:25 2015
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_START_CONTINUOUS, 8 bits, 2.8e+07fs,
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_START_CONTINUOUS, 16 bits, 1.4e+07fs,
OWed Apr 22 12:02:49 2015
: Capture failed with UHD error 8: ERROR_CODE_OVERFLOW (Overflow)
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_START_CONTINUOUS, 16 bits, 1.4e+07fs,
OWed Apr 22 12:02:49 2015
: Capture failed with UHD error 8: ERROR_CODE_OVERFLOW (Overflow)
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_START_CONTINUOUS, 16 bits, 1.4e+07fs,
OWed Apr 22 12:02:50 2015
: Capture failed with UHD error 8: ERROR_CODE_OVERFLOW (Overflow)
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_START_CONTINUOUS, 16 bits, 1.4e+07fs,
OWed Apr 22 12:02:51 2015
: Capture failed with UHD error 8: ERROR_CODE_OVERFLOW (Overflow)
STREAM_MODE_NUM_SAMPS_AND_DONE, 8 bit,200000 samples,
STREAM_MODE_START_CONTINUOUS, 16 bits, 1.4e+07fs,
Wed Apr 22 12:02:51 2015
tyler
On 04/22/2015 12:02 PM, Marcus D. Leech wrote:
> On 04/22/2015 01:03 PM, Weaver, Tyler wrote:
>> I am using the cable that was provided with the B210. I misspoke on
>> the N210, I?m sampling at 50 MS/s with a bandwidth of 40 MHz.
>>
>> Thank you for the link. I?ll change these and report if it affects
>> anything.
>>
>> What do you think is causing the bad packet errors? How could I debug
>> that? It seems to correlate with selecting 8bit samples. I would
>> think 8bit samples would tax the system less, yet it seems to have no
>> affect on the number of overflows.
> Well, 'D' is dropped packet. The question is where that dropped packet
> is happening. Once a packet in a flow of packets gets dropped, the overall
> "syntax" of the flow gets out-of-sync.
>
> Making this worse is that there's a long-standing bug in the FX3 USB-3
> chip, that Ian talked about a few days ago, where when 'O' happens, the
> DMA machinery in the FX3 gets confused. This doesn't always happen,
> and happens on some systems on not others (there are subtle
> USB-land interactions between the host controller and FX3 that are
> largely 'invisible' to the Ettus code). Ettus R&D are really busy
> trying to figure
> this out. But again, on some systems, it's fine, on others, you get
> this weirdness.
>
> In terms of USB 3 controllers, the Intel 8 series, which is what, as I
> recall, you have, is generally regarded as one of the better ones.
>
>
>>
>> Is there a known good set of USB hardware I could purchase to avoid
>> these problems?
>>
>> thank you,
>> tyler
>>
>>> On Apr 22, 2015, at 10:37 AM, Marcus D. Leech <[email protected]> wrote:
>>>
>>> On 04/22/2015 12:24 PM, Weaver, Tyler wrote:
>>>> This is not through a VM in either case. All of the following tests
>>>> were performed on the Dell.
>>>>
>>>> The initial messages say that it?s operating over USB3, clock rate
>>>> of 32 MHz, all tests pass and the reference is internal GPSDO.
>>>> Device is connected to included external power supply. 850 band
>>>> antenna is connected to RF-A RX2.
>>>>
>>>> using rx_samples_to_file
>>>> output was set to /dev/null
>>>> duration was 60 seconds
>>>> frequency was set to 800 MHz
>>>>
>>>> D = bad packet
>>>> O = overflow error
>>>>
>>>> wirefmt/rate
>>>> sc8/32e6: DO x5
>>>> sc8/16e6: DO x2
>>>> sc8/8e6: DO x2
>>>> sc8/4e6: DO
>>>> sc16/32e6: O x5
>>>> sc16/16e6: O x2
>>>> sc16/8e6: O
>>>> sc16/4e6: O
>>>>
>>>> I ran several of these multiple times and saw different numbers of
>>>> errors but not more than +/- 2 of what I showed above. I determined
>>>> the bad packet occurs when the format is set to signed complex 8
>>>> bit. Where the overflow error rate seems to happen even at very low
>>>> data rates and more at high data rates. The error printed by
>>>> rx_samples_to_file relating to the overflow indicates that the
>>>> medium (hard drive or ram?) has to sustain a rate of a certain
>>>> amount for this to be avoided. What?s confusing is that I?ve never
>>>> seen either of these errors when running the N210 I have on the same
>>>> computer at a sample rate of 40 MS/s. It is content to a
>>>> usb3-to-ethernet dongle and performs just fine.
>>>>
>>>> Are there any other tests you?d suggest? Does this tell you
>>>> anything more about my configuration? Could it have to do with the
>>>> usb?s buffering? Is there anyway to increase the size of the
>>>> buffer? Is the medium mentioned the hard drive or ram. In either
>>>> case they should be fast enough, this computer has a high end ssd
>>>> that I?ve been able to stream to at 40 MS/s (sc16) off the pci buss
>>>> with a different company?s radio with no problems.
>>>>
>>>> thank you,
>>>> tyler
>>>>
>>>>> On Apr 22, 2015, at 8:39 AM, Marcus D. Leech <[email protected]>
>>>>> wrote:
>>>>>
>>>>> On 04/21/2015 01:41 PM, Weaver, Tyler wrote:
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA512
>>>>>>
>>>>>> Sample rates:
>>>>>> I have tried various sample rates and the errors occur at > 8
>>>>>> MHz. For my application I need something > 20 MHz. Preferably I
>>>>>> want to sample at 30.72 MHz.
>>>>>>
>>>>>> Hardware:
>>>>>> dell: i7-4800MQ, 16gb ram, radion 8790M, SSD hd.
>>>>>> mac: i704980HQ, 16gb ram, nvidia gt 750M, SSD hd.
>>>>>>
>>>>>>
>>>>>> Clock rate:
>>>>>>
>>>>>> I?ve tried 30.72 and 61.44 MHz. Neither have gotten rid of the
>>>>>> errors.
>>>>>>
>>>>>>
>>>>> What happens if you do something super-simple, like using
>>>>> rx_samples_to_file, and specifying /dev/null for the output file,
>>>>> and then try your
>>>>> various sample rates. Leaving the master clock at the default
>>>>> 32MHz, I'd try 4, 8, and 16 msps.
>>>>>
>>>>> If this is through a VM, then you can expect potentially-horrible
>>>>> USB performance...
>>>>>
>>>>>
>>> Are you using the USB cable that Ettus provided, or something else?
>>>
>>> Also, you might try experimenting with some of the USB transport
>>> parameters here:
>>>
>>> http://files.ettus.com/manual/page_transport.html#transport_usb
>>>
>>> When rx_samples_to_file talks about "medium" it's talking about
>>> whatever is storing your bytes. It has now way of knowing
>>> definitively that the cause of
>>> any overruns is your filesystems inability to "keep up" it's just
>>> making a guess.
>>>
>>> Also, not sure how you're getting 40Msps out of an N2xx, since that's
>>> a rate that would require fractional resampling in the N200. Rates
>>> must be
>>> an integer fraction of whatever the master clock rate is, and on
>>> the N2xx, that is fixed at 100MHz.
>>>
>>> Also, a single overrun at startup is not-uncommon, as the kernels
>>> buffering system "ramps up". Overruns after that are an indication
>>> that the average
>>> ability of the system, overall, to "keep up" is somewhat less than
>>> the offered load. USB uses shorter transactions "over the wire"
>>> than ethernet, and
>>> is thus subject to higher overheads in things like IRQ processing.
>>> Also, the low-level USB3 drivers in the kernel may not be as
>>> optimized as
>>> ethernet drivers. USB3 is still somewhat immature in the market.
>>>
>>>
>
------------------------------
Message: 12
Date: Wed, 22 Apr 2015 20:14:40 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Real-time streaming input
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Dear Jaehoon,
we just came across this email; have your question been answered by now?
If it has not: The N210 is designed to just do exactly that, it sends
the samples as soon as you hand them to it.
Use your tx_streamer::send() [1] method to transmit samples.
A good example how to do this is still tx_samples_from_file [2].
Best regards,
Marcus
[1]
http://files.ettus.com/manual/classuhd_1_1tx__streamer.html#aeb2e0f44810693d9da99ea1e04fad21f
[2]
https://github.com/EttusResearch/uhd/blob/master/host/examples/tx_samples_from_file.cpp#L62
On 04/21/2015 03:42 AM, ??? via USRP-users wrote:
>
> Dear all,
>
>
>
>
>
> I want to transmit transmit the real-time streaming packets in my USRP
> N210 devices.
>
>
>
> How to input the streaming packet to the input of my USRP N210 to
> transmit the packets?
>
>
>
> Best regards
>
>
>
> Thanks
>
>
>
> _______________________________________________
> 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/20150422/dae20ac9/attachment-0001.html>
------------------------------
Message: 13
Date: Wed, 22 Apr 2015 11:33:40 -0700
From: Ian Buckley <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] x310 Master clock rate
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
X310 - 3x 47tap halfbands in both TX and RX directions (and then CIC)
-Ian
On Apr 22, 2015, at 2:44 AM, Marcus M?ller via USRP-users
<[email protected]> wrote:
> Hi!
>
> Thanks for following up on this.
>> With the master clock set at 200Mhz and a sampling rate of 40Msps the
>> following warning appears:
>>
>> UHD Warning:
>> The requested interpolation is odd; the user should expect CIC rolloff.
>> Select an even interpolation to ensure that a halfband filter is enabled.
>> interpolation = dsp_rate/samp_rate -> 5 = (200.000000 MHz)/(40.000000 MHz)
>>
>
> To explain the warning:
> The FPGA decimates the RX samples down, coming in at the master clock rate
> from the ADC, to the sampling rate you select.
> To do that without introducing aliasing, it has to low-pass filter them.
> The FPGA filter chain has multiple stages; if I remember correctly, the
> filters are in this order:
> 1. 1x CIC filter for odd factors in decimation
> 2. 3x 31-tap half band filters that each implement a good decimation for
> factors of 2 each.
>
> Now, if you use an odd decimation (200MHz/40MHz==5), there's no factor of 2
> in your decimation, and hence you only use the "not-as-good" CIC filter, and
> are likely to see effects of filter roll-of at the edges of your band.
>
> In TX direction, it's quite the same problem:
> 1. 1x 17-tap half band interpolators
> 2. 1x 5-tap half band interpolators
> 3. 1x CIC
>
> Therefore: if your measurements show that your signal is OK for your
> application, just ignore the warning (it's just a warning, not an error); if
> you think this is bad for the signal you want to work with, I'd recommend
> using a 50MS/s sampling rate -- that would have a decimation of 4 and should
> work beautifully. Of course, this means that your host computer would have to
> implement the interpolation.
>
> How wide is the signal you're planning to transmit spectrally? Is it
> significantly less than 40MHz wide?
>
>> When we increase the sampling rate to anything above 40Msps, the following
>> discrepancy is seen in the data.
>> If you look at the above image there seems to be some missing data.
> I can only guess here, but is it possible UHD printed an "O" when you tried
> to transmit this?
> That would imply that your computer was too slow to supply the samples in
> real time, and since the USRP did not have anything to transmit, there is a
> "pause".
>
> Best regards,
> Marcus M?ller
>
> _______________________________________________
> 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/20150422/1175a004/attachment-0001.html>
------------------------------
Message: 14
Date: Wed, 22 Apr 2015 14:46:20 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Receive two channels on the B210 with
different sample rates
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 04/22/2015 02:05 PM, Marcus D. Leech via USRP-users wrote:
> On 03/17/2015 01:55 PM, Hunter DeJarnette wrote:
>> Marcus,
>>
>> Thanks for your quick reply. Is this supported on other USRP
>> models? Are there any plans for this to be supported on the B210?
>>
>> Hunter
> No, there's no support for this in other models, either. While it's
> conceptually possible, it isn't actually implemented, partially
> because there's
> no way to setup the master clock (on, for example, the X310) in
> cases where there's no common master-clock rate that can produce both
> sample rates.
>
> The best approach is to bring both streams in at the same rate, and
> resample the lower-rate stream. If you use Gnu Radio, there are various
> resamplers, including a rational and fractional resampler.
>
>
I was mis-lead by R&D, and have now been re-lead :)
On the *X310 in particular*, you can have two different sample rates
from the two "sides" but those streams *must* be packaged inside
separate multi_usrp objects, and they both must, of course, satisfy
the integer fraction rules with respect to the master clock rate.
The streams inside a multi-usrp object are required to be at the same
sample-rate, because a multi-usrp "object" does sample time
synchronization which is maximally awkward if the streams are running
at two different rates....
>>
>> On Tue, Mar 17, 2015 at 12:51 PM, <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> This is not a supported configuration on the B210.
>>
>> If you need different sample-rates on the two streams, you'll
>> have to re-sample in software.
>>
>> On 2015-03-17 12:12, Hunter DeJarnette via USRP-users wrote:
>>
>>> I'm working on an application with the B210 where I would like
>>> to use both rx dsp's, but at different sample rates. I
>>> understand that each of the channels attached to a single
>>> rx_streamer must have the same sample rate. So to get around
>>> this issue I tried instantiating two usrp sources each with a
>>> different channel like so:
>>>
>>> self.uhd_usrp_source_0 = uhd.usrp_source(
>>> ",".join(("type=b200", "")),
>>> uhd.stream_args(
>>> cpu_format="fc32",
>>> channels=[0],
>>> ),
>>> )
>>> self.uhd_usrp_source_1 = uhd.usrp_source(
>>> ",".join(("type=b200", "")),
>>> uhd.stream_args(
>>> cpu_format="fc32",
>>> channels=[1],
>>> ),
>>> )
>>> self.uhd_usrp_source_0.set_subdev_spec("A:A A:B", 0)
>>> self.uhd_usrp_source_0.set_samp_rate(samp_rate_0)
>>> self.uhd_usrp_source_1.set_samp_rate(samp_rate_1)
>>>
>>> I found that when the sample rates for the two sources are the
>>> same I get similar performance to the using two channels on a
>>> single usrp_source. However, when I try to use different sample
>>> rates I start dropping samples. Am I setting this up right?
>>>
>>> Thanks,
>>>
>>> Hunter
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected] <mailto:[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/20150422/2ea3d310/attachment-0001.html>
------------------------------
Message: 15
Date: Wed, 22 Apr 2015 23:07:19 +0000
From: Paul B <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] B200 Broadcast FM and other signals on airband
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi guys,
My troubles seem to be at no end at the moment!
After reinstalling my Windows 8.1 due to a hard drive change, i've been having
trouble with my B200 on HDSDR using Balints ExtIO_USRP+FCD+RTL2832U + BorIP-1.6
BETA 3.
Before re-installing Windows 8.1, i had no issues at all, but since
re-installing, i've been getting what seem like ghost signals on airband. They
appear from about 114MHz through to 128MHz. They appear to be broadcast FM,
Trunking and MotoTRBO signals, though when i move the frequency slider, they
vanish, only to reappear when i move further along the band.
I've included a picture of the problem, and my settings in ExtIO:
https://www.dropbox.com/s/o6u3oe83ch4gm9o/Signals.jpg?dl=0
and my settings:
https://www.dropbox.com/s/082d17pi0osnw36/Settings.jpg?dl=0
I'm running the B200 over USB 3, and it's using 003.007.001, which
unfortunately, i can't seem to upgrade due to getting an incompatability
warning when trying to use HDSDR after upgrading. I've installed the B200 USB
Driver, and in Device Manager, my device shows up as USRP B200.
Does anyone have any idea what could be causing this problem, and any possible
solution?
Thanks for any help,
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150422/9fc2920a/attachment-0001.html>
------------------------------
Message: 16
Date: Wed, 22 Apr 2015 18:29:31 -0500
From: Carlos Quiroga <[email protected]>
To: [email protected]
Subject: [USRP-users] Can't Find USRP N200
Message-ID:
<caggd95fagqsqkhztgln2cnw8nwa1gdupiabm-qgntv20mi0...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear all,
I am new using the USRP's, i have an USRP N200 and I have installed the GNU
radio "gnuradio-3.6.0.tar.gz" and the UHD "
uhd_003.005.001-49-stable_Ubuntu-12.04-x86_64.deb" but I can't find my
USRP when I run command uhd_usrp_probe --args="addr=192.168.10.2". I have
set my host Ethernet interface (Fast Ethernet) with a static IP address
(192.168.10.1).
I have been trying load the images onto the On-board Flash for N series but
I don't know what is the difference between the binaries too:
-usrp_n200_r2_fpga.bin
-usrp_n200_r3_fpga.bin
-usrp_n200_r4_fpga.bin
in other hand when I tried to install the UHD version 003.008.003 I had
some problems to install it, that is the reason because I installed UHD
003.005.001
Any ideas on what might be preventing the USRP N200 from being identified
by the host PC?
Is the Fast Ethernet a problem in my host? (it suppose when I connect my
USRP with my laptop the Ethernet green led are on, but in my case those are
always off, and the B and F led are on)
whats the meaning of those binaries?
All advice is very apreciated, Thanks
--
Carlos F. Quiroga Ruiz
University del Valle- Cali Colombia
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150422/b52d7fa6/attachment-0001.html>
------------------------------
Message: 17
Date: Wed, 22 Apr 2015 16:43:19 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Can't Find USRP N200
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Carlos,
On 22.04.2015 16:29, Carlos Quiroga via USRP-users wrote:
> I am new using the USRP's, i have an USRP N200 and I have installed the
> GNU radio "|gnuradio-3.6.0.||tar||.gz|" and the UHD
> "uhd_003.005.001-49-stable_Ubuntu-12.04-x86_64.deb" but I can't find my
> USRP when I run command uhd_usrp_probe --args="addr=192.168.10.2". I
> have set my host Ethernet interface (Fast Ethernet) with a static IP
> address (192.168.10.1).
Two quick things to look into:
- That UHD + GNU Radio versions are very, very old. It should work, but
I recommend upgrading.
- uhd_find_devices and uhd_usrp_probe don't require you to know the
USRP's IP, as long as it's on the same subnet. So try without the
--args. If you're sure about the IP, try ping.
> I have been trying load the images onto the On-board Flash for N series
> but I don't know what is the difference between the binaries too:
>
> -usrp_n200_r2_fpga.bin
> -usrp_n200_r3_fpga.bin
> -usrp_n200_r4_fpga.bin
Different revisions (rev 2, rev 3, etc.). Your board revision should be
on the silkscreen, if in doubt. But the revision is also stored in the
EEPROM, and should correctly be detected.
> in other hand when I tried to install the UHD version 003.008.003 I had
> some problems to install it, that is the reason because I installed UHD
> 003.005.001
Which problems did you have? Which OS are you using?
> Any ideas on what might be preventing the USRP N200 from being
> identified by the host PC?
>
> Is the Fast Ethernet a problem in my host? (it suppose when I connect my
> USRP with my laptop the Ethernet green led are on, but in my case those
> are always off, and the B and F led are on)
You can find the description of the LEDs at
http://files.ettus.com/manual/page_usrp2.html#usrp2_hw_leds. You need a
1GBit connection.
Cheers,
Martin
>
> whats the meaning of those binaries?
>
> All advice is very apreciated, Thanks
------------------------------
Message: 18
Date: Wed, 22 Apr 2015 16:45:56 -0700
From: Neel Pandeya <[email protected]>
To: Carlos Quiroga <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Can't Find USRP N200
Message-ID:
<cacaxmv8mdnvr5cxyfacnhmsyamql8hfyn4k+mxauk_u55qe...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
UHD 3.5.1 is very old. You should definitely use UHD 3.8.2, and you have to
be sure to use a 1 Gbps Ethernet interface (a 100 Mbps Ethernet interface
will not work). I would use a more up-to-date version of GNU Radio, such
3.7.6. I'll send send you some instructions for installing UHD and GNU
Radio off-list, as they're too long to post here. You shouldn't need to
flash any of the images onto the N200, unless your device is having a
problem.
--Neel
On 22 April 2015 at 16:29, Carlos Quiroga via USRP-users <
[email protected]> wrote:
> Dear all,
>
> I am new using the USRP's, i have an USRP N200 and I have installed the
> GNU radio "gnuradio-3.6.0.tar.gz" and the UHD "
> uhd_003.005.001-49-stable_Ubuntu-12.04-x86_64.deb" but I can't find my
> USRP when I run command uhd_usrp_probe --args="addr=192.168.10.2". I have
> set my host Ethernet interface (Fast Ethernet) with a static IP address
> (192.168.10.1).
>
> I have been trying load the images onto the On-board Flash for N series
> but I don't know what is the difference between the binaries too:
>
> -usrp_n200_r2_fpga.bin
> -usrp_n200_r3_fpga.bin
> -usrp_n200_r4_fpga.bin
>
> in other hand when I tried to install the UHD version 003.008.003 I had
> some problems to install it, that is the reason because I installed UHD
> 003.005.001
>
> Any ideas on what might be preventing the USRP N200 from being identified
> by the host PC?
>
> Is the Fast Ethernet a problem in my host? (it suppose when I connect my
> USRP with my laptop the Ethernet green led are on, but in my case those are
> always off, and the B and F led are on)
>
> whats the meaning of those binaries?
>
> All advice is very apreciated, Thanks
>
> --
> Carlos F. Quiroga Ruiz
> University del Valle- Cali Colombia
>
> _______________________________________________
> 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/20150422/0ece064e/attachment-0001.html>
------------------------------
Message: 19
Date: Wed, 22 Apr 2015 17:11:39 -0700
From: Michael West <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Receive two channels on the B210 with
different sample rates
Message-ID:
<cam4xkrrlkfd3atvfobwju4hxmpzx6tcsddssmhv3pm2-rrb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Hunter,
My apologies to you and Marcus for the confusion. I have looked at the UHD
source code and the B210 can support different rates on each channel as
well. Your set up looks correct, but it is difficult to say what may be
happening without further information. Can you elaborate on what sample
rates you are using, what master clock rate you are using, and exactly what
errors you are seeing?
Regards,
Michael
On Wed, Apr 22, 2015 at 11:46 AM, Marcus D. Leech via USRP-users <
[email protected]> wrote:
> On 04/22/2015 02:05 PM, Marcus D. Leech via USRP-users wrote:
>
> On 03/17/2015 01:55 PM, Hunter DeJarnette wrote:
>
> Marcus,
>
> Thanks for your quick reply. Is this supported on other USRP models?
> Are there any plans for this to be supported on the B210?
>
> Hunter
>
> No, there's no support for this in other models, either. While it's
> conceptually possible, it isn't actually implemented, partially because
> there's
> no way to setup the master clock (on, for example, the X310) in cases
> where there's no common master-clock rate that can produce both
> sample rates.
>
> The best approach is to bring both streams in at the same rate, and
> resample the lower-rate stream. If you use Gnu Radio, there are various
> resamplers, including a rational and fractional resampler.
>
>
> I was mis-lead by R&D, and have now been re-lead :)
>
> On the *X310 in particular*, you can have two different sample rates from
> the two "sides" but those streams *must* be packaged inside
> separate multi_usrp objects, and they both must, of course, satisfy the
> integer fraction rules with respect to the master clock rate.
>
> The streams inside a multi-usrp object are required to be at the same
> sample-rate, because a multi-usrp "object" does sample time
> synchronization which is maximally awkward if the streams are running at
> two different rates....
>
>
>
>
> On Tue, Mar 17, 2015 at 12:51 PM, <[email protected]> wrote:
>
>> This is not a supported configuration on the B210.
>>
>> If you need different sample-rates on the two streams, you'll have to
>> re-sample in software.
>>
>>
>>
>>
>>
>>
>> On 2015-03-17 12:12, Hunter DeJarnette via USRP-users wrote:
>>
>> I'm working on an application with the B210 where I would like to use
>> both rx dsp's, but at different sample rates. I understand that each of the
>> channels attached to a single rx_streamer must have the same sample rate.
>> So to get around this issue I tried instantiating two usrp sources each
>> with a different channel like so:
>>
>> self.uhd_usrp_source_0 = uhd.usrp_source(
>> ",".join(("type=b200", "")),
>> uhd.stream_args(
>> cpu_format="fc32",
>> channels=[0],
>> ),
>> )
>> self.uhd_usrp_source_1 = uhd.usrp_source(
>> ",".join(("type=b200", "")),
>> uhd.stream_args(
>> cpu_format="fc32",
>> channels=[1],
>> ),
>> )
>> self.uhd_usrp_source_0.set_subdev_spec("A:A A:B", 0)
>> self.uhd_usrp_source_0.set_samp_rate(samp_rate_0)
>> self.uhd_usrp_source_1.set_samp_rate(samp_rate_1)
>>
>> I found that when the sample rates for the two sources are the same I get
>> similar performance to the using two channels on a single usrp_source.
>> However, when I try to use different sample rates I start dropping samples.
>> Am I setting this up right?
>>
>>
>>
>> Thanks,
>> Hunter
>>
>> _______________________________________________
>> USRP-users mailing
>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
>
> _______________________________________________
> USRP-users mailing
> [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/20150422/4345c381/attachment-0001.html>
------------------------------
Message: 20
Date: Thu, 23 Apr 2015 15:58:17 +0530
From: siva sankar <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Time of arrival of first sample in a 2 Rx setup
Message-ID:
<CAAubjiUJgzx9fZAiJVU0+z-Vgru=gkguint3g_uucw1+bef...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello List,
I am using USRP B210 and the UHD version is 003.008.000. We are
transmitting on one channel and receiving simultaneously on both the
channels and what we want is the time of arrival of the first sample in
both the receive buffers.
We have used the "time_spec_t" to get the time of the first sample but we
don't know if the time that we are getting is for both the channels or for
one of the receiver buffers.
We have tried using two "recv" commands one for each buffer hoping we could
calculate the time from each metadata parameter passed to the "recv"
command in one thread but it throws "multi channel alignment" error and
stops running.
We also tried to create individual threads for both the rx channels and
pass different metadata parameters and hence know the time of first sample
for each buffer. However, this throws segmentation fault.
Any help on how to calculate the time of first sample for each receive
buffer will be appreciated.
Thanks
Siva.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150423/f9bf7224/attachment-0001.html>
------------------------------
Message: 21
Date: Thu, 23 Apr 2015 12:55:10 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Time of arrival of first sample in a 2 Rx
setup
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hello Siva,
recv() will do an aligned reception, i.e. the first samples of both
streams were received at the same time.
Often, you don't want to /know/ /afterwards/ the time of reception, you
want to /define/ it beforehand. You can do that by using a stream_cmd
with a stream_now = false and a timespec to allow you to define when the
reception is going to take place.
Greetings,
Marcus
On 04/23/2015 12:28 PM, siva sankar via USRP-users wrote:
> Hello List,
>
> I am using USRP B210 and the UHD version is 003.008.000. We are
> transmitting on one channel and receiving simultaneously on both the
> channels and what we want is the time of arrival of the first sample
> in both the receive buffers.
>
> We have used the "time_spec_t" to get the time of the first sample but
> we don't know if the time that we are getting is for both the channels
> or for one of the receiver buffers.
>
> We have tried using two "recv" commands one for each buffer hoping we
> could calculate the time from each metadata parameter passed to the
> "recv" command in one thread but it throws "multi channel alignment"
> error and stops running.
>
> We also tried to create individual threads for both the rx channels
> and pass different metadata parameters and hence know the time of
> first sample for each buffer. However, this throws segmentation fault.
>
> Any help on how to calculate the time of first sample for each receive
> buffer will be appreciated.
>
> Thanks
> Siva.
>
>
> _______________________________________________
> 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/20150423/da55053d/attachment-0001.html>
------------------------------
Message: 22
Date: Thu, 23 Apr 2015 18:23:54 +0530
From: siva sankar <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Time of arrival of first sample in a 2 Rx
setup
Message-ID:
<caaubjixt50kmjyuzjv0edokudahg5ggcmoqbhtugnjwg6az...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hey Marcus,
Thanks for the reply.
The receivers here are at different distances from the transmitter and we
are looking for the time difference of arrival of the samples at the
receive buffers.
How do we proceed with this ?
Regards
Siva
Hello Siva,
recv() will do an aligned reception, i.e. the first samples of both streams
were received at the same time.
Often, you don't want to *know* *afterwards* the time of reception, you
want to *define* it beforehand. You can do that by using a stream_cmd with
a stream_now = false and a timespec to allow you to define when the
reception is going to take place.
Greetings,
Marcus
On 04/23/2015 12:28 PM, siva sankar via USRP-users wrote:
Hello List,
I am using USRP B210 and the UHD version is 003.008.000. We are
transmitting on one channel and receiving simultaneously on both the
channels and what we want is the time of arrival of the first sample in
both the receive buffers.
We have used the "time_spec_t" to get the time of the first sample but we
don't know if the time that we are getting is for both the channels or for
one of the receiver buffers.
We have tried using two "recv" commands one for each buffer hoping we
could calculate the time from each metadata parameter passed to the "recv"
command in one thread but it throws "multi channel alignment" error and
stops running.
We also tried to create individual threads for both the rx channels and
pass different metadata parameters and hence know the time of first sample
for each buffer. However, this throws segmentation fault.
Any help on how to calculate the time of first sample for each receive
buffer will be appreciated.
Thanks
Siva.
_______________________________________________
USRP-users mailing
[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/20150423/cd5311ba/attachment-0001.html>
------------------------------
Message: 23
Date: Thu, 23 Apr 2015 14:55:10 +0200
From: Marcus M?ller <[email protected]>
To: siva sankar <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Time of arrival of first sample in a 2 Rx
setup
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hey Siva,
I assume this means you have two B210s?
Sorry, I don't really have a picture of your setup in mind, would you
mind making a sketch?
Best regards,
Marcus
On 04/23/2015 02:53 PM, siva sankar wrote:
>
> Hey Marcus,
>
> Thanks for the reply.
> The receivers here are at different distances from the transmitter and
> we are looking for the time difference of arrival of the samples at
> the receive buffers.
>
> How do we proceed with this ?
>
> Regards
> Siva
>
> Hello Siva,
> recv() will do an aligned reception, i.e. the first samples of both
> streams were received at the same time.
>
> Often, you don't want to /know/ /afterwards/ the time of reception,
> you want to /define/ it beforehand. You can do that by using a
> stream_cmd with a stream_now = false and a timespec to allow you to
> define when the reception is going to take place.
>
> Greetings,
> Marcus
>
>
> On 04/23/2015 12:28 PM, siva sankar via USRP-users wrote:
>> Hello List,
>>
>> I am using USRP B210 and the UHD version is 003.008.000. We are
>> transmitting on one channel and receiving simultaneously on both the
>> channels and what we want is the time of arrival of the first sample
>> in both the receive buffers.
>>
>> We have used the "time_spec_t" to get the time of the first sample
>> but we don't know if the time that we are getting is for both the
>> channels or for one of the receiver buffers.
>>
>> We have tried using two "recv" commands one for each buffer hoping we
>> could calculate the time from each metadata parameter passed to the
>> "recv" command in one thread but it throws "multi channel alignment"
>> error and stops running.
>>
>> We also tried to create individual threads for both the rx channels
>> and pass different metadata parameters and hence know the time of
>> first sample for each buffer. However, this throws segmentation fault.
>>
>> Any help on how to calculate the time of first sample for each
>> receive buffer will be appreciated.
>>
>> Thanks
>> Siva.
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[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/20150423/07ab1f40/attachment-0001.html>
------------------------------
Message: 24
Date: Thu, 23 Apr 2015 16:08:11 +0200
From: LOUF Laurent <[email protected]>
To: siva sankar <[email protected]>, Marcus M?ller
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Time of arrival of first sample in a 2 Rx
setup
Message-ID:
<5eb8adb6498522479c5e7381a2c8cf354abb4b7...@thsonea01cms10p.one.grp>
Content-Type: text/plain; charset="utf-8"
Hi,
If you just want the time difference, you may want to compute the correlation
between the two signals for different offsets (unit : samples) and find the
offset that gives you the maximum of correlation (and then translate the number
of samples into a time difference with the sampling frequency). If receivers
are not too far away one from the other, I guess that could be a solution (to
be investigated).
Regards,
Laurent.
De : USRP-users [mailto:[email protected]] De la part de siva
sankar via USRP-users
Envoy? : jeudi 23 avril 2015 14:54
? : Marcus M?ller
Cc : [email protected]
Objet : Re: [USRP-users] Time of arrival of first sample in a 2 Rx setup
Hey Marcus,
Thanks for the reply.
The receivers here are at different distances from the transmitter and we are
looking for the time difference of arrival of the samples at the receive
buffers.
How do we proceed with this ?
Regards
Siva
Hello Siva,
recv() will do an aligned reception, i.e. the first samples of both streams
were received at the same time.
Often, you don't want to know afterwards the time of reception, you want to
define it beforehand. You can do that by using a stream_cmd with a stream_now =
false and a timespec to allow you to define when the reception is going to take
place.
Greetings,
Marcus
On 04/23/2015 12:28 PM, siva sankar via USRP-users wrote:
Hello List,
I am using USRP B210 and the UHD version is 003.008.000. We are transmitting on
one channel and receiving simultaneously on both the channels and what we want
is the time of arrival of the first sample in both the receive buffers.
We have used the "time_spec_t" to get the time of the first sample but we don't
know if the time that we are getting is for both the channels or for one of the
receiver buffers.
We have tried using two "recv" commands one for each buffer hoping we could
calculate the time from each metadata parameter passed to the "recv" command in
one thread but it throws "multi channel alignment" error and stops running.
We also tried to create individual threads for both the rx channels and pass
different metadata parameters and hence know the time of first sample for each
buffer. However, this throws segmentation fault.
Any help on how to calculate the time of first sample for each receive buffer
will be appreciated.
Thanks
Siva.
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[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/20150423/f17bf864/attachment-0001.html>
------------------------------
Message: 25
Date: Thu, 23 Apr 2015 08:35:46 -0700
From: Dario Fertonani <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Timed transmission after U/L errors
Message-ID:
<cajgedaijvgk3advh-h76frgddbdbnzqampfns18shk_9bvs...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
The problem has disappeared after the last "UHD maint" update. Also, we
changed our code so that zeros are transmitted when we have nothing to send
in a slot (earlier we just didn't call "send" for that slot). Which of the
two fixed the problem is not clear.
I'm still going to reply to the pending questions below.
> You description sounds like continuous transmission--if that's the case,
> then why not just use continuous streaming?
>
Yes, that is the case. We would want continuous transmission and continuous
reception. The reception part goes well, since an explicit "continuous"
stream command is available and errors are returned when continuity isn't
achieved. I would like to use the same strategy at the transmit side,
setting the start of transmission time and then going continuously from
there. However, I can't find the API for doing that. I can get something
close to that by setting the has_time_spec to false after the first packet,
but the documentation says that this transmits "ASAP", which I interpreted
as "if you want a specific time, just use has_time_spec=true always", since
we really can't have "holes", or worse "holes" that accumulate over time
causing a drift between transmission and reception. If my interpretation of
the API is wrong please correct me. Currently, to achieve continuous
full-duplex streams, we run "continuous" reception and "timed" transmission
(has_time_spec always true) with self-incrementing time_spec.
> Also, "L" means 'late', which means that by the time the USRP went to send
> the frame of samples, the time given in the header has already passed.
> If you're you're doing very-tight timing, not accounting for average
> latency through the stack, and you're getting underruns, I can imagine
> things
> starting to go badly off the rails. My suggestion would be to, when you
> get an 'L' or 'U' indication, hold-off on transmitting for a while, and
> restart
> your stream several time-slots into the future.
>
That is essentially what we do. There is a tradeoff on how early to send
the future packet (too soon doesn't allow time to "prepare" the future
packet, too late causes L/U errors). Hence, we go aggressively late while
capturing things that go wrong.
Thanks,
Dario
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150423/870fac95/attachment-0001.html>
------------------------------
Message: 26
Date: Thu, 23 Apr 2015 11:40:15 -0400
From: [email protected]
To: Dario Fertonani <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Timed transmission after U/L errors
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Look at a simple example like tx_waveforms, or tx_samples_from_file.
They both use continuous transmission.
On 2015-04-23 11:35, Dario Fertonani wrote:
> The problem has disappeared after the last "UHD maint" update. Also, we
> changed our code so that zeros are transmitted when we have nothing to send
> in a slot (earlier we just didn't call "send" for that slot). Which of the
> two fixed the problem is not clear.
> I'm still going to reply to the pending questions below.
>
>> You description sounds like continuous transmission--if that's the case,
>> then why not just use continuous streaming?
>
> Yes, that is the case. We would want continuous transmission and continuous
> reception. The reception part goes well, since an explicit "continuous"
> stream command is available and errors are returned when continuity isn't
> achieved. I would like to use the same strategy at the transmit side, setting
> the start of transmission time and then going continuously from there.
> However, I can't find the API for doing that. I can get something close to
> that by setting the has_time_spec to false after the first packet, but the
> documentation says that this transmits "ASAP", which I interpreted as "if you
> want a specific time, just use has_time_spec=true always", since we really
> can't have "holes", or worse "holes" that accumulate over time causing a
> drift between transmission and reception. If my interpretation of the API is
> wrong please correct me. Currently, to achieve continuous full-duplex
> streams, we run "continuous" reception and "timed" transmission
> (has_time_spec always true) with
self-incrementing time_spec.
>
>> Also, "L" means 'late', which means that by the time the USRP went to send
>> the frame of samples, the time given in the header has already passed.
>> If you're you're doing very-tight timing, not accounting for average latency
>> through the stack, and you're getting underruns, I can imagine things
>> starting to go badly off the rails. My suggestion would be to, when you get
>> an 'L' or 'U' indication, hold-off on transmitting for a while, and restart
>> your stream several time-slots into the future.
>
> That is essentially what we do. There is a tradeoff on how early to send the
> future packet (too soon doesn't allow time to "prepare" the future packet,
> too late causes L/U errors). Hence, we go aggressively late while capturing
> things that go wrong.
>
> Thanks,
> Dario
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150423/33ca7f96/attachment-0001.html>
------------------------------
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 56, Issue 23
******************************************
