[USRP-users] Long time for USRP N210 to respond -- is this v3.10, firewall problem, or something else?

Mendel, Susan Marie smendel at lanl.gov
Thu Mar 24 16:14:05 EDT 2016


Never mind -- I didn't realize the GUI I am using IS network manager. 

________________________________________
From: USRP-users <usrp-users-bounces at lists.ettus.com> on behalf of usrp-users-request at lists.ettus.com <usrp-users-request at lists.ettus.com>
Sent: Thursday, March 24, 2016 10:00 AM
To: usrp-users at lists.ettus.com
Subject: USRP-users Digest, Vol 67, Issue 24

Send USRP-users mailing list submissions to
        usrp-users at lists.ettus.com

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
        usrp-users-request at lists.ettus.com

You can reach the person managing the list at
        usrp-users-owner at lists.ettus.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."


Today's Topics:

   1. Re: X300 SFP+ modules compatibility (Sylvain Munaut)
   2. Re: X300 SFP+ modules compatibility (David Miller)
   3. Re: USRP under run when when trying to send messages in a low
      rate (Martin Braun)
   4. Re: Error using RFNoC OFDM Sync block on E310 (Sergio Cruz Perez)
   5. X300: DRAM FIFO 0 BIST failed! (Serge Malo)
   6. GPS and UHD Time Alignment (devin kelly)
   7. How do I change the number of taps and tap coefficients for
      the noc_block_fir_filter? (Swanson, Craig)
   8. RF NoC Consulting (John Malsbury)
   9. Re: GPS and UHD Time Alignment (Marcus D. Leech)
  10. Re: GPS and UHD Time Alignment (Michael West)
  11. FPGA update (Diyar Muhammed)
  12. Re: FDD transmission with b210? (Ernest Szczepaniak)
  13. (no subject) (Diyar Muhammed)
  14. Verifying these tap values have nothing to do with the tap
      values in axi_fir.xci (Swanson, Craig)
  15. Resetting multiple B210s connected to a single host-PC
      (Jeremy Hershberger)
  16. X310 product code unknown EEPROM (Marcus D. Leech)
  17. Re: USRP under run when when trying to send messages in a low
      rate (Damindra Bandara)
  18. Enabling Bluetooth adaptor for E310 (Jonathon Cheah)
  19. Re: Verifying these tap values have nothing to do with the
      tap values in axi_fir.xci (Jonathon Pendlum)
  20. Re: How do I change the number of taps and tap    coefficients
      for the noc_block_fir_filter? (Jonathon Pendlum)
  21. RFNoC Readback Register (Michael Wentz)
  22. Re: Verifying these tap values have nothing to do with the
      tap values in axi_fir.xci (Swanson, Craig)
  23. Re: How do I change the number of taps and tap coefficients
      for the noc_block_fir_filter? (Swanson, Craig)
  24. Re: Verifying these tap values have nothing to do with the
      tap values in axi_fir.xci (Jonathon Pendlum)
  25. Re: Verifying these tap values have nothing to do with the
      tap values in axi_fir.xci (Swanson, Craig)
  26. Re: How do I change the number of taps and tap    coefficients
      for the noc_block_fir_filter? (Jonathon Pendlum)
  27. Re: (no subject) (James Humphries)
  28. Re: Error using RFNoC OFDM Sync block on E310 (Jonathon Pendlum)
  29. B200mini: enable RF front-end via command
      (Emanuel.Staudinger at dlr.de)
  30. Re: X310 product code unknown EEPROM (Mhe)
  31. Segmentation Fault from uhd::transport when       stopping/starting
      flowgraph (Jacob Gilbert)
  32. rec_samples_to_file overflow (Xingjian Chen)
  33. Re: rec_samples_to_file overflow (Marcus D. Leech)
  34. Re: GPS and UHD Time Alignment (devin kelly)


----------------------------------------------------------------------

Message: 1
Date: Wed, 23 Mar 2016 17:06:33 +0100
From: Sylvain Munaut <246tnt at gmail.com>
To: Rob Kossler <rkossler at nd.edu>
Cc: "Marcus D. Leech" <mleech at ripnet.com>,
        "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
Subject: Re: [USRP-users] X300 SFP+ modules compatibility
Message-ID:
        <CAHL+j0-f9dYJed84wuqhP=oskdRyR0Lg6wM3unErDZFy4W7Wyw at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

You can also give AOC "Active Optical Cables" a go.

They're much cheaper than two transceiver + fiber and they exist in
various length.

Cheers,

   Sylvain



------------------------------

Message: 2
Date: Wed, 23 Mar 2016 16:49:32 +0000
From: David Miller <david.zod.miller at gmail.com>
To: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] X300 SFP+ modules compatibility
Message-ID: <56F2C91C.7010901 at gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed

The option "allow_any_sfp" can be added to the X520 driver module
(ixgbe), which I use with various Finisar transceivers.
Cheers,
Dave

On 23/03/2016 16:06, Sylvain Munaut via USRP-users wrote:
> You can also give AOC "Active Optical Cables" a go.
>
> They're much cheaper than two transceiver + fiber and they exist in
> various length.
>
> Cheers,
>
>     Sylvain
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com




------------------------------

Message: 3
Date: Wed, 23 Mar 2016 10:46:28 -0700
From: Martin Braun <martin.braun at ettus.com>
To: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] USRP under run when when trying to send
        messages in a low rate
Message-ID: <56F2D674.30900 at ettus.com>
Content-Type: text/plain; charset=windows-1252

Damindra,

this looks like bursty transmission, are you sending end-of-burst packets?


M

On 03/22/2016 08:22 AM, Damindra Bandara via USRP-users wrote:
> Hi Marcus,
>
> Thank you for getting back to me. Here is the description of my application.
>
> I want to get the user messages and transmit it via USRP. Since the
> messages are infrequent I am use a beacon message to keep the message
> stream  alive. I use QPSK as the modulation scheme. A beacon message is
> transmitted in every second. At the receiving end I extract the
> application level message and output it. I am using Etuss USRP N200 to
> test the setup.
>
> The problem is that I do not receive the message at the other end. When
> I observe the constellations at the receiver  it shows that the QPSK
> demodulator does not remain synchronized. Also I observed  'UUUUUU'  at
> the transmitter end.(which is due to an under run at the USRP).
>
>  If I transmit a file using this setup it works fine. But when I
> transmit messages it is not transmitting.
>
> The transmitter end: application-->packet encoder --> QPSK modulator -->
> USRP sink
>
> Receiver end: USRP source --> Synchronization blocks --> QPSK
> demodulator  --> Packet decoder --> application
>
> Let me know if you need further information. I really appreciate if you
> could help me to solve this issue.
>
> Thank you
> Damindra
>
> On Tue, Mar 22, 2016 at 4:05 AM, Marcus M?ller
> <usrp-users at lists.ettus.com <mailto:usrp-users at lists.ettus.com>> wrote:
>
>     Hi Damindra,
>
>     it's a bit too much guesswork involved if you don't share *what*
>     kind of application in GNU Radio you're designing. And a few
>     parameters would be helpful too: something like sampling rate of the
>     USRP, which USRP type you're using.
>
>     Generally, an underrun means your computer wasn't fast enough at
>     providing samples to your USRP.
>
>     Best regards,
>     Marcus
>
>
>     On 22.03.2016 04:06, Damindra Bandara via USRP-users wrote:
>>     Hi,
>>
>>     I am creating an application using GNURadio that transmits a
>>     message every second. When I try to do this the transmit USRP
>>     indicates that is is under run and I was not able to recover the
>>     message at the receiving end.
>>
>>     When I use the same setup to transmit a file it works fine and
>>     able to recover it.
>>
>>     Is there any procedure that should be followed when transmitting
>>     infrequent messages? I appreciate if I could get any help.
>>
>>     Thank you
>>     Damindra
>>
>>     --
>>     Damindra Savithri Bandara,
>>     PhD in Information Technology (Candidate)
>>     George Mason University,
>>     Fairfax,
>>     Virginia
>>
>>
>>     _______________________________________________
>>     USRP-users mailing list
>>     USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
>>     http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>     _______________________________________________
>     USRP-users mailing list
>     USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
>     http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> --
> Damindra Savithri Bandara,
> PhD in Information Technology (Candidate)
> George Mason University,
> Fairfax,
> Virginia
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>




------------------------------

Message: 4
Date: Wed, 23 Mar 2016 12:15:07 -0600
From: Sergio Cruz Perez <serchsype at hotmail.com>
To: Jonathon Pendlum <jonathon.pendlum at ettus.com>
Cc: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
Message-ID: <COL128-W66D668D0DCB345983C3D47BF810 at phx.gbl>
Content-Type: text/plain; charset="iso-8859-1"

Hi Jonathon,
Finally I could make the image updating the e300_core.v file as you said. I ran the uhd_usrp_probe init only and now I can see the rfnoc blocks schmidl_cox and fifo.
-- ========== Full list of RFNoC blocks: ============-- * 0/Radio_0-- * 0/Radio_1-- * 0/FIFO_0-- * 0/SchmidlCox_0
But, when i run my application I got again the same problem:
...
-- [0/SchmidlCox_0] _resolve_port_def()-- [0/SchmidlCox_0]   item type: sc16-- [0/SchmidlCox_0]   vector length: 0-- [0/SchmidlCox_0]   packet size: 0-- [0/SchmidlCox_0] _resolve_port_def()-- [0/SchmidlCox_0]   item type: sc16-- [0/SchmidlCox_0]   vector length: 64-- [0/SchmidlCox_0]   packet size: 64-- [NocScript] Executing and asserting code: SR_WRITE("CP_LENGTH", $cp_len)-- [NocScript] Executing SR_WRITE() --   [0/SchmidlCox_0] sr_write(CP_LENGTH, 00000040) ==>   [0/SchmidlCox_0] sr_write(130, 00000040, 0)-- [NocScript] Executing and asserting code: GE($threshold, 0.0) AND LE($threshold, 1.0)-- [NocScript] Executing and asserting code: SR_WRITE("THRESHOLD", IROUND(MULT(32768.0, $threshold)))-- [NocScript] Executing SR_WRITE() --   [0/SchmidlCox_0] sr_write(THRESHOLD, 00007000) ==>   [0/SchmidlCox_0] sr_write(134, 00007000, 0)Traceback (most recent call last):  File "./rx_rfnoc.py", line 207, in <module>    main()  File "./rx_rfnoc.py", line 196, in main    tb = top_block_c

 ls(chan_est=options.chan_est, freq=options.freq, gain=options.gain, lo_offset=options.lo_offset, samp_rate=options.samp_rate)  File "./rx_rfnoc.py", line 97, in __init__    self.uhd_rfnoc_ofdm_schmidlcox_0.set_arg("offset", 77)  File "/usr/local/lib/python2.7/site-packages/ettus/ettus_swig.py", line 3002, in set_arg    return _ettus_swig.rfnoc_generic_sptr_set_arg(self, *args)RuntimeError: LookupError: Path not found in tree: /mboards/0/xbar/SchmidlCox_0/args/0/offset/value...
How is that path generated? I can't find it on the E310



From: jonathon.pendlum at ettus.com
Date: Tue, 22 Mar 2016 15:17:40 -0700
Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
To: serchsype at hotmail.com
CC: usrp-users at lists.ettus.com

Sergio,
rfnoc-ofdm has gotten a little out of sync with UHD rfnoc-devel. The compat number on line 172 in e300_core.v needs to be updated to RB32_CORE_COMPAT  : rb_data <= {8'hAC, 8'h0, 8'h255, 8'h0};
I am going to merge rfnoc-ofdm into rfnoc-radio-redo soon which will fix this issue. This temporary fix should hold you over until the merge.


Jonathon
On Tue, Mar 22, 2016 at 3:07 PM, Sergio Cruz Perez <serchsype at hotmail.com> wrote:




Hi Jonathon,
It's a GNU radio flowgraph and I'm using my rfnoc fpga image. I copied the image that I made on my PC using the rfnoc-ofdm branches to the E310. My flowgraph has the root to that image in the device3 args so when I run my applications I can see that it's loading my image.
root at ettus-e300:~/pruebas# ./rx_rfnoc.py linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.010.rfnoc-316-gb7546712
-- Loading FPGA image: /home/root/sheko/usrp_e310_rfnoc_fpga.bit... done-- Initializing core control...-- Performing register loopback test... pass .....
When I don't use the rfnoc-ofdm branches I can make the image and run it on the E310 but I return to the first problem of this thread.
Thanks
Sergio
From: jonathon.pendlum at ettus.com
Date: Tue, 22 Mar 2016 14:23:28 -0700
Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
To: serchsype at hotmail.com
CC: usrp-users at lists.ettus.com

Hi Sergio,
You need copy your bitstream to the E310 and replace /usr/share/uhd/images/usrp_e300_fpga.bit. How are you running your application? Is it a GNU Radio flowgraph?


Jonathon
On Tue, Mar 22, 2016 at 10:56 AM, Sergio Cruz Perez <serchsype at hotmail.com> wrote:




Hi Jonathon,
I installed  uhd rfnoc-devel version with the rfnoc-ofdm branches on both the PC and the E310 (UHD_003.010.rfnoc-316-gb7546712). I made the image with the schmidl_cox block but  when I run my application, I got the next error:
RuntimeError: Expected FPGA compatibility number 255.x, but got 7.0:The FPGA build is not compatible with the host code build.
What should I update on my PC to make a compatible image with the E310?
RegardsSergio


From: jonathon.pendlum at ettus.com
Date: Wed, 9 Mar 2016 13:05:58 -0800
Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
To: serchsype at hotmail.com
CC: usrp-users at lists.ettus.com

Hi Sergio,
Try using the "rfnoc-ofdm" branches for uhd and gr-ettus and rebuild your FPGA image. Make sure to add the schmidl_cox block to rfnoc_e310_ce_auto_inst.v and run 'make cleanall' before building the FPGA image.


Jonathon
On Tue, Mar 8, 2016 at 8:31 PM, Sergio Cruz Perez <serchsype at hotmail.com> wrote:



