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: FPGA Replacement (Ian Buckley)
2. Re: Accessing a customized register of FPGA code from UHD
(Ian Buckley)
3. Re: [Discuss-gnuradio] New UHD seems to break a lot...
(Ralph A. Schmid, dk5ras)
4. Re: [Discuss-gnuradio] New UHD seems to break a lot...
(Martin Braun)
5. ERROR: USRP E310 Network mode (Xinke Zhang)
6. NI USRP-2943R not found by uhd (Vincent CRAUET)
7. Re: ERROR: USRP E310 Network mode (Moritz Fischer)
8. Re: NI USRP-2943R not found by uhd (Ben Hilburn)
9. Re: ERROR: USRP E310 Network mode (Xinke Zhang)
10. Re: [Discuss-gnuradio] New UHD seems to break a lot...
(Ralph A. Schmid, dk5ras)
11. B210 over Network? (Jason A. Donenfeld)
12. Re: B210 over Network? (Marcus M?ller)
13. Re: ERROR: USRP E310 Network mode (Philip Balister)
14. ZPU Interrupt Service Routine(ISR) (mojtaba rostami)
15. Re: Rx/Tx Loopback (Marcus M?ller)
----------------------------------------------------------------------
Message: 1
Date: Wed, 15 Apr 2015 10:08:23 -0700
From: Ian Buckley <[email protected]>
To: Derek Murphy <[email protected]>
Cc: "[email protected] List" <[email protected]>
Subject: Re: [USRP-users] FPGA Replacement
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
If you are asking about rework, then yes you *could* rework a B200 to B210
FPGA. In practical terms I would never consider doing it. The chances of even a
skilled rework professional doing it without impacting the board or other
components are not at all favorable. Doing it yourself I guarantee it will not
end well, nor will it offer you any warranty fallback. As far as using a
different FPGA family, then no, no other family is footprint compatable with
this Spartan6.
If you have a custom FPGA project in mind and feel you are short of FPGA
capacity there may be creative ways to trim the factory design to increase
available resources.
On Apr 15, 2015, at 7:27 AM, Moritz Fischer via USRP-users
<[email protected]> wrote:
> Derek,
>
> if you find a pin compatible 7 series FPGA and are willing to redo
> large parts of the design it's probably possible. Considering the
> amount of engineering time required however, you might as well just
> buy an X series device.
>
> Cheers,
>
> Moritz
>
> On Wed, Apr 15, 2015 at 7:08 AM, Derek Murphy via USRP-users
> <[email protected]> wrote:
>> Has anyone experimented with replacing the FPGA on the B200 to either the
>> FPGA on the B210 or something like a Xilinx Kintex-7 FPGA? I understand the
>> FPGA image will need to be modified but electrically would it work?
>>
>> _______________________________________________
>> 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: 2
Date: Wed, 15 Apr 2015 10:33:48 -0700
From: Ian Buckley <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "Candell, Richard" <[email protected]>, Chien-Chung Shen
<[email protected]>, "[email protected]"
<[email protected]>, "Proctor, Frederick M"
<[email protected]>, "Lee, Kang B" <[email protected]>
Subject: Re: [USRP-users] Accessing a customized register of FPGA code
from UHD
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Probably TOREG(x) would be what you would use in x300 UHD code Marcus.
-Ian
On Apr 14, 2015, at 3:05 AM, Marcus M?ller <[email protected]> wrote:
> Hi Isen,
>> Thanks. I was aware of the file, setting_reg.hpp, and I just did not know
>> what address number I should set up.
> The address you used for your user settings register.
>
>> setting_reg #(.my_addr(BASE+2), .width(WIDTH)) reg_tx
>> (.clk(clk),.rst(reset), .strobe(set_stb),.addr(set_addr), .in(set_data),
>> .out(in_tx),.changed());
> since you set my_addr to BASE+2, you should use the same value when poking.
> (BASE==0 is reserved for user extensions, by the way)
>
>> However, I still have no idea how to access this variable from Applications
>> like UHD program.
> You would use the poke32/peek method from
> uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp. You can access the right
> instance in x300_impl, so inside x300_impl.cpp, the right thing to do is
>
> mb.radio_perifs[0].ctrl->poke32(SR_REG(my_addr), value);
>
> with 0 being the radio control chain A, 1 being B.
>
> Now, if you want to export that functionality, the UHD way of doing that is
> adding an entry to the property tree, and binding a method to that; something
> like:
>
> _tree->create<boost::uint32_t>(mb_path / "custom" / "my_register")
> .publish(boost::bind(&radio_ctrl_core_3000::peek32,
> mb.radio_perifs[mb_i].ctrl, SR_REG(BASE,2) ))
> .subscribe(boost::bind(&radio_ctrl_core_3000::poke32,
> mb.radio_perifs[mb_i].ctrl, SR_REG(BASE,2), _1 ));
>
> inside x300_impl::setup_mb.
>
> Other than that, Ian answered a question on a very related topic yesterday,
> see
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-April/013525.html
>
> @Ian: SR_REG is the right thing to use here, isn't it?
>
> Greetings,
> Marcus
>
> On 04/14/2015 11:03 AM, Isen I-Chun Chao wrote:
>> Hi Marcus,
>>
>>
>> Also, following your instruction, I got a piece of code segment below, which
>> is from control/gpio_atr:
>> setting_reg #(.my_addr(BASE+2), .width(WIDTH)) reg_tx
>> (.clk(clk),.rst(reset), .strobe(set_stb),.addr(set_addr), .in(set_data),
>> .out(in_tx),.changed());
>>
>> However, I still have no idea how to access this variable from Applications
>> like UHD program. Is there any example code available for us? I know Marcus
>> has been dedicated to GNURadio S/W part. But I am sure there are someone who
>> is completely familiar with FPGA related problems. Could somebody helps? I
>> would very appreciate it.
>>
>>
>>
>>
>>
>>
>> Best Regards,
>> Isen I-Chun Chao
>>
>> On Wed, Apr 8, 2015 at 4:32 AM, Marcus M?ller <[email protected]>
>> wrote:
>> Commenting on code that I don't know is a bit hard, but:
>>
>> you will need to have a working instance of setting_reg; after that, you'll
>> be able to use the register just like the other registers you'd find in your
>> uhd/host/lib/usrp/x300/x300_regs.hpp.
>>
>> Git grep is really helpful finding examples for the usage of setting_reg:
>> cd fpga/usrp3/lib
>> git grep --context 3 setting_reg
>>
>> Greetings,
>> Marcus
>>
>> On 04/05/2015 04:38 AM, Isen I-Chun Chao via USRP-users wrote:
>>> Hi,
>>> I have a customized register in x300_core.v, say named *my_var.* I would
>>> like to get the register value from the application layer through UHD or
>>> whatever.
>>>
>>> I wonder if there any example in UHD can be used for my reference or anyone
>>> could provide some advice.
>>> j
>>> Thank you very much.
>>>
>>>
>>>
>>> *Best Regards,Isen I-Chun Chao*
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20150415/0216db05/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 15 Apr 2015 19:52:20 +0200
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: "'Martin Braun'" <[email protected]>,
<[email protected]>, "'GNU Radio Discussion List'"
<[email protected]>
Subject: Re: [USRP-users] [Discuss-gnuradio] New UHD seems to break a
lot...
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
RC1, master seems to work.
Ralph.
-----Original Message-----
From: Martin Braun [mailto:[email protected]]
Sent: Wednesday, April 15, 2015 15:44
To: Ralph A. Schmid, dk5ras; [email protected]; 'GNU Radio
Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
Thanks, Ralph. Just to clarify: When you say 'New UHD', do you mean
3.8.3-RC1, or latest master?
Martin
On 15.04.2015 08:40, Ralph A. Schmid, dk5ras wrote:
> It is a B210, but as a note, due to the up to now missing FPGA images
> I used 003.008.003-RC1, not the latest master. Still I had no access
> to a spectrum and DVB-T analyzer, so I have no idea what is happening,
> I just can confirm that RF is transmitted, and the receiver doesn't
> get a picture, while with the snapshot of the same VM before the upgrade
is received without problems.
> I will know more in about three hours.
>
> Ralph.
>
>> -----Original Message-----
>> From: Martin Braun [mailto:[email protected]]
>> Sent: Wednesday, April 15, 2015 3:15 PM
>> To: Ralph A. Schmid, dk5ras; [email protected]; 'GNU Radio
>> Discussion List'
>> Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
>>
>> On 15.04.2015 06:20, Ralph A. Schmid, dk5ras wrote:
>>> Hi,
>>>
>>> Not only OpenBTS is affected, also gr-dvbt/t2 do not work any more
>>> with latest uhd. A quick check during lunch break showed, the
>>> produced output is not decodable any more. I will take a closer look
>>> this evening at home, where I have more and better equipment.
>>
>> Ralph,
>>
>> which device is this on?
>>
>> Thanks,
>> Martin
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150415/7ddd2ad2/attachment-0001.sig>
------------------------------
Message: 4
Date: Wed, 15 Apr 2015 14:14:25 -0500
From: Martin Braun <[email protected]>
To: "Ralph A. Schmid, dk5ras" <[email protected]>,
[email protected], 'GNU Radio Discussion List'
<[email protected]>
Subject: Re: [USRP-users] [Discuss-gnuradio] New UHD seems to break a
lot...
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
master works, but RC1 does not? Huh, I'm confused now. Can you give some
detail on what's going on, so we can try and reproduce this?
Thanks,
Martin
On 15.04.2015 12:52, Ralph A. Schmid, dk5ras wrote:
> RC1, master seems to work.
>
> Ralph.
>
> -----Original Message-----
> From: Martin Braun [mailto:[email protected]]
> Sent: Wednesday, April 15, 2015 15:44
> To: Ralph A. Schmid, dk5ras; [email protected]; 'GNU Radio
> Discussion List'
> Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
>
> Thanks, Ralph. Just to clarify: When you say 'New UHD', do you mean
> 3.8.3-RC1, or latest master?
>
> Martin
>
> On 15.04.2015 08:40, Ralph A. Schmid, dk5ras wrote:
>> It is a B210, but as a note, due to the up to now missing FPGA images
>> I used 003.008.003-RC1, not the latest master. Still I had no access
>> to a spectrum and DVB-T analyzer, so I have no idea what is happening,
>> I just can confirm that RF is transmitted, and the receiver doesn't
>> get a picture, while with the snapshot of the same VM before the upgrade
> is received without problems.
>> I will know more in about three hours.
>>
>> Ralph.
>>
>>> -----Original Message-----
>>> From: Martin Braun [mailto:[email protected]]
>>> Sent: Wednesday, April 15, 2015 3:15 PM
>>> To: Ralph A. Schmid, dk5ras; [email protected]; 'GNU Radio
>>> Discussion List'
>>> Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
>>>
>>> On 15.04.2015 06:20, Ralph A. Schmid, dk5ras wrote:
>>>> Hi,
>>>>
>>>> Not only OpenBTS is affected, also gr-dvbt/t2 do not work any more
>>>> with latest uhd. A quick check during lunch break showed, the
>>>> produced output is not decodable any more. I will take a closer look
>>>> this evening at home, where I have more and better equipment.
>>>
>>> Ralph,
>>>
>>> which device is this on?
>>>
>>> Thanks,
>>> Martin
>>
>
>
------------------------------
Message: 5
Date: Wed, 15 Apr 2015 10:44:55 +0800 (GMT+08:00)
From: "Xinke Zhang" <[email protected]>
To: [email protected]
Subject: [USRP-users] ERROR: USRP E310 Network mode
Message-ID: <[email protected]>
Content-Type: text/plain; charset="gbk"
Hi,
I'm using the usrp e310, and reburn the sd card with
http://files.ettus.com/e3xx_images/beta/dizzy-test/sdimage-gnuradio-demo.direct.xz.
when configuring the usrp e310 as network mode (config the ip addr and start
the usrp_e3x0_network_mode), i use the uhd_find_devices and i can find the usrp
e310 devices, but when i use the uhd_usrp_probe, it came out the error message
"Error: e300_remote_codec_ctrl_impl trancation failed". Pls help check it.
Thank you in advance.
the version of uhd installed in the host pc is 3.8.2-151-gbf4f50de.
Best Regards,
Xinke
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150415/4dfce5d9/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 15 Apr 2015 14:28:31 +0200 (CEST)
From: Vincent CRAUET <[email protected]>
To: [email protected]
Subject: [USRP-users] NI USRP-2943R not found by uhd
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-15"
Hi, I have some trouble with UHD. My USRP isn't recognized.
I use NI USRP-2943R on Ubuntu 14.04 Gnuradio Live SDR Environment.
https://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD
The UHD driver is supposed to be preinstalled so I connected USRP by JTAG/USB
and it is found as ? Future technology devices International, Ltd FT 2232C Dual
USB-UART/FIFO IC?.
I checked then uhd_find_devices function, it answers no UHD devices found.
I tried to reinstall the driver with ettus tutorial using these commands :
sudo bash -c 'echo "deb
http://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/`lsb_release -cs`
`lsb_release -cs` main" > /etc/apt/sources.list.d/ettus.list'
sudo apt-get update
sudo apt-get
install -t `lsb_release -cs` uhd
My driver's version is UHD_003.008.001 and i see here (
http://files.ettus.com/manual/page_build_guide.html ) that the last release is
003.008.002.
Could 003.008.001 be obsolete for NI USRP-2943R ?
The Gnuradio live SDR Environment provides a "src" folder in which gnuradio,
gnuradio libraries and drivers are stored.
In firmware folder, i see support for usrp2, b100, b200, e300, x300 but not for
2943R.
Do you have any clues of why this USRP is not detected ?
Thanks for your support.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150415/aaf6f4be/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: firmware_folder.png
Type: image/png
Size: 17801 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150415/aaf6f4be/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uhd_folder.png
Type: image/png
Size: 18948 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150415/aaf6f4be/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uhd_find_devices.png
Type: image/png
Size: 50947 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150415/aaf6f4be/attachment-0005.png>
------------------------------
Message: 7
Date: Wed, 15 Apr 2015 16:24:30 -0500
From: Moritz Fischer <[email protected]>
To: Xinke Zhang <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] ERROR: USRP E310 Network mode
Message-ID:
<caatxahfhjvinworfgehrg27ctozvcl6h2b1tjruyszspuh7...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi Xinke,
When upgrading your device UHD you also need to upgrade your host UHD.
The current dizzy-test images are build from the 3.8.3-RC1 tag. Make
sure you build off of that.
Also note that you'll need to run uhd_images_downloader to get the
correct fpga image in place on the device.
Cheers,
Moritz
On Tue, Apr 14, 2015 at 9:44 PM, Xinke Zhang via USRP-users
<[email protected]> wrote:
>
> Hi,
>
> I'm using the usrp e310, and reburn the sd card with
> http://files.ettus.com/e3xx_images/beta/dizzy-test/sdimage-gnuradio-demo.direct.xz.
> when configuring the usrp e310 as network mode (config the ip addr and start
> the usrp_e3x0_network_mode), i use the uhd_find_devices and i can find the
> usrp e310 devices, but when i use the uhd_usrp_probe, it came out the error
> message "Error: e300_remote_codec_ctrl_impl trancation failed". Pls help
> check it. Thank you in advance.
>
> the version of uhd installed in the host pc is 3.8.2-151-gbf4f50de.
>
> Best Regards,
>
> Xinke
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 8
Date: Wed, 15 Apr 2015 16:00:40 -0700
From: Ben Hilburn <[email protected]>
To: Vincent CRAUET <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] NI USRP-2943R not found by uhd
Message-ID:
<CAOEVZkLyUKL0JRhDxTDpx=hzcklefkkxwc6syz+tviwyy-x...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Vincent -
The JTAG port cannot be used for device operation. It must be connected by
Ethernet or PCIe.
The manual may help you out:
http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_getting_started
Cheers,
Ben
On Wed, Apr 15, 2015 at 5:28 AM, Vincent CRAUET via USRP-users <
[email protected]> wrote:
> Hi, I have some trouble with UHD. My USRP isn't recognized.
>
> I use NI USRP-2943R on Ubuntu 14.04 Gnuradio Live SDR Environment.
>
> https://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD
>
>
> The UHD driver is supposed to be preinstalled so I connected USRP by
> JTAG/USB and it is found as ? Future technology devices International, Ltd
> FT 2232C Dual USB-UART/FIFO IC?.
>
> I checked then uhd_find_devices function, it answers no UHD devices found.
>
> I tried to reinstall the driver with ettus tutorial using these commands :
>
> sudo bash -c 'echo
> "debhttp://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/`lsb_release
> <http://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/lsb_release> -cs`
> `lsb_release -cs` main" > /etc/apt/sources.list.d/ettus.list'
>
> sudo apt-get update
>
> sudo apt-get
> install -t `lsb_release -cs` uhd
>
> My driver's version is UHD_003.008.001 and i see here (
> http://files.ettus.com/manual/page_build_guide.html) that the last
> release is 003.008.002.
>
> Could 003.008.001 be obsolete for NI USRP-2943R ?
>
>
> The Gnuradio live SDR Environment provides a "src" folder in which
> gnuradio, gnuradio libraries and drivers are stored.
> In firmware folder, i see support for usrp2, b100, b200, e300, x300 but
> not for 2943R.
> Do you have any clues of why this USRP is not detected ?
>
>
> Thanks for your support.
>
>
>
> _______________________________________________
> 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/20150415/be203259/attachment-0001.html>
------------------------------
Message: 9
Date: Thu, 16 Apr 2015 09:34:19 +0800 (GMT+08:00)
From: "Xinke Zhang" <[email protected]>
To: "Moritz Fischer" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] ERROR: USRP E310 Network mode
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Moritz,
Thank you.
I used the e310 sdk toolchain to build the uhd source codes in the host pc, and
then transfer the built binary to the e310 device. However, i need to copy the
seperate built binary into its corresponding directory. is there any automatic
solution to update the uhd in the e310 device? Thanks.
Best Regards,
Xinke
> -----Original Messages-----
> From: "Moritz Fischer" <[email protected]>
> Sent Time: Thursday, April 16, 2015
> To: "Xinke Zhang" <[email protected]>
> Cc: "[email protected]" <[email protected]>
> Subject: Re: [USRP-users] ERROR: USRP E310 Network mode
>
> Hi Xinke,
>
> When upgrading your device UHD you also need to upgrade your host UHD.
> The current dizzy-test images are build from the 3.8.3-RC1 tag. Make
> sure you build off of that.
> Also note that you'll need to run uhd_images_downloader to get the
> correct fpga image in place on the device.
>
> Cheers,
>
> Moritz
>
> On Tue, Apr 14, 2015 at 9:44 PM, Xinke Zhang via USRP-users
> <[email protected]> wrote:
> >
> > Hi,
> >
> > I'm using the usrp e310, and reburn the sd card with
> > http://files.ettus.com/e3xx_images/beta/dizzy-test/sdimage-gnuradio-demo.direct.xz.
> > when configuring the usrp e310 as network mode (config the ip addr and start
> > the usrp_e3x0_network_mode), i use the uhd_find_devices and i can find the
> > usrp e310 devices, but when i use the uhd_usrp_probe, it came out the error
> > message "Error: e300_remote_codec_ctrl_impl trancation failed". Pls help
> > check it. Thank you in advance.
> >
> > the version of uhd installed in the host pc is 3.8.2-151-gbf4f50de.
> >
> > Best Regards,
> >
> > Xinke
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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/20150416/c8001d7c/attachment-0001.html>
------------------------------
Message: 10
Date: Thu, 16 Apr 2015 07:13:38 +0200
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: "'Martin Braun'" <[email protected]>,
<[email protected]>, "'GNU Radio Discussion List'"
<[email protected]>
Subject: Re: [USRP-users] [Discuss-gnuradio] New UHD seems to break a
lot...
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Due to a mistake I lost this copy of the VM yesterday :/ I try to reproduce
the issues this evening, I am traveling, so lots of time in the evening, but
no test equipment. Hopefully the hotel TV set will do DVB-T :) Otherwise it
will have to wait for the weekend...
Ralph.
-----Original Message-----
From: Martin Braun [mailto:[email protected]]
Sent: Wednesday, April 15, 2015 21:14
To: Ralph A. Schmid, dk5ras; [email protected]; 'GNU Radio
Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
master works, but RC1 does not? Huh, I'm confused now. Can you give some
detail on what's going on, so we can try and reproduce this?
Thanks,
Martin
On 15.04.2015 12:52, Ralph A. Schmid, dk5ras wrote:
> RC1, master seems to work.
>
> Ralph.
>
> -----Original Message-----
> From: Martin Braun [mailto:[email protected]]
> Sent: Wednesday, April 15, 2015 15:44
> To: Ralph A. Schmid, dk5ras; [email protected]; 'GNU Radio
> Discussion List'
> Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
>
> Thanks, Ralph. Just to clarify: When you say 'New UHD', do you mean
> 3.8.3-RC1, or latest master?
>
> Martin
>
> On 15.04.2015 08:40, Ralph A. Schmid, dk5ras wrote:
>> It is a B210, but as a note, due to the up to now missing FPGA images
>> I used 003.008.003-RC1, not the latest master. Still I had no access
>> to a spectrum and DVB-T analyzer, so I have no idea what is
>> happening, I just can confirm that RF is transmitted, and the
>> receiver doesn't get a picture, while with the snapshot of the same
>> VM before the upgrade
> is received without problems.
>> I will know more in about three hours.
>>
>> Ralph.
>>
>>> -----Original Message-----
>>> From: Martin Braun [mailto:[email protected]]
>>> Sent: Wednesday, April 15, 2015 3:15 PM
>>> To: Ralph A. Schmid, dk5ras; [email protected]; 'GNU Radio
>>> Discussion List'
>>> Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
>>>
>>> On 15.04.2015 06:20, Ralph A. Schmid, dk5ras wrote:
>>>> Hi,
>>>>
>>>> Not only OpenBTS is affected, also gr-dvbt/t2 do not work any more
>>>> with latest uhd. A quick check during lunch break showed, the
>>>> produced output is not decodable any more. I will take a closer
>>>> look this evening at home, where I have more and better equipment.
>>>
>>> Ralph,
>>>
>>> which device is this on?
>>>
>>> Thanks,
>>> Martin
>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150416/040c0582/attachment-0001.sig>
------------------------------
Message: 11
Date: Thu, 16 Apr 2015 10:37:24 +0200
From: "Jason A. Donenfeld" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] B210 over Network?
Message-ID:
<cahmme9r7_dymp4lhtl4qzqxwluowqbzb-+1j75fbxhxq-75...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi folks,
I've got a B210. I'm interested in putting it on a network, making it
accessible over TCP or UDP. The RTL project has rtl_tcp, which seems
to work well for those tiny adapters. UHD supports network connections
for other series of products that have integrated Ethernet
controllers. But I haven't been able to find anything that would
suffice for the B210. The end goal is to plug the B210 into a
sufficiently powerful USB3/GbE box (perhaps a NUC or some shiny 64bit
ARM hardware), and then be able to access it from anywhere in the lab,
using UHD.
Perhaps I missed a "usrp_network --start-listening" command somewhere?
Any pointers would be greatly appreciated.
Thanks,
Jason
------------------------------
Message: 12
Date: Thu, 16 Apr 2015 11:06:52 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] B210 over Network?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Jason,
UHD doesn't have built-in capabilities for that -- the USB and the
Network transports are just too different.
There's a lot of things you can do to work around that limitation.
For example, if you can live with "just" getting samples streamed
anywhere after setting everything up (ie. no changing frequency, gain,
sampling rate etc later on), try the rx_samples_to_udp example that
comes with UHD [1]. If you have UHD installed, it's probably already
somewhere like /usr[/local/]/lib/uhd/examples.
Of course, that will just give you raw samples, but no control backchannel.
If you need that, you could try building your own gr-uhd-based GNU Radio
flow graph, with XML-RPC, and implement as much as you need in RPC
calls. That's still no direct UHD interface.
No matter how you solve this:
Gigabit Ethernet limits your sampling rate, effectively by enforcing
that the samples need to fit through the network cable.
Assuming you'd typically stuff 16bit-sampled values into your packets,
that upper limit would be
1e9 bit/s / (16bit I + 16 bit Q) = (1e9/32) Hz , assuming there was
absolutely zero overhead. This further illustrates why we can't simply
take the USB packets and transport them over ethernet -- managing the
overhead of the much smaller USB packets, together with the much higher
roundtrip time, would make UHD impractical.
I think the key to finding the right solution for your lab here is
knowing what you want a little better; if you, for example, just want to
plot spectrum from across the room, having a sufficiently powerful PC
with GNU Radio, doing all the calculation and just sending as little
data as necessary across the network might be the key. If you need full
interactivity, things are going to get a lot more application-specific.
You'll want to split your application into something like a
low-latency/hardware-related part, running on the computer connected
directly to the B210, and a higher-level logical/signal processing part,
running anywhere. An example of that architecture is OpenBTS, with its
transceiver modules actually being more or less separate from the whole
"how to run a GSM base station" logic.
Greetings,
Marcus
[1]https://github.com/EttusResearch/uhd/tree/master/host/examples
On 04/16/2015 10:37 AM, Jason A. Donenfeld via USRP-users wrote:
> Hi folks,
>
> I've got a B210. I'm interested in putting it on a network, making it
> accessible over TCP or UDP. The RTL project has rtl_tcp, which seems
> to work well for those tiny adapters. UHD supports network connections
> for other series of products that have integrated Ethernet
> controllers. But I haven't been able to find anything that would
> suffice for the B210. The end goal is to plug the B210 into a
> sufficiently powerful USB3/GbE box (perhaps a NUC or some shiny 64bit
> ARM hardware), and then be able to access it from anywhere in the lab,
> using UHD.
>
> Perhaps I missed a "usrp_network --start-listening" command somewhere?
>
> Any pointers would be greatly appreciated.
>
> Thanks,
> Jason
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 13
Date: Thu, 16 Apr 2015 08:43:37 -0400
From: Philip Balister <[email protected]>
To: Xinke Zhang <[email protected]>, Moritz Fischer
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] ERROR: USRP E310 Network mode
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 04/15/2015 09:34 PM, Xinke Zhang via USRP-users wrote:
>
> Hi Moritz,
>
> Thank you.
>
> I used the e310 sdk toolchain to build the uhd source codes in the host pc,
> and then transfer the built binary to the e310 device. However, i need to
> copy the seperate built binary into its corresponding directory. is there any
> automatic solution to update the uhd in the e310 device? Thanks.
UHD on the latest set of test images is uhd-3.8.3-rc1. You do not need
to update it.
You do need to install 3.8.3-rc1 on the PC you are running network mode
from.
Philip
>
> Best Regards,
>
> Xinke
>
>> -----Original Messages-----
>> From: "Moritz Fischer" <[email protected]>
>> Sent Time: Thursday, April 16, 2015
>> To: "Xinke Zhang" <[email protected]>
>> Cc: "[email protected]" <[email protected]>
>> Subject: Re: [USRP-users] ERROR: USRP E310 Network mode
>>
>> Hi Xinke,
>>
>> When upgrading your device UHD you also need to upgrade your host UHD.
>> The current dizzy-test images are build from the 3.8.3-RC1 tag. Make
>> sure you build off of that.
>> Also note that you'll need to run uhd_images_downloader to get the
>> correct fpga image in place on the device.
>>
>> Cheers,
>>
>> Moritz
>>
>> On Tue, Apr 14, 2015 at 9:44 PM, Xinke Zhang via USRP-users
>> <[email protected]> wrote:
>>>
>>> Hi,
>>>
>>> I'm using the usrp e310, and reburn the sd card with
>>> http://files.ettus.com/e3xx_images/beta/dizzy-test/sdimage-gnuradio-demo.direct.xz.
>>> when configuring the usrp e310 as network mode (config the ip addr and start
>>> the usrp_e3x0_network_mode), i use the uhd_find_devices and i can find the
>>> usrp e310 devices, but when i use the uhd_usrp_probe, it came out the error
>>> message "Error: e300_remote_codec_ctrl_impl trancation failed". Pls help
>>> check it. Thank you in advance.
>>>
>>> the version of uhd installed in the host pc is 3.8.2-151-gbf4f50de.
>>>
>>> Best Regards,
>>>
>>> Xinke
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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: 14
Date: Thu, 16 Apr 2015 06:19:15 +0000 (UTC)
From: mojtaba rostami <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] ZPU Interrupt Service Routine(ISR)
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi ,How can i write an ISR in ZPU C code?
For example i connected a signal that generate a rising edge every second?to
bit 0 of irq bus of pic module, now in c code of ZPU how can i detect and
handle it?
Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150416/2ebaf0bc/attachment-0001.html>
------------------------------
Message: 15
Date: Thu, 16 Apr 2015 17:08:14 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Rx/Tx Loopback
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Rob, hi crowd,
just a notification: we discussed a fix that you verified, namely,
making the usrp_sink start to transmit just a bit later than the
usrp_source starts receiving (and not the other way around). Johnathan
has just merged that into maint, so it's kinda "mainline" now :)
Greetings,
Marcus
On 04/02/2015 07:37 PM, Rob Kossler via USRP-users wrote:
> I'm not much concerned with latency. My original goal with this
> flowgraph was to demonstrate RF channel modeling using multiple signal
> fading blocks in between the UHD source and sink. So, essentially
> there is some DSP to be applied to the data prior to retransmission.
> I figured that as long as the CPU DSP processing was fast enough at
> the given data rate, it would be able to supply samples to the sink as
> fast as needed. When this didn't work as expected, I simplified
> things to remove the fading blocks and just have the source and sink
> (which is the GRC file I previously attached).
>
> So, I think I can tolerate latency just fine. Perhaps I need to add a
> time constant to the metadata as Ian suggested and/or implement some
> type of buffering block in GRC to avoid Underruns. Let me know if
> anyone has ideas on this. My initial goal is to get this simple
> flowgraph working before reverting back to adding fading blocks or
> other processing.
>
> Rob
>
>
>
> On Thu, Apr 2, 2015 at 12:31 PM, Ian Buckley <[email protected]
> <mailto:[email protected]>> wrote:
>
> So this is an interesting one, and a little unexpected for me, but
> I think I know whats happening.
> First off I reproduced this exactly as Rob described using B210,
> so it's symptomatic of UHD in general rather than X310 specific.
> When data is RX'ed on a USRP every UHD packet contains vita time
> metadata in the header that identifies the timestamp with which
> the first sample in the packet was received.
> Now note that the TX returns "L" as the error, not "U"?so it's not
> underflowing whilst TX streaming, its rejecting TX UHD packets as
> having a timestamp thats in the past w.r.t the current vita time.
> (Note TX and RX within a USRP channel are sharing the same H/W
> vita time counter.)
>
> I believe that this flow graph causes the RX time stamps to be
> placed into the TX data stream as timestamps that are targets for
> transmission, and of course by definition they will always be in
> the past when they arrive at the TX DSP.
>
> Someone who is better at GR than me will probably know what block
> to pass this through to strip the metadata. So saying that I think
> that this style of simplistic flow graph is still doomed to not
> run reliably because being fed from a sample source thats forced
> to run in lockstep with the sample sink means that an adequate
> buffer of samples will never accumulate in the TX buffering of the
> USRP to absorb the inevitable jitter in data delivery from the
> host. Perhaps the way to do this is to add a constant time offset
> to all the RX timestamps that will force some buffering in H/W(If
> Robs goal is minimal latency this might be less than useful for him?)
>
> -Ian
>
> On Apr 2, 2015, at 7:51 AM, Marcus D. Leech via USRP-users
> <[email protected] <mailto:[email protected]>>
> wrote:
>
>> Well, I wonder if our gr-uhd maintainer has a comment.
>>
>> This seems very odd to me, and perhaps there's a subtlety in the
>> way gr-uhd tries to be helpful and setup a bunch of stuff
>> involving sample timing automatically.
>>
>>
>>
>>
>>
>> On 2015-04-02 10:28, Rob Kossler wrote:
>>
>>> On Wed, Apr 1, 2015 at 11:45 PM, Marcus D. Leech
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>> On 04/01/2015 11:41 PM, Rob Kossler wrote:
>>>>
>>>>
>>>>
>>>> Yes, those are the sync options. Since there is only one
>>>> device, I only selected "unknown PPS" for one of the two
>>>> streamers. Is that correct?
>>>> Rob
>>> That would be correct for a device that had 1PPS. I don't
>>> recall whether X3xx has a "fake" internal 1PPS signal or
>>> not. Since this is a single device
>>> at this point, just choose "don't sync" for both of them.
>>>
>>>
>>> I tried "don't sync" for both as well as putting constant
>>> multiply blocks in between the source / sink. Neither seems to
>>> fix my "Late" issue. However, if I exit GRC and simply run
>>> benchmark_rate in full duplex, it has no issues even at higher
>>> sample rates.
>>>
>>> Attached are 3 files: the modified GRC flowgraph as well as two
>>> text files showing the results obtained when running this
>>> flowgraph from GRC as compared to running benchmark_rate. The
>>> flowgraph sample rate is 1 MS/s while the benchmark_rate is
>>> running at 10 MS/s (BTW, it also runs fine at 1MS/s).
>>>
>>> Rob
>>>
>>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150416/ce9b1733/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 56, Issue 16
******************************************
