[Discuss-gnuradio] Cannot ping the usrp2
I am using USRP2 device my device works fine with GNU radio.
O.S=Ubuntu 10.04
Ip settings 192.168.10.1 netmask 255.255.255.0
I tested the firewall is disabled by using
umer@umer:~/Downloads$ sudo ufw status
Status: inactive
I want to ping the ip address 192.168.10.2 but the response is unreachable.
I have tried changing the ip address by using
umer@umer:~/Downloads$ sudo ./usrp2_recovery.py --ifc=eth0
--new-ip=192.168.10.2('Opening raw socket on interface:', 'eth0')
('Loading packet with ip address:', '192.168.10.2')
Sending packet (22 bytes)
Done
Umer
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] WBX Rev.3.0
Hi, can anyone give me the link where to get the schematic of the WBX daughterboard rev 3.0 and the schematic of WBX-FE-Simple R5.0. Many thanks. Dominique. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Cannot ping the usrp2
On Thu, May 31, 2012 at 05:01:56PM +0100, umer.rabb...@bt.com wrote: > I am using USRP2 device my device works fine with GNU radio. Hm, so what exactly is your problem? > O.S=Ubuntu 10.04 > Ip settings 192.168.10.1 netmask 255.255.255.0 > > I tested the firewall is disabled by using > umer@umer:~/Downloads$ sudo ufw status > Status: inactive > > I want to ping the ip address 192.168.10.2 but the response is unreachable. I don't think you *can* ping USRP2s. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpl1kSsmKNMB.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QAM Mod and QAM Demod block in GRC
These blocks are implemented in python. Have a look at the following two files to start off with: gnuradio/gr-digital/python/qam.py gnuradio/gr-digital/python/generic_mod_demod.py Ben On Wed, May 30, 2012 at 11:41 PM, jiajue ou wrote: > Hi all, > > > > I’m working on an experiment which needs to modify qam modulation block in > gnuradio. But I cannot find the source C++ file the qam blocks use. e.g., > OFDM demod block uses digital_ofdm_frame_sink in > gnuradiobuild/gnuradio/gr-digital/lib. What about qam blocks? > > Thank you for your help! > > > > Best, > > jia > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Cannot ping the usrp2
On 05/31/2012 09:11 AM, Martin Braun wrote: > On Thu, May 31, 2012 at 05:01:56PM +0100, umer.rabb...@bt.com wrote: >> I am using USRP2 device my device works fine with GNU radio. > > Hm, so what exactly is your problem? > >> O.S=Ubuntu 10.04 >> Ip settings 192.168.10.1 netmask 255.255.255.0 >> >> I tested the firewall is disabled by using >> umer@umer:~/Downloads$ sudo ufw status >> Status: inactive >> >> I want to ping the ip address 192.168.10.2 but the response is unreachable. > > I don't think you *can* ping USRP2s. > Yea the fw for the old libusrp2 drivers didnt have ping. But its fine on UHD :-) Start here to get the driver and images: http://code.ettus.com/redmine/ettus/projects/uhd/wiki And the SD card instructions: http://files.ettus.com/uhd_docs/manual/html/usrp2.html#load-the-images-onto-the-sd-card-usrp2-only -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to dynamically stop the host PC receiving samples from USRP and restart it again without touching the top block?
On 05/30/2012 06:33 PM, Alex Zhang wrote: > Hi, > > In my applications, after the flow graph is initialized, I need to > dynamically control the receiving of the USRP samples, i.e, at time T1, I > want the USRP to transfer the received samples to PC, while in T2, I do not > allow the PC to receive these samples. > Stop receiving the unusing packets from USRP can save the traffic over > ethernet and decrease the demands of processing resource on host PC. > > the gr_mute block seems only suppress the incoming packets to further > processing, but these unusing samples can still come into the flow graph. > > Also, the tb.run and tb.wait can be executed more than twice as wish, but > it seems to be not so flexible. It would be good if there some commands > called to control the block of uhd.usrp_source to achieve such purpose? > > I had a post on this recently, wish I could find it in the archives... So, the problem with stopping streaming is that the work function will return zero and the scheduler marks the block as done. So, if you take this changeset here. You should be able to stop and restart a running USRP without problem. http://gnuradio.org/cgit/jblum.git/log/?h=wip_uhd_stopper Use the following methods on the block: usrp->start() usrp->stop() and if you want to be precise about time, call usrp->set_stream_time(...) before calling start() -josh > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Multiple USRP N210s: LEDs and Ethernet lights on after program termination
On 05/30/2012 08:52 AM, Ryan Wolfarth wrote:
> Problem solved! rx_samples_to_file doesn't include a stream_cmd_stop!
> Here's our fix:
>
> Add the following after line 93 (outfile.close()):
>
> if(!num_requested_samples){
> uhd::stream_cmd_t
> stream_cmd_stop(uhd::stream_cmd_t::STREAM_MODE_STOP_CONTINUOUS);
> usrp->issue_stream_cmd(stream_cmd_stop);
> }
>
> This seems to do the trick. The C debug light is off as is the Ethernet
> link activity light!
>
Ah, that makes sense. Thanks for the patch.
I wonder a little bit what happens with this supposed ICMP packet I
mentioned. But its just kind of a handy nicety, so I wouldn't worry
about it.
-Josh
> -Ryan
>
> On Wed, May 30, 2012 at 11:35 AM, Darren Long wrote:
>
>> I've noticed that when stopping a GRC sketch and starting another, I get
>> unknown stream ID reports from my B100, requiring a restart of the USRP to
>> recover. This used to happen a while back, but was fixed. Perhaps the fix
>> has been broken or the issue is similar.
>>
>> Darren
>>
>> Sent from my iPhone
>>
>> On 30 May 2012, at 16:23, Ryan Wolfarth wrote:
>>
>> Hi Josh,
>>
>> Thanks for your quick reply! We are actually using rx_samples_to_file as
>> a first attempt at benchmarking the systems data transfer speed. We give a
>> proper crtl+c whenever we terminate the program, but the problem persists.
>> We tried rx_timed_samples per your recommendation and found that the port
>> and USRP terminated properly. The program doesn't seem to be modified from
>> previous releases, so my first blind guess is that there could be an issue
>> with the interface on one side of our network card (Intel 82576 Gigabit
>> controller).
>>
>> Due to the simplicity of our data collection scheme, we will probably
>> modify rx_samples_to_file to respond to an external trigger. So if we
>> could get the example working properly that would be a great starting
>> point. Do you have any more ideas?
>>
>> Thanks again,
>> Ryan
>>
>> On Tue, May 29, 2012 at 11:09 PM, Josh Blum wrote:
>>
>>>
>>>
>>> On 05/29/2012 05:36 PM, Ryan Wolfarth wrote:
Hi list,
We've setup 4 USRP N210 rev4s with a Dell PowerEdge R510 server to
>>> collect
RF data for GPS related experiments. The server works great and we
>>> seem to
be able to write 20 Msps from each device simultaneously to a RAID array
with no overflows. However, after each collection program is
>>> terminated,
the Ethernet and debugging LEDs (C, D, blinking E, and F) remain on. We
tested this with a single device with the same result. Does anybody
>>> know
the cause of this and if we should be worried? We're running UHD 3.4.2
(downloaded 2 days ago). All N210s were updated with the firmware/image
downloaded from the same version and compiled from source using GNU ZPU
Tools and Xilinx ISE 13.1 respectively. The server is running 64-bit
Ubuntu 12.04. Any help is appreciated!
>>>
>>> http://files.ettus.com/uhd_docs/manual/html/usrp2.html#front-panel-leds
>>>
>>> I would only really be worried about C which means the device is still
>>> sending samples out of the ethernet port. This can happen if the
>>> streaming isnt properly shutoff like ctrl+c or destructors not being
>>> called.
>>>
>>> Additionally, (if it is still streaming) the USRP isnt getting an ICMP
>>> destination unreachable from the host when the socket on the host
>>> closes. Its possible that due to your network setup that this packet
>>> doesnt get generated and/or delivered.
>>>
>>> If it is the deconstructor issue, sometimes its useful in gr python apps
>>> to set the top block object to None to help python garbage collect it.
>>>
>>> tb.stop()
>>> tb = None
>>>
>>> I would also see if things shutoff as expected when your run one of the
>>> included examples such as rx_timed_samples
>>>
>>> Hope that helps!
>>> -josh
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to dynamically stop the host PC receiving samples from USRP and restart it again without touching the top block?
It is great to hear this solution! On Thu, May 31, 2012 at 1:28 PM, Josh Blum wrote: > > > On 05/30/2012 06:33 PM, Alex Zhang wrote: > > Hi, > > > > In my applications, after the flow graph is initialized, I need to > > dynamically control the receiving of the USRP samples, i.e, at time T1, I > > want the USRP to transfer the received samples to PC, while in T2, I do > not > > allow the PC to receive these samples. > > Stop receiving the unusing packets from USRP can save the traffic over > > ethernet and decrease the demands of processing resource on host PC. > > > > the gr_mute block seems only suppress the incoming packets to further > > processing, but these unusing samples can still come into the flow graph. > > > > Also, the tb.run and tb.wait can be executed more than twice as wish, but > > it seems to be not so flexible. It would be good if there some commands > > called to control the block of uhd.usrp_source to achieve such purpose? > > > > > > > I had a post on this recently, wish I could find it in the archives... > > So, the problem with stopping streaming is that the work function will > return zero and the scheduler marks the block as done. > > So, if you take this changeset here. You should be able to stop and > restart a running USRP without problem. > http://gnuradio.org/cgit/jblum.git/log/?h=wip_uhd_stopper > > Use the following methods on the block: > > usrp->start() > usrp->stop() > and if you want to be precise about time, call > usrp->set_stream_time(...) before calling start() > > -josh > > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Alex, *Dreams can come true – just believe.* ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 114, Issue 33
>>>>>>>> The memory bus to the ARM provides 40 MBytes / second. This is >>>>>> used >>>>>>>>>>>> for >>>>>>>>>>>> streaming samples, as controlled via software. Currently, UHD >>>>>> supports >>>>>>>>>>>> 16 >>>>>>>>>>>> bit and 8 bit samples for TX & RX. The GPMC can only going to >>>>>> talk to >>>>>>>>>>>> one >>>>>>>>>>>> slave at a time; the possible slaves are TX, RX, and ethernet. >>>>>>>>>>>> So >>>>>> you >>>>>>>>>>>> can >>>>>>>>>>>> only be sending TX samples, receiving RX samples, or >>>>>>>>>>>> communicating >>>>>> via >>>>>>>>>>>> ethernet. >>>>>>>>>>>> >>>>>>>>>>>> Thus, doing the math with the numbers above, you can stream: >>>>>>>>>>>> 16 bit I, 16 bit Q -- Total: 32-bit samples -- @ 10 MSps >>>>>>>>>>>> 8 bit I, 8 bit Q -- Total: 16-bit samples -- @ 20 MSps >>>>>>>>>>>> >>>>>>>>>>>> What you choose to do with this data is obviously up to you. It >>>>>>>>>>>> is >>>>>>>>>>>> very >>>>>>>>>>>> easy to try to do more processing than the ARM can handle, in >>>>>>>>>>>> which >>>>>>>>>>>> case >>>>>>>>>>>> samples will start getting thrown out by UHD. Thus, you can >>>>>> typically >>>>>>>>>>>> process between 4 and 8 MHz of baseband bandwidth, depending on >>>>>> your >>>>>>>>>>>> application. If you are willing to dig deep into the code to >>>>>>>>>>>> make >>>>>> NEON >>>>>>>>>>>> and >>>>>>>>>>>> C64 optimizations, you can improve the performance dramatically. >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Ben >>>>>>>>>>>> >>>>>>>>>>>> Ben Hilburn <http://goo.gl/5DdZ3> @ Ettus Research, >>>>>>>>>>>> LLC<http://www.ettus.com/> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Tue, May 22, 2012 at 7:47 PM, Page Jack >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> I want to know the overo model used in e100 and the largest data >>>>>>>>>>>>> transfer rate between fpga and overo in e100. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards! >>>>>>>>>>>>> >>>>>>>>>>>>> ___ >>>>>>>>>>>>> USRP-users mailing list >>>>>>>>>>>>> usrp-us...@lists.ettus.com >>>>>>>>>>>>> >>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ___ >>>>>>>>> USRP-users mailing list >>>>>>>>> usrp-us...@lists.ettus.com >>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>
Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 114, Issue 33
>>>>>>> >>>>>>>>>>>>> On Tue, May 22, 2012 at 7:47 PM, Page Jack >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> I want to know the overo model used in e100 and the largest data >>>>>>>>>>>>>> transfer rate between fpga and overo in e100. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards! >>>>>>>>>>>>>> >>>>>>>>>>>>>> ___ >>>>>>>>>>>>>> USRP-users mailing list >>>>>>>>>>>>>> usrp-us...@lists.ettus.com >>>>>>>>>>>>>> >>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ___ >>>>>>>>>> USRP-users mailing list >>>>>>>>>> usrp-us...@lists.ettus.com >>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>>>> >>>>>>>> >>>>>>>> ___ >>>>>>>> USRP-users mailing list >>>>>>>> usrp-us...@lists.ettus.com >>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> ___ >>>>>> USRP-users mailing list >>>>>> usrp-us...@lists.ettus.com >>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>> >>>>>> >>>>> >>>> ___ >>>> USRP-users mailing list >>>> usrp-us...@lists.ettus.com >>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> >>> >> >> >> >> -- >> >> Message: 3 >> Date: Wed, 30 May 2012 15:04:48 -0400 >> From: Josh Stevens >> To: discuss-gnuradio@gnu.org >> Subject: [Discuss-gnuradio] File sink file size mismatch problem. >> Message-ID: >> >> Content-Type: text/plain; charset="iso-8859-1" >> >> Hello All, >> >> A couple of days ago i had installed a GNURadio digital image >> processing block that makes an image source and sink block available as >> displayed in the image below. >> *Resource* : https://github.com/a-w-s/GNURadio-DIP >> *Flowgraph* : http://i.imgur.com/1lJzD.png >> >> The output of the image source and the input to the image sink are "floats" >> only and nothing else. I tried to collect pixel information into a file >> sink and i am successful at that but the problem comes in when the size of >> the input file size is not the same as the size of the file sink output. >> >> The image is a basic black and white test image called lena.bmp whose file >> size is 65.0 KB. The link to which is also provided below , >> *Resource to Image :* >> https://www.google.com/search?q=lena+256+x+256&hl=en&prmd=imvns&source=lnms&tbm=isch&ei=_G7GT7vkC4rs8wSG99SaBg&sa=X&oi=mode_link&ct=mode&cd=2&sqi=2&ved=0CD8Q_AUoAQ&biw=1280&bih=827 >> >> The file size of the received file (file sink) is 76.0 KB. >> >> The reason why I pay more attention to this is because i intend to >> calculate BER / Pixel Error Rate which would take into account a reference >> stream which in this case would be the file with the extra bits , and Image >> sink output ( or the demodulated output) . >> >> Please feel free to ask me any questions that one might have . >> >> Thanks and regards, >> Josh. >> -- next part -- >> An HTML attachment was scrubbed... >> URL: >> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120530/02e0b9e0/attachment.html> >> >> -- >> >> Message: 4 >> Date: Wed, 30 May 2012 20:33:26 -0500 >> From: Alex Zhang >> To: gnuradio mailing list >> Subject: [Discuss-gnuradio] How to dynamically stop the host PC >> receiving samples from USRP and restart it again without touching the >> top block? >> Message-ID: >> >> Content-Type: text/plain; charset="windows-1252" >> >> Hi, >> >> In my applications, after the flow graph is initialized, I need to >> dynamically control the receiving of the USRP samples, i.e, at time T1, I >> want the USRP to transfer the received samples to PC, while in T2, I do not >> allow the PC to receive these samples. >> Stop receiving the unusing packets from USRP can save the traffic over >> ethernet and decrease the demands of processing resource on host PC. >> >> the gr_mute block seems only suppress the incoming packets to further >> processing, but these unusing samples can still come into the flow graph. >> >> Also, the tb.run and tb.wait can be executed more than twice as wish, but >> it seems to be not so flexible. It would be good if there some commands >> called to control the block of uhd.usrp_source to achieve such purpose? >> -- >> >> Alex, >> *Dreams can come true ? just believe.* >> -- next part -- >> An HTML attachment was scrubbed... >> URL: >> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120530/c78fba1c/attachment.html> >> >> -- >> >> Message: 5 >> Date: Thu, 31 May 2012 14:41:36 +0800 >> From: "jiajue ou" >> To: >> Subject: [Discuss-gnuradio] QAM Mod and QAM Demod block in GRC >> Message-ID: <008b01cd3ef8$6d74e000$485ea000$@yahoo.com.cn> >> Content-Type: text/plain; charset="us-ascii" >> >> Hi all, >> >> >> >> I'm working on an experiment which needs to modify qam modulation block in >> gnuradio. But I cannot find the source C++ file the qam blocks use. e.g., >> OFDM demod block uses digital_ofdm_frame_sink in >> gnuradiobuild/gnuradio/gr-digital/lib. What about qam blocks? >> >> Thank you for your help! >> >> >> >> Best, >> >> jia >> >> -- next part -- >> An HTML attachment was scrubbed... >> URL: >> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20120531/3cf4a81d/attachment.html> >> >> -- >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> End of Discuss-gnuradio Digest, Vol 114, Issue 33 >> * > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