Hi Jonathon,
Yes, I followed the RFNoC:Getting started guide to install the rfnoc-devel branch and the gr-ettus  OOT module. I forgot to mention that in my first attempt to make the fpga image I had the next error:
ERROR: [Synth 8-448] named port connection 's_axis_phase_tlast' does not exist for instance 'cfo_corrector' of module 'cordic_rotator' [/home/sheko/uhd/fpga-src/usrp3/lib/rfnoc/schmidl_cox.v:163]
I removed that port in the schmidl_cox.v file and then it was possible to make the image with the schmidl_cox block.
Thanks
Sergio





From: jonathon.pendlum at ettus.com
Date: Tue, 8 Mar 2016 16:51:20 -0800
Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
To: serchsype at hotmail.com
CC: usrp-users at lists.ettus.com

Hi Sergio,
Are you using the rfnoc-ofdm branches for uhd and gr-ettus?


Jonathon
On Tue, Mar 8, 2016 at 4:31 PM, Sergio Cruz Perez via USRP-users <usrp-users at lists.ettus.com> wrote:




Hi,
I'm learning to use RFNoC to implement an  OFDM receiver on a E310.  The original FPGA image had just 3 RFNoC blocks: FIFO, Window and FFT, so I made a new image removing the window and the FFT blocks and replacing them for a schmidl_cox block. When I run my application with the new image I get the next error:
File "/usr/local/lib/python2.7/site-packages/ettus/ettus_swig.py", line 3002, in set_argreturn _ettus_swig.rfnoc_generic_sptr_set_arg(self, *args)
RuntimeError: LookupError: Path not found in tree: /mboards/0/xbar/SchmidlCox_0/args/0/offset/value
Has anyone run into the same problem?
I'm using UHD_003.010.rfnoc-314-gf773e72b
Thanks
Sergio Cruz



_______________________________________________

USRP-users mailing list

USRP-users at lists.ettus.com

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/20160323/94f8371a/attachment-0001.html>

------------------------------

Message: 5
Date: Wed, 23 Mar 2016 14:28:42 -0400
From: Serge Malo <serge.malo at skydelsolutions.com>
To: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
Subject: [USRP-users] X300: DRAM FIFO 0 BIST failed!
Message-ID:
        <CAOhu+FOm3JY5AAL=4KpjYD4pKUdpcdx-dY-KnjZEV0GwQpD_WA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi all,

I'm using X300s, with UHD 3.10 and HG image
(uhd-images_003.010.git-118-g6c5d59cb).
Generally, everything works fine, but I see the following error (about 1
time out of 4) only on one specific X300 (S/N 30A58F5, P/N 156485D):
Error: RuntimeError: DRAM FIFO 0 BIST failed!

The error happens when making the multi_usrp object.
I know that those FPGA images are BETA, but I am suspecting a defect with
this X300.
Is there anything I could try to fix/avoid this problem? Or should I try to
contact support to initiate a RMA request?

Complete output:
tx_waveforms.exe --args addr=192.168.40.2 --rate 2500000 --freq 1e9
--channels 0,1 --ref=external
Win32; Microsoft Visual C++ version 12.0; Boost_105500;
UHD_003.010.git-119-g42a3eeb6


Creating the usrp device with: addr=192.168.40.2...
-- X300 initialization sequence...
-- Determining maximum frame size... 8000 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
Error: RuntimeError: DRAM FIFO 0 BIST failed!


Best regards,
Serge.



--
*Serge Malo *
CDO & Co-founder, Skydel Solutions
Cell: 1-514-294-4017
www.skydelsolutions.com
Twitter: @skydelsol <https://twitter.com/skydelsol>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160323/cb8211bd/attachment-0001.html>

------------------------------

Message: 6
Date: Wed, 23 Mar 2016 16:29:33 -0400
From: devin kelly <dwwkelly at gmail.com>
To: usrp-users <usrp-users at lists.ettus.com>
Subject: [USRP-users] GPS and UHD Time Alignment
Message-ID:
        <CAANLyub=NwJqxSijO=JjmOj2sbXpaCbbfBMN465GJMWBCXsz2g at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hello,

I'm on UHD 3.9.2 and I've been having some problems with aligning the UHD
time and GPS time on my X310.  My GPS, as far as I can tell, acquires and
maintains lock fine.  However, everytime I run query_gpsdo_sensors the UHD
and GPS time are not aligned (UHD time is always some low number like 1,2
or 3).

I downloaded the the master copy query_gpsdo_sensors here:

https://github.com/EttusResearch/uhd/blob/master/host/utils/query_gpsdo_sensors.cpp

And built it against 3.9.2, everything works seems to work fine when I run
it:

Time source is now gpsdo
GPS Locked
Setting the reference clock source to "gpsdo"...

Clock source is now gpsdo
**************************************Helpful Notes on Clock/PPS
Selection**************************************
As you can see, the default 10 MHz Reference and 1 PPS signals are now from
the GPSDO.
If you would like to use the internal reference(TCXO) in other
applications, you must configure that explicitly.
****************************************************************************************************************
USRP Locked to GPSDO 10 MHz Reference.

GPS and UHD Device time are NOT aligned;
last_pps: 3 vs gps: 1458764120. Trying to set the device time to GPS time...
--     1) catch time transition at pps edge
--     2) set times next pps (synchronously)
last_pps: 1458764124 vs gps: 1458764124.
GPS and UHD Device time are aligned.
Printing available NMEA strings:
GPS_GPGGA:
$GPGGA,201524.00,4227.5889,N,07116.0425,W,2,10,1.2,86.8,M,-33.1,M,,*68
GPS_GPRMC: $GPRMC,201524.00,A,4227.5889,N,07116.0425,W,0.0,0.0,230316,,*29
GPS Epoch time at last PPS: 1458764124.00000 seconds
UHD Device time last PPS:   1458764124.00000 seconds
UHD Device time right now:  1458764124.24561 seconds
PC Clock time:              1458764124 seconds

GPS and UHD time aren't aligned but query_gpsdo_senors aligns them for me
fine.  However if I run querry_gpsdo_sensors again the clocks are
un-aligned again!

Time source is now gpsdo
GPS Locked
Setting the reference clock source to "gpsdo"...

Clock source is now gpsdo
**************************************Helpful Notes on Clock/PPS
Selection**************************************
As you can see, the default 10 MHz Reference and 1 PPS signals are now from
the GPSDO.
If you would like to use the internal reference(TCXO) in other
applications, you must configure that explicitly.
****************************************************************************************************************
USRP Locked to GPSDO 10 MHz Reference.

GPS and UHD Device time are NOT aligned;
last_pps: 3 vs gps: 1458764770. Trying to set the device time to GPS time...
--     1) catch time transition at pps edge
--     2) set times next pps (synchronously)
last_pps: 1458764774 vs gps: 1458764774.
GPS and UHD Device time are aligned.
Printing available NMEA strings:
GPS_GPGGA:
$GPGGA,202614.00,4227.5830,N,07116.0439,W,2,11,1.0,80.9,M,-33.1,M,,*60
GPS_GPRMC: $GPRMC,202614.00,A,4227.5830,N,07116.0439,W,0.2,0.0,230316,,*27
GPS Epoch time at last PPS: 1458764774.00000 seconds
UHD Device time last PPS:   1458764774.00000 seconds
UHD Device time right now:  1458764774.24745 seconds
PC Clock time:              1458764774 seconds

Done!

What's going on here?  I think the newest UHD release is 3.9.3 so I could
try that but could there be some other issue?

Thanks for any help,

Devin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160323/eb1d7fbe/attachment-0001.html>

------------------------------

Message: 7
Date: Wed, 23 Mar 2016 20:47:01 +0000
From: "Swanson, Craig" <Craig.Swanson at gtri.gatech.edu>
To: Jonathon Pendlum <jonathon.pendlum at ettus.com>
Cc: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
Subject: [USRP-users] How do I change the number of taps and tap
        coefficients for the noc_block_fir_filter?
Message-ID: <1458766021357.82482 at gtri.gatech.edu>
Content-Type: text/plain; charset="iso-8859-1"

?Jonathon,

I remember you reviewed how to do this at GRCon15, but I don't remember.

Craig


Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160323/55b6c85b/attachment-0001.html>

------------------------------

Message: 8
Date: Wed, 23 Mar 2016 13:56:26 -0700
From: John Malsbury <jmalsbury.personal at gmail.com>
To: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
Subject: [USRP-users] RF NoC Consulting
Message-ID:
        <CAK+fQfdC9W1QRF+RxY9Zh4Cia8_KBxGGfUr36r6gLY8F2P+nqw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

I may have a need to offload some RF NoC projects.  If you think you are an
expert in RF NoC and interested in some work, send me a message.

-John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160323/03c4b5f4/attachment-0001.html>

------------------------------

Message: 9
Date: Wed, 23 Mar 2016 16:57:13 -0400
From: "Marcus D. Leech" <mleech at ripnet.com>
To: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] GPS and UHD Time Alignment
Message-ID: <56F30329.7090803 at ripnet.com>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"

On 03/23/2016 04:29 PM, devin kelly via USRP-users wrote:
> Hello,
>
> I'm on UHD 3.9.2 and I've been having some problems with aligning the
> UHD time and GPS time on my X310. My GPS, as far as I can tell,
> acquires and maintains lock fine.  However, everytime I run
> query_gpsdo_sensors the UHD and GPS time are not aligned (UHD time is
> always some low number like 1,2 or 3).
>
> I downloaded the the master copy query_gpsdo_sensors here:
>
> https://github.com/EttusResearch/uhd/blob/master/host/utils/query_gpsdo_sensors.cpp
>
> And built it against 3.9.2, everything works seems to work fine when I
> run it:
>
> Time source is now gpsdo
> GPS Locked
> Setting the reference clock source to "gpsdo"...
>
> Clock source is now gpsdo
> **************************************Helpful Notes on Clock/PPS
> Selection**************************************
> As you can see, the default 10 MHz Reference and 1 PPS signals are now
> from the GPSDO.
> If you would like to use the internal reference(TCXO) in other
> applications, you must configure that explicitly.
> ****************************************************************************************************************
> USRP Locked to GPSDO 10 MHz Reference.
>
> GPS and UHD Device time are NOT aligned;
> last_pps: 3 vs gps: 1458764120. Trying to set the device time to GPS
> time...
> --     1) catch time transition at pps edge
> --     2) set times next pps (synchronously)
> last_pps: 1458764124 vs gps: 1458764124.
> GPS and UHD Device time are aligned.
> Printing available NMEA strings:
> GPS_GPGGA:
> $GPGGA,201524.00,4227.5889,N,07116.0425,W,2,10,1.2,86.8,M,-33.1,M,,*68
> GPS_GPRMC:
> $GPRMC,201524.00,A,4227.5889,N,07116.0425,W,0.0,0.0,230316,,*29
> GPS Epoch time at last PPS: 1458764124.00000 seconds
> UHD Device time last PPS:   1458764124.00000 seconds
> UHD Device time right now:  1458764124.24561 seconds
> PC Clock time:              1458764124 seconds
>
> GPS and UHD time aren't aligned but query_gpsdo_senors aligns them for
> me fine.  However if I run querry_gpsdo_sensors again the clocks are
> un-aligned again!
>
> Time source is now gpsdo
> GPS Locked
> Setting the reference clock source to "gpsdo"...
>
> Clock source is now gpsdo
> **************************************Helpful Notes on Clock/PPS
> Selection**************************************
> As you can see, the default 10 MHz Reference and 1 PPS signals are now
> from the GPSDO.
> If you would like to use the internal reference(TCXO) in other
> applications, you must configure that explicitly.
> ****************************************************************************************************************
> USRP Locked to GPSDO 10 MHz Reference.
>
> GPS and UHD Device time are NOT aligned;
> last_pps: 3 vs gps: 1458764770. Trying to set the device time to GPS
> time...
> --     1) catch time transition at pps edge
> --     2) set times next pps (synchronously)
> last_pps: 1458764774 vs gps: 1458764774.
> GPS and UHD Device time are aligned.
> Printing available NMEA strings:
> GPS_GPGGA:
> $GPGGA,202614.00,4227.5830,N,07116.0439,W,2,11,1.0,80.9,M,-33.1,M,,*60
> GPS_GPRMC:
> $GPRMC,202614.00,A,4227.5830,N,07116.0439,W,0.2,0.0,230316,,*27
> GPS Epoch time at last PPS: 1458764774.00000 seconds
> UHD Device time last PPS:   1458764774.00000 seconds
> UHD Device time right now:  1458764774.24745 seconds
> PC Clock time:              1458764774 seconds
>
> Done!
>
> What's going on here?  I think the newest UHD release is 3.9.3 so I
> could try that but could there be some other issue?
>
> Thanks for any help,
>
> Devin
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
When you re-run, do you do so immediately?   What's the scenario? What
do you do between running query_gpsdo_sensor instances?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160323/9c296e97/attachment-0001.html>

------------------------------

Message: 10
Date: Wed, 23 Mar 2016 14:14:54 -0700
From: Michael West <michael.west at ettus.com>
To: "Marcus D. Leech" <mleech at ripnet.com>
Cc: "USRP-users at lists.ettus.com" <usrp-users at lists.ettus.com>
Subject: Re: [USRP-users] GPS and UHD Time Alignment
Message-ID:
        <CAM4xKrq2hd5z5hxaujuFUqHMy=CbzM-CrqoNFZ9mjrR0VekWGA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Devin,

The version of the query_gpsdo_sensor utility in UHD 3.9.2 and 3.9.3 does
not work properly on the X310.  You did the correct thing by downloading
the version at the head of the master branch.  That version explicitly sets
the time and clock sources to "gpsdo", where the other versions of the
utility assumed the sources were set to "gpsdo" by default.  UHD 3.10.0
will have the corrected version of the utility.

Regards,
Michael

On Wed, Mar 23, 2016 at 1:57 PM, Marcus D. Leech via USRP-users <
usrp-users at lists.ettus.com> wrote:

