Re: [USRP-users] USRP-users help needed

2018-02-28 Thread Stern, Joseph via USRP-users
Thank you all for your help.  I have been going through both the FPGA and 
host-side driver code for the B200mini and, in my still very limited 
understanding of SDRs in general, have come up with the following DDC chain:

  1.  multiplex 12-bit I and Q into 24-bit value
  2.  phase align with the NCO
  3.  use the CORDIC functionality to perform the down-shifting math to some IF 
or possibly baseband
  4.  apply the CIC algorithm to FIR filter and decimate
  5.  apply up to two half band filters, further decimating
  6.  clip I and Q by one bit due to the potential, maximum gain in the 
previous algorithms

I discovered the following:

  *   using an even (or unit) decimation prevents CIC rolloff
  *   two half band filters (abbreviated hb0 and hb1 in the Verilog and C++ 
code) are available, and each one decimates by a factor of two
  *   (half band filters are used as LPFs, when the signal is shifted all the 
way down to baseband)
  *   the only data being poked into the USRP interface are { hb0 enabled, hb1 
enabled, remaining decimation }

I'm sure you have spotted several misunderstandings in the above.  I'm still 
fuzzy on why the decimation is being set the way that it is.  It feels like the 
host-side driver code independently calculates all the filter and decimation 
properties that will be reflected on the FPGA side.  Please feel free to 
clarify for me the down-shifting and the inherent decimation when using half 
band filters (and anything I am completely oblivious to).



Thanks again for your help and guidance.


From: USRP-users [usrp-users-boun...@lists.ettus.com] on behalf of Marcus D. 
Leech via USRP-users [usrp-users@lists.ettus.com]
Sent: Monday, February 26, 2018 1:20 PM
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP-users help needed

On 02/26/2018 12:07 PM, Stern, Joseph via USRP-users wrote:

Dear USRP users:



We have been trying to understand the low-level details of the USRP 
architecture (namely, for the B200mini); there seems very little explicit 
insight provided on the Ettus web site into how decimation is performed in the 
FPGA (and commanded from the driver side).  I also cannot locate the 
open-source and freely available FPGA code.  Could someone assist me in gaining 
this insight?



Thank you very much!



Joe Stern

Ettus don't provide detailed design documents, but the source-code, as you say, 
is freely available:

Get the source from here:

https://github.com/EttusResearch/uhd

The do a "git submodule init"

The source bits of source code are somewhat separate, the the FPGA source code 
being a GIT sub-module.

In terms of "how is decimation commanded", that's the host-side driver in 
setting sample rates.  The job is divided between the capabilities of the
  AD9361 chip, and the FPGA.  In many cases, almost the entirety of 
