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: usrp_e driver (Philip Balister)
2. Re: Fwd: USRP N210 using code without console output. (Josh Blum)
3. Re: FPGA and FW update of N210 (Farhad Abdolian)
4. Re: FPGA and FW update of N210 (Marcus D. Leech)
5. Re: FPGA and FW update of N210 (Farhad Abdolian)
6. Re: FPGA and FW update of N210 (Marcus D. Leech)
7. FW and FPGA images (Nowlan, Sean)
8. E100 overflow behaviour (Thomas Tsou)
9. Re: FW and FPGA images (Josh Blum)
10. Re: E100 overflow behaviour (Josh Blum)
11. Re: E100 overflow behaviour (Thomas Tsou)
12. Re: E100 overflow behaviour (Josh Blum)
13. Re: FW and FPGA images (Nowlan, Sean)
14. Re: FW and FPGA images (Josh Blum)
15. Re: E100 overflow behaviour (Thomas Tsou)
16. Re: E100 overflow behaviour (Josh Blum)
17. Re: E100 overflow behaviour (Thomas Tsou)
18. problem Communication between 2 USRP1 (vegihat vegihat)
----------------------------------------------------------------------
Message: 1
Date: Mon, 09 Apr 2012 10:16:22 -0700
From: Philip Balister <[email protected]>
To: Ahmed Alsawi <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] usrp_e driver
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 04/08/2012 12:33 PM, Ahmed Alsawi wrote:
> Dear all,
> i am working on E100, My application is to send raw bytes to FPGA and
> receive it back,,,
> I know i will use the driver directly ... Did anyone try working on the
> driver ?
>
> - I tried to read host/usrp_e_utils/usrp-e-loopback.cpp ,,,,
> it referenced macros written in the uhd which i don't fully understand.
> it uses ioctl to pass the data to driver ,, shall i use the same way?
Take a look at:
uhd/host/lib/usrp/e100/e100_mmap_zero_copy.cpp
The data transfer is done via a mmaped buffer. So you will not see lots
of calls to the read/write. poll is used to test for data
available/space available.
Philip
------------------------------
Message: 2
Date: Mon, 09 Apr 2012 10:33:24 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Fwd: USRP N210 using code without console
output.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
On 04/09/2012 02:39 AM, Andrey Krasheninnikov wrote:
>
>
>
> -------- ???????????? ????????? --------
> ?? ????: Andrey Krasheninnikov <[email protected]>
> ????: [email protected]
> ????: Tue, 03 Apr 2012 13:32:13 +0400
> ????: USRP N210 using code without console output.
>
>
>
> In Windows I would like to use uhd.dll with GUI application without
> output to console. Can I disable output to console (don't use instruction
> "cout" and "cerr") for USRP N210?
>
>
See
http://files.ettus.com/uhd_docs/manual/html/general.html#disabling-or-redirecting-prints-to-stdout
-josh
> Yours faithfully A.Krasheninnnikov
>
> ----------------------------------------------------------------------
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 3
Date: Mon, 9 Apr 2012 11:32:03 -0700 (PDT)
From: Farhad Abdolian <[email protected]>
To: Orkhan Badirkhanli <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] FPGA and FW update of N210
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
Today I found my old USRP1 and it works without any problem, I have problem
with USRP N210 and no matter what I do, none of the 2 units I have being
recognized by my laptop.
For now I am OK, I have to deliver the code I am working on and I can do this
with USRP1 instead of USRP2, I not need the extra functionality of the N210.
Maybe after my deadline, I can have time to go back and fix this problem but
for now, I am shelving both of them and use the old unit.
Best regards,
Farhad
>________________________________
> From: Orkhan Badirkhanli <[email protected]>
>To: Farhad Abdolian <[email protected]>
>Cc: "[email protected]" <[email protected]>
>Sent: Thursday, April 5, 2012 10:45 PM
>Subject: Re: [USRP-users] FPGA and FW update of N210
>
>
>Farhad
>
>I had very similar problem when I first connected the usrp. I was getting ping
>responses but uhd_find_devices and other similar functions did not work. I
>simply burned fw and fpga images again and the problem resolved.
>
>Did you have any luck with burning fpga and fw images?
>
>
>On Thu, Apr 5, 2012 at 11:17 PM, Farhad Abdolian <[email protected]> wrote:
>
>HI John,
>>I did and the results are the same:
>>
>>
>>
>>linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.004.000-32-g51c81a39
>>
>>Error: LookupError: KeyError: No devices found for ----->
>>Empty Device Address
>>
>>
>>And uhd_find_devices gives
>>
>>
>>linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.004.000-32-g51c81a39
>>No UHD Devices Found
>>
>>
>>I am getting frustrated, the ping works without any problems:
>>ping 192.168.10.2
>>PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data.
>>64 bytes from 192.168.10.2: icmp_seq=1 ttl=64 time=0.069 ms
>>64 bytes from 192.168.10.2: icmp_seq=2 ttl=64 time=0.060 ms
>>64 bytes from 192.168.10.2: icmp_seq=3 ttl=64 time=0.058 ms
>>64 bytes from 192.168.10.2: icmp_seq=4 ttl=64 time=0.062 ms
>>^C
>>--- 192.168.10.2 ping statistics ---
>>4 packets transmitted, 4 received, 0% packet loss, time 3000ms
>>rtt min/avg/max/mdev = 0.058/0.062/0.069/0.007 ms
>>
>>
>>I have to figure out what the problem is!
>>BR,
>>Farhad
>>
>>
>>>________________________________
>>> From: Jonathan Fox <[email protected]>
>>>To: Farhad Abdolian <[email protected]>
>>>Cc: "[email protected]" <[email protected]>
>>>Sent: Thursday, April 5, 2012 3:42 PM
>>>
>>>Subject: Re: [USRP-users] FPGA and FW update of N210
>>>
>>>
>>>Farhad,
>>>
>>>Please try "uhd_usrp_probe".
>>>
>>>-Jon
>>>
>>>On 4/5/12, Farhad Abdolian <[email protected]> wrote:
>>>> Hi,
>>>> How
>>>>? do I know what revision my USRP N210 is? I am trying to update the FPGA
>>>>? image on the 2 USRPs I have and don't know which FPGA code to use.
>>>>
>>>> The problem I have is that I can not detect the USRPs using
>>>> uhd_find_devices.
>>>>
>>>> I can ping the USRP and I can upgrade the FW but I can not 'detect' it and
>>>> use it.
>>>>
>>>> Really appreciate your help,
>>>>
>>>> BR,
>>>> Farhad
>>>
>>>
>>>
>>_______________________________________________
>>USRP-users mailing list
>>[email protected]
>>http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
>--
>Orkhan
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120409/b8ad2cfc/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 09 Apr 2012 14:43:29 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] FPGA and FW update of N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 04/09/2012 02:32 PM, Farhad Abdolian wrote:
> Hi,
> Today I found my old USRP1 and it works without any problem, I have
> problem with USRP N210 and no matter what I do, none of the 2 units I
> have being recognized by my laptop.
>
> For now I am OK, I have to deliver the code I am working on and I can
> do this with USRP1 instead of USRP2, I not need the extra
> functionality of the N210.
>
> Maybe after my deadline, I can have time to go back and fix this
> problem but for now, I am shelving both of them and use the old unit.
>
> Best regards,
> Farhad
>
You're probably just running old firmware on the N210. Here are the
notes for programming new firmware:
http://files.ettus.com/uhd_docs/manual/html/usrp2.html#load-the-images-onto-the-on-board-flash-usrp-n-series-only
And images can be fetched from here:
http://files.ettus.com/binaries/uhd_stable/latest_release/uhd-images_003.004.000-release.tar.gz
> ------------------------------------------------------------------------
> *From:* Orkhan Badirkhanli <[email protected]>
> *To:* Farhad Abdolian <[email protected]>
> *Cc:* "[email protected]" <[email protected]>
> *Sent:* Thursday, April 5, 2012 10:45 PM
> *Subject:* Re: [USRP-users] FPGA and FW update of N210
>
> Farhad
>
> I had very similar problem when I first connected the usrp. I was
> getting ping responses but uhd_find_devices and other similar
> functions did not work. I simply burned fw and fpga images again
> and the problem resolved.
>
> Did you have any luck with burning fpga and fw images?
>
> On Thu, Apr 5, 2012 at 11:17 PM, Farhad Abdolian
> <[email protected] <mailto:[email protected]>> wrote:
>
> HI John,
> I did and the results are the same:
>
> linux; GNU C++ version 4.4.3; Boost_104000;
> UHD_003.004.000-32-g51c81a39
>
> Error: LookupError: KeyError: No devices found for ----->
> Empty Device Address
>
> And uhd_find_devices gives
>
> linux; GNU C++ version 4.4.3; Boost_104000;
> UHD_003.004.000-32-g51c81a39
> No UHD Devices Found
>
> I am getting frustrated, the ping works without any problems:
> ping 192.168.10.2
> PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data.
> 64 bytes from 192.168.10.2 <http://192.168.10.2>: icmp_seq=1
> ttl=64 time=0.069 ms
> 64 bytes from 192.168.10.2 <http://192.168.10.2>: icmp_seq=2
> ttl=64 time=0.060 ms
> 64 bytes from 192.168.10.2 <http://192.168.10.2>: icmp_seq=3
> ttl=64 time=0.058 ms
> 64 bytes from 192.168.10.2 <http://192.168.10.2>: icmp_seq=4
> ttl=64 time=0.062 ms
> ^C
> --- 192.168.10.2 ping statistics ---
> 4 packets transmitted, 4 received, 0% packet loss, time 3000ms
> rtt min/avg/max/mdev = 0.058/0.062/0.069/0.007 ms
>
> I have to figure out what the problem is!
> BR,
> Farhad
>
>
> ------------------------------------------------------------------------
> *From:* Jonathan Fox <[email protected]
> <mailto:[email protected]>>
> *To:* Farhad Abdolian <[email protected]
> <mailto:[email protected]>>
> *Cc:* "[email protected]
> <mailto:[email protected]>"
> <[email protected]
> <mailto:[email protected]>>
> *Sent:* Thursday, April 5, 2012 3:42 PM
>
> *Subject:* Re: [USRP-users] FPGA and FW update of N210
>
> Farhad,
>
> Please try "uhd_usrp_probe".
>
> -Jon
>
> On 4/5/12, Farhad Abdolian <[email protected]
> <mailto:[email protected]>> wrote:
> > Hi,
> > How
> > do I know what revision my USRP N210 is? I am trying to
> update the FPGA
> > image on the 2 USRPs I have and don't know which FPGA
> code to use.
> >
> > The problem I have is that I can not detect the USRPs using
> > uhd_find_devices.
> >
> > I can ping the USRP and I can upgrade the FW but I can
> not 'detect' it and
> > use it.
> >
> > Really appreciate your help,
> >
> > BR,
> > Farhad
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> --
> Orkhan
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120409/fade4d9e/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 9 Apr 2012 12:59:42 -0700 (PDT)
From: Farhad Abdolian <[email protected]>
To: "Marcus D. Leech" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] FPGA and FW update of N210
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi Marcus,
No, I actually managed to upgrade both the FW and the FPGA code of the USRPs I
have, but the problem is still the same, I can ping the unit but I could never
detect it. I am afraid the problem is with my PC rather than with the USRP, and
right now I don't have time to solve this.
Best regards,
Farhad
>________________________________
> From: Marcus D. Leech <[email protected]>
>To: [email protected]
>Sent: Monday, April 9, 2012 8:43 PM
>Subject: Re: [USRP-users] FPGA and FW update of N210
>
>
>On 04/09/2012 02:32 PM, Farhad Abdolian wrote:
>Hi,
>>Today I found my old USRP1 and it works without any problem, I have problem
>>with USRP N210 and no matter what I do, none of the 2 units I have being
>>recognized by my laptop.
>>
>>
>>For now I am OK, I have to deliver the code I am working on and I can do this
>>with USRP1 instead of USRP2, I not need the extra functionality of the N210.
>>
>>
>>
>>Maybe after my deadline, I can have time to go back and fix this problem but
>>for now, I am shelving both of them and use the old unit.
>>
>>
>>Best regards,
>>Farhad
>>
>>
You're probably just running old firmware on the N210.? Here are the notes for
programming new firmware:
>
>http://files.ettus.com/uhd_docs/manual/html/usrp2.html#load-the-images-onto-the-on-board-flash-usrp-n-series-only
>
>And images can be fetched from here:
>
>http://files.ettus.com/binaries/uhd_stable/latest_release/uhd-images_003.004.000-release.tar.gz
>
>
>
>
>>>________________________________
>>> From: Orkhan Badirkhanli <[email protected]>
>>>To: Farhad Abdolian <[email protected]>
>>>Cc: "[email protected]" <[email protected]>
>>>Sent: Thursday, April 5, 2012 10:45 PM
>>>Subject: Re: [USRP-users] FPGA and FW update of N210
>>>
>>>
>>>Farhad
>>>
>>>I had very similar problem when I first connected the
usrp. I was getting ping responses but
uhd_find_devices and other similar functions did not
work. I simply burned fw and fpga images again and the
problem resolved.
>>>
>>>Did you have any luck with burning fpga and fw images?
>>>
>>>
>>>On Thu, Apr 5, 2012 at 11:17 PM, Farhad Abdolian <[email protected]>
>>>wrote:
>>>
>>>HI John,
>>>>I did and the results are the same:
>>>>
>>>>
>>>>
>>>>linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.004.000-32-g51c81a39
>>>>
>>>>Error: LookupError: KeyError: No devices
found for ----->
>>>>Empty Device Address
>>>>
>>>>
>>>>And uhd_find_devices gives
>>>>
>>>>
>>>>linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.004.000-32-g51c81a39
>>>>No UHD Devices Found
>>>>
>>>>
>>>>I am getting frustrated, the ping works without any problems:
>>>>ping 192.168.10.2
>>>>PING 192.168.10.2 (192.168.10.2) 56(84)
bytes of data.
>>>>64 bytes from 192.168.10.2: icmp_seq=1 ttl=64 time=0.069 ms
>>>>64 bytes from 192.168.10.2: icmp_seq=2 ttl=64 time=0.060 ms
>>>>64 bytes from 192.168.10.2: icmp_seq=3 ttl=64 time=0.058 ms
>>>>64 bytes from 192.168.10.2: icmp_seq=4 ttl=64 time=0.062 ms
>>>>^C
>>>>--- 192.168.10.2 ping statistics ---
>>>>4 packets transmitted, 4 received, 0% packet
loss, time 3000ms
>>>>rtt min/avg/max/mdev =
0.058/0.062/0.069/0.007 ms
>>>>
>>>>
>>>>I have to figure out what the problem is!
>>>>BR,
>>>>Farhad
>>>>
>>>>
>>>>>________________________________
>>>>> From: Jonathan Fox <[email protected]>
>>>>>To: Farhad Abdolian <[email protected]>
>>>>>Cc: "[email protected]" <[email protected]>
>>>>>Sent: Thursday, April 5, 2012 3:42 PM
>>>>>
>>>>>Subject: Re: [USRP-users] FPGA and FW update of N210
>>>>>
>>>>>
>>>>>Farhad,
>>>>>
>>>>>Please try "uhd_usrp_probe".
>>>>>
>>>>>-Jon
>>>>>
>>>>>On 4/5/12, Farhad Abdolian <[email protected]> wrote:
>>>>>> Hi,
>>>>>> How
>>>>>>? do I know what revision my
USRP N210 is? I am trying to update
the FPGA
>>>>>>? image on the 2 USRPs I have
and don't know which FPGA code to
use.
>>>>>>
>>>>>> The problem I have is that I
can not detect the USRPs using
>>>>>> uhd_find_devices.
>>>>>>
>>>>>> I can ping the USRP and I can
upgrade the FW but I can not
'detect' it and
>>>>>> use it.
>>>>>>
>>>>>> Really appreciate your help,
>>>>>>
>>>>>> BR,
>>>>>> Farhad
>>>>>
>>>>>
>>>>>
>>>>_______________________________________________
>>>>USRP-users mailing list
>>>>[email protected]
>>>>http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>
>>>
>>>--
>>>Orkhan
>>>
>>>
>>>
>>
_______________________________________________
USRP-users mailing list [email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
>_______________________________________________
>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/20120409/fc114554/attachment-0001.html>
------------------------------
Message: 6
Date: Mon, 09 Apr 2012 16:01:49 -0400
From: "Marcus D. Leech" <[email protected]>
To: Farhad Abdolian <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] FPGA and FW update of N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 04/09/2012 03:59 PM, Farhad Abdolian wrote:
> Hi Marcus,
> No, I actually managed to upgrade both the FW and the FPGA code of the
> USRPs I have, but the problem is still the same, I can ping the unit
> but I could never detect it. I am afraid the problem is with my PC
> rather than with the USRP, and right now I don't have time to solve this.
>
> Best regards,
> Farhad
If you:
uhd_usrp_probe --args "addr=192.168.10.2"
Rather than relying on the autodiscovery, what happens?
Are you trying to use the N210 on a network segment that is perhaps
shared with other devices (computers, etc) that might have the same
address? Is the networking on your PC setup correctly? See here:
http://files.ettus.com/uhd_docs/manual/html/usrp2.html#setup-networking
> ------------------------------------------------------------------------
> *From:* Marcus D. Leech <[email protected]>
> *To:* [email protected]
> *Sent:* Monday, April 9, 2012 8:43 PM
> *Subject:* Re: [USRP-users] FPGA and FW update of N210
>
> On 04/09/2012 02:32 PM, Farhad Abdolian wrote:
>> Hi,
>> Today I found my old USRP1 and it works without any problem, I
>> have problem with USRP N210 and no matter what I do, none of the
>> 2 units I have being recognized by my laptop.
>>
>> For now I am OK, I have to deliver the code I am working on and I
>> can do this with USRP1 instead of USRP2, I not need the extra
>> functionality of the N210.
>>
>> Maybe after my deadline, I can have time to go back and fix this
>> problem but for now, I am shelving both of them and use the old unit.
>>
>> Best regards,
>> Farhad
>>
> You're probably just running old firmware on the N210. Here are
> the notes for programming new firmware:
>
>
> http://files.ettus.com/uhd_docs/manual/html/usrp2.html#load-the-images-onto-the-on-board-flash-usrp-n-series-only
>
> And images can be fetched from here:
>
>
> http://files.ettus.com/binaries/uhd_stable/latest_release/uhd-images_003.004.000-release.tar.gz
>
>
>>
>> ------------------------------------------------------------------------
>> *From:* Orkhan Badirkhanli <[email protected]>
>> <mailto:[email protected]>
>> *To:* Farhad Abdolian <[email protected]>
>> <mailto:[email protected]>
>> *Cc:* "[email protected]"
>> <mailto:[email protected]>
>> <[email protected]> <mailto:[email protected]>
>> *Sent:* Thursday, April 5, 2012 10:45 PM
>> *Subject:* Re: [USRP-users] FPGA and FW update of N210
>>
>> Farhad
>>
>> I had very similar problem when I first connected the usrp. I
>> was getting ping responses but uhd_find_devices and other
>> similar functions did not work. I simply burned fw and fpga
>> images again and the problem resolved.
>>
>> Did you have any luck with burning fpga and fw images?
>>
>> On Thu, Apr 5, 2012 at 11:17 PM, Farhad Abdolian
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> HI John,
>> I did and the results are the same:
>>
>> linux; GNU C++ version 4.4.3; Boost_104000;
>> UHD_003.004.000-32-g51c81a39
>>
>> Error: LookupError: KeyError: No devices found for ----->
>> Empty Device Address
>>
>> And uhd_find_devices gives
>>
>> linux; GNU C++ version 4.4.3; Boost_104000;
>> UHD_003.004.000-32-g51c81a39
>> No UHD Devices Found
>>
>> I am getting frustrated, the ping works without any problems:
>> ping 192.168.10.2
>> PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data.
>> 64 bytes from 192.168.10.2 <http://192.168.10.2>:
>> icmp_seq=1 ttl=64 time=0.069 ms
>> 64 bytes from 192.168.10.2 <http://192.168.10.2>:
>> icmp_seq=2 ttl=64 time=0.060 ms
>> 64 bytes from 192.168.10.2 <http://192.168.10.2>:
>> icmp_seq=3 ttl=64 time=0.058 ms
>> 64 bytes from 192.168.10.2 <http://192.168.10.2>:
>> icmp_seq=4 ttl=64 time=0.062 ms
>> ^C
>> --- 192.168.10.2 ping statistics ---
>> 4 packets transmitted, 4 received, 0% packet loss, time
>> 3000ms
>> rtt min/avg/max/mdev = 0.058/0.062/0.069/0.007 ms
>>
>> I have to figure out what the problem is!
>> BR,
>> Farhad
>>
>>
>> ------------------------------------------------------------------------
>> *From:* Jonathan Fox <[email protected]
>> <mailto:[email protected]>>
>> *To:* Farhad Abdolian <[email protected]
>> <mailto:[email protected]>>
>> *Cc:* "[email protected]
>> <mailto:[email protected]>"
>> <[email protected]
>> <mailto:[email protected]>>
>> *Sent:* Thursday, April 5, 2012 3:42 PM
>>
>> *Subject:* Re: [USRP-users] FPGA and FW update of N210
>>
>> Farhad,
>>
>> Please try "uhd_usrp_probe".
>>
>> -Jon
>>
>> On 4/5/12, Farhad Abdolian <[email protected]
>> <mailto:[email protected]>> wrote:
>> > Hi,
>> > How
>> > do I know what revision my USRP N210 is? I am
>> trying to update the FPGA
>> > image on the 2 USRPs I have and don't know which
>> FPGA code to use.
>> >
>> > The problem I have is that I can not detect the
>> USRPs using
>> > uhd_find_devices.
>> >
>> > I can ping the USRP and I can upgrade the FW but I
>> can not 'detect' it and
>> > use it.
>> >
>> > Really appreciate your help,
>> >
>> > BR,
>> > Farhad
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> <mailto:[email protected]>
>>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>>
>> --
>> Orkhan
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120409/60824b34/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 9 Apr 2012 23:07:51 +0000
From: "Nowlan, Sean" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] FW and FPGA images
Message-ID: <195933287DC65748BA7AE867BA8E430B62177FA2@apatlisdmbx02>
Content-Type: text/plain; charset="us-ascii"
I have some code already running in production using UHD commit eb11b052
downloaded 15-NOV-2011 at 21:20:29 UTC. I'm trying to find the corresponding FW
and FPGA images (which I apparently didn't back up). Unfortunately they're not
from an actual release, so they're not up on files.ettus.com. If anybody at
Ettus has a chance, could you send me these files? I have an N200 Rev.4. Thanks!
My other option is to upgrade UHD to an actual release, but I don't want to
risk breaking my production setup.
Thanks,
Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120409/308e01c5/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 9 Apr 2012 18:45:05 -0400
From: Thomas Tsou <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] E100 overflow behaviour
Message-ID:
<CAF5FEsDFi=EbnxSpirBiAOnsf3jbRUZ3u66B4rPWv=vcfrk...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
There have been a few reports of odd, overflow related errors in kal.
These errors occur because rx_streamer::recv() returns less than the
number of samples specified, which kal considers an error, but the
receive metadata states no such condition. As it turns out, this
behaviour occurs with rx_timed_samples too.
With the e1xx-003 image, rx_timed_samples consistently generates the
following output where a 28 sample packet arrives _before_ the
overflow is reported. AFAIK, this partial packet does not appear on
USRP2 or with earlier releases.
Is this to be expected behaviour with 003.004.000 and future releases?
or is this a bug?
# /usr/share/uhd/examples/rx_timed_samples --rate 6.4e6 --nsamps 1000000
linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500;
UHD_003.004.000-0-unknown
Creating the usrp device with: ...
-- Opening device node /dev/usrp_e0...
-- Initializing FPGA clock to 64.000000MHz...
-- USRP-E100 clock control: 10
-- r_counter: 2
-- a_counter: 0
-- b_counter: 20
-- prescaler: 8
-- vco_divider: 5
-- chan_divider: 5
-- vco_rate: 1600.000000MHz
-- chan_rate: 320.000000MHz
-- out_rate: 64.000000MHz
--
-- Performing wishbone readback test... pass
Using Device: Single USRP:
Device: E-Series Device
Mboard 0: E100 (euewanee)
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: WBX RX v2 + Simple GDB
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: WBX TX v2 + Simple GDB
Setting RX Rate: 6.400000 Msps...
Actual RX Rate: 6.400000 Msps...
Setting device timestamp to 0...
Begin streaming 1000000 samples, 1.500000 seconds in the future...
Received packet: 507 samples, 1 full secs, 0.500000 frac secs
Received packet: 507 samples, 1 full secs, 0.500080 frac secs
Received packet: 507 samples, 1 full secs, 0.500159 frac secs
...
Received packet: 507 samples, 1 full secs, 0.556959 frac secs
Received packet: 507 samples, 1 full secs, 0.557038 frac secs
Received packet: 28 samples, 1 full secs, 0.557117 frac secs
OError: Unexpected error code 0x8
Thomas
------------------------------
Message: 9
Date: Mon, 09 Apr 2012 16:17:52 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] FW and FPGA images
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 04/09/2012 04:07 PM, Nowlan, Sean wrote:
> I have some code already running in production using UHD commit
> eb11b052 downloaded 15-NOV-2011 at 21:20:29 UTC. I'm trying to find
> the corresponding FW and FPGA images (which I apparently didn't back
> up). Unfortunately they're not from an actual release, so they're not
> up on files.ettus.com. If anybody at Ettus has a chance, could you
> send me these files? I have an N200 Rev.4. Thanks!
>
I put the older images into a folder with the date that I replaced them.
So, some files shuffled around recently, but they are still around. Take
a look here: http://files.ettus.com/binaries/master_images/old/older/
-josh
------------------------------
Message: 10
Date: Mon, 09 Apr 2012 16:27:20 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] E100 overflow behaviour
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 04/09/2012 03:45 PM, Thomas Tsou wrote:
> There have been a few reports of odd, overflow related errors in kal.
> These errors occur because rx_streamer::recv() returns less than the
> number of samples specified, which kal considers an error, but the
> receive metadata states no such condition. As it turns out, this
> behaviour occurs with rx_timed_samples too.
>
So thats is correct behavior for an overflow on a device that has RX
back-pressure (b100/e100). But it obviously should not be overflowing so
soon.
Is this using the new streamer API?
If not, I believe you are seeing a bug where the DSP gets inadvertently
cleared on the first call to recv(INT16). The problem is that the stream
command gets canceled. This is fixed here, please give these images a
try: http://files.ettus.com/tmp/
-josh
> With the e1xx-003 image, rx_timed_samples consistently generates the
> following output where a 28 sample packet arrives _before_ the
> overflow is reported. AFAIK, this partial packet does not appear on
> USRP2 or with earlier releases.
>
> Is this to be expected behaviour with 003.004.000 and future releases?
> or is this a bug?
>
> # /usr/share/uhd/examples/rx_timed_samples --rate 6.4e6 --nsamps 1000000
> linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500;
> UHD_003.004.000-0-unknown
>
> Creating the usrp device with: ...
> -- Opening device node /dev/usrp_e0...
> -- Initializing FPGA clock to 64.000000MHz...
> -- USRP-E100 clock control: 10
> -- r_counter: 2
> -- a_counter: 0
> -- b_counter: 20
> -- prescaler: 8
> -- vco_divider: 5
> -- chan_divider: 5
> -- vco_rate: 1600.000000MHz
> -- chan_rate: 320.000000MHz
> -- out_rate: 64.000000MHz
------------------------------
Message: 11
Date: Mon, 9 Apr 2012 19:40:58 -0400
From: Thomas Tsou <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] E100 overflow behaviour
Message-ID:
<caf5fesdhuffzfrgq8ygcphyn4obm6vrpeocinrzrghhesjq...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Apr 9, 2012 at 7:27 PM, Josh Blum <[email protected]> wrote:
>
> On 04/09/2012 03:45 PM, Thomas Tsou wrote:
>> There have been a few reports of odd, overflow related errors in kal.
>> These errors occur because rx_streamer::recv() returns less than the
>> number of samples specified, which kal considers an error, but the
>> receive metadata states no such condition. As it turns out, this
>> behaviour occurs with rx_timed_samples too.
>>
>
> So thats is correct behavior for an overflow on a device that has RX
> back-pressure (b100/e100). But it obviously should not be overflowing so
> soon.
>
> Is this using the new streamer API?
> If not, I believe you are seeing a bug where the DSP gets inadvertently
> cleared on the first call to recv(INT16). The problem is that the stream
> command gets canceled. This is fixed here, please give these images a
> try: http://files.ettus.com/tmp/
This occurs with the streamer api and the shipping rx_timed_samples.
So, absent of timeout or overrun conditions, returning less samples
than requested is expected behaviour? I can deal with that, but my
assumptions were based on comments from the streamer receive api.
* This is a blocking call and will not return until the number
* of samples returned have been written into each buffer.
* Under a timeout condition, the number of samples returned
* may be less than the number of samples specified.
Thomas
------------------------------
Message: 12
Date: Mon, 09 Apr 2012 16:55:54 -0700
From: Josh Blum <[email protected]>
To: Thomas Tsou <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] E100 overflow behaviour
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 04/09/2012 04:40 PM, Thomas Tsou wrote:
> On Mon, Apr 9, 2012 at 7:27 PM, Josh Blum <[email protected]> wrote:
>>
>> On 04/09/2012 03:45 PM, Thomas Tsou wrote:
>>> There have been a few reports of odd, overflow related errors in kal.
>>> These errors occur because rx_streamer::recv() returns less than the
>>> number of samples specified, which kal considers an error, but the
>>> receive metadata states no such condition. As it turns out, this
>>> behaviour occurs with rx_timed_samples too.
>>>
>>
>> So thats is correct behavior for an overflow on a device that has RX
>> back-pressure (b100/e100). But it obviously should not be overflowing so
>> soon.
>>
>> Is this using the new streamer API?
>> If not, I believe you are seeing a bug where the DSP gets inadvertently
>> cleared on the first call to recv(INT16). The problem is that the stream
>> command gets canceled. This is fixed here, please give these images a
>> try: http://files.ettus.com/tmp/
>
> This occurs with the streamer api and the shipping rx_timed_samples.
>
> So, absent of timeout or overrun conditions, returning less samples
> than requested is expected behaviour? I can deal with that, but my
> assumptions were based on comments from the streamer receive api.
>
> * This is a blocking call and will not return until the number
> * of samples returned have been written into each buffer.
> * Under a timeout condition, the number of samples returned
> * may be less than the number of samples specified.
>
Correct.
It might just be that you are really seeing an overflow. You have the
sample rate up pretty high, and its converting the samples to floats,
and printing on every packet.
Still, the same command is ok for balister. Perhaps some of the
optimization flags were missing during compile? If so, can you rebuild
and make sure the flags appear when you make VERBOSE=1?
-josh
------------------------------
Message: 13
Date: Mon, 9 Apr 2012 23:57:22 +0000
From: "Nowlan, Sean" <[email protected]>
To: "[email protected]" <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] FW and FPGA images
Message-ID: <195933287DC65748BA7AE867BA8E430B62177FF6@apatlisdmbx02>
Content-Type: text/plain; charset="us-ascii"
Thanks! Unfortunately I couldn't find that particular commit in any of those
folders. Would it be somewhere else?
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Josh Blum
Sent: Monday, April 09, 2012 7:18 PM
To: [email protected]
Subject: Re: [USRP-users] FW and FPGA images
On 04/09/2012 04:07 PM, Nowlan, Sean wrote:
> I have some code already running in production using UHD commit
> eb11b052 downloaded 15-NOV-2011 at 21:20:29 UTC. I'm trying to find
> the corresponding FW and FPGA images (which I apparently didn't back
> up). Unfortunately they're not from an actual release, so they're not
> up on files.ettus.com. If anybody at Ettus has a chance, could you
> send me these files? I have an N200 Rev.4. Thanks!
>
I put the older images into a folder with the date that I replaced them.
So, some files shuffled around recently, but they are still around. Take a look
here: http://files.ettus.com/binaries/master_images/old/older/
-josh
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 14
Date: Mon, 09 Apr 2012 17:01:19 -0700
From: Josh Blum <[email protected]>
To: "Nowlan, Sean" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] FW and FPGA images
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 04/09/2012 04:57 PM, Nowlan, Sean wrote:
> Thanks! Unfortunately I couldn't find that particular commit in any of those
> folders. Would it be somewhere else?
>
There isnt an image package built for every commit, just when FPGA/FW
stuff changes.
You can go by the date of the commit vs the date the image package was
retired. Or the commit hash and the hash on the image package. You are
looking for a range on the image package that encompasses your commit.
-josh
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Josh Blum
> Sent: Monday, April 09, 2012 7:18 PM
> To: [email protected]
> Subject: Re: [USRP-users] FW and FPGA images
>
>
>
> On 04/09/2012 04:07 PM, Nowlan, Sean wrote:
>> I have some code already running in production using UHD commit
>> eb11b052 downloaded 15-NOV-2011 at 21:20:29 UTC. I'm trying to find
>> the corresponding FW and FPGA images (which I apparently didn't back
>> up). Unfortunately they're not from an actual release, so they're not
>> up on files.ettus.com. If anybody at Ettus has a chance, could you
>> send me these files? I have an N200 Rev.4. Thanks!
>>
>
> I put the older images into a folder with the date that I replaced them.
> So, some files shuffled around recently, but they are still around. Take a
> look here: http://files.ettus.com/binaries/master_images/old/older/
>
> -josh
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 15
Date: Mon, 9 Apr 2012 20:06:21 -0400
From: Thomas Tsou <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] E100 overflow behaviour
Message-ID:
<caf5fesdvjg3grbmprorvhdt3xoizkua1f-xwo9ndlgvemqf...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Apr 9, 2012 at 7:55 PM, Josh Blum <[email protected]> wrote:
> On 04/09/2012 04:40 PM, Thomas Tsou wrote:
>> So, absent of timeout or overrun conditions, returning less samples
>> than requested is expected behaviour? I can deal with that, but my
>> assumptions were based on comments from the streamer receive api.
>>
>> ? ? ?* This is a blocking call and will not return until the number
>> ? ? ?* of samples returned have been written into each buffer.
>> ? ? ?* Under a timeout condition, the number of samples returned
>> ? ? ?* may be less than the number of samples specified.
>>
>
> Correct.
>
> It might just be that you are really seeing an overflow. You have the
> sample rate up pretty high, and its converting the samples to floats,
> and printing on every packet.
There is an overflow directly after the mini packet. In other words, I
should handle the overflow somewhat preemptively, I suppose, and not
expect the overflow flag to be set until the following packet. That's
fine.
> Still, the same command is ok for balister. Perhaps some of the
> optimization flags were missing during compile? If so, can you rebuild
> and make sure the flags appear when you make VERBOSE=1?
I didn't build anything. This is rx_timed_samples from the following image.
http://files.ettus.com/e1xx_images/e1xx-003/
Thomas
------------------------------
Message: 16
Date: Mon, 09 Apr 2012 17:15:54 -0700
From: Josh Blum <[email protected]>
To: Thomas Tsou <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] E100 overflow behaviour
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
> There is an overflow directly after the mini packet. In other words, I
> should handle the overflow somewhat preemptively, I suppose, and not
> expect the overflow flag to be set until the following packet. That's
> fine.
>
Yes, thats correct. This comes directly from the FPGA logic stopping a
packet early when space runs out, and then sending a inline message
packet. So you kind of have to call recv() again after a short packet to
confirm its an overflow.
>> Still, the same command is ok for balister. Perhaps some of the
>> optimization flags were missing during compile? If so, can you rebuild
>> and make sure the flags appear when you make VERBOSE=1?
>
> I didn't build anything. This is rx_timed_samples from the following image.
>
> http://files.ettus.com/e1xx_images/e1xx-003/
>
I take it back... so for balister: with --dilv, rx_timed_samples with
1e6 samples is ok. Without --dilv (the verbose enabled), it overflows.
So the processor cant respond fast enough when printing on every packet.
-josh
------------------------------
Message: 17
Date: Mon, 9 Apr 2012 21:10:39 -0400
From: Thomas Tsou <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] E100 overflow behaviour
Message-ID:
<caf5fescvuiz4_o6ch_cgw9vta6sjgke_v4hqrqsd2q+0dbi...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Apr 9, 2012 at 8:15 PM, Josh Blum <[email protected]> wrote:
> Yes, thats correct. This comes directly from the FPGA logic stopping a
> packet early when space runs out, and then sending a inline message
> packet. So you kind of have to call recv() again after a short packet to
> confirm its an overflow.
Ok. That's good to know.
> I take it back... so for balister: with --dilv, rx_timed_samples with
> 1e6 samples is ok. Without --dilv (the verbose enabled), it overflows.
> So the processor cant respond fast enough when printing on every packet.
Works that way here too. That wasn't really my concern though. I just
picked a value high enough to force the overrun and generate the
mini-packet scenario. Anyhow, at least we're on the same page now :)
Thomas
------------------------------
Message: 18
Date: Tue, 10 Apr 2012 09:36:45 -0400
From: vegihat vegihat <[email protected]>
To: [email protected]
Subject: [USRP-users] problem Communication between 2 USRP1
Message-ID:
<CAAa8Va09FCNSz3xtvV+A12593y3BD=cpj9xj-xkbnfy22o4...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I have 2 PCs and 2 USRP1.
Ubuntu 10.04 and the latest Gnu Radio 3.6 have been installed on both
PCs using http://www.sbrac.org/files/build-gnuradio
I try to install a communication path between usrp using
/usr/local/share/gnuradio/examples/digital/narrowband/tunnel.py
what i try is
PC1
$ sudo su
# ./tunnel.py --freq 423.0M --bitrate 500k
# ifconfig gr0 192.168.200.1
PC2
$ sudo su
# ./tunnel.py --freq 423.0M --bitrate 500k
# ifconfig gr0 192.168.200.2
then i ping from one PC to onether and i take
>From 192.168.200.1 icmp_seq=316 Destination Host Unreachable
>From http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSUHD is
said that
USRP1
USRP1 requires the libusrp driver found in GNU Radio. Please note that
libusrp support is now deprecated in GNU Radio and will be removed
permanently in GNU Radio version 3.5. Stable version 3.4.2 of GNU Radio
is recommended.
but from here http://gnuradio.org/redmine/projects/gnuradio/wiki/USRP is
said
The primary driver for all Ettus Research products - including the USRP1
- is UHD, the Universal Hardware Driver. UHD is considered stable and
actively maintained by Ettus Research. The UHD driver is recommended for
nearly all users.
so what is the most possible problem? do i need to install Gnu Radio
3.4.2?
ps:USRPs was bought at 2007
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120410/2f671c02/attachment-0001.html>
------------------------------
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
End of USRP-users Digest, Vol 20, Issue 10
******************************************