> On 03/23/2016 04:29 PM, devin kelly via USRP-users wrote:
>
> Hello,
>
> I'm on UHD 3.9.2 and I've been having some problems with aligning the UHD
> time and GPS time on my X310.  My GPS, as far as I can tell, acquires and
> maintains lock fine.  However, everytime I run query_gpsdo_sensors the UHD
> and GPS time are not aligned (UHD time is always some low number like 1,2
> or 3).
>
> I downloaded the the master copy query_gpsdo_sensors here:
>
>
> https://github.com/EttusResearch/uhd/blob/master/host/utils/query_gpsdo_sensors.cpp
>
> And built it against 3.9.2, everything works seems to work fine when I run
> it:
>
> Time source is now gpsdo
> GPS Locked
> Setting the reference clock source to "gpsdo"...
>
> Clock source is now gpsdo
> **************************************Helpful Notes on Clock/PPS
> Selection**************************************
> As you can see, the default 10 MHz Reference and 1 PPS signals are now
> from the GPSDO.
> If you would like to use the internal reference(TCXO) in other
> applications, you must configure that explicitly.
>
> ****************************************************************************************************************
> USRP Locked to GPSDO 10 MHz Reference.
>
> GPS and UHD Device time are NOT aligned;
> last_pps: 3 vs gps: 1458764120. Trying to set the device time to GPS
> time...
> --     1) catch time transition at pps edge
> --     2) set times next pps (synchronously)
> last_pps: 1458764124 vs gps: 1458764124.
> GPS and UHD Device time are aligned.
> Printing available NMEA strings:
> GPS_GPGGA:
> $GPGGA,201524.00,4227.5889,N,07116.0425,W,2,10,1.2,86.8,M,-33.1,M,,*68
> GPS_GPRMC: $GPRMC,201524.00,A,4227.5889,N,07116.0425,W,0.0,0.0,230316,,*29
> GPS Epoch time at last PPS: 1458764124.00000 seconds
> UHD Device time last PPS:   1458764124.00000 seconds
> UHD Device time right now:  1458764124.24561 seconds
> PC Clock time:              1458764124 seconds
>
> GPS and UHD time aren't aligned but query_gpsdo_senors aligns them for me
> fine.  However if I run querry_gpsdo_sensors again the clocks are
> un-aligned again!
>
> Time source is now gpsdo
> GPS Locked
> Setting the reference clock source to "gpsdo"...
>
> Clock source is now gpsdo
> **************************************Helpful Notes on Clock/PPS
> Selection**************************************
> As you can see, the default 10 MHz Reference and 1 PPS signals are now
> from the GPSDO.
> If you would like to use the internal reference(TCXO) in other
> applications, you must configure that explicitly.
>
> ****************************************************************************************************************
> USRP Locked to GPSDO 10 MHz Reference.
>
> GPS and UHD Device time are NOT aligned;
> last_pps: 3 vs gps: 1458764770. Trying to set the device time to GPS
> time...
> --     1) catch time transition at pps edge
> --     2) set times next pps (synchronously)
> last_pps: 1458764774 vs gps: 1458764774.
> GPS and UHD Device time are aligned.
> Printing available NMEA strings:
> GPS_GPGGA:
> $GPGGA,202614.00,4227.5830,N,07116.0439,W,2,11,1.0,80.9,M,-33.1,M,,*60
> GPS_GPRMC: $GPRMC,202614.00,A,4227.5830,N,07116.0439,W,0.2,0.0,230316,,*27
> GPS Epoch time at last PPS: 1458764774.00000 seconds
> UHD Device time last PPS:   1458764774.00000 seconds
> UHD Device time right now:  1458764774.24745 seconds
> PC Clock time:              1458764774 seconds
>
> Done!
>
> What's going on here?  I think the newest UHD release is 3.9.3 so I could
> try that but could there be some other issue?
>
> Thanks for any help,
>
> Devin
>
>
> _______________________________________________
> USRP-users mailing listUSRP-users at lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> When you re-run, do you do so immediately?   What's the scenario?  What do
> you do between running query_gpsdo_sensor instances?
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> 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/20160323/ed513927/attachment-0001.html>

------------------------------

Message: 11
Date: Wed, 23 Mar 2016 19:19:19 +0000
From: Diyar Muhammed <diyar.muhammed at mhe-krg.org>
To: usrp-users at lists.ettus.com
Subject: [USRP-users] FPGA update
Message-ID:
        <CAPB6+TPFijEvhzAHu0fxTFpmWqMp_6m2v251BzzcL1twU8PKJA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Dear All,
I have got new usrp x310 with UBX160 daughter board, I assembled the usrp,
but when I run the uhd_usrp_probe --args addr=192.168.10.2 there is a UHD
Warning:
*X300 unknown product code in EEPROM:30818*
*Error: RuntimeError: Expected firmware compatibility number 3.0, but got
4.0:*
*The firmware build is not compatible with the host code build.*
*Please run:*
*                 "/usr/local/lib/uhd/utils/uhd_images_downloader.py"*

I found from ettus website how I can download and update image (
http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_hw_1gige) but when I
run uhd_image_loader --args="type=x300,addr=192.168.10.2,fpga=HGS", I got
from terminal uhd_image_loader: command not found.
I need advace, about this problem:

*uhd_image_loader: command not found.*

Regards,
Diyar Muhammed
Ministry of Higher Education and Scientific Research
Duty: Network Administration and Design
Website:  www.mhe-krg.org
Cell Phone: 009647504690060
Office Phone:   00964662554683
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160323/71e388a2/attachment-0001.html>

------------------------------

Message: 12
Date: Wed, 23 Mar 2016 20:02:15 +0100
From: Ernest Szczepaniak <ernest.szczepaniak.en2 at gmail.com>
To: Marcus M?ller <marcus.mueller at ettus.com>
Cc: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] FDD transmission with b210?
Message-ID:
        <CAAFRbsU5GsSNeLkpeJJT=AAidSKd-FpetnQS1W_GLURWik+tEQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Dear Marcus,

Thanks for your quick and detailed reply.

My question was asked from PHY designing perspective. When im looking at
baseband, pre IFFT frame (in frequency domain), I can assign carriers for
the whole system (these carrier indices are used for uplink, and those for
downlink for both transmission sides respectively), making it more flexible
for the future. It could be done by tunning RX and TX to different
frequencies, but now, carrier indices have to be calculated for both sides
independently (dunno if you understand this way of thinking :D ). And this,
as you said, is achievable from hardware perspective.

Im trying to make a system similar to 4G style.

And now correct me if im wrong.

Does LTE FDD mode works that way? (transmitter and receiver working on same
frequency). Or is it just impossible to be done? I read that in LTE uplink
(SC-FDMA), there is an additional DFT block after constellation mapping,
and after that, even so called "distribution mapping" could be done,
spreading uplink transmision to non adjecent carriers. I think it would be
impossible to receive this with TX and RX working on different frequencies.
Correct or not?

Im curious after this movie:

https://www.youtube.com/watch?v=9zmAH_ewkSk

Best regards,
Ernest



2016-03-23 16:07 GMT+01:00 Marcus M?ller <usrp-users at lists.ettus.com>:

> Dear Ernest,
>
> On 23.03.2016 12:19, Ernest Szczepaniak via USRP-users wrote:
> > Does B210 supports full duplex transmission?
> Yes!
> > Any reference to detailed information about how it is realized onboard?
> Well, on the ettus.com product page you'll find the product brief PDF
> with a schematic. You'll notice that all parts in the signal chain are
> fully duplexed (which is true down to everything but the USB interrupt
> handling in the USB controller processor).
> So maybe you could specify that question.
> >
> > Is it possible to design system like this? (thats my mathworks topic)
> >
> >
> http://www.mathworks.com/matlabcentral/answers/274985-frequency-division-duplex-simulation-am-i-correct
> >
> Well, the idea of FDD is that, yes, signals overlay each other in time,
> but not in time domain, so you can just build a receiver that listens
> only to specific frequencies, and not the ones it's transmitting on.
>
> From a hardware perspective, when doing FDD, you're always tempted to
> tune RX so that the TX is not even in RX's analog input, which could
> otherwise lead to nonlinearity, and hence, RX distortion, due to the
> fact that sensitive receivers become non-perfect when exposed to high
> powers (like the crosstalk from the TX antenna at the same frequency).
>
> Now, I've seen FDD be done with USRPs, and I think it's easy to do, as
> long as the sender and receiver aren't too far apart even with RX and TX
> tuned to the same frequency. For more complicated situations, one would
> calculate the TX and RX as two separate passbands, and use the fact that
> you can use analog filters to limit the crosstalk.
>
> Can you give us a few corner data of your planned FDD setup?
>
> Best regards,
> Marcus
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> 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/20160323/ef5d8d6b/attachment-0001.html>

------------------------------

Message: 13
Date: Wed, 23 Mar 2016 15:09:00 -0700
From: Diyar Muhammed <diyar.muhammed at mhe-krg.org>
To: usrp-users at lists.ettus.com
Subject: [USRP-users] (no subject)
Message-ID:
        <CAPB6+TMM-pbqZF4O4iQ3qpMaK+h88RYzMPb3z7_X-fBTAijGrQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Dear All,
I assembled usrp x310, and I had a warning, so I downloaded FPGA image and
then I have upgraded FPGA by using the command: usrp_x3xx_fpga_burner
--addr=192.168.10.2
--fpga-path=/usr/local/share/uhd/images/usrp_x310_fpga_HGS.bit.
after that the usrp x310 is able to find daughter board, but still I have a
UHD warning as shown in the below, as shown below:

mint at mint ~ $ uhd_usrp_probe 192.168.10.2
linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.001-105-g91ae742f


UHD Warning:
    X300 unknown product code in EEPROM: 30818

UHD Warning:
    X300 unknown product code in EEPROM: 30818

UHD Warning:
    X300 unknown product code in EEPROM: 30818

UHD Warning:
    X300 unknown product code in EEPROM: 30818
-- X300 initialization sequence...
-- Determining maximum frame size... 1472 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...

UHD Warning:
    X300 unknown product code in EEPROM: 30818
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Initialize Radio control...
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Initializing clock and time using internal sources... done
  _____________________________________________________
 /
|       Device: X-Series Device
|     _____________________________________________________
|    /
|   |       Mboard: X300?
|   |   revision: 8
|   |   product: 30818
|   |   mac-addr0: 00:80:2f:23:7b:6f
|   |   mac-addr1: 00:80:2f:23:7b:70
|   |   gateway: 192.168.10.1
|   |   ip-addr0: 192.168.10.2
|   |   subnet0: 255.255.255.0
|   |   ip-addr1: 192.168.20.2
|   |   subnet1: 255.255.255.0
|   |   ip-addr2: 192.168.30.2
|   |   subnet2: 255.255.255.0
|   |   ip-addr3: 192.168.40.2
|   |   subnet3: 255.255.255.0
|   |   serial: 30C0991
|   |   FW Version: 3.0
|   |   FPGA Version: 9.0
|   |
|   |   Time sources: internal, external, gpsdo
|   |   Clock sources: internal, external, gpsdo
|   |   Sensors: ref_locked
|   |     _____________________________________________________
|   |    /
|   |   |       RX DSP: 0
|   |   |   Freq range: -100.000 to 100.000 MHz
|   |     _____________________________________________________
|   |    /
|   |   |       RX DSP: 1
|   |   |   Freq range: -100.000 to 100.000 MHz
|   |     _____________________________________________________
|   |    /
|   |   |       RX Dboard: A
|   |   |   ID: UBX-160 v1 (0x007a)
|   |   |   Serial: 30C2AAB
|   |   |     _____________________________________________________
|   |   |    /
|   |   |   |       RX Frontend: 0
|   |   |   |   Name: UBX RX
|   |   |   |   Antennas: TX/RX, RX2, CAL
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 10.000 to 6000.000 MHz
|   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   |     _____________________________________________________
|   |   |    /
|   |   |   |       RX Codec: A
|   |   |   |   Name: ads62p48
|   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
|   |     _____________________________________________________
|   |    /
|   |   |       RX Dboard: B
|   |   |   ID: UBX-160 v1 (0x007a)
|   |   |   Serial: 30C2A33
|   |   |     _____________________________________________________
|   |   |    /
|   |   |   |       RX Frontend: 0
|   |   |   |   Name: UBX RX
|   |   |   |   Antennas: TX/RX, RX2, CAL
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 10.000 to 6000.000 MHz
|   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   |     _____________________________________________________
|   |   |    /
|   |   |   |       RX Codec: B
|   |   |   |   Name: ads62p48
|   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
|   |     _____________________________________________________
|   |    /
|   |   |       TX DSP: 0
|   |   |   Freq range: -100.000 to 100.000 MHz
|   |     _____________________________________________________
|   |    /
|   |   |       TX DSP: 1
|   |   |   Freq range: -100.000 to 100.000 MHz
|   |     _____________________________________________________
|   |    /
|   |   |       TX Dboard: A
|   |   |   ID: UBX-160 v1 (0x0079)
|   |   |   Serial: 30C2AAB
|   |   |     _____________________________________________________
|   |   |    /
|   |   |   |       TX Frontend: 0
|   |   |   |   Name: UBX TX
|   |   |   |   Antennas: TX/RX, CAL
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 10.000 to 6000.000 MHz
|   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
|   |   |   |   Connection Type: QI
|   |   |   |   Uses LO offset: No
|   |   |     _____________________________________________________
|   |   |    /
|   |   |   |       TX Codec: A
|   |   |   |   Name: ad9146
|   |   |   |   Gain Elements: None
|   |     _____________________________________________________
|   |    /
|   |   |       TX Dboard: B
|   |   |   ID: UBX-160 v1 (0x0079)
|   |   |   Serial: 30C2A33
|   |   |     _____________________________________________________
|   |   |    /
|   |   |   |       TX Frontend: 0
|   |   |   |   Name: UBX TX
|   |   |   |   Antennas: TX/RX, CAL
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 10.000 to 6000.000 MHz
|   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
|   |   |   |   Connection Type: QI
|   |   |   |   Uses LO offset: No
|   |   |     _____________________________________________________
|   |   |    /
|   |   |   |       TX Codec: B
|   |   |   |   Name: ad9146
|   |   |   |   Gain Elements: None

mint at mint ~ $

What I have to do to sort out that?
in advance many thanks.
--
Regards,
Diyar Muhammed
Ministry of Higher Education and Scientific Research
Duty: Network Administration and Design
Website:  www.mhe-krg.org
Cell Phone: 009647504690060
Office Phone:   00964662554683
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160323/ef1260cc/attachment-0001.html>

