Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: Unable to create Vivado projekt or to build clean repo
(Jonathon Pendlum)
2. Re: Where can I find a tutorial on how to use the MPSK SNR
Estimator? (Martin Braun)
3. Re: B210 user registers (Ian Buckley)
4. Re: B210 user registers (Ian Buckley)
5. Re: E310 and USB Serial Port (Thierry Guichon)
6. Frequency synchronization problem (Herlook Search)
7. Re: E310 and USB Serial Port (Philip Balister)
8. Re: Frequency synchronization problem (Marcus D. Leech)
9. E310 FPGA design_Loopback test (BHUSHAN PAWAR)
10. E310 - OpenBTS and OsmoTRX NOHANDOVER (Pablo Colodr?n)
11. External power to the B200 ( John Petrich)
12. Re: E310 Clock Synchronization with internal GPS (Kyle A Logue)
----------------------------------------------------------------------
Message: 1
Date: Tue, 26 Apr 2016 09:14:30 -0700
From: Jonathon Pendlum <[email protected]>
To: James Wagner <[email protected]>
Cc: Patrick Berger <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Unable to create Vivado projekt or to build
clean repo
Message-ID:
<CAGdo0uTs3TdHrrWhBB4iTwiCWB=+e1saf9a8ejwwttas4rh...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi James,
Did you try running 'make cleanall' and building again?
Jonathon
On Mon, Apr 25, 2016 at 2:36 PM, James Wagner <[email protected]> wrote:
> I am also getting the same error.
>
> this is an attempt to build the base RFNOC HGS image with no change in the
> utilized blocks.
>
> I run
>
> source setupenv.sh --vivado-path=/home/sdr-dev/xilinx/Vivado
>
> which outputs the following
>
> Setting up X3x0 FPGA build environment (64-bit)...
> bash:
> /home/sdr-dev/xilinx/Vivado_HLS/2015.2/.settings64-Vivado_High_Level_Synthesis.sh:
> No such file or directory
> bash: /opt/Xilinx/DocNav/.settings64-DocNav.sh: No such file or directory
> - Vivado: Found (/home/sdr-dev/xilinx/Vivado/2015.2/bin)
>
> Environment successfully initialized.
>
>
>
> I then run the command
>
> make X310_RFNOC_HGS
>
> yielding a message saying
>
>
> INFO: [Common 17-206] Exiting Webtalk at Mon Apr 25 14:31:25 2016...
> INFO: [Vivado 12-3441] generate_netlist_ip - operation complete
> synth_ip: Time (s): cpu = 00:00:58 ; elapsed = 00:01:17 . Memory (MB):
> peak = 1857.766 ; gain = 970.414 ; free physical = 4787 ; free virtual =
> 14137
> # if [string match $gen_example_proj "1"] {
> # puts "BUILDER: Generating Example Design..."
> # open_example_project -force -dir . [get_ips $ip_name]
> # }
> BUILDER: Generating Example Design...
> ERROR: [Common 17-69] Command failed: * The IP Data in the repository is
> incompatible with the current instance (despite having identical Version
> and Revision). You will need to update the IP before viewing the
> customization and generating outputs.
> * IP file
> '/home/sdr-dev/repo/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/ten_gig_eth_pcs_pma/ten_gig_eth_pcs_pma.xml'
> for IP 'ten_gig_eth_pcs_pma' contains stale content.
> Please select 'Report IP Status' from the 'Tools/Report' menu or run Tcl
> command 'report_ip_status' for more information.
> INFO: [Common 17-206] Exiting Vivado at Mon Apr 25 14:31:25 2016...
> Releasing IP location:
> /home/sdr-dev/repo/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/ten_gig_eth_pcs_pma
> make[1]: ***
> [/home/sdr-dev/repo/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/ten_gig_eth_pcs_pma/ten_gig_eth_pcs_pma.xci.out]
> Error 1
> make[1]: Leaving directory `/home/sdr-dev/repo/uhd/fpga-src/usrp3/top/x300'
> make: *** [X310_RFNOC_HGS] Error 2
>
>
>
>
>
> On Sun, Apr 10, 2016 at 12:52 PM, Jonathon Pendlum via USRP-users <
> [email protected]> wrote:
>
>> Hi Patrick,
>>
>> What branch are you on? rfnoc-devel or rfnoc-ofdm? Did you run source
>> setupenv.sh in the usrp3/top/x300/ directory? What is it output?
>>
>>
>>
>> Jonathon
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160426/497e15a5/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 26 Apr 2016 09:41:12 -0700
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] Where can I find a tutorial on how to use
the MPSK SNR Estimator?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
That's the paper I was going to point you to too. It has good references
to more detailed papers as well.
M
On 04/25/2016 04:45 PM, Richard Bell wrote:
> Oh and this is the paper Tom used that explains the algorithms
>
> "A Comparison of SNR Estimation Techniques for the AWGN Channel", David
> R. Pauluzzi and Norman C. Beaulieu, Fellow, IEEE
>
> Rich
>
> On Mon, Apr 25, 2016 at 4:43 PM, Richard Bell <[email protected]
> <mailto:[email protected]>> wrote:
>
> No tutorial that I know of.
>
> My experience has been the only type that works well is the 2nd and
> 4th moment.
>
> Start very simple and build up from there. Feed a noise source into
> the estimator and see if you can get the estimator to spit out what
> you know you're putting into it. Then add something between them and
> see if you understand the output. Keep on going until your system is
> done. That's how I learned how to use it.
>
> Rich
>
>
> On Mon, Apr 25, 2016 at 3:41 PM, Swanson, Craig via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> ?Martin,
>
> I would like to learn how to use the MPSK SNR Estimator or MPSK
> SNR Estimator Probe block and the best way I learn is by going
> through tutorials. At one time, there was
> a gr-digital/examples/snr_estimators.py or snr_estimators.grc.
>
>
> What do you suggest?
>
>
> 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 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>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
------------------------------
Message: 3
Date: Tue, 26 Apr 2016 10:37:07 -0700
From: Ian Buckley <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] B210 user registers
Message-ID:
<cam_0ocgedb4z-_hsy5tmx3_2bas1rzikyfjb3jl+ruygdz4...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Marcus since Petr is asking about user settings specifically I suspect he
has enabled and connected his custom logic to the user_settings module in
radio_b200.v. Can you confirm please Petr?. This currently lacks for B2x0,
as Petr pointed out, access via the usual UHD API.
-Ian
On Tue, Apr 26, 2016 at 1:07 AM, Marcus M?ller <[email protected]>
wrote:
> Dear Petr,
>
> interfacing with the registers is usually done via radio_ctrl_core_3000 on
> the third-gen devices like the B2xx.
> Which actual instance of that you want to use depends on which part of the
> B210 FPGA your settings register is connected ? there's the _local_ctrl,
> and one radio_perifs[0,1].ctrl for each DSP chain in b200_impl .
>
> Best regards,
> Marcus
>
>
> On 26.04.2016 06:23, Petr Pracha? via USRP-users wrote:
>
> Hi,
> I have USRP B210, and I need to write into user setting register in FPGA.
> Is any easy way to do this? For many other radios (B100, N2x0, E100) is
> implemented function set_user_register(). Why isn't implemented
> user_setting_core in B200_impl.cpp? . It is really important to me, because
> I have spend too many time with changing Verilog code, but its unusable
> without ctrl from host computer.
> Thank you for answer.
>
> Petr
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160426/5650da48/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 27 Apr 2016 00:24:54 -0700
From: Ian Buckley <[email protected]>
To: Petr Pracha? <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] B210 user registers
Message-ID:
<cam_0ocfjumn6skhdto9daskvpw5r6egsgpyg40h4nrcmq-e...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Petr, just to double check: You did enable user settings in the FPGA build?
You would do this by changing " .USER_SETTINGS(0), ->
.USER_SETTINGS(1)," in b200_core.v for both radio instances.
-Ian
Marcus, thank you for your answer, but what the Ian wrote is true. I have
> my custom logic in FPGA and I need access to the registers resp. set_data
> registers with set_addr: 8'd253 and 8'd254, which are reserved for
> user_setting in Verilog code. I don?t understand why isn't any method for
> write to this registers in UHD for B2X0 while for any others USRP is it.
> I tried to implement the similar method, which is implemented in
> B100_impl.cpp.
> This is the part of code which i wrote to the B200_impl.cpp and then a
> tried to call function set_user_register(addr,data,0) in from main().
> _user = user_settings_core_200::make(_local_ctrl, TOREG(253));
> _tree->create<user_settings_core_200::user_reg_t>(mb_path /
> "user/regs")
> .subscribe(boost::bind(&user_settings_core_200::set_reg, _user, _1));
> I have build it without any error or warning, but it had no effect on the
> registers in FPGA when I run the program.
> Does anyone know how can I fix this problem? Thank you
On Tue, Apr 26, 2016 at 11:36 PM, Petr Pracha? <[email protected]> wrote:
>
> Marcus, thank you for your answer, but what the Ian wrote is true. I have
> my custom logic in FPGA and I need access to the registers resp. set_data
> registers with set_addr: 8'd253 and 8'd254, which are reserved for
> user_setting in Verilog code. I don?t understand why isn't any method for
> write to this registers in UHD for B2X0 while for any others USRP is it.
>
> I tried to implement the similar method, which is implemented in
> B100_impl.cpp.
>
> This is the part of code which i wrote to the B200_impl.cpp and then a
> tried to call function set_user_register(addr,data,0) in from main().
>
>
> _user = user_settings_core_200::make(_local_ctrl, TOREG(253));
>
> _tree->create<user_settings_core_200::user_reg_t>(mb_path /
> "user/regs")
>
> .subscribe(boost::bind(&user_settings_core_200::set_reg, _user, _1));
>
>
> I have build it without any error or warning, but it had no effect on the
> registers in FPGA when I run the program.
>
> Does anyone know how can I fix this problem? Thank you
>
>
>
>
> On Tue, Apr 26, 2016 at 11:27 AM, Ian Buckley <[email protected]>
> wrote:
>
> Marcus since Petr is asking about user settings specifically I suspect he
> has enabled and connected his custom logic to the user_settings module in
> radio_b200.v. Can you confirm please Petr?. This currently lacks for B2x0,
> as Petr pointed out, access via the usual UHD API.
> -Ian
>
>
> On Tue, Apr 26, 2016 at 1:07 AM, Marcus M?ller <[email protected]
> > wrote:
>
> Dear Petr,
>
> interfacing with the registers is usually done via radio_ctrl_core_3000 on
> the third-gen devices like the B2xx.
> Which actual instance of that you want to use depends on which part of the
> B210 FPGA your settings register is connected ? there's the _local_ctrl,
> and one radio_perifs[0,1].ctrl for each DSP chain in b200_impl .
>
> Best regards,
> Marcus
>
>
> On 26.04.2016 06:23, Petr Pracha? via USRP-users wrote:
>
> Hi,
> I have USRP B210, and I need to write into user setting register in FPGA.
> Is any easy way to do this? For many other radios (B100, N2x0, E100) is
> implemented function set_user_register(). Why isn't implemented
> user_setting_core in B200_impl.cpp? . It is really important to me, because
> I have spend too many time with changing Verilog code, but its unusable
> without ctrl from host computer.
> Thank you for answer.
>
> Petr
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160427/92b008cc/attachment-0001.html>
------------------------------
Message: 5
Date: Wed, 27 Apr 2016 07:38:11 -0400
From: "Thierry Guichon" <[email protected]>
To: "'USRP Mailing List'" <[email protected]>
Subject: Re: [USRP-users] E310 and USB Serial Port
Message-ID: <3D2AA4CF2D4A428FA3544B8FC872E54B@Tristan>
Content-Type: text/plain; charset="us-ascii"
Hello Philip,
Some time ago you provided me with a fix to resolve an issue that I had with
a missing driver for a USB serial port device (See below). This was on
release 3 for the E310
Unfortunately, I had to update to release 4, and it looks like I now have
the same problem with this serial port which is not recognized.
May I ask for your support again?
Thank you
Thierry
-----Original Message-----
From: USRP-users [mailto:[email protected]] On Behalf Of
Philip Balister via USRP-users
Sent: Monday, August 10, 2015 3:05 PM
To: [email protected]
Subject: Re: [USRP-users] E310 and USB Serial Port
On 08/04/2015 11:46 PM, Thierry Guichon via USRP-users wrote:
> Hello,
>
>
> I am attempting to connect a ATEN International UC-232A USB to serial
> converter. This device works correctly with an E100.
>
> When trying to use it with an E310, no ttyUSBx exists or are created.
> The usb device is detected as can be seen by the output of lsusb and
> dmesg. (device 007)
> Could you give me a hint as to what is needed to recognize this USB
> device.
We've worked through this and found the magic kconfig option. Future
releases will have:
CONFIG_USB_SERIAL_PL2303=m
in the kconfig.
Philip
>
> Thanks
>
> Thierry
>
> root /home/modemdev # lsusb
> Bus 001 Device 002: ID 0424:2513 Standard Microsystems Corp. 2.0 Hub
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 001 Device 007: ID 0557:2008 ATEN International Co., Ltd UC-232A
> Serial Port [pl2303]
> Bus 001 Device 004: ID 0556:0004 Asahi Kasei Microsystems Co., Ltd
>
> dmesg
> [22661.429826] axi_fpga 40000000.axi-fpga: in axi_fpga_open, d->dev_open
> = 0
> [22661.437043] axi_fpga 40000000.axi-fpga: in axi_fpga_mmap
> [22661.442356] axi_fpga 40000000.axi-fpga: Size = 5242880, expected size
> = 5242880
> [22666.267504] axi_fpga 40000000.axi-fpga: in axi_fpga_release
> [23141.592173] usb 1-1.2: USB disconnect, device number 6
> [23232.452016] usb 1-1.2: new full-speed USB device number 7 using zynq-
> ehci
>
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 6
Date: Wed, 27 Apr 2016 14:40:22 +0200
From: Herlook Search <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Frequency synchronization problem
Message-ID:
<ca+ekp-bdh2rbxuzr4v+gkbegddcdr5fbmhtki0ap3c1gdcj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi everyone,
I use two USRP N210 with the RFX2450. I manipulate them in C++.
I would like to characterize the USRPs. In that way, I send very simple
signals, as a constant signal in baseband. When I send this signal, I
observe a circle in baseband due to the CFO. This is what I expected.
If I send the same signal when the USRPs are synchronized with the same 10
MHz clock (I use an external square wave generator), I see that the
amplitude of this sequence quickly decreases through time. If I use an
alternate sequence of {-1;+1}, I also observe that its amplitude decreases.
But it seems that the synchronisation works because, when I do an OFDM
communication or a single carrier communication with the 10 MHz clock, I
can recover my QAM constellation without CFO.
Can you confirm that these results are expected from such a configuration?
If it is the case, can we avoid them?
Thanks in advance.
Marc
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160427/c6da1030/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 27 Apr 2016 08:41:48 -0400
From: Philip Balister <[email protected]>
To: [email protected], 'USRP Mailing List'
<[email protected]>
Subject: Re: [USRP-users] E310 and USB Serial Port
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 04/27/2016 07:38 AM, Thierry Guichon via USRP-users wrote:
> Hello Philip,
>
> Some time ago you provided me with a fix to resolve an issue that I had with
> a missing driver for a USB serial port device (See below). This was on
> release 3 for the E310
>
>
> Unfortunately, I had to update to release 4, and it looks like I now have
> the same problem with this serial port which is not recognized.
>
> May I ask for your support again?
Yes, my mistake. Before replying to this email I added it. I'm going to
make some new test images with this in it. Hopefully within a week.
Philip
>
>
> Thank you
>
> Thierry
>
> -----Original Message-----
> From: USRP-users [mailto:[email protected]] On Behalf Of
> Philip Balister via USRP-users
> Sent: Monday, August 10, 2015 3:05 PM
> To: [email protected]
> Subject: Re: [USRP-users] E310 and USB Serial Port
>
> On 08/04/2015 11:46 PM, Thierry Guichon via USRP-users wrote:
>> Hello,
>>
>>
>> I am attempting to connect a ATEN International UC-232A USB to serial
>> converter. This device works correctly with an E100.
>>
>> When trying to use it with an E310, no ttyUSBx exists or are created.
>> The usb device is detected as can be seen by the output of lsusb and
>> dmesg. (device 007)
>> Could you give me a hint as to what is needed to recognize this USB
>> device.
>
> We've worked through this and found the magic kconfig option. Future
> releases will have:
>
> CONFIG_USB_SERIAL_PL2303=m
>
> in the kconfig.
>
> Philip
>
>>
>> Thanks
>>
>> Thierry
>>
>> root /home/modemdev # lsusb
>> Bus 001 Device 002: ID 0424:2513 Standard Microsystems Corp. 2.0 Hub
>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>> Bus 001 Device 007: ID 0557:2008 ATEN International Co., Ltd UC-232A
>> Serial Port [pl2303]
>> Bus 001 Device 004: ID 0556:0004 Asahi Kasei Microsystems Co., Ltd
>>
>> dmesg
>> [22661.429826] axi_fpga 40000000.axi-fpga: in axi_fpga_open, d->dev_open
>> = 0
>> [22661.437043] axi_fpga 40000000.axi-fpga: in axi_fpga_mmap
>> [22661.442356] axi_fpga 40000000.axi-fpga: Size = 5242880, expected size
>> = 5242880
>> [22666.267504] axi_fpga 40000000.axi-fpga: in axi_fpga_release
>> [23141.592173] usb 1-1.2: USB disconnect, device number 6
>> [23232.452016] usb 1-1.2: new full-speed USB device number 7 using zynq-
>> ehci
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 8
Date: Wed, 27 Apr 2016 09:39:59 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Frequency synchronization problem
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 04/27/2016 08:40 AM, Herlook Search via USRP-users wrote:
> Hi everyone,
>
> I use two USRP N210 with the RFX2450. I manipulate them in C++.
>
> I would like to characterize the USRPs. In that way, I send very
> simple signals, as a constant signal in baseband. When I send this
> signal, I observe a circle in baseband due to the CFO. This is what I
> expected.
>
> If I send the same signal when the USRPs are synchronized with the
> same 10 MHz clock (I use an external square wave generator), I see
> that the amplitude of this sequence quickly decreases through time. If
> I use an alternate sequence of {-1;+1}, I also observe that its
> amplitude decreases.
>
> But it seems that the synchronisation works because, when I do an OFDM
> communication or a single carrier communication with the 10 MHz clock,
> I can recover my QAM constellation without CFO.
>
> Can you confirm that these results are expected from such a
> configuration? If it is the case, can we avoid them?
>
> Thanks in advance.
>
> Marc
>
Make sure that your baseband tone is far enough away from DC so as not
to get swallowed by the DC-offset compensation algorithm, which takes a
while to converge.
------------------------------
Message: 9
Date: Wed, 27 Apr 2016 17:09:11 +0200
From: BHUSHAN PAWAR <[email protected]>
To: [email protected], [email protected]
Cc: Daniel Rudolf <[email protected]>, Marcus M?ller
<[email protected]>, Jonathon Pendlum
<[email protected]>
Subject: [USRP-users] E310 FPGA design_Loopback test
Message-ID:
<cafvcn_8i1unu8ddkttjwy8t+cfaurhcbjqgv9iurqvu_ocp...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello all,
- During initailiazation E310 performs few tests like register loopback
test(3 times) and CODEC loopback (2 times) and Timer loopback test (2
times). Can you briefly explain each test or suggest some data to read to
understand this issue?
- I am trying to achieve Rx to Tx loopback by editing current FPGA
design. In the current FPGA, data is moved from E310_core --> FIFO -->
Processing System --> FIFO --> E310_core. In the edited FPGA design, I am
trying to bypass Processing system in the data path to reduce time delay.
When I load the edited bit file on E310 it gives below errors,
[pawa_bh@ohff24 ~]$ ssh -X [email protected]
Last login: Fri Jan 22 00:54:11 2016 from ohff24.local
root@ettus-e3xx-sg1:~# uhd_usrp_probe --args='fpga=/tmp/e300.bit'
linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.009.002-0-unknown
-- Loading FPGA image: /tmp/e300.bit... done
-- Detecting internal GPSDO .... found
-- Initializing core control...
-- Performing register loopback test... pass
-- Performing register loopback test... Error: EnvironmentError: IOError:
Radio ctrl (0) no response packet - AssertionError: bool(buff)
in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
at
/home/balister/release-4/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/uhd/3.9.2-r0/uhd-3.9.2/lib/usrp/cores/radio_ctrl_core_3000.cpp:198
Can you explain the reason for this error?
- As I am looking for FPGA modification, I was reading about RFNOC. In
the below mentioned link (https://github.com/EttusResearch/uhd/wiki) it
is mentioned that Pure FPGA flow graphs are currently unsupported (i.e.
RX->TX loopback). Can you briefly explain the reason for this?
*Thanks & Regards,*
*Bhushan R.V. Pawar.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160427/05c8304d/attachment-0001.html>
------------------------------
Message: 10
Date: Wed, 27 Apr 2016 13:45:36 +0200
From: Pablo Colodr?n <[email protected]>
To: [email protected]
Subject: [USRP-users] E310 - OpenBTS and OsmoTRX NOHANDOVER
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hi all,
I have succesfully compiled OpenBTS (git commit
6f8bd144823b489f991ac3d1120ab12dcff33029) following the steps described
in http://openbts.org/w/index.php?title=E3x0.
Device configuration consists of a USRP E310 with the following
connections: GPS antenna connected to sync signal (GPSDO is locked), GSM
antenna connected to TRX-A and GSM antenna+40dB attenuator connected to
RX2A (for preventing RF overrange in RX).
Launching OsmoTRX (using -f flag) and OpenBTS, I manage to see the GSM
network in the mobile phone. Using a GSM spectrum analyzer, I also
checked that Tx signal has a 700Hz offset, but this enough for the
mobile phone to see the network. However, when I try to attach the
phone, I can only see few messages like the following:
WARNING 3042473040 22:26:06.8 Transceiver.cpp:825:driveControl:
NOHANDOVER at timeslot 0 subslot 0
WARNING 3042473040 22:26:06.8 Transceiver.cpp:825:driveControl:
NOHANDOVER at timeslot 0 subslot 0
Aparrently, they are RACH messages sent by the phone but not processed
by the transceiver.
TRX-A led is red and RX2-A led is green when I launch all software. I
used default configurations for OpenBTS, OsmoTRX and ettus E310. This is
the output of the OsmoTRX when it starts up:
root@ettus-e300:/usr/local/bin# ./osmo-trx -f
linux; GNU C++ version 4.9.1; Boost_105600; UHD_003.008.004-0-unknown
Config Settings
Log Level............... NOTICE
Device args.............
TRX Base Port........... 5700
TRX Address............. 127.0.0.1
Channels................ 1
Samples-per-Symbol...... 1
External Reference...... Disabled
C0 Filler Table......... Dummy bursts
Diversity............... Disabled
Tuning offset........... 0
RSSI to dBm offset...... 0
Swap channels........... 0
-- Loading FPGA image: /usr/share/uhd/images/usrp_e310_fpga.bit... done
-- Detecting internal GPSDO.... found
-- Initializing core control...
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Performing CODEC loopback test... pass
-- Setting time source to internal
-- Asking for clock rate 32 MHz
-- Actually got clock rate 32 MHz
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
-- Initializing time to the internal GPSDO
-- Asking for clock rate 26 MHz
-- Actually got clock rate 26 MHz
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
-- Setting E3XX 1 SPS
-- Transceiver active with 1 channel(s)
Any help will be appreciated.
Regards,
--
131010-CRT-#P-Firma html-V1.00
*Pablo Colodr?n*
SW Development Leader
CENTUM R&T -www.centum-rt.com <http://www.centum-rt.com/>
*//**/T /*+34 986 120 460
*/F/*+34 986 120 461*/
/*
crt1-01.png
*_P_*Please don?t print this e-mail unless you really need to!
Este correo electr?nico y los documentos que, en su caso, lo acompa?an
pueden contener informaci?n reservada y/o confidencial dirigida
exclusivamente al uso del destinatario. Si Ud. no es el destinatario, le
rogamos que nos lo notifique inmediatamente, por esta misma v?a, no
estando autorizado para su exhibici?n, copia ni distribuci?n a otras
personas o entidades. Si ha recibido este correo electr?nico por error,
le rogamos que lo destruya o elimine de su sistema. El correo
electr?nico v?a Internet no permite asegurar ni la confidencialidad de
los mensajes que se transmiten ni la correcta recepci?n de los mismos.
En caso de que el destinatario de este mensaje no consienta la
utilizaci?n del correo electr?nico v?a Internet, rogamos lo ponga en
nuestro conocimiento de manera inmediata.
**************
The information in this e-mail and, if applicable, in any of the files
attached thereto, is confidential and intended solely for the attention
and use of the named addressee. If you are not the intended recipient,
please contact us forthwith via e-mail. Please note that you are not
authorized to disclose, copy or distribute the information herein to any
third person or entity. If you have received this e-mail in error,
please destroy it or delete it from your computer system. Neither
confidentiality nor correct receipt of messages in an e-mail sent via
Internet may be granted. Should the addressee of this message not agree
to the use of the e-mail via internet, he/she is kindly requested to let
us know forthwith.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160427/03dfebc8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 14617 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160427/03dfebc8/attachment-0001.png>
------------------------------
Message: 11
Date: Wed, 27 Apr 2016 08:38:38 -0700
From: " John Petrich" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] External power to the B200
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Are there any things that I need to consider to power the B200 from an
external 6 volt power supply? Am cautious about the combination of the
powered USB 3 data link and external power supply. Not sure if that
combination will cause problems. It is likely that the power switching is
likely accomplished automatically and internal to the B200 but want to be
sure.
Regards,
John Petrich
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160427/c5024987/attachment-0001.html>
------------------------------
Message: 12
Date: Wed, 27 Apr 2016 15:51:22 +0000
From: Kyle A Logue <[email protected]>
To: "[email protected]" <[email protected]>, Ettus Mail List
<[email protected]>
Subject: Re: [USRP-users] E310 Clock Synchronization with internal GPS
Message-ID:
<bl2pr09mb09635630b32acb679204c10fb9...@bl2pr09mb0963.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="windows-1252"
A quick correction:
I said this problem was unresolved in 3.10.x but that is not strictly true. It
is unresolved in the E310 Release 4 image which is using 3.9.2.
Paul Garver posted to the mailing list today this tidbit:
For others who may be searching this same topic, I?ll provide an update. We had
an error in our metadata recording code which was causing the mean time delay
estimation between multiple B200s to be on the order of microseconds (~25uS) at
25 MSPS. Now, we have all three B200s sync?d within a sample on UHD 3.8.5 using
a timing reference and 10 MHz/1PPS. The sample mean is around 40nS and the
sample variance is extremely low (reads zero). To do better than this, I
presume we will need to compensate for the random phase by calibrating on every
run / retune.
We use our custom recording tool in gr-analysis to record the times, which
looks like it time-tags accurately as long as the correct segment size is given
(default is OK).
https://github.com/garverp/gr-analysis
Does this seem reasonable? Does anyone else have time alignment results for the
B200 they would care to share?
PWG
Which may indicate that there is something in UHD 3.9.5+ that could address
this problem, but i haven't seen any alpha images on files.ettus.com newer than
release 4.
Something to keep an eye on,
Kyle
________________________________
From: USRP-users <[email protected]> on behalf of Thierry
Guichon via USRP-users <[email protected]>
Sent: Thursday, April 21, 2016 10:34
To: 'USRP Mailing List'
Subject: Re: [USRP-users] E310 Clock Synchronization with internal GPS
Thank you Marcus and Kyle,
It looks like anyhow I need to update my image :-)
The offset of 2 microseconds that you are experiencing will not be a problem
for my application. The offsets that I am currently seeing are more in the
order of several hundreds milliseconds so there is something fundamentally
wrong with either my setup or the UHD version that I am using.
I will see what I get after the upgrade.
Sincerely
Thierry
________________________________
From: USRP-users [mailto:[email protected]] On Behalf Of Kyle
A Logue via USRP-users
Sent: Thursday, April 21, 2016 1:09 PM
To: Ettus Mail List
Subject: Re: [USRP-users] E310 Clock Synchronization with internal GPS
Thierry:
This question has come up so many times and there isn't a proper solution for
it yet. To me it's the largest outstanding bug in the E310 and a deal-killer
for several applications.
You can use my dance for synchronizing the E310 GPS previously posted here:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-January/017483.html
But the best you can do is GPS time +- 2000ns. Even if you use an external
signal source for time synchronization, the onboard pps trigger is never more
than 20ns accurate to GPS time. As a quick summary, some of the other posts
talking about this problem:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-November/016928.html
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-November/016928.html>http://permalink.gmane.org/gmane.comp.hardware.usrp.e100/18253
The issue seems to arise from an FPGA pps trigger issue, but it's still
unresolved in UHD 003.010.x.
As a side note, you need to be using the Release 4 version of the SD image,
previous releases used the GPSDO quite differently.
Good Luck.
Kyle Logue
________________________________
From: USRP-users <[email protected]> on behalf of Marcus D.
Leech via USRP-users <[email protected]>
Sent: Thursday, April 21, 2016 07:12
To: [email protected]
Subject: Re: [USRP-users] E310 Clock Synchronization with internal GPS
On 04/21/2016 09:04 AM, Thierry Guichon via USRP-users wrote:
Hello
I am facing a problem with the E310 that I do not encounter when using the E100
Here is the relevant configuration to the device:
set_time_next_pps(time_spec_t{}); // Set the time at 0 at the next pps tick
#if device == E31X
set_time_source("gpsdo")
#endif
In both devices, the gps reports to be locked.
We then receive a signal which is externally synchronized to the GPS PPS.
When receiving this signal, the E100 correctly reports the reception time at a
few us after the PPS while the E310 reports this time at a large offset after
the PPS. In addition, for the E310, this offset changes each time the program
is run.
It appears as if on the E310 calling set_time_next_pps(time_spec_t{}) does not
set the time at the internal GPS 1 PPS tick? Did I miss a configuration step?
I am using UHD 003.008.005
If you can, I strongly recommend upgrading your E310 to the latest system
image, which has a much-more-recent UHD.
Use the image from here:
http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-e3xx-sg1/sdimage-gnuradio-dev.direct.xz
Using the instructions here:
http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_upgrade_sd_card
Also, we're probably going to have to see more of your setup code to make a
determination about what might be wrong.
Thank you
Thierry
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160427/ea10aa81/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 68, Issue 28
******************************************
