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: [Spectrum Sense] Output (Mike Jameson)
2. Re: UHD - Calibration Tools (Rancid Fisch)
3. USRP :: MATLAB's comm.SDRuTransmitter (Stan Gamla)
4. Re: Timing constraints violations using custom_dsp_rx module
(Josh Blum)
5. Re: third ddc (Josh Blum)
6. [] Non-working multicast IGMP on E100 (Antonio Mancina)
7. Re: UHD - Calibration Tools (Mike McLernon)
8. Re: [] Non-working multicast IGMP on E100 (Philip Balister)
9. Re: [] Non-working multicast IGMP on E100 (Antonio Mancina)
10. How long does USRP need to switch its center frequency (lwei)
11. Re: [] Non-working multicast IGMP on E100 (Philip Balister)
12. Re: [] Non-working multicast IGMP on E100 (Antonio Mancina)
13. Re: [] Non-working multicast IGMP on E100 ([email protected])
14. Re: [] Non-working multicast IGMP on E100 (Antonio Mancina)
15. Re: [] Non-working multicast IGMP on E100 ([email protected])
16. Re: [] Non-working multicast IGMP on E100 (Antonio Mancina)
17. Re: [] Non-working multicast IGMP on E100 ([email protected])
18. Re: [] Non-working multicast IGMP on E100 (Antonio Mancina)
19. Re: USRP :: MATLAB's comm.SDRuTransmitter (Mike McLernon)
20. Re: [] Non-working multicast IGMP on E100 ([email protected])
21. Re: [] Non-working multicast IGMP on E100 (Antonio Mancina)
22. Re: USRP :: MATLAB's comm.SDRuTransmitter (Stan Gamla)
23. Problem using MIMO cable (mepard)
----------------------------------------------------------------------
Message: 1
Date: Sun, 24 Mar 2013 17:07:16 +0000
From: Mike Jameson <[email protected]>
To: Rog?rio Rivera <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] [Spectrum Sense] Output
Message-ID:
<CAJcjmiS-+t4SGOMwA-Le=+tqkud3rebmfawe6vahfvs8s53...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Rogerio,
Have a look at the attached version I just put together for you.
It prints out the frequency and average magnitude. The
'--channel-bandwidth' parameter rounds the frequency, default is currently
'12.5e3' so set it to '1' or cancel out line 242 to disable the channel
rounding.
>From here you could save the data to csv and go from there.
Mike
--
Mike Jameson M0MIK BSc
Radio Communications Technology Specialist
Email: [email protected]
Web: http://www.scanoo.com
On 22 March 2013 20:40, Rog?rio Rivera <[email protected]> wrote:
> Greetings.
> I am using USRP N210 with Daughterboard WBX and I am using
> usrp_spectrum_sense.py and I am receiving on the terminal prompt the center
> frequency. I have added the "print m.data" line to the
> "usrp_spectrum_sense.py" code but so far I can't plot a spectrum graph
> using the data received from the USRP.
> Do I have to add any command line to the python code?
> Is the "gr_plot_fft.py" relevant for me in this case?
> How do I get that real time graph?
> Thanks in advance,
> Rogerio.
>
> _______________________________________________
> 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/20130324/d34a9cf8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: usrp_spectrum_sense.py
Type: application/octet-stream
Size: 10237 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130324/d34a9cf8/attachment-0001.py>
------------------------------
Message: 2
Date: Sun, 24 Mar 2013 19:12:11 +0100
From: Rancid Fisch <[email protected]>
To: Nicholas Corgan <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] UHD - Calibration Tools
Message-ID:
<caomgnsf4qr_3otgetmhsyf8ekkkfksvihob3rgjr1wn-nmj...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Does this mean that there is no workaround?
Which version of MATLAB supports UHD 003.004.001 (and later)?
On Sun, Mar 24, 2013 at 3:04 PM, Nicholas Corgan <[email protected]>wrote:
> Unfortunately, the calibration utilities weren't introduced until UHD
> 003.004.001.
>
>
> On Sun, Mar 24, 2013 at 3:40 AM, Rancid Fisch <[email protected]>wrote:
>
>> The UHD documentation (
>> http://files.ettus.com/uhd_docs/manual/html/calibration.html) cites the
>> following utilities:
>>
>>
>> - *uhd_cal_rx_iq_balance:* - mimimizes RX IQ imbalance vs. LO
>> frequency
>> - *uhd_cal_tx_dc_offset:* - mimimizes TX DC offset vs. LO frequency
>> - *uhd_cal_tx_iq_balance:* - mimimizes TX IQ imbalance vs. LO
>> frequency
>>
>> Although the documentation states that these are installed into
>> *<install-path>/bin
>> *I cannot find them there -- or anywhere on my PC.
>>
>> I have two Rev 4.0 N210s, one with a WBX the other a SBX RF daughter
>> board. My PCs run MATLAB R2012a, one under Windows XP (32-bit) the other
>> Windows 7 (64-bit) and hence require UHD 003.002.003.
>> Where can I find the calibration routines listed above for my specific
>> configuration and are they available as compiled executable files?
>> __________
>> Rancid Fisch
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
> --
> Nicholas Corgan
>
--
__________
Rancid Fisch
mailto:[email protected] <[email protected]>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130324/c147eca5/attachment-0001.html>
------------------------------
Message: 3
Date: Sun, 24 Mar 2013 21:53:51 +0100
From: Stan Gamla <[email protected]>
To: USRP-USERS Ettus <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: [USRP-users] USRP :: MATLAB's comm.SDRuTransmitter
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
MATLAB's USRP documentation (e.g.
/commusrp/help/methods/sdru_transmitter/comm.sdrutransmitter.step.html)
explains the step function as follows:
stepTransmit signal and control data to USRPTM board
Syntaxstep(H,X)
UNDER = step(H,X)
step(H,X,FC)
step(H,X,LO)
step(H,X,GAIN)
step(H,X,INTERP)
Descriptionstep(H,X) transmits signal and control
data to a USRPTM board using User Datagram
Protocol (UDP) packets. The input signal, X, is a
column vector of double values.
What range has X--what are its minimum and maximum values?
Thanks,
Stan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130324/60c98032/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 1608 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130324/60c98032/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 1253 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130324/60c98032/attachment-0003.png>
------------------------------
Message: 4
Date: Sun, 24 Mar 2013 23:31:08 -0500
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Timing constraints violations using
custom_dsp_rx module
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 03/23/2013 05:55 AM, Florian Schlembach wrote:
> I am just trying to dig into that problem little bit more. I think I
> have narrowed down the root cause for the timing involations.
> It seems like the logic within the settings_fifo_control.v is
> responsible for this:
>
> time_compare time_compare(
> .time_now(vita_time_reg), .trigger_time(command_ticks_reg),
> .late(late));
> `else
> assign late = 1;
> `endif
>
> wire time_ready = (out_command_has_time)? late : 1;
> wire action = (cmd_state == EVENT_CMD) && ~result_fifo_full &&
> perfs_ready && time_ready;
>
> vita_time_reg is 64-bit wide and there still comes something after this
> during one cycle. I reckon thats the root cause for the timing
> violation. I'll have to see where I can insert another pipeline stage.
>
> In general, it seems like if there is more logic put into the custom
> module and the FPGA design gets bigger. Timing constraints in terms of
> routing delays are more difficult to meet. Possibly, the USRP FPGA code
> should be modified at this point.
>
> May I ask for the author of the settings_control bus so we could
> possibly work on a solution?
>
It may be best to free up some space by removing an RX DSP chain in the
u2p_core.v (if unused). That would also free up one of the large 64bit
time compare blocks.
Also, if you are not using the timed aspect of the timed commands, then
this could also be saved by adding FIFO_CTRL_NO_TIME=1 to the
CUSTOM_DEFS variable in the makefile.
-josh
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 5
Date: Sun, 24 Mar 2013 23:25:59 -0500
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] third ddc
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 03/23/2013 05:09 PM, dave wrote:
> Thanks for all the help so far!
> I'm trying to add a third ddc. I've modified u2plus_core, packet_router,
> and a few other things and at least the rtl schematic seems to look as
> though the new channel is wired in. If I try to set_subdev_spec with
> "A:0 A:0 A:0" or call uhd_usrp_probe the N210 reports only two DSP
> devices. Where do these calls learn about what's programmed into the
> fpgas? I can't tell if this a symptom that the third chain is still not
> really wired in or if I need to modify the API on or to the PC side.
>
You will find there is a for loop over in the host code here:
http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/host/lib/usrp/usrp2/usrp2_impl.cpp#L552
Hope that helps!
_josh
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 6
Date: Mon, 25 Mar 2013 12:19:19 +0100
From: Antonio Mancina <[email protected]>
To: [email protected]
Subject: [USRP-users] [] Non-working multicast IGMP on E100
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi all,
I'm trying to run the following python code on a E100.
----
# multicast_receiver.py
import socket
import struct
MCAST_GRP = '224.1.1.1'
MCAST_PORT = 5007
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
sock.bind(('', MCAST_PORT))
mreq = struct.pack("4sl", socket.inet_aton(MCAST_GRP), socket.INADDR_ANY)
sock.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq)
while True:
print sock.recv(10240)
-------------------------
If I open a shell and run a
tcpdump -n igmp -i eth0
on it, I don't see any IGMP packets going out from the eth0 interface
at program start and exit times (there should be multicast join and
leaves messages respectively).
I found something on Internet about a kernel option CONFIG_IP_MULTICAST
which might be not set. According to these guesses, in order to let the
E100 receive multicast messages, it should be set to YES.
Would someone please confirm this is the reason why I'm not neither
seeing IGMP messages nor receiving multicast ones and suggesting a
workaround for this?
Thanks in advance,
Antonio
------------------------------
Message: 7
Date: Mon, 25 Mar 2013 11:57:12 +0000
From: Mike McLernon <[email protected]>
To: Rancid Fisch <[email protected]>, Nicholas Corgan
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD - Calibration Tools
Message-ID:
<e3879be9a282cb45aab7ce258a9ae48f219cd...@exmb-01-ah.ad.mathworks.com>
Content-Type: text/plain; charset="us-ascii"
Version R2013a of MATLAB, available now, uses UHD 003.004.002. It does not
provide a MATLAB API to the calibration tools listed below.
Mike
From: USRP-users [mailto:[email protected]] On Behalf Of
Rancid Fisch
Sent: Sunday, March 24, 2013 2:12 PM
To: Nicholas Corgan
Cc: [email protected]
Subject: Re: [USRP-users] UHD - Calibration Tools
Does this mean that there is no workaround?
Which version of MATLAB supports UHD 003.004.001 (and later)?
On Sun, Mar 24, 2013 at 3:04 PM, Nicholas Corgan <[email protected]> wrote:
Unfortunately, the calibration utilities weren't introduced until UHD
003.004.001.
On Sun, Mar 24, 2013 at 3:40 AM, Rancid Fisch <[email protected]> wrote:
The UHD documentation
(http://files.ettus.com/uhd_docs/manual/html/calibration.html) cites the
following utilities:
* uhd_cal_rx_iq_balance: - mimimizes RX IQ imbalance vs. LO
frequency
* uhd_cal_tx_dc_offset: - mimimizes TX DC offset vs. LO frequency
* uhd_cal_tx_iq_balance: - mimimizes TX IQ imbalance vs. LO
frequency
Although the documentation states that these are installed into
<install-path>/bin I cannot find them there -- or anywhere on my PC.
I have two Rev 4.0 N210s, one with a WBX the other a SBX RF daughter
board. My PCs run MATLAB R2012a, one under Windows XP (32-bit) the other
Windows 7 (64-bit) and hence require UHD 003.002.003.
Where can I find the calibration routines listed above for my specific
configuration and are they available as compiled executable files?
__________
Rancid Fisch
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Nicholas Corgan
--
__________
Rancid Fisch
mailto:[email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130325/3e81b217/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 476 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130325/3e81b217/attachment-0001.sig>
------------------------------
Message: 8
Date: Mon, 25 Mar 2013 09:20:05 -0400
From: Philip Balister <[email protected]>
To: Antonio Mancina <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] [] Non-working multicast IGMP on E100
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 03/25/2013 07:19 AM, Antonio Mancina wrote:
> Hi all,
>
> I'm trying to run the following python code on a E100.
>
> ----
> # multicast_receiver.py
>
> import socket
> import struct
>
> MCAST_GRP = '224.1.1.1'
> MCAST_PORT = 5007
>
> sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
> sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
> sock.bind(('', MCAST_PORT))
> mreq = struct.pack("4sl", socket.inet_aton(MCAST_GRP), socket.INADDR_ANY)
>
> sock.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq)
>
> while True:
> print sock.recv(10240)
> -------------------------
>
> If I open a shell and run a
>
> tcpdump -n igmp -i eth0
>
> on it, I don't see any IGMP packets going out from the eth0 interface
> at program start and exit times (there should be multicast join and
> leaves messages respectively).
>
> I found something on Internet about a kernel option CONFIG_IP_MULTICAST
> which might be not set. According to these guesses, in order to let the
> E100 receive multicast messages, it should be set to YES.
You are correct, it is not set. I need to update the kernel soon to fix
some of the S problems people have seen and will include this change.
Do I need to change anything else for your work?
Thanks,
Philip
>
> Would someone please confirm this is the reason why I'm not neither
> seeing IGMP messages nor receiving multicast ones and suggesting a
> workaround for this?
>
> Thanks in advance,
> Antonio
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
------------------------------
Message: 9
Date: Mon, 25 Mar 2013 14:26:26 +0100
From: Antonio Mancina <[email protected]>
To: Philip Balister <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] [] Non-working multicast IGMP on E100
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi Philip,
On 03/25/2013 02:20 PM, Philip Balister wrote:
> On 03/25/2013 07:19 AM, Antonio Mancina wrote:
>> I found something on Internet about a kernel option CONFIG_IP_MULTICAST
>> which might be not set. According to these guesses, in order to let the
>> E100 receive multicast messages, it should be set to YES.
>
> You are correct, it is not set. I need to update the kernel soon to fix
> some of the S problems people have seen and will include this change.
thanks for your confirmation. In the meanwhile I tried to follow your
instructions here
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/usrpe1xx/wiki/E1XX_Kernel_hacking
I successfully built a uImage with that support built-in, copied it on
the E100 and rebooted it.
I verified, through a script living in the scripts/ directory that
the support of the uImage image for multicast was on:
root@usrp-e1xx:~# ./extract-ikconfig /boot/uImage | grep -i multicast
CONFIG_IP_MULTICAST=y
Nevertheless, when I try to run the command netstat -g, here's its
output:
root@usrp-e1xx:~# netstat -g
IPv6/IPv4 Group Memberships
Interface RefCnt Group
--------------- ------ ---------------------
netstat: no support for `AF INET (igmp)' on this system.
lo 1 ff02::1
eth0 1 ff02::1:ff85:304b
eth0 1 ff02::1
As you can see, there's still some multicast support problem which
I seem not able to fix. The multicast IGMP messages are not going
out from the interface, either.
I hope and am sure you'll have more luck.
> Do I need to change anything else for your work?
Not as of now. I do thank you for you kindness and availability.
Looking forward to reading news from you.
Antonio
------------------------------
Message: 10
Date: Mon, 25 Mar 2013 14:44:13 +0100
From: lwei <[email protected]>
To: [email protected]
Subject: [USRP-users] How long does USRP need to switch its center
frequency
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi all,
I know this is a rather basic question, but I notice the function
usrp->set_rx_freq(freq); actually takes around 19 ms to return.
So I then tried to use wireshark to capture the packets, the I notice
between there are 32 UDP packets, sent with 36 bytes payload...and the
time spent on those packets are about 19 ms, which corresponds with the
software delay I measured with cpp binary
I am using Boost_104000, UHD_003.001.000-9f1e49e (ye..a bit out of date
I know, hope this is not where things go wrong).
Does anyone know why it takes so long to set the frequency? is there
something I am doing wrong or is this issue already solved by a newer
uhd version?
Kind regards,
--
Wei Liu
Researcher
Ghent University - IBBT
Department of Information Technology (INTEC)
Internet Based Communication Networks and Services (IBCN)
Zuiderpoort Office Park, Building C0
Gaston Crommenlaan 8 bus 201
9050 Gent, Belgium
http://www.ibcn.intec.ugent.be/
Phone: +32 (0)9 33 14946
Fax: +32 (0)9 33 14899
E-mail: [email protected]
Route: http://www.ibcn.intec.ugent.be/route.html
------------------------------
Message: 11
Date: Mon, 25 Mar 2013 09:50:02 -0400
From: Philip Balister <[email protected]>
To: Antonio Mancina <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] [] Non-working multicast IGMP on E100
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 03/25/2013 09:26 AM, Antonio Mancina wrote:
> Hi Philip,
>
>
> On 03/25/2013 02:20 PM, Philip Balister wrote:
>> On 03/25/2013 07:19 AM, Antonio Mancina wrote:
>>> I found something on Internet about a kernel option CONFIG_IP_MULTICAST
>>> which might be not set. According to these guesses, in order to let the
>>> E100 receive multicast messages, it should be set to YES.
>>
>> You are correct, it is not set. I need to update the kernel soon to fix
>> some of the S problems people have seen and will include this change.
>
>
> thanks for your confirmation. In the meanwhile I tried to follow your
> instructions here
>
> http://ettus-apps.sourcerepo.com/redmine/ettus/projects/usrpe1xx/wiki/E1XX_Kernel_hacking
>
>
> I successfully built a uImage with that support built-in, copied it on
> the E100 and rebooted it.
>
> I verified, through a script living in the scripts/ directory that
> the support of the uImage image for multicast was on:
>
> root@usrp-e1xx:~# ./extract-ikconfig /boot/uImage | grep -i multicast
> CONFIG_IP_MULTICAST=y
>
> Nevertheless, when I try to run the command netstat -g, here's its
> output:
>
> root@usrp-e1xx:~# netstat -g
> IPv6/IPv4 Group Memberships
> Interface RefCnt Group
> --------------- ------ ---------------------
> netstat: no support for `AF INET (igmp)' on this system.
> lo 1 ff02::1
> eth0 1 ff02::1:ff85:304b
> eth0 1 ff02::1
I think you need the file /proc/net/igmp to exist on your machine. Can
you check for this? On mine (wo mulitcast) I have the igmp6 file only.
Philip
PS: I am not a multicast expert, so bear with me :)
>
>
> As you can see, there's still some multicast support problem which
> I seem not able to fix. The multicast IGMP messages are not going
> out from the interface, either.
>
> I hope and am sure you'll have more luck.
>
>
>> Do I need to change anything else for your work?
>
>
> Not as of now. I do thank you for you kindness and availability.
>
> Looking forward to reading news from you.
> Antonio
>
>
>
------------------------------
Message: 12
Date: Mon, 25 Mar 2013 14:57:47 +0100
From: Antonio Mancina <[email protected]>
To: Philip Balister <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] [] Non-working multicast IGMP on E100
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 03/25/2013 02:50 PM, Philip Balister wrote:
> On 03/25/2013 09:26 AM, Antonio Mancina wrote:
------
>> netstat: no support for `AF INET (igmp)' on this system.
>> lo 1 ff02::1
>> eth0 1 ff02::1:ff85:304b
>> eth0 1 ff02::1
>
> I think you need the file /proc/net/igmp to exist on your machine. Can
> you check for this? On mine (wo mulitcast) I have the igmp6 file only.
You are right, there's still no /proc/net/igmp file on my machine.
I don't understand why this is happening with the proper kernel option
enabled.
Any ideas about how to fix this?
> PS: I am not a multicast expert, so bear with me :)
Neither am I, hope to learn something useful from this problem ;-)
Thanks again,
Antonio
>
>
>
>>
>>
>> As you can see, there's still some multicast support problem which
>> I seem not able to fix. The multicast IGMP messages are not going
>> out from the interface, either.
>>
>> I hope and am sure you'll have more luck.
>>
>>
>>> Do I need to change anything else for your work?
>>
>>
>> Not as of now. I do thank you for you kindness and availability.
>>
>> Looking forward to reading news from you.
>> Antonio
>>
>>
>>
>
------------------------------
Message: 13
Date: Mon, 25 Mar 2013 10:00:21 -0400
From: [email protected]
To: <[email protected]>
Subject: Re: [USRP-users] [] Non-working multicast IGMP on E100
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
On 25 Mar 2013 09:50, Philip Balister wrote:
> On 03/25/2013 09:26
AM, Antonio Mancina wrote:
>
>> Hi Philip, On 03/25/2013 02:20 PM,
Philip Balister wrote:
>>
>>> On 03/25/2013 07:19 AM, Antonio Mancina
wrote:
>>>
>>>> I found something on Internet about a kernel option
CONFIG_IP_MULTICAST which might be not set. According to these guesses,
in order to let the E100 receive multicast messages, it should be set to
YES.
>>> You are correct, it is not set. I need to update the kernel
soon to fix some of the S problems people have seen and will include
this change.
>> thanks for your confirmation. In the meanwhile I tried
to follow your instructions here
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/usrpe1xx/wiki/E1XX_Kernel_hacking
[1] I successfully built a uImage with that support built-in, copied it
on the E100 and rebooted it. I verified, through a script living in the
scripts/ directory that the support of the uImage image for multicast
was on: root@usrp-e1xx:~# ./extract-ikconfig /boot/uImage | grep -i
multicast CONFIG_IP_MULTICAST=y Nevertheless, when I try to run the
command netstat -g, here's its output: root@usrp-e1xx:~# netstat -g
IPv6/IPv4 Group Memberships Interface RefCnt Group ---------------
------ --------------------- netstat: no support for `AF INET (igmp)' on
this system. lo 1 ff02::1 eth0 1 ff02::1:ff85:304b eth0 1 ff02::1
>
> I
think you need the file /proc/net/igmp to exist on your machine. Can
>
you check for this? On mine (wo mulitcast) I have the igmp6 file only.
>
> Philip
>
> PS: I am not a multicast expert, so bear with me :)
>
>>
As you can see, there's still some multicast support problem which I
seem not able to fix. The multicast IGMP messages are not going out from
the interface, either. I hope and am sure you'll have more luck.
>>
>>> Do I need to change anything else for your work?
>> Not as of now.
I do thank you for you kindness and availability. Looking forward to
reading news from you. Antonio
>
>
_______________________________________________
> USRP-users mailing
list
> [email protected]
>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
I
don't recall in your code whether you're using the IP_ADD_MEMBERSHIP
socket option -- it's not sufficient to simply bind to a multicast
address, you also have to request a membership ADD using that socket
option--and that is what prompts the use of IGMP, as far as I can tell.
But like Phil, my experience with multicast is very rudimentary.
Links:
------
[1]
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/usrpe1xx/wiki/E1XX_Kernel_hacking
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130325/690a3e3b/attachment-0001.html>
------------------------------
Message: 14
Date: Mon, 25 Mar 2013 15:06:04 +0100
From: Antonio Mancina <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] [] Non-working multicast IGMP on E100
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi Marcus,
> I don't recall in your code whether you're using the IP_ADD_MEMBERSHIP
> socket option -- it's not sufficient to simply bind to a multicast
> address, you also have to request a membership ADD using that socket
> option--and that is what prompts the use of IGMP, as far as I can tell.
in the code I attached to my first post there's this row
sock.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq)
that should serve just that purpose.
Anyway, this code properly works on any other machines I work with.
Thanks!
Antonio
------------------------------
Message: 15
Date: Mon, 25 Mar 2013 10:10:25 -0400
From: [email protected]
To: <[email protected]>
Subject: Re: [USRP-users] [] Non-working multicast IGMP on E100
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
On 25 Mar 2013 10:06, Antonio Mancina wrote:
> Hi Marcus,
>
>> I
don't recall in your code whether you're using the IP_ADD_MEMBERSHIP
socket option -- it's not sufficient to simply bind to a multicast
address, you also have to request a membership ADD using that socket
option--and that is what prompts the use of IGMP, as far as I can
tell.
>
> in the code I attached to my first post there's this row
>
>
sock.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq)
>
>
that should serve just that purpose.
> Anyway, this code properly works
on any other machines I work with.
>
> Thanks!
> Antonio
>
>
_______________________________________________
> USRP-users mailing
list
> [email protected]
>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Check
also that MULTICAST is set on the interface. This should happen
automatically, as the hardware driver sets that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130325/d3c7af60/attachment-0001.html>
------------------------------
Message: 16
Date: Mon, 25 Mar 2013 15:12:37 +0100
From: Antonio Mancina <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] [] Non-working multicast IGMP on E100
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 03/25/2013 03:10 PM, [email protected] wrote:
> Check also that MULTICAST is set on the interface. This should happen
> automatically, as the hardware driver sets that.
This seems not to be the problem, either.
root@usrp-e1xx:# ifconfig
eth0 Link encap:Ethernet HWaddr A0:36:FA:85:30:4B
inet addr:192.168.26.170 Bcast:192.168.26.255
Mask:255.255.255.0
inet6 addr: fe80::a236:faff:fe85:304b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:484465 errors:0 dropped:4 overruns:0 frame:0
TX packets:451762 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:257377971 (245.4 MiB) TX bytes:382443932 (364.7 MiB)
Interrupt:80
Thanks,
Antonio
------------------------------
Message: 17
Date: Mon, 25 Mar 2013 10:37:55 -0400
From: [email protected]
To: <[email protected]>
Subject: Re: [USRP-users] [] Non-working multicast IGMP on E100
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
On 25 Mar 2013 10:12, Antonio Mancina wrote:
> On 03/25/2013 03:10
PM, [email protected]:
>
>> Check also that MULTICAST is set on
the interface. This should happen automatically, as the hardware driver
sets that.
>
> This seems not to be the problem, either.
>
>
root@usrp-e1xx:# ifconfig
> eth0 Link encap:Ethernet HWaddr
A0:36:FA:85:30:4B
> inet addr:192.168.26.170 Bcast:192.168.26.255
>
Mask:255.255.255.0
> inet6 addr: fe80::a236:faff:fe85:304b/64
Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX
packets:484465 errors:0 dropped:4 overruns:0 frame:0
> TX packets:451762
errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
>
RX bytes:257377971 (245.4 MiB) TX bytes:382443932 (364.7 MiB)
>
Interrupt:80
>
> Thanks,
> Antonio
>
>
_______________________________________________
> USRP-users mailing
list
> [email protected]
>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
OK,
a couple of other things:
sysctl -a |grep igmp
What does that
return?
grep multica /proc/kallsyms
What does that return?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130325/7cc759a9/attachment-0001.html>
------------------------------
Message: 18
Date: Mon, 25 Mar 2013 15:40:42 +0100
From: Antonio Mancina <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] [] Non-working multicast IGMP on E100
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> OK, a couple of other things:
>
> sysctl -a |grep igmp
error: permission denied on key 'net.ipv4.route.flush'
net.ipv4.igmp_max_memberships = 20
net.ipv4.igmp_max_msf = 10
net.ipv4.conf.all.force_igmp_version = 0
net.ipv4.conf.default.force_igmp_version = 0
net.ipv4.conf.lo.force_igmp_version = 0
net.ipv4.conf.eth0.force_igmp_version = 0
error: permission denied on key 'net.ipv6.route.flush'
>
> What does that return?
>
> grep multica /proc/kallsyms
c02725f8 t smsc911x_rx_multicast_update
c0272bc8 t smsc911x_set_multicast_list
c027504c t ax88172_set_multicast
c0275110 t asix_set_multicast
c03320ac t show_multicast
c033698c T __netlink_clear_multicast_users
c03369d0 T netlink_clear_multicast_users
c0336fdc T genlmsg_multicast_allns
c033b604 T ip_rt_multicast_event
c050e228 r __ksymtab_genlmsg_multicast_allns
c0516b54 r __kcrctab_genlmsg_multicast_allns
c052da60 r __kstrtab_genlmsg_multicast_allns
c0594c00 d dev_attr_multicast
------------------------------
Message: 19
Date: Mon, 25 Mar 2013 15:02:59 +0000
From: Mike McLernon <[email protected]>
To: Stan Gamla <[email protected]>
Cc: USRP-USERS Ettus <[email protected]>, Darel Linebarger
<[email protected]>
Subject: Re: [USRP-users] USRP :: MATLAB's comm.SDRuTransmitter
Message-ID:
<e3879be9a282cb45aab7ce258a9ae48f219cd...@exmb-01-ah.ad.mathworks.com>
Content-Type: text/plain; charset="us-ascii"
Hi Stan,
The MATLAB code for comm.SDRuTransmitter does not perform any range checking on
its inputs. So the object itself will accept any double values.
Any range checking would be performed by the underlying UHD code.
Best,
Mike
From: Stan Gamla [mailto:[email protected]]
Sent: Sunday, March 24, 2013 4:54 PM
To: USRP-USERS Ettus
Cc: Darel Linebarger; Marc Erickson; Ethem Sozer; Mike McLernon
Subject: USRP :: MATLAB's comm.SDRuTransmitter
MATLAB's USRP documentation (e.g.
/commusrp/help/methods/sdru_transmitter/comm.sdrutransmitter.step.html)
explains the step function as follows:
step
Transmit signal and control data to USRPTM board
Syntax
step(H,X)
UNDER = step(H,X)
step(H,X,FC)
step(H,X,LO)
step(H,X,GAIN)
step(H,X,INTERP)
Description
step(H,X) transmits signal and control data to a USRPTM board using User
Datagram Protocol (UDP) packets. The input signal, X, is a column vector of
double values.
What range has X--what are its minimum and maximum values?
Thanks,
Stan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130325/40635cdb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 476 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130325/40635cdb/attachment-0001.sig>
------------------------------
Message: 20
Date: Mon, 25 Mar 2013 11:05:02 -0400
From: [email protected]
To: <[email protected]>
Subject: Re: [USRP-users] [] Non-working multicast IGMP on E100
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
On 25 Mar 2013 10:40, Antonio Mancina wrote:
>> OK, a couple of
other things: sysctl -a |grep igmp
>
> error: permission denied on key
'net.ipv4.route.flush'
> net.ipv4.igmp_max_memberships = 20
>
net.ipv4.igmp_max_msf = 10
> net.ipv4.conf.all.force_igmp_version = 0
>
net.ipv4.conf.default.force_igmp_version = 0
>
net.ipv4.conf.lo.force_igmp_version = 0
>
net.ipv4.conf.eth0.force_igmp_version = 0
> error: permission denied on
key 'net.ipv6.route.flush'
>
>> What does that return? grep multica
/proc/kallsyms
>
> c02725f8 t smsc911x_rx_multicast_update
> c0272bc8 t
smsc911x_set_multicast_list
> c027504c t ax88172_set_multicast
>
c0275110 t asix_set_multicast
> c03320ac t show_multicast
> c033698c T
__netlink_clear_multicast_users
> c03369d0 T
netlink_clear_multicast_users
> c0336fdc T genlmsg_multicast_allns
>
c033b604 T ip_rt_multicast_event
> c050e228 r
__ksymtab_genlmsg_multicast_allns
> c0516b54 r
__kcrctab_genlmsg_multicast_allns
> c052da60 r
__kstrtab_genlmsg_multicast_allns
> c0594c00 d dev_attr_multicast
>
>
_______________________________________________
> USRP-users mailing
list
> [email protected]
>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Hmm,
well, that's what you'd expect from a multicast-enabled kernel.
Not
sure what to make of your "netstat -g" results given the above data...
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130325/cf9cab5d/attachment-0001.html>
------------------------------
Message: 21
Date: Mon, 25 Mar 2013 16:19:02 +0100
From: Antonio Mancina <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] [] Non-working multicast IGMP on E100
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 03/25/2013 04:05 PM, [email protected] wrote:
> Hmm, well, that's what you'd expect from a multicast-enabled kernel.
>
> Not sure what to make of your "netstat -g" results given the above data...
I'm sure it is, I had this output compared to one coming from a properly
working kernel and I already noticed things are very similar.
The main point here is the lack of /proc/net/igmp file (which the error
in netstat -g comes from). Also, I still not see any igmp messages out
of eth0 when starting or stopping the test program.
Thanks,
Antonio
------------------------------
Message: 22
Date: Mon, 25 Mar 2013 16:44:20 +0100
From: Stan Gamla <[email protected]>
To: Mike McLernon <[email protected]>
Cc: USRP-USERS Ettus <[email protected]>, Darel Linebarger
<[email protected]>
Subject: Re: [USRP-users] USRP :: MATLAB's comm.SDRuTransmitter
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Could anyone expand on Mike's answer regarding the use of UHD via MATLAB and
clearly state the numerical for the following:
minimum value of I data for transmitmaximum value of I data for transmitminimum
value of Q data for transmitmaximum value of Q data for transmitminimum value
of I data for receivemaximum value of I data for receiveminimum value of Q data
for receivemaximum value of Q data for receive
From: [email protected]
To: [email protected]
CC: [email protected]; [email protected];
[email protected]; [email protected]
Subject: RE: USRP :: MATLAB's comm.SDRuTransmitter
Date: Mon, 25 Mar 2013 15:02:59 +0000
Hi Stan,
The MATLAB code for comm.SDRuTransmitter does not perform any range checking on
its inputs. So the object itself will accept any double values.
Any range checking would be performed by the underlying UHD code.
Best,
Mike
From: Stan Gamla [mailto:[email protected]]
Sent: Sunday, March 24, 2013 4:54 PM
To: USRP-USERS Ettus
Cc: Darel Linebarger; Marc Erickson; Ethem Sozer; Mike McLernon
Subject: USRP :: MATLAB's comm.SDRuTransmitter
MATLAB's USRP documentation (e.g.
/commusrp/help/methods/sdru_transmitter/comm.sdrutransmitter.step.html)
explains the step function as follows:
step
Transmit signal and control data to USRPTM board
Syntax
step(H,X)
UNDER = step(H,X)
step(H,X,FC)
step(H,X,LO)
step(H,X,GAIN)
step(H,X,INTERP)
Description
step(H,X) transmits signal and control data to a USRPTM board using User
Datagram Protocol (UDP) packets. The input signal, X, is a column vector of
double values.
What range has X--what are its minimum and maximum values?
Thanks,
Stan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130325/073e24cf/attachment-0001.html>
------------------------------
Message: 23
Date: Mon, 25 Mar 2013 10:50:41 -0500
From: mepard <[email protected]>
To: [email protected], "[email protected]" <[email protected]>
Subject: [USRP-users] Problem using MIMO cable
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
(Was: [USRP-users] Disturbance in the force or Glitch in the matrix?)
This is looking like a problem with MIMO cable support.
This morning I removed the MIMO cable, put both N210s on the same reference and
PPS, and updated the UHD USRP Source to use external clock and time sources for
both motherboards. I've now done 10 70-second acquisitions in a row with no
glitches at all. With the MIMO cable I never had two 70-second successes in a
row and most 70-second acquisitions had 2 or 3 glitches.
Now I suspect an issue keeping the FPGAs synchronized over the MIMO cable. Both
N210s already had their own ethernet connection and the MIMO cable was only
being used to synchronize samples times.
-Marc
On Mar 21, 2013, at 6:01 PM, mepard <[email protected]> wrote:
> On Mar 19, 2013, at 4:21 PM, mepard <[email protected]> wrote:
>
>> Increasing the MTU and recv_frame_size to 4096 and the spp (samples per
>> packet) to 1000 seems to prevent the dropped samples.
>
> Turns out this wasn't the case -- it's an intermittent problem and I just got
> lucky.
>
> I looked into how the packets from the two N210s are aligned and added some
> instrumentation to super_recv_packet_handler.hpp (enclosed). That's
> definitely where the samples are getting dropped, but I'm still not sure what
> the root cause is. In recv_packet_handler::alignment_check, I made it write a
> message with the packet type when it is about to toss existing buffers due to
> the time. Lost samples I see in the data correspond to these messages. I also
> added a message when it (re)gains alignment. Here's what a 70-second
> acquisition looks like:
>
> _A_000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000_A_000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000_A_000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000_A_000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000_A_0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000_A_
>
> The first _A_ is the initial alignment and the subsequent _A_s are when it
> regains alignment after the zeros which represent dropped buffers due to a
> PACKET_IF_DATA. Note there are no sequence errors. So far, that has been the
> case every single time. I also added more one-letter messages for other
> conditions and none of those are appearing either.
>
> I did find one thing a little suspicious. It looks like the trick of swapping
> the current and next buffer info's when returning an error could potentially
> break the relationship between current and previous info's, triggering
> PACKET_TIMESTAMP_ERROR, but I have not seen it actually happen.
>
> The usual sample rate is 12.5e6 sps, which is what I used with the sequence
> above. When reduced, the packet drops still occur, but it seems to take fewer
> dropped packets to recover with lower sample rates.
>
> At 3125000 sps I got this:
>
> _A_0000000000000000000000000000000000000000_A_000000000000000000000000000000000000000000_A_0000000000000000000000000000000000000000_A_
>
> At 390625 sps, this:
>
> _A_0000_A_0000_A_0000_A_0000_A_
>
> Still no sequence errors or the like.
>
> I can understand how dropped packets from either box can cause this, but why
> would it always be a multiple of 16 packets, thus avoiding a
> PACKET_SEQUENCE_ERROR?
>
> Any ideas?
>
> -Marc
>
> <super_recv_packet_handler.hpp>_______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
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 31, Issue 24
******************************************