------------------------------

Message: 14
Date: Wed, 23 Mar 2016 22:20:41 +0000
From: "Swanson, Craig" <Craig.Swanson at gtri.gatech.edu>
To: Jonathon Pendlum <jonathon.pendlum at ettus.com>, Martin Braun
        <martin.braun at ettus.com>
Cc: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>,
        "Brothers,      Timothy" <Timothy.Brothers at gtri.gatech.edu>
Subject: [USRP-users] Verifying these tap values have nothing to do
        with the tap values in axi_fir.xci
Message-ID: <1458771641132.20554 at gtri.gatech.edu>
Content-Type: text/plain; charset="iso-8859-1"

Jonathon and Martin,

I found your instructions in the video from the conference and I modified the lib/ip/axi_fir/axi_fir.xci file using the Vivado build ip tool, then created a .bit file.  I added the FIR block to my flowgraph.  I noticed you can add tap values in the block shown below.  I wanted to make sure these tap values have no impact on and do not supercede what actually happens in my noc_block_fir_filter.


Craig


[cid:c96d8510-baa8-4754-b4d5-76f82cab443c]


Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160323/7011aeec/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedImage.png
Type: image/png
Size: 146035 bytes
Desc: pastedImage.png
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160323/7011aeec/attachment-0001.png>

------------------------------

Message: 15
Date: Wed, 23 Mar 2016 18:53:03 -0400
From: Jeremy Hershberger <Jeremy.L.Hershberger.16 at nd.edu>
To: usrp-users <usrp-users at lists.ettus.com>
Subject: [USRP-users] Resetting multiple B210s connected to a single
        host-PC
Message-ID:
        <CAMZiKLpzWUfX3qab+qQes+=9HK6HXjnRfQoQ5dn6=Vfi_WNd3g at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Suppose I have two B210s connected to same PC, under ubuntu 14.04.  I want
to reset just one of the two devices via the b2xx_fx3_utils.  I see that I
can specify the VID or PID as one of the arguments.  However, via the lsusb
command, I can see that both B210s have the same VID and PID (VID=0x2500,
PID=0x0020).  So how does one select which B210 is reset via the
b2xx_fx3_utils command?

Thanks,

-Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160323/63b72569/attachment-0001.html>

------------------------------

Message: 16
Date: Wed, 23 Mar 2016 20:50:52 -0400
From: "Marcus D. Leech" <mleech at ripnet.com>
To: Diyar Muhammed <diyar.muhammed at mhe-krg.org>,
        "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
Subject: [USRP-users] X310 product code unknown EEPROM
Message-ID: <56F339EC.8010800 at ripnet.com>
Content-Type: text/plain; charset=windows-1252; format=flowed

On 03/23/2016 06:09 PM, Diyar Muhammed via USRP-users wrote:
> Dear All,
> I assembled usrp x310, and I had a warning, so I downloaded FPGA image
> and then I have upgraded FPGA by using the command:
> usrp_x3xx_fpga_burner --addr=192.168.10.2
> --fpga-path=/usr/local/share/uhd/images/usrp_x310_fpga_HGS.bit.
> after that the usrp x310 is able to find daughter board, but still I
> have a UHD warning as shown in the below, as shown below:
>
> mint at mint ~ $ uhd_usrp_probe 192.168.10.2
> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.001-105-g91ae742f
>
You have a newer X310 hardware version that isn't supported by that
very-old version of UHD.  Newer X310s *CANNOT* be supported by
   older UHD due to hardware changes that were made.

Upgrade to 3.9.2 or the just-released 3.9.3  UHD version.


>
> UHD Warning:
>     X300 unknown product code in EEPROM: 30818
>
> UHD Warning:
>     X300 unknown product code in EEPROM: 30818
>
> UHD Warning:
>     X300 unknown product code in EEPROM: 30818
>
> UHD Warning:
>     X300 unknown product code in EEPROM: 30818
> -- X300 initialization sequence...
> -- Determining maximum frame size... 1472 bytes.
> -- Setup basic communication...
> -- Loading values from EEPROM...
>
> UHD Warning:
>     X300 unknown product code in EEPROM: 30818
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> -- Initialize Radio control...
> -- Performing register loopback test... pass
> -- Performing register loopback test... pass
> -- Initializing clock and time using internal sources... done
>   _____________________________________________________
>  /
> |       Device: X-Series Device
> |     _____________________________________________________
> |    /
> |   |       Mboard: X300?
> |   |   revision: 8
> |   |   product: 30818
> |   |   mac-addr0: 00:80:2f:23:7b:6f
> |   |   mac-addr1: 00:80:2f:23:7b:70
> |   |   gateway: 192.168.10.1
> |   |   ip-addr0: 192.168.10.2
> |   |   subnet0: 255.255.255.0
> |   |   ip-addr1: 192.168.20.2
> |   |   subnet1: 255.255.255.0
> |   |   ip-addr2: 192.168.30.2
> |   |   subnet2: 255.255.255.0
> |   |   ip-addr3: 192.168.40.2
> |   |   subnet3: 255.255.255.0
> |   |   serial: 30C0991
> |   |   FW Version: 3.0
> |   |   FPGA Version: 9.0
> |   |
> |   |   Time sources: internal, external, gpsdo
> |   |   Clock sources: internal, external, gpsdo
> |   |   Sensors: ref_locked
> |   | _____________________________________________________
> |   |    /
> |   |   |       RX DSP: 0
> |   |   |   Freq range: -100.000 to 100.000 MHz
> |   | _____________________________________________________
> |   |    /
> |   |   |       RX DSP: 1
> |   |   |   Freq range: -100.000 to 100.000 MHz
> |   | _____________________________________________________
> |   |    /
> |   |   |       RX Dboard: A
> |   |   |   ID: UBX-160 v1 (0x007a)
> |   |   |   Serial: 30C2AAB
> |   |   | _____________________________________________________
> |   |   |    /
> |   |   |   |       RX Frontend: 0
> |   |   |   |   Name: UBX RX
> |   |   |   |   Antennas: TX/RX, RX2, CAL
> |   |   |   |   Sensors: lo_locked
> |   |   |   |   Freq range: 10.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _____________________________________________________
> |   |   |    /
> |   |   |   |       RX Codec: A
> |   |   |   |   Name: ads62p48
> |   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
> |   | _____________________________________________________
> |   |    /
> |   |   |       RX Dboard: B
> |   |   |   ID: UBX-160 v1 (0x007a)
> |   |   |   Serial: 30C2A33
> |   |   | _____________________________________________________
> |   |   |    /
> |   |   |   |       RX Frontend: 0
> |   |   |   |   Name: UBX RX
> |   |   |   |   Antennas: TX/RX, RX2, CAL
> |   |   |   |   Sensors: lo_locked
> |   |   |   |   Freq range: 10.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _____________________________________________________
> |   |   |    /
> |   |   |   |       RX Codec: B
> |   |   |   |   Name: ads62p48
> |   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
> |   | _____________________________________________________
> |   |    /
> |   |   |       TX DSP: 0
> |   |   |   Freq range: -100.000 to 100.000 MHz
> |   | _____________________________________________________
> |   |    /
> |   |   |       TX DSP: 1
> |   |   |   Freq range: -100.000 to 100.000 MHz
> |   | _____________________________________________________
> |   |    /
> |   |   |       TX Dboard: A
> |   |   |   ID: UBX-160 v1 (0x0079)
> |   |   |   Serial: 30C2AAB
> |   |   | _____________________________________________________
> |   |   |    /
> |   |   |   |       TX Frontend: 0
> |   |   |   |   Name: UBX TX
> |   |   |   |   Antennas: TX/RX, CAL
> |   |   |   |   Sensors: lo_locked
> |   |   |   |   Freq range: 10.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
> |   |   |   |   Connection Type: QI
> |   |   |   |   Uses LO offset: No
> |   |   | _____________________________________________________
> |   |   |    /
> |   |   |   |       TX Codec: A
> |   |   |   |   Name: ad9146
> |   |   |   |   Gain Elements: None
> |   | _____________________________________________________
> |   |    /
> |   |   |       TX Dboard: B
> |   |   |   ID: UBX-160 v1 (0x0079)
> |   |   |   Serial: 30C2A33
> |   |   | _____________________________________________________
> |   |   |    /
> |   |   |   |       TX Frontend: 0
> |   |   |   |   Name: UBX TX
> |   |   |   |   Antennas: TX/RX, CAL
> |   |   |   |   Sensors: lo_locked
> |   |   |   |   Freq range: 10.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
> |   |   |   |   Connection Type: QI
> |   |   |   |   Uses LO offset: No
> |   |   | _____________________________________________________
> |   |   |    /
> |   |   |   |       TX Codec: B
> |   |   |   |   Name: ad9146
> |   |   |   |   Gain Elements: None
>
> mint at mint ~ $
>
> What I have to do to sort out that?
> in advance many thanks.




------------------------------

Message: 17
Date: Wed, 23 Mar 2016 21:19:35 -0400
From: Damindra Bandara <damindra.bandara at gmail.com>
To: Martin Braun <martin.braun at ettus.com>
Cc: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] USRP under run when when trying to send
        messages in a low rate
Message-ID:
        <CANpceN8RzZQKTZrxiYGxPF-gJ7BE_LVUf-KKnS=BbSD+wHQgCw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Martin,

I do not know about end of burst packets. If possible could you please give
me more details on what I should do.

Thank you
Damindra

On Wed, Mar 23, 2016 at 1:46 PM, Martin Braun via USRP-users <
usrp-users at lists.ettus.com> wrote:

> Damindra,
>
> this looks like bursty transmission, are you sending end-of-burst packets?
>
>
> M
>
> On 03/22/2016 08:22 AM, Damindra Bandara via USRP-users wrote:
> > Hi Marcus,
> >
> > Thank you for getting back to me. Here is the description of my
> application.
> >
> > I want to get the user messages and transmit it via USRP. Since the
> > messages are infrequent I am use a beacon message to keep the message
> > stream  alive. I use QPSK as the modulation scheme. A beacon message is
> > transmitted in every second. At the receiving end I extract the
> > application level message and output it. I am using Etuss USRP N200 to
> > test the setup.
> >
> > The problem is that I do not receive the message at the other end. When
> > I observe the constellations at the receiver  it shows that the QPSK
> > demodulator does not remain synchronized. Also I observed  'UUUUUU'  at
> > the transmitter end.(which is due to an under run at the USRP).
> >
> >  If I transmit a file using this setup it works fine. But when I
> > transmit messages it is not transmitting.
> >
> > The transmitter end: application-->packet encoder --> QPSK modulator -->
> > USRP sink
> >
> > Receiver end: USRP source --> Synchronization blocks --> QPSK
> > demodulator  --> Packet decoder --> application
> >
> > Let me know if you need further information. I really appreciate if you
> > could help me to solve this issue.
> >
> > Thank you
> > Damindra
> >
> > On Tue, Mar 22, 2016 at 4:05 AM, Marcus M?ller
> > <usrp-users at lists.ettus.com <mailto:usrp-users at lists.ettus.com>> wrote:
> >
> >     Hi Damindra,
> >
> >     it's a bit too much guesswork involved if you don't share *what*
> >     kind of application in GNU Radio you're designing. And a few
> >     parameters would be helpful too: something like sampling rate of the
> >     USRP, which USRP type you're using.
> >
> >     Generally, an underrun means your computer wasn't fast enough at
> >     providing samples to your USRP.
> >
> >     Best regards,
> >     Marcus
> >
> >
> >     On 22.03.2016 04:06, Damindra Bandara via USRP-users wrote:
> >>     Hi,
> >>
> >>     I am creating an application using GNURadio that transmits a
> >>     message every second. When I try to do this the transmit USRP
> >>     indicates that is is under run and I was not able to recover the
> >>     message at the receiving end.
> >>
> >>     When I use the same setup to transmit a file it works fine and
> >>     able to recover it.
> >>
> >>     Is there any procedure that should be followed when transmitting
> >>     infrequent messages? I appreciate if I could get any help.
> >>
> >>     Thank you
> >>     Damindra
> >>
> >>     --
> >>     Damindra Savithri Bandara,
> >>     PhD in Information Technology (Candidate)
> >>     George Mason University,
> >>     Fairfax,
> >>     Virginia
> >>
> >>
> >>     _______________________________________________
> >>     USRP-users mailing list
> >>     USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
> >>     http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> >     _______________________________________________
> >     USRP-users mailing list
> >     USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
> >     http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> >
> >
> > --
> > Damindra Savithri Bandara,
> > PhD in Information Technology (Candidate)
> > George Mason University,
> > Fairfax,
> > Virginia
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users at lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>



--
Damindra Savithri Bandara,
PhD in Information Technology (Candidate)
George Mason University,
Fairfax,
Virginia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160323/309b8ffb/attachment-0001.html>

------------------------------

Message: 18
Date: Wed, 23 Mar 2016 18:32:19 -0700
From: Jonathon Cheah <jcheah at ieee.org>
To: usrp-users at lists.ettus.com
Subject: [USRP-users] Enabling Bluetooth adaptor for E310
Message-ID:
        <CAKsUvU9KxVTVmd4N-joC8SQmdA3uqFpbd+uOcb1tbgfM9mHR1g at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Philip,



I have tried several old Bluetooth adaptars such as Belkin 20+EDR F8T012
and Dlink DBT-120. Since Bluetooth adaptars are reasonably inexpensive,
any Bluetooth adaptar that works with E310 will be great.



-jc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160323/0f961933/attachment-0001.html>

------------------------------

Message: 19
Date: Wed, 23 Mar 2016 19:35:03 -0700
From: Jonathon Pendlum <jonathon.pendlum at ettus.com>
To: "Swanson, Craig" <Craig.Swanson at gtri.gatech.edu>
Cc: Martin Braun <martin.braun at ettus.com>,
        "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>,      "Brothers,
        Timothy" <Timothy.Brothers at gtri.gatech.edu>
Subject: Re: [USRP-users] Verifying these tap values have nothing to
        do with the tap values in axi_fir.xci
Message-ID:
        <CAGdo0uQu3e=UZQufnnyxL6hMG6UajVzi-kDN2TT7e4W-MwOsfw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Craig,