decimation/filtering is done inside the AD9361 chip, since it effectively has 
an internal
  ADC that samples at 750Msps (can't remember the precise number), and the 
sample rate offered on its data interface is relatively to that, so in many
  cases, there is NO decimation performed within the FPGA.   This is all in the 
source code a shown above.



This message and any enclosures are intended only for the addressee. Please
notify the sender by email if you are not the intended recipient. If you are
not the intended recipient, you may not use, copy, disclose, or distribute this
message or its contents or enclosures to any other person and any such actions
may be unlawful. Ball reserves the right to monitor and review all messages
and enclosures sent to or from this email address.



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


This message and any enclosures are intended only for the addressee.  Please 
notify the sender by email if you are not the intended recipient.  If you are 
not the intended recipient, you may not use, copy, disclose, or distribute this 
message or its contents or enclosures to any other person and any such actions 
may be unlawful.  Ball reserves the right to monitor and review all messages 
and enclosures sent to or from this email address.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


Re: [USRP-users] x310 ZPU firmware

2018-02-28 Thread Ana Svirčić via USRP-users
Hello,

 

I was wondering has anyone managed to build the ZPU firmware on Windows? 

 

I’m trying to modify the original ettus x310 fpga design and the zpu fw, and
I’m stuck with the below mentioned error.

 

Also, I have another question regarding what to do once I build the fw. If I
understand correctly, the output of the zpugcc compiler is the .elf file. 
Do I convert it to .hex file? How do I do that? How do I include it in the
fpga design? 

 

Thank you,

Ana Svircic

 

 

From: Ana Svirčić [mailto:ana.svir...@mikroprojekt.hr] 
Sent: Monday, February 19, 2018 1:12 PM
To: 'usrp-users@lists.ettus.com' 
Subject: x310 ZPU firmware

 

Hi all, 

 

I’m trying to build the ZPU firmware for the x310 on Windows using Cygwin.
I downloaded zpugcc from github (https://github.com/zylin/zpugcc) and added
the path to the zpugcc bin directory to the $PATH environment variable. 

I run the following commands in cygwin and get the following error:

 

mkdir /cygdrive/c/Users/roadwarrior/Desktop/e/uhd/firmware/build

cd /cygdrive/c/Users/roadwarrior/Desktop/e/uhd/firmware/build

 

cmake ../usrp3

CMake Deprecation Warning at
/usr/share/cmake-3.6.2/Modules/CMakeForceCompiler.cmake:79 (message):

  The CMAKE_FORCE_C_COMPILER macro is deprecated.  Instead just set

  CMAKE_C_COMPILER and allow CMake to identify the compiler.

Call Stack (most recent call first):

  CMakeLists.txt:25 (CMAKE_FORCE_C_COMPILER)

 

 

-- Found PythonInterp: /cygdrive/c/ProgramData/Anaconda3/python.exe (found
version "3.6.3")

-- Configuring done

-- Generating done

-- Build files have been written to:
/cygdrive/c/Users/roadwarrior/Desktop/e/uhd/firmware/build

 

make

Scanning dependencies of target usrp3fw

[  2%] Building C object lib/CMakeFiles/usrp3fw.dir/udp_uart.c.obj

zpu-elf-gcc.exe:
/cygdrive/c/Users/roadwarrior/Desktop/e/uhd/firmware/usrp3/lib/udp_uart.c:
No such file or directory

zpu-elf-gcc.exe: no input files

make[2]: *** [lib/CMakeFiles/usrp3fw.dir/build.make:63:
lib/CMakeFiles/usrp3fw.dir/udp_uart.c.obj] Error 1

make[1]: *** [CMakeFiles/Makefile2:86: lib/CMakeFiles/usrp3fw.dir/all] Error
2

make: *** [Makefile:128: all] Error 2

 

 

The file udp_uart.c does exist in the mentioned directory. Don't know how to
proceed.  Can anybody help with this issue? 

 

Thank you and regards,

 

Ana Svircic

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


Re: [USRP-users] USRP-users help needed

2018-02-28 Thread Stern, Joseph via USRP-users
I have a couple specific questions I am hoping someone can answer, after this 
FYI:



I finally found the level of block diagram I wanted when Googling for "ettus 
ddc undersampling."  On the page, 
http://www.analog.com/en/products/rf-microwave/integrated-transceivers-transmitters-receivers/wideband-transceivers-ic/ad9361.html,
 I came across the link to 
https://github.com/analogdevicesinc/iio-oscilloscope/blob/master/block_diagrams/AD9361.svg.
  This clearly shows the functionality I was trying to describe in my previous 
post; I believe that, if HB3 is disabled, this diagram matches the B200mini 
exactly.



So, what is the maximum decimation that the B200mini can perform?



And, is undersampling performed at the final stage, in order to send baseband 
samples to the host?


From: USRP-users [usrp-users-boun...@lists.ettus.com] on behalf of Stern, 
Joseph via USRP-users [usrp-users@lists.ettus.com]
Sent: Wednesday, February 28, 2018 8:28 AM
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP-users help needed


Thank you all for your help.  I have been going through both the FPGA and 
host-side driver code for the B200mini and, in my still very limited 
understanding of SDRs in general, have come up with the following DDC chain:

  1.  multiplex 12-bit I and Q into 24-bit value
  2.  phase align with the NCO
  3.  use the CORDIC functionality to perform the down-shifting math to some IF 
or possibly baseband
  4.  apply the CIC algorithm to FIR filter and decimate
  5.  apply up to two half band filters, further decimating
  6.  clip I and Q by one bit due to the potential, maximum gain in the 
previous algorithms

I discovered the following:

  *   using an even (or unit) decimation prevents CIC rolloff
  *   two half band filters (abbreviated hb0 and hb1 in the Verilog and C++ 
code) are available, and each one decimates by a factor of two
  *   (half band filters are used as LPFs, when the signal is shifted all the 
way down to baseband)
  *   the only data being poked into the USRP interface are { hb0 enabled, hb1 
enabled, remaining decimation }

I'm sure you have spotted several misunderstandings in the above.  I'm still 
fuzzy on why the decimation is being set the way that it is.  It feels like the 
host-side driver code independently calculates all the filter and decimation 
properties that will be reflected on the FPGA side.  Please feel free to 
clarify for me the down-shifting and the inherent decimation when using half 
band filters (and anything I am completely oblivious to).



Thanks again for your help and guidance.


From: USRP-users [usrp-users-boun...@lists.ettus.com] on behalf of Marcus D. 
Leech via USRP-users [usrp-users@lists.ettus.com]
Sent: Monday, February 26, 2018 1:20 PM
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP-users help needed

On 02/26/2018 12:07 PM, Stern, Joseph via USRP-users wrote:

Dear USRP users:



We have been trying to understand the low-level details of the USRP 
architecture (namely, for the B200mini); there seems very little explicit 
insight provided on the Ettus web site into how decimation is performed in the 
FPGA (and commanded from the driver side).  I also cannot locate the 
open-source and freely available FPGA code.  Could someone assist me in gaining 
this insight?



Thank you very much!



Joe Stern

Ettus don't provide detailed design documents, but the source-code, as you say, 
is freely available:

Get the source from here:

https://github.com/EttusResearch/uhd

The do a "git submodule init"

The source bits of source code are somewhat separate, the the FPGA source code 
being a GIT sub-module.

In terms of "how is decimation commanded", that's the host-side driver in 
setting sample rates.  The job is divided between the capabilities of the
  AD9361 chip, and the FPGA.  In many cases, almost the entirety of 
decimation/filtering is done inside the AD9361 chip, since it effectively has 
an internal
  ADC that samples at 750Msps (can't remember the precise number), and the 
sample rate offered on its data interface is relatively to that, so in many
  cases, there is NO decimation performed within the FPGA.   This is all in the 
source code a shown above.



This message and any enclosures are intended only for the addressee. Please
notify the sender by email if you are not the intended recipient. If you are
not the intended recipient, you may not use, copy, disclose, or distribute this
message or its contents or enclosures to any other person and any such actions
may be unlawful. Ball reserves the right to monitor and review all messages
and enclosures sent to or from this email address.



__

[USRP-users] N310

2018-02-28 Thread Louis Brown via USRP-users
Any news on when the N310 will be available?

Thanks,
Lou


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


[USRP-users] USRP E310 and its DC suppression

2018-02-28 Thread Brais Ares via USRP-users
Hello,

We are using a E310 device to capture a signal and further process it in
Matlab. We also have a frontend that lift the received signal around 43 dB
before going into the E310.

When we use direct RF to baseband conversion we observe a high DC
suppression, around 50 dB (see figure here )

Is there any way to avoid it or the only option is to move this "hole" by
tuning the lo_offset in tune_request_t (then not using direct RF
conversion, but converting to IF first) further away from the signal I'm
interested in?

And out of curiosity, which would be the exact block of the rx chain which
is performing this DC suppression?

Regards,
Brais.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


Re: [USRP-users] USRP E310 and its DC suppression

2018-02-28 Thread Marcus D. Leech via USRP-users

On 02/28/2018 03:32 PM, Brais Ares via USRP-users wrote:

Hello,

We are using a E310 device to capture a signal and further process it 
in Matlab. We also have a frontend that lift the received signal 
around 43 dB before going into the E310.


When we use direct RF to baseband conversion we observe a high DC 
suppression, around 50 dB (see figure here )


Is there any way to avoid it or the only option is to move this "hole" 
by tuning the lo_offset in tune_request_t (then not using direct RF 
conversion, but converting to IF first) further away from the signal 
I'm interested in?


And out of curiosity, which would be the exact block of the rx chain 
which is performing this DC suppression?


Regards,
Brais.


DC offset suppression is performed inside the AD9361.

If your signal is right at the notional centre frequency and is very 
narrowband, you can get significant suppression of it.  The way to deal 
with this is

  to use offset tuning.


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


Re: [USRP-users] USRP-users help needed

2018-02-28 Thread Marcus D. Leech via USRP-users

On 02/28/2018 12:06 PM, Stern, Joseph via USRP-users wrote:


I have a couple specific questions I am hoping someone can answer, 
after this FYI:


I finally found the level of block diagram I wanted when Googling for 
"ettus ddc undersampling."  On the page, 
http://www.analog.com/en/products/rf-microwave/integrated-transceivers-transmitters-receivers/wideband-transceivers-ic/ad9361.html, 
I came across the link to 
https://github.com/analogdevicesinc/iio-oscilloscope/blob/master/block_diagrams/AD9361.svg. 
This clearly shows the functionality I was trying to describe in my 
previous post; I believe that, if HB3 is disabled, this diagram 
matches the B200mini exactly.


So, what is the maximum decimation that the B200mini can perform?

You generally don't need to worry about how many stages of decimation 
are involved, except when there's some half-band rolloff at odd decimations.
  You simply ask UHD for the desired sample-rate, and it arranges 
everything under the covers.   But you can certainly get very high 
effective decimation
  values by fixing the master-clock rate (which basically sets the ADC 
sample rate), at some high value, like 40MHz, and then asking for a low

  sample-rate, like 250kHz.

The samples are already complex-baseband by the time the AD9361 as dealt 
with them, so I'm not sure that I understand your final question below.


I'm getting the impression (and PLEASE correct me if I'm wrong), that 
this may turn into what we call an "X-Y" type question.  You have a problem,
  X, and rather than describe that problem, you've already decided that 
'Y' (or understanding Y) is the right solution, and are asking about 'Y' 
instead.


Are you concerned that the B210 doesn't "correctly" produce samples at 
the correct (decimated) rate?  Do you have some very-special requirement
  that causes you to understand the B210 internal signal-processing 
chain in agonizing detail?  (If so, I'll point out that the DSP chain 
within the B210
  has changed considerably several times in its lifecycle, so getting a 
"at the molecular level" understanding of it may be a fleeting thing).



And, is undersampling performed at the final stage, in order to send 
baseband samples to the host?



*From:* USRP-users [usrp-users-boun...@lists.ettus.com] on behalf of 
Stern, Joseph via USRP-users [usrp-users@lists.ettus.com]

*Sent:* Wednesday, February 28, 2018 8:28 AM
*To:* usrp-users@lists.ettus.com
*Subject:* Re: [USRP-users] USRP-users help needed

Thank you all for your help.  I have been going through both the FPGA 
and host-side driver code for the B200mini and, in my still very 
limited understanding of SDRs in general, have come up with the 
following DDC chain:


 1. multiplex 12-bit I and Q into 24-bit value
 2. phase align with the NCO
 3. use the CORDIC functionality to perform the down-shifting math to
some IF or possibly baseband
 4. apply the CIC algorithm to FIR filter and decimate
 5. apply up to two half band filters, further decimating
 6. clip I and Q by one bit due to the potential, maximum gain in the
previous algorithms

I discovered the following:

  * using an even (or unit) decimation prevents CIC rolloff
  * two half band filters (abbreviated hb0 and hb1 in the Verilog and
C++ code) are available, and each one decimates by a factor of two
  * (half band filters are used as LPFs, when the signal is shifted
all the way down to baseband)
  * the only data being poked into the USRP interface are { hb0
enabled, hb1 enabled, remaining decimation }

I'm sure you have spotted several misunderstandings in the above.  I'm 
still fuzzy on why the decimation is being set the way that it is.  It 
feels like the host-side driver code independently calculates all the 
filter and decimation properties that will be reflected on the FPGA 
side.  Please feel free to clarify for me the down-shifting and the 
inherent decimation when using half band filters (and anything I am 
completely oblivious to).


Thanks again for your help and guidance.


*From:* USRP-users [usrp-users-boun...@lists.ettus.com] on behalf of 
Marcus D. Leech via USRP-users [usrp-users@lists.ettus.com]

*Sent:* Monday, February 26, 2018 1:20 PM
*To:* usrp-users@lists.ettus.com
*Subject:* Re: [USRP-users] USRP-users help needed

On 02/26/2018 12:07 PM, Stern, Joseph via USRP-users wrote:


Dear USRP users:

We have been trying to understand the low-level details of the 
USRP architecture (namely, for the B200mini); there seems very little 
explicit insight provided on the Ettus web site into how decimation 
is performed in the FPGA (and commanded from the driver side).  I 
also cannot locate the open-source and freely available FPGA code. 
Could someone assist me in gaining this insight?


Thank you very much!

Joe Stern

Ettus don't provide detailed design documents, bu

[USRP-users] Concurrent Rx on USRP E312

2018-02-28 Thread kailash kumar via USRP-users
Hi,

I am trying to explore the possibility of using Rx channels(0,1)
independently and concurrently on Ettus USRP E312.

Here is what I am trying:

USRP 1  --> Rx Freq 1 --> Filter --> Demodulation and Decode 1 --> Audio
Sink
 --> Rx Freq 2 --> Filter --> Demodulation and Decode 2 -->
Audio Sink

When transmit at frequency 2, Data gets received on both Rx channels and
gets processed even though center freq is different.

Attached is the flow graph.

Is it possible to use both Rx concurrently? If yes, anything that I am
missing wrt flowgraph?

Thanks
Kailash
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com