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. LO Frequency (Pedro Gabriel Adami)
2. Re: LO Frequency (Marcus D. Leech)
3. Re: Asymmetry in achievable TX/RX rates (Claudio Cicconetti)
4. Re: [RFNoC] FPGA image is 2 bytes larger than expected
(Felipe Augusto Pereira de Figueiredo)
5. Re: X310 - It is possible to feed samples from a file to the
rx chain? (Paolo Palana)
6. Re: No GPSDO found message (Nikita Airee)
7. Re: LO offset effect on passband (Dominik Eyerly)
8. Re: LO Frequency (Mike McLernon)
----------------------------------------------------------------------
Message: 1
Date: Sun, 26 Feb 2017 23:06:59 -0300
From: Pedro Gabriel Adami <[email protected]>
To: [email protected]
Subject: [USRP-users] LO Frequency
Message-ID:
<CA+FB9W-8R7UorEArEpUngqbmXt_csO=gwvjsoujmm4gbyms...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
Inside USRP configuration in Simulink there is a parameter called "LO
Frequency". I have been looking for definitions or explanations about it,
but I had no success. Could you, please, explain it for me briefly?
Thanks in advance!
Cheers,
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170226/a42fed35/attachment-0001.html>
------------------------------
Message: 2
Date: Sun, 26 Feb 2017 22:20:46 -0500
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] LO Frequency
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 02/26/2017 09:06 PM, Pedro Gabriel Adami via USRP-users wrote:
> Hello,
>
> Inside USRP configuration in Simulink there is a parameter called "LO
> Frequency". I have been looking for definitions or explanations about
> it, but I had no success. Could you, please, explain it for me briefly?
>
> Thanks in advance!
>
> Cheers,
> Peter
>
>
It's the frequency of the Local Oscillator, which is combined with your
incoming signal in a mixer to produce the baseband signal as seen
by the ADC.
See "Local Oscillator" and "Superheterodyne receiver" and "zero-IF
receiver" in google.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170226/f68302db/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 27 Feb 2017 10:00:38 +0100
From: Claudio Cicconetti <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Asymmetry in achievable TX/RX rates
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Dear all,
I have been struggling for a few months to do continuous streaming of
100 MS/s towards an X300 with a single 10 GbE on Linux (Ubuntu).
My mission is not yet fully accomplished (see below) but I have a few
findings to share that may be useful to others:
- data _must_ be ready when you issue the send() command: no way you can
do processing between consecutive calls to send()
- assigning real-time scheduling priority to the sending thread: surely
does not harm, but also does _not_ save you from underruns if there are
concurrent threads on the same core, even if they have best-effort priority
- CPU speed is important but, again, is _not_ a life-saver: I have same
performance, in terms of rate of underruns, with Intel E5-2660 @ 2.60
GHz and Intel i7-6700K @ 4.00 GHz
- fiddling with OS (ie. changing CPU frequency scaling, locking thread
to a core, disabling IRQ balancing, disabling unused cores) very easily
leads to a _worse_ performance; on the other hand, I never managed to
get any noticeable improvements out of these tricks
- NIC interrupt coalescing _must_ be enabled in my case (Intel 82599ES):
with interrupt coalescing enabled I have about 8000 interrupts/s, which
is much below the maximum my CPU+OS can sustain (easily 6-7x that)
- for all other network-related configuration the default is sufficient,
including the number of TX descriptors and network buffers
- the size of the vectors passed to send() does not influence
performance; in particular, it does _not_ help to split the vector into
chunks with a size that is a multiple of the maximum samples per packet
The only remaining issue I have is that I get sporadic underruns (in the
order of one every several minutes, on average) that are periodic with
base 10 seconds within 0.01 s. For instance, first underrun at
08:22:54.83, next could be at 08:31:04.83 and then 08:34:24.83 and so on.
Since the only non-vital daemon running on the PC is sshd, I wonder
whether it is something related to the OS (Google did help me
pin-pointing the issue) or to the UHD (something like "every 1 billions
samples do something special").
Best regards,
Claudio
On 02/24/2017 10:47 PM, Martin Braun via USRP-users wrote:
> Stefano,
>
> let me just add some statements to this:
>
> - In general, it's harder to create data at high rates from a PC and
> then receive it on the FPGA than vice versa. On top of what Ian said,
> regular OSes + GPPs have a lot of scheduling latency/randomness. At 100
> Msps, on the 3.10 release cycle, you will get an underrun if you miss a
> chance to transmit a data packet by a small number of ?s (the actual
> value is hard to tell, but we're speaking of two-digit orders of
> magnitude). But even 100 ?s scheduling delays are possible. On my
> machine, I need to tune some knobs until I get this kind of performance,
> such as using "performance" CPU governors (I also increase the number of
> Tx descriptors with ethtool -G, but I'm not sure that's as influential.
> I would still recommend you bump it all the way up to 4096).
> - With dual-channel, this gets exacerbated because you have multiple
> threads competing for timely access to the transport device. I would
> assume that with dual cables, that's not true, but who knows what's
> going on internally.
>
> - On 3.10, we are currently *worse off* than on 3.9 in terms of
> streaming performance. There's a whole bunch of reasons for that, but
> the good news is we're currently working on some fixes to improve
> streaming performance. With the current 3.10 release, it's hard to run
> at 200 Msps from GNU Radio, for instance. If your software has
> comparable rates to benchmark_rate, then you're probably not going to be
> affected by this anyway.
>
> -- M
>
>
> On 02/23/2017 12:05 PM, Ian Buckley via USRP-users wrote:
>> Stefano
>> I'll take a stab at explaining the probable background on this. UHD uses
>> credit based flow control to avoid overflowing buffers in the USRP. When
>> you prepare to start a new TX operation the TX buffer inside the USRP is
>> completely empty and can fill at wire rate speed. At some point it
>> may/will become full and at this point the credit based flow control
>> algorithm will pace the data over the network such that it approximates
>> the TX rate over the air (Which is hard real time). When the actual TX
>> over the air operation starts relative to when the buffering of data
>> commences can yield some challenging situations.
>> If the TX operation starts as soon as the first samples of data reach
>> the TX DSP (i.e buffer is practically empty) then it runs the very real
>> risk of underflowing because it consumes data at a constant rate but
>> data delivered from the host tends to be bursty and jitter in delivery
>> (since the host is non-realtime in design) and also the main sample
>> buffer is a DRAM with a single port to which access is arbitrated adding
>> more jitter as ingress and egress compete for access. Typically UHD
>> deals with the "buffer practically empty" case by starting streaming the
>> data to the USRP well in advance of a scheduled TX operation start time
>> allowing time for buffers to fill somewhat, but the buffer access
>> arbitration is tricky at startup since you have a corner case situation
>> with data streaming in at wire speeds rather than rate limited by the
>> credit algorithm plus data being drained at the configured sample rate
>> by the TX DSP. What you are probably therefore seeing is underflows (@
>> the DSP) during the initial fill of the buffer as internal bandwidth is
>> transiently exceeded, and then smoother operation as the bit rate over
>> the network drops back to approximate the transmission sample rate once
>> the buffer is full.
>>
>> I'm a couple of years stale on the internal implementation details of
>> this now, but that is the gist of the challenge.
>> -Ian
>>
>>
>>
>> On Feb 23, 2017, at 11:02 AM, Stefano Bettelli via USRP-users
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>> Hi,
>>>
>>> We are still in the process of extracting maximum performance from our
>>> USRP X310's, and we have a weird problem with transmission of data,
>>> which does not appear while reading data. The USRP that I am
>>> considering has two 10G fibre connections, and uses the XG FPGA
>>> firmware (we use the latest UHD, 3.10.1.1). The software developed by
>>> us and the benchmark_rate example agree on both RX and TX, so I will
>>> report only the results with the benchmark_rate. RX works nicely, we
>>> have 800MB/s on each fibre:
>>>
>>> ./benchmark --args "addr=192.168.30.2,second_addr=192.168.40.2"
>>> --duration 30 --channel "0,1" --rx_otw sc16 --rx_cpu sc16 --rx_rate 200e6
>>> linux; GNU C++ version 5.4.0 20160609; Boost_105800;
>>> UHD_003.010.001.001-release
>>> [...]
>>> Testing receive rate 200.000000 Msps on 2 channels
>>> Benchmark rate summary:
>>> Num received samples: 12000120052
>>> Num dropped samples: 0
>>> Num overflows detected: 0
>>> Num transmitted samples: 0
>>> Num sequence errors: 0
>>> Num underflows detected: 0
>>> Num late commands: 0
>>> Num timeouts: 0
>>>
>>> However, TX shows a lot of problems for rates larger that 50MS/s, for
>>> instance:
>>>
>>> ./benchmark --args "addr=192.168.30.2,second_addr=192.168.40.2"
>>> --duration 30 --channel "0,1" --tx_otw sc16 --tx_cpu sc16 --tx_rate 100e6
>>> linux; GNU C++ version 5.4.0 20160609; Boost_105800;
>>> UHD_003.010.001.001-release
>>> [?]
>>> Testing transmit rate 100.000000 Msps on 2 channels
>>> [? throws a lot of U?s ?]
>>> Benchmark rate summary:
>>> Num received samples: 0
>>> Num dropped samples: 0
>>> Num overflows detected: 0
>>> Num transmitted samples: 6013212352
>>> Num sequence errors: 0
>>> Num underflows detected: 18509
>>> Num late commands: 0
>>> Num timeouts: 0
>>>
>>> Eventually there is transmission at 400MB/s on both fibres, but we
>>> lose the initial part. Achieving tx_rate=200e6 does not work at all
>>> (the USRP stops replying). By observing the threads with htop we see
>>> that one thread approaches 80-90% of CPU usage. By comparison with our
>>> program, where we can identify the threads, I infer that it is the
>>> thread containing the tx_streamer->send() call; this call seems to be
>>> very heavy. All this looks strange because the Ethernet fibres are
>>> exactly the same, and the rest of the system seems to be configured in
>>> the same way for RX and TX:
>>>
>>> Both network interfaces have MTU=9000:
>>> ifconfig | grep enp129 -A3
>>> enp129s0f0 Link encap:Ethernet HWaddr e8:4d:d0:c5:1b:2c
>>> inet addr:192.168.40.1 Bcast:192.168.40.255 Mask:255.255.255.0
>>> inet6 addr: fe80::ea4d:d0ff:fec5:1b2c/64 Scope:Link
>>> UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
>>> --
>>> enp129s0f1 Link encap:Ethernet HWaddr e8:4d:d0:c5:1b:2d
>>> inet addr:192.168.30.1 Bcast:192.168.30.255 Mask:255.255.255.0
>>> inet6 addr: fe80::ea4d:d0ff:fec5:1b2d/64 Scope:Link
>>> UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
>>>
>>> Both RX and TX have large network buffer sizes
>>> sysctl -a | grep net.core.*mem_max
>>> net.core.rmem_max = 33554432
>>> net.core.wmem_max = 33554432
>>>
>>> both RX and TX have the same number of descriptors (also on the other
>>> card):
>>> ethtool -g enp129s0f0
>>> Ring parameters for enp129s0f0:
>>> Pre-set maximums:
>>> RX: 4096
>>> RX Mini: 0
>>> RX Jumbo: 0
>>> TX: 4096
>>> Current hardware settings:
>>> RX: 512
>>> RX Mini: 0
>>> RX Jumbo: 0
>>> TX: 512
>>>
>>> Interrupt coalescing seems not to be available on these cards. The
>>> server is also quite powerful, 2xXeon with 48 cores in total, and
>>> 128GB of memory. Cores run at at least 3GHz. Can you suggest any idea
>>> to help us debugging this problem? Thanks in advance,
>>>
>>> Best regards/Mit freundlichen Gruessen,
>>>
>>> Stefano Bettelli
>>> Senior research engineer
>>>
>>> _______________________________________________
>>> 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
>>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 4
Date: Mon, 27 Feb 2017 11:23:38 +0100
From: Felipe Augusto Pereira de Figueiredo <[email protected]>
To: Sam Carey <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] [RFNoC] FPGA image is 2 bytes larger than
expected
Message-ID:
<ca+abmwkqdfcc2mqnzmnqeksuma50sqqjtfcc30_i3l6g4ht...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Dear Sam,
Many thanks for your tip, I've followed that and it worked. Just
changed the size of the macro with the expected bitstream size.
I hope someone from Ettus can explain why that problem happens and if
it can be solved other way instead of tweaking the source code.
Now the output of "uhd_usrp_probe" is like I had expected it to be.
| | _____________________________________________________
| | /
| | | RFNoC blocks on this device:
| | |
| | | * DmaFIFO_0
| | | * Radio_0
| | | * Radio_1
| | | * DDC_0
| | | * DDC_1
| | | * DUC_0
| | | * DUC_1
| | | * FFT_0
Thanks and Best Regards,
Felipe
On Fri, Feb 24, 2017 at 3:27 PM, Sam Carey <[email protected]> wrote:
> Howdy,
>
> I had this problem a while back. My workaround was to simply edit the image
> loader code so that it is OK with the larger file size.
> Just do a search for the smaller byte number in the uhd/host source code,
> change it to the larger byte number, and rebuild/reinstall uhd.
> Apparently, the byte count is not a strict requirement for image loading.
>
> You're the second other person I've seen with this problem.
> Maybe somebody could apply this change to the main branch or something?
>
> -Sam
>
>
------------------------------
Message: 5
Date: Mon, 27 Feb 2017 11:43:40 +0100
From: Paolo Palana <[email protected]>
To: Jason Matusiak <[email protected]>,
[email protected]
Subject: Re: [USRP-users] X310 - It is possible to feed samples from a
file to the rx chain?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 02/24/2017 05:35 PM, Jason Matusiak wrote:
> Paolo,
>
> I may be oversimplifying this, but would a file-source block work for
> you? I currently have a known-signal that is saved in a file that I
> use to test out my custom RFNoC blocks, it seems to work pretty well
> (just remember to add a throttle since you aren't using the radio
> front-end anymore).
Dear Jason, first of all thank you for your replay.
What you said sounds exactly like what I want. I didn't noticed this
block before, this is of course my fault.
What I really need is a way to feed to my block a test signal, e.g. a
sinusoid, and then observe the results.
May be you can explain better how to you use this features or give a
link to understand how to do that?
Reading the HDL code give me no hint.
Have a good day.
Paolo
------------------------------
Message: 6
Date: Mon, 27 Feb 2017 16:13:11 +0530
From: Nikita Airee <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] No GPSDO found message
Message-ID:
<CAOT=stnuiwd0txrmce8wmnpkytxuwm-tzabcyiuzeta88-a...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi list,
the information I had provided might not have been enough. So here is some
more:
My X310 has internal GPSDO. This is visible to UHD when I perform
uhd_usrp_probe provided it is connected to my laptop using Gigabit ethernet:
linux; GNU C++ version 4.8.4; Boost_106000; UHD_003.009.006-0-g122d5f8e
-- X300 initialization sequence...
-- Determining maximum frame size... 1472 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- *Detecting internal GPSDO.... Found an internal GPSDO: LC_XO, Firmware
Rev 0.929a*
-- Initialize Radio0 control...
-- Performing register loopback test... pass
-- Initialize Radio1 control...
-- Performing register loopback test... pass
...
However, when I use PCI Express for connection, it says:
linux; GNU C++ version 4.8.4; Boost_106000; UHD_003.009.006-0-g122d5f8e
-- X300 initialization sequence...
-- Connecting to niusrpriorpc at localhost:5444...
-- Using LVBITX bitfile /usr/local/share/uhd/images/
usrp_x310_fpga_HGS.lvbitx...
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
--
*Detecting internal GPSDO.... UHD Error: GPS invalid reply "", assuming
none availableNo GPSDO found*
-- Initialize Radio0 control...
-- Performing register loopback test... pass
-- Initialize Radio1 control...
-- Performing register loopback test... pass
...
When the same USRP is connected to a laptop with a different UHD version
via PCIe, I get:
linux; GNU C++ version 4.8.2; Boost_106000; UHD_3.11.0.git-28-gc66cb1ba
-- X300 initialization sequence...
-- Connecting to niusrpriorpc at localhost:5444...
-- Using LVBITX bitfile
/usr/local/share/uhd/images/usrp_x310_fpga_HG.lvbitx...
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- *Detecting internal GPSDO.... Found an internal GPSDO: LC_XO, Firmware
Rev 0.929a*
-- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1186.1MB/s)
-- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1189.4MB/s)
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
...
Also when I try sync_to_gps, it says:
...
Waiting for reference lock...LOCKED
*WARNING: GPS not locked - time will not be accurate until locked *
USRP time: 1136078288.000000000
GPSDO time: 1136078288.000000000
SUCCESS: USRP time synchronized to GPS time
On querying gpsdo sensors soon after, I find that :
USRP Locked to GPSDO 10 MHz Reference.
GPS and UHD Device time are NOT aligned;
last_pps: 9 vs gps: 1136078227. Trying to set the device time to GPS
time...
-- 1) catch time transition at pps edge
-- 2) set times next pps (synchronously)
last_pps: 1136078231 vs gps: 1136078231.
GPS and UHD Device time are aligned.
Printing available NMEA strings:
GPS_GPGGA:
$GPGGA,011711.00,0000.0000,N,00000.0000,E,0,99,1.0,0.0,M,0.0,M,,*5B
GPS_GPRMC: $GPRMC,011711.00,V,0000.0000,N,00000.0000,E,0.0,0.0,010106,,*25
GPS Epoch time at last PPS: 1136078232.00000 seconds
UHD Device time last PPS: 1136078232.00000 seconds
UHD Device time right now: 1136078232.27291 seconds
PC Clock time: 1487756260 seconds
...
Could anybody please help me with this? I suppose that when the gps is
locked, it means that uhd is time aligned with gps? If so, I would also
really like to know exactly how you permanently lock gps.
Bests,
Nikita Airee
On Tue, Feb 21, 2017 at 8:20 PM, Nikita Airee <[email protected]> wrote:
> Hi list,
>
> I have:
>
> Ubuntu 14.04
>
> UHD: 003.009.006-0-g122d5f8e
>
> USRP X310 with CBX20 + GPSDO
>
> I moved to UHD 3.9.6 very recently and since then have been facing the
> following issue related to GPSDO:
>
> *UHD Error: GPS invalid reply "", assuming none available
> No GPSDO found*
>
> UHD_3.11.0.git-28-gc66cb1ba would never throw up this message.
>
> Is this a known issue? If not, how do I use GPSDO?
>
> Bests,
>
> Nikita Airee
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170227/ecb799b1/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 27 Feb 2017 13:06:10 +0100
From: Dominik Eyerly <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] LO offset effect on passband
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Michael,
Thanks for getting back to me. Unfortunately, this does not improve the
plots. Even settings the bandwidth to max (56e6) still produces a
lopsided passband. Do you have any other recommendations I could try?
cheers,
dominik
On 02/25/2017 10:48 PM, Michael West wrote:
> Hi Dominik,
>
> I believe you need to set the rx_bandwidth to rate + abs(2*lo_offset).
>
> Regards,
> Michael
>
> On Thu, Feb 23, 2017 at 7:02 AM, Dominik Eyerly via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hello,
>
> I have some follow-up questions to the LO offset discussion. Some
> quick background, I've been characterizing and calibrating the rx
> of the B205-i for several months now and I am trying to squeeze
> every bit of performance out of it. In general, the calibration
> works quite well. However, I'm always looking for tips and tricks
> to improve the performance. It was mentioned that one should use
> an offset of at least +/-6MHz for optimal performance. In spirit
> of this I wanted to investigate the flatness of the passband with
> the two options (no offset, -8MHz offset). According to this
> https://files.ettus.com/manual/page_usrp_b200.html
> <https://files.ettus.com/manual/page_usrp_b200.html> 56MHz is the
> max master clock so I set mine to 40MHz to enable a 20MHz sample
> rate. My rx_bandwidth is set according to rate+abs(LO_OFFSET).
> The test is performed in the following way:
>
> 1. Set B205 rx freq to 2.4G, gain to 35, rate to 20M, (10db
> external pad connected)
> 2. Generator sweeps a tone from 2.4G-30M to 2.4G+30M in 50kHz
> steps at constant -20dBm output power.
> 3. Fetch 50k samples per sweep point, flat top window, FFT,
> extract largest tone and put it in dBm.
>
> The plots linked below are the results of the two sweeps (0
> offset, -8MHz offset). Note that the y-axis scale has an arbitrary
> x-dBm offset that is not interesting for this test.
>
> http://imgur.com/a/laDFy
>
> I noticed that the flatness and shape of the two options are quite
> different. Some things I expected like the image being mixed in at
> the lower frequencies for the -8MHz offset, however, I was hoping
> the passband would look more similar. For example, at +4MHz tone
> freq, there is 1dB of difference. My question is as simple as, is
> this expected or am I configuring something incorrectly? Also,
> what procedure would you recommend for equalizing the passband?
>
> cheers,
> Dominik
>
> --
>
>
>
> --
>
> i.A. Dominik Eyerly
> Software
>
> Tel: +49 (0) 351 7958019 233 <tel:+49%20351%207958019233>
> Fax: +49 (0) 351 7958019 232 <tel:+49%20351%207958019232>
> Email: [email protected]
> <mailto:[email protected]>
>
> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
> www.konrad-technologies.de <http://www.konrad-technologies.de>
> www.abexstandard.org <http://www.abexstandard.org>
>
> *Support Telefon: +49 (0) 7732 9815 100 <tel:+49%207732%209815100>*
> [email protected] <mailto:[email protected]>
> sig
> Gesch?ftsleitung: Michael Konrad
> Handelsregisternr: HRB 550593 in Freiburg
> Ust-Id-Nr. DE 206693267
>
> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden
> Dokumente, enthalten Informationen der Konrad GmbH und sind nur f?r die
> adressierte Person bestimmt. Diese k?nnen vertraulich und/oder von
> Ver?ffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an nicht
> autorisierte Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar
> gemacht werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den
> Absender bitte umgehend. Danke
>
> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
> it, contains information from Konrad GmbH, which is intended only for the use
> of the individual or entity to which it is addressed, and which may contain
> information that is privileged, confidential, and/or otherwise exempt from
> disclosure under applicable law. If the reader of this message is not the
> intended recipient, any disclosure, dissemination, distribution, copying or
> other use of this communication or its substance is prohibited. If you have
> received this communication in error, please contact us immediately. Thank
> you.
>
> _______________________________________________ USRP-users mailing
> list [email protected]
> <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>
--
--
i.A. Dominik Eyerly
Software
Tel: +49 (0) 351 7958019 233
Fax: +49 (0) 351 7958019 232
Email: [email protected]
<mailto:[email protected]>
*Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
www.konrad-technologies.de <http://www.konrad-technologies.de>
www.abexstandard.org <http://www.abexstandard.org>
*Support Telefon: +49 (0) 7732 9815 100*
[email protected] <mailto:[email protected]>
sig
Gesch?ftsleitung: Michael Konrad
Handelsregisternr: HRB 550593 in Freiburg
Ust-Id-Nr. DE 206693267
VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente,
enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte Person
bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen ausgenommen
sein. Das Kopieren und die Weitergabe an nicht autorisierte Dritte sind
verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht werden. Falls Sie
nicht der Empf?nger sind, benachrichtigen Sie den Absender bitte umgehend. Danke
CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany it,
contains information from Konrad GmbH, which is intended only for the use of
the individual or entity to which it is addressed, and which may contain
information that is privileged, confidential, and/or otherwise exempt from
disclosure under applicable law. If the reader of this message is not the
intended recipient, any disclosure, dissemination, distribution, copying or
other use of this communication or its substance is prohibited. If you have
received this communication in error, please contact us immediately. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170227/d3ae21d1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170227/d3ae21d1/attachment-0001.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170227/d3ae21d1/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170227/d3ae21d1/attachment-0001.asc>
------------------------------
Message: 8
Date: Mon, 27 Feb 2017 12:53:07 +0000
From: Mike McLernon <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] LO Frequency
Message-ID:
<bn1pr05mb437c357b13415ef84d69fe6e9...@bn1pr05mb437.namprd05.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
See also the description of LO Frequency at the documentation page for the SDRu
Receiver block, at
https://www.mathworks.com/help/supportpkg/usrpradio/ug/sdrureceiver.html.
Mike
From: USRP-users [mailto:[email protected]] On Behalf Of
Marcus D. Leech via USRP-users
Sent: Sunday, February 26, 2017 10:21 PM
To: [email protected]
Subject: Re: [USRP-users] LO Frequency
On 02/26/2017 09:06 PM, Pedro Gabriel Adami via USRP-users wrote:
Hello,
Inside USRP configuration in Simulink there is a parameter called "LO
Frequency". I have been looking for definitions or explanations about it, but I
had no success. Could you, please, explain it for me briefly?
Thanks in advance!
Cheers,
Peter
It's the frequency of the Local Oscillator, which is combined with your
incoming signal in a mixer to produce the baseband signal as seen
by the ADC.
See "Local Oscillator" and "Superheterodyne receiver" and "zero-IF receiver" in
google.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170227/d2cedfe0/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 78, Issue 25
******************************************