Those coefficients will be loaded into the FIR filter automatically at
startup and overwrite whatever default taps your specified in the .xci
file. If you set default taps in the .xci file, you should also put those
taps in that text box.



Jonathon

On Wed, Mar 23, 2016 at 3:20 PM, Swanson, Craig <
Craig.Swanson at gtri.gatech.edu> wrote:

> Jonathon and Martin,
>
> I found your instructions in the video from the conference and I modified
> the lib/ip/axi_fir/axi_fir.xci file using the Vivado build ip tool, then
> created a .bit file.  I added the FIR block to my flowgraph.  I noticed you
> can add tap values in the block shown below.  I wanted to make sure these
> tap values have no impact on and do not supercede what actually happens in
> my noc_block_fir_filter.
>
>
> Craig
>
>
>
>
> *Craig F. Swanson*
>
> *Research Engineer II *
> *Information and Communications Laboratory*
> *Communications, Systems, and Spectrum Division*
> *Georgia Tech Research Institute*
>
>
> *Room 560 250 14th St NW *
> *Atlanta, GA 30318*
> *Cell: 770.298.9156 <770.298.9156>*
> http://www.gtri.gatech.edu
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160323/0a395d51/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedImage.png
Type: image/png
Size: 146035 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160323/0a395d51/attachment-0001.png>

------------------------------

Message: 20
Date: Wed, 23 Mar 2016 19:36:19 -0700
From: Jonathon Pendlum <jonathon.pendlum at ettus.com>
To: "Swanson, Craig" <Craig.Swanson at gtri.gatech.edu>
Cc: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
Subject: Re: [USRP-users] How do I change the number of taps and tap
        coefficients for the noc_block_fir_filter?
Message-ID:
        <CAGdo0uQMg0rkEBpuf7qjaq7hMVSm2HGKyXTBn_bzSoP-e1q-4g at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

I think you figured this out (per another thread you posted) but in case
you didn't, you need to generate a new .xci file for the AXI FIR filter.
You can use the Vivado GUI to do that.



Jonathon

On Wed, Mar 23, 2016 at 1:47 PM, Swanson, Craig <
Craig.Swanson at gtri.gatech.edu> wrote:

> ?Jonathon,
>
> I remember you reviewed how to do this at GRCon15, but I don't remember.
>
> Craig
>
>
> *Craig F. Swanson*
>
> *Research Engineer II *
> *Information and Communications Laboratory*
> *Communications, Systems, and Spectrum Division*
> *Georgia Tech Research Institute*
>
>
> *Room 560 250 14th St NW *
> *Atlanta, GA 30318*
> *Cell: 770.298.9156 <770.298.9156>*
> http://www.gtri.gatech.edu
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160323/8dfff6dd/attachment-0001.html>

------------------------------

Message: 21
Date: Wed, 23 Mar 2016 22:38:24 -0400
From: Michael Wentz <mchlwntz at gmail.com>
To: usrp-users at lists.ettus.com
Subject: [USRP-users] RFNoC Readback Register
Message-ID:
        <CAFTrPL3Y4ms7v069f5mrvSMU-Vapq_q2Q8bMaovB8Kyr6yo8TA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi,

I added a readback register to a block I'm working on based on what I found
in the examples (FIR filter, FFT, etc.). Is there any way I can read back
the register at some specified interval (or by user intervention) while my
block is being used in a GNU Radio flowgraph?

Based on what I saw in rfnoc_fosphor_c_impl (from gr-ettus), I'm wondering
if I could add a message port and handler to my block that would enable me
to do a readback when a message is sent to the block during runtime. It
looks like the fosphor block is using this to set registers.

-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160323/dea551c8/attachment-0001.html>

------------------------------

Message: 22
Date: Thu, 24 Mar 2016 02:43:27 +0000
From: "Swanson, Craig" <Craig.Swanson at gtri.gatech.edu>
To: Jonathon Pendlum <jonathon.pendlum at ettus.com>
Cc: Martin Braun <martin.braun at ettus.com>,
        "usrp-users at lists.ettus.com"    <usrp-users at lists.ettus.com>, "Brothers,
        Timothy"        <Timothy.Brothers at gtri.gatech.edu>
Subject: Re: [USRP-users] Verifying these tap values have nothing to
        do with the tap values in axi_fir.xci
Message-ID:
        <2489de288197430496c23b1ead4e342c at apatlisdmail04.core.gtri.org>
Content-Type: text/plain; charset="utf-8"

Jonathon,
Wow, I am glad I asked.  What happens if the .xci specifies 21 filter taps and the uhd block specifies 41?  I am assuming it will throw out an error somewhere?
Craig

Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th Street NW
Atlanta, GA 30318
Cell: 770-298-9156
http://www.gtri.gatech.edu

From: Jonathon Pendlum [mailto:jonathon.pendlum at ettus.com]
Sent: Wednesday, March 23, 2016 10:35 PM
To: Swanson, Craig <Craig.Swanson at gtri.gatech.edu>
Cc: Martin Braun <martin.braun at ettus.com>; usrp-users at lists.ettus.com; Brothers, Timothy <Timothy.Brothers at gtri.gatech.edu>
Subject: Re: Verifying these tap values have nothing to do with the tap values in axi_fir.xci

Hi Craig,

Those coefficients will be loaded into the FIR filter automatically at startup and overwrite whatever default taps your specified in the .xci file. If you set default taps in the .xci file, you should also put those taps in that text box.



Jonathon

On Wed, Mar 23, 2016 at 3:20 PM, Swanson, Craig <Craig.Swanson at gtri.gatech.edu<mailto:Craig.Swanson at gtri.gatech.edu>> wrote:

Jonathon and Martin,

I found your instructions in the video from the conference and I modified the lib/ip/axi_fir/axi_fir.xci file using the Vivado build ip tool, then created a .bit file.  I added the FIR block to my flowgraph.  I noticed you can add tap values in the block shown below.  I wanted to make sure these tap values have no impact on and do not supercede what actually happens in my noc_block_fir_filter.



Craig



[cid:image001.png at 01D18555.69E71000]


Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156<tel:770.298.9156>
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160324/214fd6cc/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 57394 bytes
Desc: image001.png
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160324/214fd6cc/attachment-0001.png>

------------------------------

Message: 23
Date: Thu, 24 Mar 2016 02:47:36 +0000
From: "Swanson, Craig" <Craig.Swanson at gtri.gatech.edu>
To: Jonathon Pendlum <jonathon.pendlum at ettus.com>
Cc: Martin Braun <martin.braun at ettus.com>,
        "usrp-users at lists.ettus.com"    <usrp-users at lists.ettus.com>, "Brothers,
        Timothy"        <Timothy.Brothers at gtri.gatech.edu>
Subject: Re: [USRP-users] How do I change the number of taps and tap
        coefficients for the noc_block_fir_filter?
Message-ID:
        <1a6c3152f98d47bc8c43b0e54c3c0b2b at apatlisdmail04.core.gtri.org>
Content-Type: text/plain; charset="utf-8"

Jonathon,
Yes, I modified the axi_fir.xci file to have 41 coefficients.  So I just wanted to verify the scenario if the .bit file specified 41 coefficients and the python file generated in GRC specified 21, what would happen?

Craig

Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th Street NW
Atlanta, GA 30318
Cell: 770-298-9156
http://www.gtri.gatech.edu

From: Jonathon Pendlum [mailto:jonathon.pendlum at ettus.com]
Sent: Wednesday, March 23, 2016 10:36 PM
To: Swanson, Craig <Craig.Swanson at gtri.gatech.edu>
Cc: usrp-users at lists.ettus.com
Subject: Re: How do I change the number of taps and tap coefficients for the noc_block_fir_filter?

I think you figured this out (per another thread you posted) but in case you didn't, you need to generate a new .xci file for the AXI FIR filter. You can use the Vivado GUI to do that.



Jonathon

On Wed, Mar 23, 2016 at 1:47 PM, Swanson, Craig <Craig.Swanson at gtri.gatech.edu<mailto:Craig.Swanson at gtri.gatech.edu>> wrote:

?Jonathon,

I remember you reviewed how to do this at GRCon15, but I don't remember.

Craig


Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156<tel:770.298.9156>
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160324/e5e75ead/attachment-0001.html>

------------------------------

Message: 24
Date: Wed, 23 Mar 2016 19:50:14 -0700
From: Jonathon Pendlum <jonathon.pendlum at ettus.com>
To: "Swanson, Craig" <Craig.Swanson at gtri.gatech.edu>
Cc: Martin Braun <martin.braun at ettus.com>,
        "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>,      "Brothers,
        Timothy" <Timothy.Brothers at gtri.gatech.edu>
Subject: Re: [USRP-users] Verifying these tap values have nothing to
        do with the tap values in axi_fir.xci
Message-ID:
        <CAGdo0uSrPOa8BF_rCdB+TDmvcWms1wBvdo0zbyYp7dtoQ=w7RQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Craig,

Did you update NUM_TAPS in axi_fir.v to 21? If so, then it will throw an
error. If not, you'll likely have strange output when the block tries to
program the Xilinx FIR filter instance with an incorrect number of
coefficients.

Unfortunately we don't have a mechanism to parse the .xci to make sure
there is consistency between axi_fir.v and axi_fir.xci. You could make a
HLS FIR filter implementation that would make this kind of consistency
possible. In fact, I plan on doing this as a more detailed HLS example one
day.



Jonathon

On Wed, Mar 23, 2016 at 7:43 PM, Swanson, Craig <
Craig.Swanson at gtri.gatech.edu> wrote:

> Jonathon,
>
> Wow, I am glad I asked.  What happens if the .xci specifies 21 filter taps
> and the uhd block specifies 41?  I am assuming it will throw out an error
> somewhere?
>
> Craig
>
>
>
> *Craig F. Swanson*
>
> *Research Engineer II*
>
> *Information and Communications Laboratory*
>
> *Communications, Systems, and Spectrum Division*
>
> Georgia Tech Research Institute
>
> Room 560
>
> 250 14th Street NW
>
> Atlanta, GA 30318
>
> Cell: 770-298-9156
>
> http://www.gtri.gatech.edu
>
>
>
> *From:* Jonathon Pendlum [mailto:jonathon.pendlum at ettus.com]
> *Sent:* Wednesday, March 23, 2016 10:35 PM
> *To:* Swanson, Craig <Craig.Swanson at gtri.gatech.edu>
> *Cc:* Martin Braun <martin.braun at ettus.com>; usrp-users at lists.ettus.com;
> Brothers, Timothy <Timothy.Brothers at gtri.gatech.edu>
> *Subject:* Re: Verifying these tap values have nothing to do with the tap
> values in axi_fir.xci
>
>
>
> Hi Craig,
>
>
>
> Those coefficients will be loaded into the FIR filter automatically at
> startup and overwrite whatever default taps your specified in the .xci
> file. If you set default taps in the .xci file, you should also put those
> taps in that text box.
>
>
>
>
>
>
>
> Jonathon
>
>
>
> On Wed, Mar 23, 2016 at 3:20 PM, Swanson, Craig <
> Craig.Swanson at gtri.gatech.edu> wrote:
>
> Jonathon and Martin,
>
> I found your instructions in the video from the conference and I modified
> the lib/ip/axi_fir/axi_fir.xci file using the Vivado build ip tool, then
> created a .bit file.  I added the FIR block to my flowgraph.  I noticed you
> can add tap values in the block shown below.  I wanted to make sure these
> tap values have no impact on and do not supercede what actually happens in
> my noc_block_fir_filter.
>
>
>
> Craig
>
>
>
>
>
> *Craig F. Swanson*
>
> *Research Engineer II*
>
> *Information and Communications Laboratory*
>
> *Communications, Systems, and Spectrum Division*
>
> *Georgia Tech Research Institute*
>
>
> *Room 560 250 14th St NW*
>
> *Atlanta, GA 30318*
>
> *Cell: 770.298.9156 <770.298.9156>*
>
> http://www.gtri.gatech.edu
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160323/839414bc/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 57394 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160323/839414bc/attachment-0001.png>

------------------------------

Message: 25
Date: Thu, 24 Mar 2016 02:53:07 +0000
From: "Swanson, Craig" <Craig.Swanson at gtri.gatech.edu>
To: Jonathon Pendlum <jonathon.pendlum at ettus.com>
Cc: Martin Braun <martin.braun at ettus.com>,
        "usrp-users at lists.ettus.com"    <usrp-users at lists.ettus.com>, "Brothers,
        Timothy"        <Timothy.Brothers at gtri.gatech.edu>
Subject: Re: [USRP-users] Verifying these tap values have nothing to
        do with the tap values in axi_fir.xci
Message-ID:
        <cec9e56d9bf44fd496aa1b062803bf3f at apatlisdmail04.core.gtri.org>
Content-Type: text/plain; charset="utf-8"

Jonathon,
Thanks for answering my question.  Now I understand it better.  As you said, both need to have NUM_TAPS the same value.
Thanks,
Craig

Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th Street NW
Atlanta, GA 30318
Cell: 770-298-9156
http://www.gtri.gatech.edu

From: Jonathon Pendlum [mailto:jonathon.pendlum at ettus.com]
Sent: Wednesday, March 23, 2016 10:50 PM
To: Swanson, Craig <Craig.Swanson at gtri.gatech.edu>
Cc: Martin Braun <martin.braun at ettus.com>; usrp-users at lists.ettus.com; Brothers, Timothy <Timothy.Brothers at gtri.gatech.edu>
Subject: Re: Verifying these tap values have nothing to do with the tap values in axi_fir.xci

Hi Craig,

Did you update NUM_TAPS in axi_fir.v to 21? If so, then it will throw an error. If not, you'll likely have strange output when the block tries to program the Xilinx FIR filter instance with an incorrect number of coefficients.

Unfortunately we don't have a mechanism to parse the .xci to make sure there is consistency between axi_fir.v and axi_fir.xci. You could make a HLS FIR filter implementation that would make this kind of consistency possible. In fact, I plan on doing this as a more detailed HLS example one day.



Jonathon

