Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: No UHD Devices Found (Javier Ricke)
2. Re: No UHD Devices Found (Marcus D. Leech)
3. Re: UHD and Soundcard confliction? (Ian Buckley)
4. USRP X310 alternate PCIe host card (Timothy Schaffer)
5. Re: USRP X310 motherboard issues (Timothy Schaffer)
6. Re: USRP X310 alternate PCIe host card (Matt Ettus)
7. UHD and Soundcard confliction?? (wonder freedomfighter)
8. Re: UHD and Soundcard confliction?? (Marcus D. Leech)
9. Re: UHD and Soundcard confliction?? (Ian Buckley)
10. Re: UHD and Soundcard confliction?? (Marcus D. Leech)
11. Need USRP to India through ebay (Vikram Khore)
12. Re: Strange behavior of N210 with timed commands (Martin Braun)
13. Re: Strange behavior of N210 with timed commands (LOUF Laurent)
----------------------------------------------------------------------
Message: 1
Date: Sun, 14 Dec 2014 14:07:47 -0300
From: Javier Ricke <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] No UHD Devices Found
Message-ID:
<CAP7s5+zu4=1n+e0txe83-eqlulgunuibzk_tg0ec2yxbpds...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
end :D?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141214/bd3dd6ea/attachment-0001.html>
------------------------------
Message: 2
Date: Sun, 14 Dec 2014 12:15:08 -0500
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] No UHD Devices Found
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 12/14/2014 12:07 PM, Javier Ricke via USRP-users wrote:
> end :D?
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Well, I don't understand what's going on. I've repeatedly sent you,
from my Ettus account, instructions on re-programming to EEPROM in an
attempt to restore your B100, including a .bin file. Did you not
receive said e-mails?
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141214/a2ace172/attachment-0001.html>
------------------------------
Message: 3
Date: Sun, 14 Dec 2014 11:12:11 -0800
From: Ian Buckley <[email protected]>
To: wonder freedomfighter <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD and Soundcard confliction?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Again, Marcus's advice is good, you should seek help on the GNURadio list.
You haven't got a hardware issue, you have a GNURadio flow graph issue.
Both the USRP and the Audio card are real time time devices with fixed sample
rates.
Your flow graph must take this into account and match those sample rates.
On Dec 14, 2014, at 8:15 AM, wonder freedomfighter via USRP-users
<[email protected]> wrote:
> Here are some more details regarding my sound problem
> I?m using a MSI gaming seven motherboard which has several audio outputs
> HDMI, S/PDIF and analogue I have tried all options
> I?m running a FM flow graph in gnu radio with the audio set to 48khz
> I have tried to change the options that I could find within Ubuntu to no
> regards
> This is my flow graph test Fm
> <test Fm.grc>_______________________________________________
> 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/20141214/477d7388/attachment-0001.html>
------------------------------
Message: 4
Date: Sun, 14 Dec 2014 14:13:39 -0500
From: Timothy Schaffer <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] USRP X310 alternate PCIe host card
Message-ID:
<CACx9bDoiJ55LsxyQP=1-jd8pcley-voj2y2bjmcbjdlcnfp...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I was wondering if anyone has attempted to use the X310 with a different
PCIe/MXI host card than the one sold by NI?
I'm currently using the 10gbe interface which is fine in regards to speed,
but wasn't aware that Labview integration (reprogram FPGA) was only
available over the PCIe interface (although to be honest the writing was on
the wall, I just didn't read it).
>From what I've been able to read so far, it appears that the drivers for
the PCIe interface are actually for the X3XX and not necessarily the actual
NI PCIe interface card. It also seems like this card is essentially
transparent to the operating system. Having never used PCIe expanders
before I'm just guessing here, wondering if anyone out there has any
experience with this?
Specifically I was hoping that I could get by with
http://www.maxexpansion.com/adapters/pcie-x4 which is roughly $500 cheaper
than the NI route. This has the advantage of saving me enough money to
purchase 2 x LFTX and 2 x LFRX daughterboards :)
-Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141214/c8dbf7e1/attachment-0001.html>
------------------------------
Message: 5
Date: Sun, 14 Dec 2014 14:24:55 -0500
From: Timothy Schaffer <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP X310 motherboard issues
Message-ID:
<CACx9bDqCNACjusxe=2elkcqnzarjsmj8o40ict6t5mwkpxf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Just wanted to close the loop on this for historical purposes. This problem
was in fact resolved by updating the FPGA firmware and was not related to
any hardware issues. A quick RX cal after updating the firmware cleared up
any discrepancies that were left between the two subdevs.
On Wed, Dec 10, 2014 at 6:40 PM, Matt Ettus <[email protected]> wrote:
>
>
> The timing error is caused by an unconstrained path, so some builds will
> work and some won't. I don't know if that version and the particular image
> you would be using were ones that worked or didn't. You can try, but I'd
> suggest just waiting for the known good ones to come tomorrow.
>
> Matt
>
>
>
> On Wed, Dec 10, 2014 at 3:33 PM, T via USRP-users <
> [email protected]> wrote:
>
>> Matt - that makes sense, the glitches are apparent on the scope attached
>> to subdev B. No worries, this is really the first weekend I've tried to
>> work on the X310 since I got it, so I was concerned there may have been a
>> hardware issue with it. Do you know if the UHD 3.7.2 drivers have the same
>> glitch? I was thinking about installing them tonight.
>>
>> -Tim
>>
>> Sent from my iPad
>>
>> On Dec 10, 2014, at 14:37, Matt Ettus <[email protected]> wrote:
>>
>>
>> Tim,
>>
>> This is actually caused by a timing problem that crept into the FPGA
>> builds because we had an unconstrained path. What you are seeing is
>> signals passing between clock domains and sometimes a few bits don't make
>> it in time so you get a glitch. We noticed it a few days ago, and have
>> fixed it. We are building new images in all the variations, and the new
>> builds will be available tomorrow. Sorry for the inconvenience.
>>
>> Thanks,
>> Matt
>>
>>
>> On Wed, Dec 10, 2014 at 10:02 AM, Timothy Schaffer via USRP-users <
>> [email protected]> wrote:
>>
>>> I received an X310 from NI last week along with 2 x WBX-120 boards and
>>> I've noticed a difference in signal quality between the A and B subdevs of
>>> the motherboard. Overall, It seems the signals receive from the B side are
>>> generally distorted and prone to harmonics. I naturally assumed this was an
>>> issue with the WBX boards, so I swapped them and noticed the same issues.
>>> Next I swapped the cables connected to the bulkhead and still the same
>>> issue.
>>> I''m currently using UHD 3.008.000-52, but have not tried other
>>> versions. I've reloaded the FPGA firmware, ran all 3 cal routines on both
>>> subdevs. I'm not sure what else to try? I'v eattached a couple of screen
>>> shots of some of the tests I performed with an HP E4432B. The tests were
>>> done back to back using the same cable from the siggen to the USRP.
>>>
>>> You can see in these two screen shots, the actual distortion to the
>>> waveform in the scope.
>>> <multi_tone_B.png>.<multi-tone_A.png>
>>>
>>> Here is a DQPSK(24.3ksps) test signal at 303 MHz
>>>
>>> <QPSK_A.png><QPSK_B.png>
>>>
>>> Any ideas on what could be wrong, or does it need to go back to NI for
>>> repair/replace?
>>>
>>> -Tim
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141214/bd91b5a0/attachment-0001.html>
------------------------------
Message: 6
Date: Sun, 14 Dec 2014 11:27:08 -0800
From: Matt Ettus <[email protected]>
To: Timothy Schaffer <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP X310 alternate PCIe host card
Message-ID:
<CAN=1kn8k+tytbq1xxl93kj_9y9yjmnnzrz6r0cgzypmptcr...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
The PCIe to Cabled-PCIe cards should all be interchangeable, so that other
board is probably fine. In general, those boards should not need their own
drivers.
Matt
On Sun, Dec 14, 2014 at 11:13 AM, Timothy Schaffer via USRP-users <
[email protected]> wrote:
>
> I was wondering if anyone has attempted to use the X310 with a different
> PCIe/MXI host card than the one sold by NI?
>
> I'm currently using the 10gbe interface which is fine in regards to speed,
> but wasn't aware that Labview integration (reprogram FPGA) was only
> available over the PCIe interface (although to be honest the writing was on
> the wall, I just didn't read it).
>
> From what I've been able to read so far, it appears that the drivers for
> the PCIe interface are actually for the X3XX and not necessarily the actual
> NI PCIe interface card. It also seems like this card is essentially
> transparent to the operating system. Having never used PCIe expanders
> before I'm just guessing here, wondering if anyone out there has any
> experience with this?
>
> Specifically I was hoping that I could get by with
> http://www.maxexpansion.com/adapters/pcie-x4 which is roughly $500
> cheaper than the NI route. This has the advantage of saving me enough money
> to purchase 2 x LFTX and 2 x LFRX daughterboards :)
>
> -Tim
>
> _______________________________________________
> 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/20141214/64e6d39c/attachment-0001.html>
------------------------------
Message: 7
Date: Sun, 14 Dec 2014 20:34:54 +0100
From: wonder freedomfighter <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] UHD and Soundcard confliction??
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1256"
My flow-graph is outputting 48 KHz, which is the standard
for soundcards,
Which is my problem: hence why I seek expertise on
this matter, and not to be belittled because am asking for some guidance
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141214/07e3e3c4/attachment-0001.html>
------------------------------
Message: 8
Date: Sun, 14 Dec 2014 14:42:50 -0500
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UHD and Soundcard confliction??
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 12/14/2014 02:34 PM, wonder freedomfighter via USRP-users wrote:
>
> My flow-graph is outputting 48 KHz, which is the standard for soundcards,
>
> Which is my problem: hence why I seek expertise on this matter, and
> not to be belittled because am asking for some guidance
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
My point is that unless you share your flow-graph with us (and, the
gnuradio-users forum is probably best for that), there's not a lot of
help we
can offer you. I honestly have no intention of belittling anyone.
But, seriously, it's nearly impossible to offer opinions on what might
be wrong unless
you share your complete flow-graph and setup description. Without
that, we're all just taking wild guesses.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141214/15de7660/attachment-0001.html>
------------------------------
Message: 9
Date: Sun, 14 Dec 2014 12:34:05 -0800
From: Ian Buckley <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] UHD and Soundcard confliction??
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Your flow graph is presenting samples to the sound card at 8.33333kHz.
10e6 * 5 / (50 * 12 * 10) = 8.333kHz.
Hence why you would be wise to visit the GNURadio listserv, folks there will be
happy to help you with a GNURadio problem and the answer will be recorded there
for the benefit of others with similar problems.
BTW. As a matter of listserv etiquette, you should always reply to emails,
enabling the listserv to understand that all related messages are part of the
same thread.
-Ian
(Marcus, flow graph was attached to the 2nd thread)
On Dec 14, 2014, at 11:42 AM, Marcus D. Leech via USRP-users
<[email protected]> wrote:
> On 12/14/2014 02:34 PM, wonder freedomfighter via USRP-users wrote:
>> My flow-graph is outputting 48 KHz, which is the standard for soundcards,
>>
>> Which is my problem: hence why I seek expertise on this matter, and not to
>> be belittled because am asking for some guidance
>>
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> My point is that unless you share your flow-graph with us (and, the
> gnuradio-users forum is probably best for that), there's not a lot of help we
> can offer you. I honestly have no intention of belittling anyone. But,
> seriously, it's nearly impossible to offer opinions on what might be wrong
> unless
> you share your complete flow-graph and setup description. Without that,
> we're all just taking wild guesses.
>
>
> _______________________________________________
> 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/20141214/960123cf/attachment-0001.html>
------------------------------
Message: 10
Date: Sun, 14 Dec 2014 15:37:30 -0500
From: "Marcus D. Leech" <[email protected]>
To: Ian Buckley <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] UHD and Soundcard confliction??
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 12/14/2014 03:34 PM, Ian Buckley wrote:
> Your flow graph is presenting samples to the sound card at 8.33333kHz.
> 10e6 * 5 / (50 * 12 * 10) = 8.333kHz.
> Hence why you would be wise to visit the GNURadio listserv, folks
> there will be happy to help you with a GNURadio problem and the answer
> will be recorded there for the benefit of others with similar problems.
>
> BTW. As a matter of listserv etiquette, you should always reply to
> emails, enabling the listserv to understand that all related messages
> are part of the same thread.
> -Ian
> (Marcus, flow graph was attached to the 2nd thread)
I utterly missed it. Sorry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141214/40360bf0/attachment-0001.html>
------------------------------
Message: 11
Date: Mon, 15 Dec 2014 11:56:08 +0530
From: Vikram Khore <[email protected]>
To: [email protected]
Subject: [USRP-users] Need USRP to India through ebay
Message-ID:
<cakfnrjtrrrpjq0t7erzz6275jsnstanyrz4je_vp-gjsbuj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi
This is repeated call
I need to buy from ebay
1) can get second hand on reasonable rates
2) processing will be fast
Please let me know if anybody is selling it
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141215/7074e2c0/attachment-0001.html>
------------------------------
Message: 12
Date: Mon, 15 Dec 2014 10:32:55 +0100
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Strange behavior of N210 with timed commands
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 12/12/2014 02:58 PM, LOUF Laurent via USRP-users wrote:
> I?m not quite sure how to use this mailing list so do not hesitate to
> redirect me to a better place or to someone that may know the answer to
> my question.
Hey Laurent,
you came to the right place.
> That being said, I?m currently working with an USRP N210 at work and
> observed a strange behavior on which I would like to have your input. I
> use the USRP to receive a signal, apply a channel simulation on it and
> transmit the signal obtained. I have absolutely no problem on the
> receive part but one little on the transmit part. The signal I use is
> sampled at 2Msamples / second, and I work on frames of 1250 samples, so
> frames of 625?s. So the whole process goes that way, I receive a frame,
> apply the channel simulation and then transmit it, at a fixed interval.
To clarify: You're working on a continuous stream of samples, processed
in chunks of 1250 samples? Or do you 'only' receive 1250 samples, then
stop, do the processing and restart?
> The problem occurs now : I do some calculations based on the time when I
> receive the first frame, add the latency of my system and a number of
> times 625?s corresponding to the number of frames sent, which makes the
> time to transmit the frame, that is sent to the USRP along with the
> current frame. If I put an interval of exactly 625?s, I get a fastpath
> message ?L? every two frames, and I can see that the data of the second
> frame is not transmitted. If I put an interval of 625,1?s, everything
> seems to work fine and I don?t get any error. The metadata I send along
> with the frame are : start_of_burst = true , end_of_burst = true ,
> has_time_spec = true and the time spec I got from my calculations. That
> feels strange to me since I don?t even have to add the time
> corresponding to one sample to get it to work (0,5?s). Could it be
> something related to the burst mode that I?m using ? I did not fully get
> that part reading the documentation, so feel free to enlighten me on
> that subject.
When you say burst mode, that sounds like you're using
STREAM_MODE_NUM_SAMPS_AND_DONE. Is that correct? Also, how are you
calculating your system latency?
If you've determined that precisely, you might be cutting it very close,
and the .5?s is all you need to just make it in time.
Note that the time stamp is stored in ticks, i.e. with reference to the
DAC sampling rate (100 Msps on the N210). .5?s is thus a difference of
50 samples.
Cheers,
M
------------------------------
Message: 13
Date: Mon, 15 Dec 2014 11:29:01 +0100
From: LOUF Laurent <[email protected]>
To: Martin Braun <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Strange behavior of N210 with timed commands
Message-ID:
<842_1418639343_548eb7ef_842_385_2_5eb8adb6498522479c5e7381a2c8cf354aae470...@thsonea01cms10p.one.grp>
Content-Type: text/plain; charset="iso-8859-1"
Hello Martin,
I indeed work on a continuous stream of samples. To measure the latency, I do
as follows :
- First, I send a dummy packet through the chain to initialize everything
(filters, FFT, ... )
- Once this packet is sent, I issue a stream command with a time spec of 1s
(I initialize the time to 0 when starting the system), with the mode
STREAM_MODE_START_CONTINUOUS
- When I have to send the first processed packet, I calculate the latency as
follows : with the packet is transmitted through my system the time of
reception (obtained with gettimeofday), so I take the current time - the time
of reception, divide that quantity by 625 (which gives me the number of frames
of latency), add 3 (just to be sure as gettimeofday may not be that precise,
and to leave time to send the data), and re-multiply that by 625. It gives me a
rough estimate of the latency in ?s, that I add to 1s (as the system was
supposed to begin to stream at 1s).
- Following packets have a time spec equal to the previously calculated time
spec of the first packet + current number of packet * 625.1?s
There do not seem to be a problem with the time spec of the first packet as I
never get an error when sending it, it's only when I replace 625.1?s by 625?s
as the spacing between two consecutive frames that I get a fastpath message
every two frames, and only one of two frames seems to be actually sent.
Concerning the burst mode on the sending part, I've just played around to find
something that worked, it's maybe not the parameters that I should use for my
application.
Cheers,
Laurent.
[@@OPEN @@]
-----Message d'origine-----
De?: USRP-users [mailto:[email protected]] De la part de
Martin Braun via USRP-users
Envoy??: lundi 15 d?cembre 2014 10:33
??: [email protected]
Objet?: Re: [USRP-users] Strange behavior of N210 with timed commands
On 12/12/2014 02:58 PM, LOUF Laurent via USRP-users wrote:
> I'm not quite sure how to use this mailing list so do not hesitate to
> redirect me to a better place or to someone that may know the answer
> to my question.
Hey Laurent,
you came to the right place.
> That being said, I'm currently working with an USRP N210 at work and
> observed a strange behavior on which I would like to have your input.
> I use the USRP to receive a signal, apply a channel simulation on it
> and transmit the signal obtained. I have absolutely no problem on the
> receive part but one little on the transmit part. The signal I use is
> sampled at 2Msamples / second, and I work on frames of 1250 samples,
> so frames of 625?s. So the whole process goes that way, I receive a
> frame, apply the channel simulation and then transmit it, at a fixed interval.
To clarify: You're working on a continuous stream of samples, processed in
chunks of 1250 samples? Or do you 'only' receive 1250 samples, then stop, do
the processing and restart?
> The problem occurs now : I do some calculations based on the time when
> I receive the first frame, add the latency of my system and a number
> of times 625?s corresponding to the number of frames sent, which makes
> the time to transmit the frame, that is sent to the USRP along with
> the current frame. If I put an interval of exactly 625?s, I get a
> fastpath message "L" every two frames, and I can see that the data of
> the second frame is not transmitted. If I put an interval of 625,1?s,
> everything seems to work fine and I don't get any error. The metadata
> I send along with the frame are : start_of_burst = true , end_of_burst
> = true , has_time_spec = true and the time spec I got from my
> calculations. That feels strange to me since I don't even have to add
> the time corresponding to one sample to get it to work (0,5?s). Could
> it be something related to the burst mode that I'm using ? I did not
> fully get that part reading the documentation, so feel free to
> enlighten me on that subject.
When you say burst mode, that sounds like you're using
STREAM_MODE_NUM_SAMPS_AND_DONE. Is that correct? Also, how are you calculating
your system latency?
If you've determined that precisely, you might be cutting it very close, and
the .5?s is all you need to just make it in time.
Note that the time stamp is stored in ticks, i.e. with reference to the DAC
sampling rate (100 Msps on the N210). .5?s is thus a difference of
50 samples.
Cheers,
M
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 52, Issue 17
******************************************