On Wed, Mar 23, 2016 at 7:43 PM, Swanson, Craig <Craig.Swanson at gtri.gatech.edu<mailto:Craig.Swanson at gtri.gatech.edu>> wrote:
Jonathon,
Wow, I am glad I asked.  What happens if the .xci specifies 21 filter taps and the uhd block specifies 41?  I am assuming it will throw out an error somewhere?
Craig

Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th Street NW
Atlanta, GA 30318
Cell: 770-298-9156<tel:770-298-9156>
http://www.gtri.gatech.edu

From: Jonathon Pendlum [mailto:jonathon.pendlum at ettus.com<mailto:jonathon.pendlum at ettus.com>]
Sent: Wednesday, March 23, 2016 10:35 PM
To: Swanson, Craig <Craig.Swanson at gtri.gatech.edu<mailto:Craig.Swanson at gtri.gatech.edu>>
Cc: Martin Braun <martin.braun at ettus.com<mailto:martin.braun at ettus.com>>; usrp-users at lists.ettus.com<mailto:usrp-users at lists.ettus.com>; Brothers, Timothy <Timothy.Brothers at gtri.gatech.edu<mailto:Timothy.Brothers at gtri.gatech.edu>>
Subject: Re: Verifying these tap values have nothing to do with the tap values in axi_fir.xci

Hi Craig,

Those coefficients will be loaded into the FIR filter automatically at startup and overwrite whatever default taps your specified in the .xci file. If you set default taps in the .xci file, you should also put those taps in that text box.



Jonathon

On Wed, Mar 23, 2016 at 3:20 PM, Swanson, Craig <Craig.Swanson at gtri.gatech.edu<mailto:Craig.Swanson at gtri.gatech.edu>> wrote:

Jonathon and Martin,

I found your instructions in the video from the conference and I modified the lib/ip/axi_fir/axi_fir.xci file using the Vivado build ip tool, then created a .bit file.  I added the FIR block to my flowgraph.  I noticed you can add tap values in the block shown below.  I wanted to make sure these tap values have no impact on and do not supercede what actually happens in my noc_block_fir_filter.



Craig



[cid:image001.png at 01D18556.C38B1A10]


Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156<tel:770.298.9156>
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160324/b389d027/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 57394 bytes
Desc: image001.png
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160324/b389d027/attachment-0001.png>

------------------------------

Message: 26
Date: Wed, 23 Mar 2016 19:55:29 -0700
From: Jonathon Pendlum <jonathon.pendlum at ettus.com>
To: "Swanson, Craig" <Craig.Swanson at gtri.gatech.edu>
Cc: Martin Braun <martin.braun at ettus.com>,
        "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>,      "Brothers,
        Timothy" <Timothy.Brothers at gtri.gatech.edu>
Subject: Re: [USRP-users] How do I change the number of taps and tap
        coefficients for the noc_block_fir_filter?
Message-ID:
        <CAGdo0uQFWPwyff5uA=W5B99p=FNeQ=d=JAqC7D=6RwK0UFG2oQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Craig,

At first you would see no difference as only 21 coefficients would be
loaded but the block expects 41. If you sent your 21 coefficients again,
then your filter output would look distorted as the second set of
coefficients would complete the expected 41. Basically, don't do this. :-)



Jonathon

On Wed, Mar 23, 2016 at 7:47 PM, Swanson, Craig <
Craig.Swanson at gtri.gatech.edu> wrote:

> Jonathon,
>
> Yes, I modified the axi_fir.xci file to have 41 coefficients.  So I just
> wanted to verify the scenario if the .bit file specified 41 coefficients
> and the python file generated in GRC specified 21, what would happen?
>
>
>
> Craig
>
>
>
> *Craig F. Swanson*
>
> *Research Engineer II*
>
> *Information and Communications Laboratory*
>
> *Communications, Systems, and Spectrum Division*
>
> Georgia Tech Research Institute
>
> Room 560
>
> 250 14th Street NW
>
> Atlanta, GA 30318
>
> Cell: 770-298-9156
>
> http://www.gtri.gatech.edu
>
>
>
> *From:* Jonathon Pendlum [mailto:jonathon.pendlum at ettus.com]
> *Sent:* Wednesday, March 23, 2016 10:36 PM
> *To:* Swanson, Craig <Craig.Swanson at gtri.gatech.edu>
> *Cc:* usrp-users at lists.ettus.com
> *Subject:* Re: How do I change the number of taps and tap coefficients
> for the noc_block_fir_filter?
>
>
>
> I think you figured this out (per another thread you posted) but in case
> you didn't, you need to generate a new .xci file for the AXI FIR filter.
> You can use the Vivado GUI to do that.
>
>
>
>
>
>
>
> Jonathon
>
>
>
> On Wed, Mar 23, 2016 at 1:47 PM, Swanson, Craig <
> Craig.Swanson at gtri.gatech.edu> wrote:
>
> ?Jonathon,
>
> I remember you reviewed how to do this at GRCon15, but I don't remember.
>
> Craig
>
>
>
> *Craig F. Swanson*
>
> *Research Engineer II*
>
> *Information and Communications Laboratory*
>
> *Communications, Systems, and Spectrum Division*
>
> *Georgia Tech Research Institute*
>
>
> *Room 560 250 14th St NW*
>
> *Atlanta, GA 30318*
>
> *Cell: 770.298.9156 <770.298.9156>*
>
> http://www.gtri.gatech.edu
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160323/1448934c/attachment-0001.html>

------------------------------

Message: 27
Date: Wed, 23 Mar 2016 22:59:49 -0400
From: James Humphries <james.humphries at ettus.com>
To: Diyar Muhammed <diyar.muhammed at mhe-krg.org>
Cc: "USRP-users at lists.ettus.com" <usrp-users at lists.ettus.com>
Subject: Re: [USRP-users] (no subject)
Message-ID:
        <CAEwGFhVXje6MCZox=ERP8_uAZx9O7YPw3oT_cLuM3qTiPTCPrw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Diyar,

You have a newer Rev. 7-8 X310 and you are running an older version of UHD
(3.8.1).

You will need to update to at least 3.9.0, but I recommend you update to
the latest version of UHD.

-Trip

On Wed, Mar 23, 2016 at 6:09 PM, Diyar Muhammed via USRP-users <
usrp-users at lists.ettus.com> wrote:

> Dear All,
> I assembled usrp x310, and I had a warning, so I downloaded FPGA image and
> then I have upgraded FPGA by using the command: usrp_x3xx_fpga_burner
> --addr=192.168.10.2
> --fpga-path=/usr/local/share/uhd/images/usrp_x310_fpga_HGS.bit.
> after that the usrp x310 is able to find daughter board, but still I have
> a UHD warning as shown in the below, as shown below:
>
> mint at mint ~ $ uhd_usrp_probe 192.168.10.2
> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.001-105-g91ae742f
>
>
> UHD Warning:
>     X300 unknown product code in EEPROM: 30818
>
> UHD Warning:
>     X300 unknown product code in EEPROM: 30818
>
> UHD Warning:
>     X300 unknown product code in EEPROM: 30818
>
> UHD Warning:
>     X300 unknown product code in EEPROM: 30818
> -- X300 initialization sequence...
> -- Determining maximum frame size... 1472 bytes.
> -- Setup basic communication...
> -- Loading values from EEPROM...
>
> UHD Warning:
>     X300 unknown product code in EEPROM: 30818
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> -- Initialize Radio control...
> -- Performing register loopback test... pass
> -- Performing register loopback test... pass
> -- Initializing clock and time using internal sources... done
>   _____________________________________________________
>  /
> |       Device: X-Series Device
> |     _____________________________________________________
> |    /
> |   |       Mboard: X300?
> |   |   revision: 8
> |   |   product: 30818
> |   |   mac-addr0: 00:80:2f:23:7b:6f
> |   |   mac-addr1: 00:80:2f:23:7b:70
> |   |   gateway: 192.168.10.1
> |   |   ip-addr0: 192.168.10.2
> |   |   subnet0: 255.255.255.0
> |   |   ip-addr1: 192.168.20.2
> |   |   subnet1: 255.255.255.0
> |   |   ip-addr2: 192.168.30.2
> |   |   subnet2: 255.255.255.0
> |   |   ip-addr3: 192.168.40.2
> |   |   subnet3: 255.255.255.0
> |   |   serial: 30C0991
> |   |   FW Version: 3.0
> |   |   FPGA Version: 9.0
> |   |
> |   |   Time sources: internal, external, gpsdo
> |   |   Clock sources: internal, external, gpsdo
> |   |   Sensors: ref_locked
> |   |     _____________________________________________________
> |   |    /
> |   |   |       RX DSP: 0
> |   |   |   Freq range: -100.000 to 100.000 MHz
> |   |     _____________________________________________________
> |   |    /
> |   |   |       RX DSP: 1
> |   |   |   Freq range: -100.000 to 100.000 MHz
> |   |     _____________________________________________________
> |   |    /
> |   |   |       RX Dboard: A
> |   |   |   ID: UBX-160 v1 (0x007a)
> |   |   |   Serial: 30C2AAB
> |   |   |     _____________________________________________________
> |   |   |    /
> |   |   |   |       RX Frontend: 0
> |   |   |   |   Name: UBX RX
> |   |   |   |   Antennas: TX/RX, RX2, CAL
> |   |   |   |   Sensors: lo_locked
> |   |   |   |   Freq range: 10.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   |     _____________________________________________________
> |   |   |    /
> |   |   |   |       RX Codec: A
> |   |   |   |   Name: ads62p48
> |   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
> |   |     _____________________________________________________
> |   |    /
> |   |   |       RX Dboard: B
> |   |   |   ID: UBX-160 v1 (0x007a)
> |   |   |   Serial: 30C2A33
> |   |   |     _____________________________________________________
> |   |   |    /
> |   |   |   |       RX Frontend: 0
> |   |   |   |   Name: UBX RX
> |   |   |   |   Antennas: TX/RX, RX2, CAL
> |   |   |   |   Sensors: lo_locked
> |   |   |   |   Freq range: 10.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   |     _____________________________________________________
> |   |   |    /
> |   |   |   |       RX Codec: B
> |   |   |   |   Name: ads62p48
> |   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
> |   |     _____________________________________________________
> |   |    /
> |   |   |       TX DSP: 0
> |   |   |   Freq range: -100.000 to 100.000 MHz
> |   |     _____________________________________________________
> |   |    /
> |   |   |       TX DSP: 1
> |   |   |   Freq range: -100.000 to 100.000 MHz
> |   |     _____________________________________________________
> |   |    /
> |   |   |       TX Dboard: A
> |   |   |   ID: UBX-160 v1 (0x0079)
> |   |   |   Serial: 30C2AAB
> |   |   |     _____________________________________________________
> |   |   |    /
> |   |   |   |       TX Frontend: 0
> |   |   |   |   Name: UBX TX
> |   |   |   |   Antennas: TX/RX, CAL
> |   |   |   |   Sensors: lo_locked
> |   |   |   |   Freq range: 10.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
> |   |   |   |   Connection Type: QI
> |   |   |   |   Uses LO offset: No
> |   |   |     _____________________________________________________
> |   |   |    /
> |   |   |   |       TX Codec: A
> |   |   |   |   Name: ad9146
> |   |   |   |   Gain Elements: None
> |   |     _____________________________________________________
> |   |    /
> |   |   |       TX Dboard: B
> |   |   |   ID: UBX-160 v1 (0x0079)
> |   |   |   Serial: 30C2A33
> |   |   |     _____________________________________________________
> |   |   |    /
> |   |   |   |       TX Frontend: 0
> |   |   |   |   Name: UBX TX
> |   |   |   |   Antennas: TX/RX, CAL
> |   |   |   |   Sensors: lo_locked
> |   |   |   |   Freq range: 10.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
> |   |   |   |   Connection Type: QI
> |   |   |   |   Uses LO offset: No
> |   |   |     _____________________________________________________
> |   |   |    /
> |   |   |   |       TX Codec: B
> |   |   |   |   Name: ad9146
> |   |   |   |   Gain Elements: None
>
> mint at mint ~ $
>
> What I have to do to sort out that?
> in advance many thanks.
> --
> Regards,
> Diyar Muhammed
> Ministry of Higher Education and Scientific Research
> Duty: Network Administration and Design
> Website:  www.mhe-krg.org
> Cell Phone: 009647504690060
> Office Phone:   00964662554683
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> 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/20160323/6109789f/attachment-0001.html>

------------------------------

Message: 28
Date: Wed, 23 Mar 2016 20:12:59 -0700
From: Jonathon Pendlum <jonathon.pendlum at ettus.com>
To: Sergio Cruz Perez <serchsype at hotmail.com>
Cc: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
Message-ID:
        <CAGdo0uTe+ONsT9R8FeMiG5TDPWo2JoZc0=aFofaRXNiPwW2_hg at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Sergio,

Looks like the block is being enumerated but UHD is not populating the
property tree correctly. What commit of UHD rfnoc-devel are you using?



Jonathon

On Wed, Mar 23, 2016 at 11:15 AM, Sergio Cruz Perez <serchsype at hotmail.com>
wrote:

> Hi Jonathon,
>
> Finally I could make the image updating the e300_core.v file as you said.
> I ran the uhd_usrp_probe init only and now I can see the rfnoc blocks
> schmidl_cox and fifo.
>
> *-- ========== Full list of RFNoC blocks: ============*
> *-- * 0/Radio_0*
> *-- * 0/Radio_1*
> *-- * 0/FIFO_0*
> *-- * 0/SchmidlCox_0*
>
> But, when i run my application I got again the same problem:
>
> ...
> *-- [0/SchmidlCox_0] _resolve_port_def()*
> *-- [0/SchmidlCox_0]   item type: sc16*
> *-- [0/SchmidlCox_0]   vector length: 0*
> *-- [0/SchmidlCox_0]   packet size: 0*
> *-- [0/SchmidlCox_0] _resolve_port_def()*
> *-- [0/SchmidlCox_0]   item type: sc16*
> *-- [0/SchmidlCox_0]   vector length: 64*
> *-- [0/SchmidlCox_0]   packet size: 64*
> *-- [NocScript] Executing and asserting code: SR_WRITE("CP_LENGTH",
> $cp_len)*
> *-- [NocScript] Executing SR_WRITE() *
> *--   [0/SchmidlCox_0] sr_write(CP_LENGTH, 00000040) ==>
> [0/SchmidlCox_0] sr_write(130, 00000040, 0)*
> *-- [NocScript] Executing and asserting code: GE($threshold, 0.0) AND
> LE($threshold, 1.0)*
> *-- [NocScript] Executing and asserting code: SR_WRITE("THRESHOLD",
> IROUND(MULT(32768.0, $threshold)))*
> *-- [NocScript] Executing SR_WRITE() *
> *--   [0/SchmidlCox_0] sr_write(THRESHOLD, 00007000) ==>
> [0/SchmidlCox_0] sr_write(134, 00007000, 0)*
> *Traceback (most recent call last):*
> *  File "./rx_rfnoc.py", line 207, in <module>*
> *    main()*
> *  File "./rx_rfnoc.py", line 196, in main*
> *    tb = top_block_cls(chan_est=options.chan_est, freq=options.freq,
> gain=options.gain, lo_offset=options.lo_offset,
> samp_rate=options.samp_rate)*
> *  File "./rx_rfnoc.py", line 97, in __init__*
> *    self.uhd_rfnoc_ofdm_schmidlcox_0.set_arg("offset", 77)*
> *  File "/usr/local/lib/python2.7/site-packages/ettus/ettus_swig.py", line
> 3002, in set_arg*
> *    return _ettus_swig.rfnoc_generic_sptr_set_arg(self, *args)*
> *RuntimeError: LookupError: Path not found in tree:
> /mboards/0/xbar/SchmidlCox_0/args/0/offset/value*
> ...
>
> How is that path generated? I can't find it on the E310
>
>
>
>
> ------------------------------
> From: jonathon.pendlum at ettus.com
> Date: Tue, 22 Mar 2016 15:17:40 -0700
> Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
> To: serchsype at hotmail.com
> CC: usrp-users at lists.ettus.com
>
> Sergio,
>
> rfnoc-ofdm has gotten a little out of sync with UHD rfnoc-devel. The
> compat number on line 172 in e300_core.v needs to be updated
> to RB32_CORE_COMPAT  : rb_data <= {8'hAC, 8'h0, 8'h255, 8'h0};
>
> I am going to merge rfnoc-ofdm into rfnoc-radio-redo soon which will fix
> this issue. This temporary fix should hold you over until the merge.
>
>
>
> Jonathon
>
> On Tue, Mar 22, 2016 at 3:07 PM, Sergio Cruz Perez <serchsype at hotmail.com>
> wrote:
>
>
> Hi Jonathon,
>
> It's a GNU radio flowgraph and I'm using my rfnoc fpga image. I copied the
> image that I made on my PC using the rfnoc-ofdm branches to the E310. My
> flowgraph has the root to that image in the device3 args so when I run my
> applications I can see that it's loading my image.
>
> root at ettus-e300:~/pruebas# ./rx_rfnoc.py
> linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.010.rfnoc-316-gb7546712
>
> -- Loading FPGA image: /home/root/sheko/usrp_e310_rfnoc_fpga.bit... done
> -- Initializing core control...
> -- Performing register loopback test... pass .
> ....
>
> When I don't use the rfnoc-ofdm branches I can make the image and run it
> on the E310 but I return to the first problem of this thread.
>
> Thanks
>
> Sergio
>
> ------------------------------
> From: jonathon.pendlum at ettus.com
> Date: Tue, 22 Mar 2016 14:23:28 -0700
>
> Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
> To: serchsype at hotmail.com
> CC: usrp-users at lists.ettus.com
>
> Hi Sergio,
>
> You need copy your bitstream to the E310 and replace
> /usr/share/uhd/images/usrp_e300_fpga.bit. How are you running your
> application? Is it a GNU Radio flowgraph?
>
>
>
> Jonathon
>
> On Tue, Mar 22, 2016 at 10:56 AM, Sergio Cruz Perez <serchsype at hotmail.com
> > wrote:
>
>
> Hi Jonathon,
>
> I installed  uhd rfnoc-devel version with the rfnoc-ofdm branches on both
> the PC and the E310 (UHD_003.010.rfnoc-316-gb7546712). I made the image
> with the schmidl_cox block but  when I run my application, I got the next
> error:
>
> RuntimeError: Expected FPGA compatibility number 255.x, but got 7.0:
> The FPGA build is not compatible with the host code build.
>
> What should I update on my PC to make a compatible image with the E310?
>
> Regards
> Sergio
>
>
>
> ------------------------------
> From: jonathon.pendlum at ettus.com
> Date: Wed, 9 Mar 2016 13:05:58 -0800
>
> Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
> To: serchsype at hotmail.com
> CC: usrp-users at lists.ettus.com
>
> Hi Sergio,
>
> Try using the "rfnoc-ofdm" branches for uhd and gr-ettus and rebuild your
> FPGA image. Make sure to add the schmidl_cox block to
> rfnoc_e310_ce_auto_inst.v and run 'make cleanall' before building the FPGA
> image.
>
>
>
> Jonathon
>
> On Tue, Mar 8, 2016 at 8:31 PM, Sergio Cruz Perez <serchsype at hotmail.com>
> wrote:
>
> Hi Jonathon,
>
> Yes, I followed the RFNoC:Getting started guide to install the rfnoc-devel
> branch and the gr-ettus  OOT module. I forgot to mention that in my first
> attempt to make the fpga image I had the next error:
>
> ERROR: [Synth 8-448] named port connection 's_axis_phase_tlast' does not
> exist for instance 'cfo_corrector' of module 'cordic_rotator'
> [/home/sheko/uhd/fpga-src/usrp3/lib/rfnoc/schmidl_cox.v:163]
>
> I removed that port in the schmidl_cox.v file and then it was possible to
> make the image with the schmidl_cox block.
>
> Thanks
>
> Sergio
>
>
>
>
>
> ------------------------------
> From: jonathon.pendlum at ettus.com
> Date: Tue, 8 Mar 2016 16:51:20 -0800
> Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
> To: serchsype at hotmail.com
> CC: usrp-users at lists.ettus.com
>
>
> Hi Sergio,
>
> Are you using the rfnoc-ofdm branches for uhd and gr-ettus?
>
>
>
> Jonathon
>
> On Tue, Mar 8, 2016 at 4:31 PM, Sergio Cruz Perez via USRP-users <
> usrp-users at lists.ettus.com> wrote:
>
>
> Hi,
>
> I'm learning to use RFNoC to implement an  OFDM receiver on a E310.  The
> original FPGA image had just 3 RFNoC blocks: FIFO, Window and FFT, so I
> made a new image removing the window and the FFT blocks and replacing them
> for a schmidl_cox block. When I run my application with the new image I get
> the next error:
>
> File "/usr/local/lib/python2.7/site-packages/ettus/ettus_swig.py", line
> 3002, in set_arg
> return _ettus_swig.rfnoc_generic_sptr_set_arg(self, *args)
>
> RuntimeError: LookupError: Path not found in tree:
> /mboards/0/xbar/SchmidlCox_0/args/0/offset/value
>
> Has anyone run into the same problem?
>
> I'm using UHD_003.010.rfnoc-314-gf773e72b
>
> Thanks
>
> Sergio Cruz
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> 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/20160323/f45f79bd/attachment-0001.html>

------------------------------

Message: 29
Date: Thu, 24 Mar 2016 07:59:08 +0000
From: <Emanuel.Staudinger at dlr.de>
To: <usrp-users at lists.ettus.com>
Subject: [USRP-users] B200mini: enable RF front-end via command
Message-ID:
        <38E0BEB98EBB5941BDC0A8EA39458CB4345C5020 at dlrexmbx02.intra.dlr.de>
Content-Type: text/plain; charset="us-ascii"

Hi there,

I adapted the example program "txrx_samples_to_file" to transmit an arbitrary pre-defined signal from a binary file and simultaneously receive a signal. My end-application is something like round-trip delay ranging with full/half-duplex operation.

When I use an X310 with the CBX front-ends, I clearly see received signal distortions, because the CBX front-ends (Tx and Rx) are switched on once a streaming command or send/receive command was issued. This setup time can be reduced by setting the ATR commands correctly or by a patch which has been circulated in this mailing list.

Now I would like to have the same for the B200mini. E.g., in my application I allow already a setup time of 10ms to create the transmit worker thread, and to avoid late-commands. Now I would like to activate the transmit portion and receive portion of the front-end chip during this 10ms setup-time.  Are there specific ATR commands for that? Or does anyone have a patch for that (I'm using the latest UHD release 3.9.3)? Besides that I would need such functionality also for another application for TDD, where I would like to pre-schedule the activation of the transmit front-end portion.

Thanks in advance,
Regards,
Emanuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160324/035f0a86/attachment-0001.html>

------------------------------

Message: 30
Date: Thu, 24 Mar 2016 08:02:58 +0000
From: Mhe <diyar.muhammed at mhe-krg.org>
To: "Marcus D. Leech" <mleech at ripnet.com>
Cc: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
Subject: Re: [USRP-users] X310 product code unknown EEPROM
Message-ID: <921E57F4-B58A-48E9-AD6A-C21D020CAB8B at mhe-krg.org>
Content-Type: text/plain;       charset=us-ascii

Dear Marcus,
Many thank for your advice,
How I can upgrade UHD?
Regards,
Diyar Muhammed
M: 009647504690060

> On Mar 24, 2016, at 12:50 AM, Marcus D. Leech <mleech at ripnet.com> wrote:
>
>> On 03/23/2016 06:09 PM, Diyar Muhammed via USRP-users wrote:
>> Dear All,
>> I assembled usrp x310, and I had a warning, so I downloaded FPGA image and then I have upgraded FPGA by using the command: usrp_x3xx_fpga_burner --addr=192.168.10.2 --fpga-path=/usr/local/share/uhd/images/usrp_x310_fpga_HGS.bit.
>> after that the usrp x310 is able to find daughter board, but still I have a UHD warning as shown in the below, as shown below:
>>
>> mint at mint ~ $ uhd_usrp_probe 192.168.10.2
>> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.001-105-g91ae742f
> You have a newer X310 hardware version that isn't supported by that very-old version of UHD.  Newer X310s *CANNOT* be supported by
>  older UHD due to hardware changes that were made.
>
> Upgrade to 3.9.2 or the just-released 3.9.3  UHD version.
>
>
>>
>> UHD Warning:
>>    X300 unknown product code in EEPROM: 30818
>>
>> UHD Warning:
>>    X300 unknown product code in EEPROM: 30818
>>
>> UHD Warning:
>>    X300 unknown product code in EEPROM: 30818
>>
>> UHD Warning:
>>    X300 unknown product code in EEPROM: 30818
>> -- X300 initialization sequence...
>> -- Determining maximum frame size... 1472 bytes.
>> -- Setup basic communication...
>> -- Loading values from EEPROM...
>>
>> UHD Warning:
>>    X300 unknown product code in EEPROM: 30818
>> -- Setup RF frontend clocking...
>> -- Radio 1x clock:200
>> -- Initialize Radio control...
>> -- Performing register loopback test... pass
>> -- Performing register loopback test... pass
>> -- Initializing clock and time using internal sources... done
>>  _____________________________________________________
>> /
>> |       Device: X-Series Device
>> |     _____________________________________________________
>> |    /
>> |   |       Mboard: X300?
>> |   |   revision: 8
>> |   |   product: 30818
>> |   |   mac-addr0: 00:80:2f:23:7b:6f
>> |   |   mac-addr1: 00:80:2f:23:7b:70
>> |   |   gateway: 192.168.10.1
>> |   |   ip-addr0: 192.168.10.2
>> |   |   subnet0: 255.255.255.0
>> |   |   ip-addr1: 192.168.20.2
>> |   |   subnet1: 255.255.255.0
>> |   |   ip-addr2: 192.168.30.2
>> |   |   subnet2: 255.255.255.0
>> |   |   ip-addr3: 192.168.40.2
>> |   |   subnet3: 255.255.255.0
>> |   |   serial: 30C0991
>> |   |   FW Version: 3.0
>> |   |   FPGA Version: 9.0
>> |   |
>> |   |   Time sources: internal, external, gpsdo
>> |   |   Clock sources: internal, external, gpsdo
>> |   |   Sensors: ref_locked
>> |   | _____________________________________________________
>> |   |    /
>> |   |   |       RX DSP: 0
>> |   |   |   Freq range: -100.000 to 100.000 MHz
>> |   | _____________________________________________________
>> |   |    /
>> |   |   |       RX DSP: 1
>> |   |   |   Freq range: -100.000 to 100.000 MHz
>> |   | _____________________________________________________
>> |   |    /
>> |   |   |       RX Dboard: A
>> |   |   |   ID: UBX-160 v1 (0x007a)
>> |   |   |   Serial: 30C2AAB
>> |   |   | _____________________________________________________
>> |   |   |    /
>> |   |   |   |       RX Frontend: 0
>> |   |   |   |   Name: UBX RX
>> |   |   |   |   Antennas: TX/RX, RX2, CAL
>> |   |   |   |   Sensors: lo_locked
>> |   |   |   |   Freq range: 10.000 to 6000.000 MHz
>> |   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
>> |   |   |   |   Connection Type: IQ
>> |   |   |   |   Uses LO offset: No
>> |   |   | _____________________________________________________
>> |   |   |    /
>> |   |   |   |       RX Codec: A
>> |   |   |   |   Name: ads62p48
>> |   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
>> |   | _____________________________________________________
>> |   |    /
>> |   |   |       RX Dboard: B
>> |   |   |   ID: UBX-160 v1 (0x007a)
>> |   |   |   Serial: 30C2A33
>> |   |   | _____________________________________________________
>> |   |   |    /
>> |   |   |   |       RX Frontend: 0
>> |   |   |   |   Name: UBX RX
>> |   |   |   |   Antennas: TX/RX, RX2, CAL
>> |   |   |   |   Sensors: lo_locked
>> |   |   |   |   Freq range: 10.000 to 6000.000 MHz
>> |   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
>> |   |   |   |   Connection Type: IQ
>> |   |   |   |   Uses LO offset: No
>> |   |   | _____________________________________________________
>> |   |   |    /
>> |   |   |   |       RX Codec: B
>> |   |   |   |   Name: ads62p48
>> |   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
>> |   | _____________________________________________________
>> |   |    /
>> |   |   |       TX DSP: 0
>> |   |   |   Freq range: -100.000 to 100.000 MHz
>> |   | _____________________________________________________
>> |   |    /
>> |   |   |       TX DSP: 1
>> |   |   |   Freq range: -100.000 to 100.000 MHz
>> |   | _____________________________________________________
>> |   |    /
>> |   |   |       TX Dboard: A
>> |   |   |   ID: UBX-160 v1 (0x0079)
>> |   |   |   Serial: 30C2AAB
>> |   |   | _____________________________________________________
>> |   |   |    /
>> |   |   |   |       TX Frontend: 0
>> |   |   |   |   Name: UBX TX
>> |   |   |   |   Antennas: TX/RX, CAL
>> |   |   |   |   Sensors: lo_locked
>> |   |   |   |   Freq range: 10.000 to 6000.000 MHz
>> |   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
>> |   |   |   |   Connection Type: QI
>> |   |   |   |   Uses LO offset: No
>> |   |   | _____________________________________________________
>> |   |   |    /
>> |   |   |   |       TX Codec: A
>> |   |   |   |   Name: ad9146
>> |   |   |   |   Gain Elements: None
>> |   | _____________________________________________________
>> |   |    /
>> |   |   |       TX Dboard: B
>> |   |   |   ID: UBX-160 v1 (0x0079)
>> |   |   |   Serial: 30C2A33
>> |   |   | _____________________________________________________
>> |   |   |    /
>> |   |   |   |       TX Frontend: 0
>> |   |   |   |   Name: UBX TX
>> |   |   |   |   Antennas: TX/RX, CAL
>> |   |   |   |   Sensors: lo_locked
>> |   |   |   |   Freq range: 10.000 to 6000.000 MHz
>> |   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
>> |   |   |   |   Connection Type: QI
>> |   |   |   |   Uses LO offset: No
>> |   |   | _____________________________________________________
>> |   |   |    /
>> |   |   |   |       TX Codec: B
>> |   |   |   |   Name: ad9146
>> |   |   |   |   Gain Elements: None
>>
>> mint at mint ~ $
>>
>> What I have to do to sort out that?
>> in advance many thanks.
>



------------------------------

Message: 31
Date: Thu, 24 Mar 2016 07:54:29 -0600
From: Jacob Gilbert <mrjacobagilbert at gmail.com>
To: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
Subject: [USRP-users] Segmentation Fault from uhd::transport when
        stopping/starting flowgraph
Message-ID:
        <CAC52AkCmfHW4cw3UonatSQdEp-t7upeQee9zw2qgUJCJseZAqw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

I have a flowgraph that requires stopping and starting to reconfigure its
output, and have run into two different segfaults originating from within
UHD.

Starting and stopping is done based on user input and by either issuing the
stop() wait() sequence, or by having a block return "WORK_DONE" (-1). Both
have been shown to produce both types of segfault, however the WORK_DONE
method anecdotally appears to be less frequent. The errors always occur
while waiting for the wait() function to return and occasionally hang for
an extremely long time before actually throwing sigsev.

BT's of the segfaults are here:

------------

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f8704fe9700 (LWP 103995)]
0x00007f87b25589d0 in
uhd::transport::sph::recv_packet_handler::converter_thread_task(unsigned
long) () from /usr/local/lib/libuhd.so.003
(gdb) i trace
No tracepoints.
(gdb) bt
#0  0x00007f87b25589d0 in
uhd::transport::sph::recv_packet_handler::converter_thread_task(unsigned
long) () from /usr/local/lib/libuhd.so.003
#1  0x00007f87b26e8433 in task_impl::task_loop(boost::function<void ()>
const&) ()
   from /usr/local/lib/libuhd.so.003
#2  0x00007f87be684e7a in ?? () from
/usr/lib/x86_64-linux-gnu/libboost_thread.so.1.55.0
#3  0x00007f87d2831182 in start_thread (arg=0x7f8704fe9700) at
pthread_create.c:312
#4  0x00007f87d255e47d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

------------

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fce1cff9700 (LWP 112591)]
0x00007fcebb8e0b83 in
__convert_sc16_item32_be_1_fc32_1_PRIORITY_SIMD::operator()(uhd::ref_vector<void
const*> const&, uhd::ref_vector<void*> const&, unsigned long) () from
/usr/local/lib/libuhd.so.003
(gdb) bt
#0  0x00007fcebb8e0b83 in
__convert_sc16_item32_be_1_fc32_1_PRIORITY_SIMD::operator()(uhd::ref_vector<void
const*> const&, uhd::ref_vector<void*> const&, unsigned long) () from
/usr/local/lib/libuhd.so.003
#1  0x00007fcebbb33ad9 in
uhd::transport::sph::recv_packet_handler::converter_thread_task(unsigned
long) () from /usr/local/lib/libuhd.so.003
#2  0x00007fcebbcc3433 in task_impl::task_loop(boost::function<void ()>
const&)
    () from /usr/local/lib/libuhd.so.003
#3  0x00007fcec7c5fe7a in ?? ()
   from /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.55.0
#4  0x00007fcedbe0c182 in start_thread (arg=0x7fce1cff9700)
    at pthread_create.c:312
#5  0x00007fcedbb3947d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(gdb)

------------

System Details:
OS: Ubuntu 14.04-3
UHD 3.9.2
GNU Radio: 3.7.9.1

Thanks,
Jacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160324/f0af5fde/attachment-0001.html>

------------------------------

Message: 32
Date: Thu, 24 Mar 2016 15:39:32 +0000
From: Xingjian Chen <xingjian at umass.edu>
To: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
Subject: [USRP-users] rec_samples_to_file overflow
Message-ID: <CE1BA7E5929533488C6364476B9C23A81AD6EFE4 at oit-ex2010-mb3>
Content-Type: text/plain; charset="us-ascii"

Hello guys.
I set B200mini receiving samples using UHD example called "rx_samples_to_file.cpp" at rate of 56MB/s with float32 I/Q data. It always get overflow message as below:
"Got an overflow indication. Please consider the following:
  Your write medium must sustain a rate of 448.000000MB/s.
  Dropped samples will not be written to the file.
  Please modify this example for your purposes.
  This message will not appear again."
However, my memory speed is over 3 GB/s according to the test using the method here:
http://serverfault.com/questions/372020/what-are-the-best-possible-ways-to-benchmark-ram-no-ecc-under-linux-arm
I find the problem is from this sentence in the rx_samples_to_file.cpp:
size_t num_rx_samps = rx_stream->recv(&buff.front(), buff.size(), md, 3.0, enable_size_map);
I guess the rx_stream command does not utilizing all my memory capability. Any ideas?

Thank you!


------------------------------

Message: 33
Date: Thu, 24 Mar 2016 11:53:13 -0400
From: "Marcus D. Leech" <mleech at ripnet.com>
To: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] rec_samples_to_file overflow
Message-ID: <56F40D69.7070605 at ripnet.com>
Content-Type: text/plain; charset=windows-1252; format=flowed

On 03/24/2016 11:39 AM, Xingjian Chen via USRP-users wrote:
> Hello guys.
> I set B200mini receiving samples using UHD example called "rx_samples_to_file.cpp" at rate of 56MB/s with float32 I/Q data. It always get overflow message as below:
> "Got an overflow indication. Please consider the following:
>    Your write medium must sustain a rate of 448.000000MB/s.
>    Dropped samples will not be written to the file.
>    Please modify this example for your purposes.
>    This message will not appear again."
> However, my memory speed is over 3 GB/s according to the test using the method here:
> http://serverfault.com/questions/372020/what-are-the-best-possible-ways-to-benchmark-ram-no-ecc-under-linux-arm
> I find the problem is from this sentence in the rx_samples_to_file.cpp:
> size_t num_rx_samps = rx_stream->recv(&buff.front(), buff.size(), md, 3.0, enable_size_map);
> I guess the rx_stream command does not utilizing all my memory capability. Any ideas?
>
> Thank you!
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Are you writing to a file on a ramdisk, or just a regular disk?

Unless you have a RAID array, it would be very difficult to sustain
448MB/sec write rates to a single disk.





------------------------------

Message: 34
Date: Thu, 24 Mar 2016 11:59:04 -0400
From: devin kelly <dwwkelly at gmail.com>
To: "USRP-users at lists.ettus.com" <usrp-users at lists.ettus.com>
Subject: Re: [USRP-users] GPS and UHD Time Alignment
Message-ID:
        <CAANLyuborvYL5-NEN2EBuDc0biMgc6mYruYOOtO2r6uR1kO6CQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

The issue is that as soon as I align the two clocks they become
un-aligned.  So if I run the master branch version of query_gpsdo_sensors
back-to-back (without interruption) the UHD and GPS clocks aren't aligned
_both_ times.

I do this with the 3.9.2 version of the UHD and FPGA firmware/image, so
part of my question is for UHD 3.9.{0,1,2} is this a problem with just
query_gpsdo_sensors or is there something wrong with library or FPGA image
too?

On Wed, Mar 23, 2016 at 5:14 PM, Michael West via USRP-users <
usrp-users at lists.ettus.com> wrote:

> Hi Devin,
>
> The version of the query_gpsdo_sensor utility in UHD 3.9.2 and 3.9.3 does
> not work properly on the X310.  You did the correct thing by downloading
> the version at the head of the master branch.  That version explicitly sets
> the time and clock sources to "gpsdo", where the other versions of the
> utility assumed the sources were set to "gpsdo" by default.  UHD 3.10.0
> will have the corrected version of the utility.
>
> Regards,
> Michael
>
> On Wed, Mar 23, 2016 at 1:57 PM, Marcus D. Leech via USRP-users <
> usrp-users at lists.ettus.com> wrote:
>
>> On 03/23/2016 04:29 PM, devin kelly via USRP-users wrote:
>>
>> Hello,
>>
>> I'm on UHD 3.9.2 and I've been having some problems with aligning the UHD
>> time and GPS time on my X310.  My GPS, as far as I can tell, acquires and
>> maintains lock fine.  However, everytime I run query_gpsdo_sensors the UHD
>> and GPS time are not aligned (UHD time is always some low number like 1,2
>> or 3).
>>
>> I downloaded the the master copy query_gpsdo_sensors here:
>>
>>
>> https://github.com/EttusResearch/uhd/blob/master/host/utils/query_gpsdo_sensors.cpp
>>
>> And built it against 3.9.2, everything works seems to work fine when I
>> run it:
>>
>> Time source is now gpsdo
>> GPS Locked
>> Setting the reference clock source to "gpsdo"...
>>
>> Clock source is now gpsdo
>> **************************************Helpful Notes on Clock/PPS
>> Selection**************************************
>> As you can see, the default 10 MHz Reference and 1 PPS signals are now
>> from the GPSDO.
>> If you would like to use the internal reference(TCXO) in other
>> applications, you must configure that explicitly.
>>
>> ****************************************************************************************************************
>> USRP Locked to GPSDO 10 MHz Reference.
>>
>> GPS and UHD Device time are NOT aligned;
>> last_pps: 3 vs gps: 1458764120. Trying to set the device time to GPS
>> time...
>> --     1) catch time transition at pps edge
>> --     2) set times next pps (synchronously)
>> last_pps: 1458764124 vs gps: 1458764124.
>> GPS and UHD Device time are aligned.
>> Printing available NMEA strings:
>> GPS_GPGGA:
>> $GPGGA,201524.00,4227.5889,N,07116.0425,W,2,10,1.2,86.8,M,-33.1,M,,*68
>> GPS_GPRMC:
>> $GPRMC,201524.00,A,4227.5889,N,07116.0425,W,0.0,0.0,230316,,*29
>> GPS Epoch time at last PPS: 1458764124.00000 seconds
>> UHD Device time last PPS:   1458764124.00000 seconds
>> UHD Device time right now:  1458764124.24561 seconds
>> PC Clock time:              1458764124 seconds
>>
>> GPS and UHD time aren't aligned but query_gpsdo_senors aligns them for me
>> fine.  However if I run querry_gpsdo_sensors again the clocks are
>> un-aligned again!
>>
>> Time source is now gpsdo
>> GPS Locked
>> Setting the reference clock source to "gpsdo"...
>>
>> Clock source is now gpsdo
>> **************************************Helpful Notes on Clock/PPS
>> Selection**************************************
>> As you can see, the default 10 MHz Reference and 1 PPS signals are now
>> from the GPSDO.
>> If you would like to use the internal reference(TCXO) in other
>> applications, you must configure that explicitly.
>>
>> ****************************************************************************************************************
>> USRP Locked to GPSDO 10 MHz Reference.
>>
>> GPS and UHD Device time are NOT aligned;
>> last_pps: 3 vs gps: 1458764770. Trying to set the device time to GPS
>> time...
>> --     1) catch time transition at pps edge
>> --     2) set times next pps (synchronously)
>> last_pps: 1458764774 vs gps: 1458764774.
>> GPS and UHD Device time are aligned.
>> Printing available NMEA strings:
>> GPS_GPGGA:
>> $GPGGA,202614.00,4227.5830,N,07116.0439,W,2,11,1.0,80.9,M,-33.1,M,,*60
>> GPS_GPRMC:
>> $GPRMC,202614.00,A,4227.5830,N,07116.0439,W,0.2,0.0,230316,,*27
>> GPS Epoch time at last PPS: 1458764774.00000 seconds
>> UHD Device time last PPS:   1458764774.00000 seconds
>> UHD Device time right now:  1458764774.24745 seconds
>> PC Clock time:              1458764774 seconds
>>
>> Done!
>>
>> What's going on here?  I think the newest UHD release is 3.9.3 so I could
>> try that but could there be some other issue?
>>
>> Thanks for any help,
>>
>> Devin
>>
>>
>> _______________________________________________
>> USRP-users mailing listUSRP-users at lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>> When you re-run, do you do so immediately?   What's the scenario?  What
>> do you do between running query_gpsdo_sensor instances?
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> 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/20160324/3fb9a39d/attachment-0001.html>

------------------------------

Subject: Digest Footer

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


------------------------------

End of USRP-users Digest, Vol 67, Issue 24
******************************************




More information about the USRP-users mailing list