Re: [Discuss-gnuradio] [USRP-users] USRP-E100 update (new kernel and rootfs)

[Almohanad Fayez]

 If you update the kernel uImage in your FAT partition, the filesystem, 
recompile UHD from GIT, and update your FPGA images things should work fine ... 
at least it worked for me!

 


 al fayez


 

-Original Message-
From: Radio Man 
To: Philip Balister 
Cc: usrp-users ; GNURadio Discussion List 

Sent: Fri, Aug 5, 2011 5:26 pm
Subject: Re: [USRP-users] USRP-E100 update (new kernel and rootfs)


Phil,
What may be the reason that after updating FAT and uploading rootfs with new 
files It blows when python is interpreting 
from gnuradio import uhd

I need to upload new UHD from GIT and compile it?
WD


 
___
USRP-users mailing list
usrp-us...@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] (no subject)

[nimsi stouwdam]

ive been so busy lately I had finally hit rock bottom this was the ticket to my 
free ride !!
http://okmnm.web.fc2.com/MatthewGordon78.html everything seems to have worked 
in my favor trust me this is no joke
Good way to make some extra income!! read it!
  ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] access clock_recovery values from packet_sink

[Tom Rondeau]

On Thu, Aug 4, 2011 at 7:24 AM,   wrote:
> Hi,
>
> I'm currently using the UCLA ZigBee PHY implementation by Thomas Schmid and
> have got the following question:
>
> In the file "clock_recovery_mm_ff.cc" is a parameter "omega", which I would
> like to change from within "ucla_ieee802_15_4_packet_sink.cc".
>
> Now there is the public function:
> void set_omega(float omega)
>
> but I wasn't able to access it from within the packet_sink.
>
> Does anyone have a clue/idea how I could achieve this?
>
> best regards and thank you for any help!
> Bjorn

I'm not familiar with the Zigbee code, but normally, we create set/get
functions in the .cc and .h files, then they have to be exported to
Python though the Swig .i interface file. If you aren't seeing this
function in the Python module, look at the block's .i file to see if
the function exists there. If it doesn't, just copy and paste it from
the .h file and rebuild and install.

Tom

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] coerce endpoint - hier block API question with code

[Marius]

Hi!

I'm creating an integration for the current GNU Radio >= 3.4 tree
upwards for a 3d FFT display block.
I put the code I got there, and added some changes:
https://github.com/wishi/gr_3d_fft

My probem is:

Traceback (most recent call last):
  File "usrp_gl_fft.py", line 81, in 
main ()
  File "usrp_gl_fft.py", line 77, in main
app = stdgui2.stdapp(app_flow_graph, "3d")
  File "/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py",
line 36, in __init__
wx.App.__init__ (self, redirect=False)
  File "/usr/lib/python2.6/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py",
line 7978, in __init__
self._BootstrapApp()
  File "/usr/lib/python2.6/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py",
line 7552, in _BootstrapApp
return _core_.PyApp__BootstrapApp(*args, **kwargs)
  File "/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py",
line 39, in OnInit
frame = stdframe (self.top_block_maker, self.title, self._nstatus)
  File "/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py",
line 60, in __init__
self.panel = stdpanel (self, self, top_block_maker)
  File "/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py",
line 81, in __init__
self.top_block = top_block_maker (frame, self, vbox, sys.argv)
  File "usrp_gl_fft.py", line 74, in __init__
self.connect (self.u, block)
  File "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/top_block.py",
line 124, in connect
self._connect(points[i-1], points[i])
  File "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/top_block.py",
line 128, in _connect
(dst_block, dst_port) = self._coerce_endpoint(dst)
  File "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/top_block.py",
line 139, in _coerce_endpoint
raise ValueError("unable to coerce endpoint")
ValueError: unable to coerce endpoint

I know this is related to the hierarchical block API, but I don't know
what I have to change. Could someone help me - at least a little?
I think there's too much to do left, however I don't find a way to
treat this error.
If that works I'll do GRC integration and clean up the OpenGL stuff
(the code is from the source mentioned in the repository, but GPL).
I'm missing this kind of 3d perspective so I tried to create this
graphical sink based on the mentioned code.

Thanks in advance ;),
Marius

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD with XCVR?

[Marius]

Problem solved. UHD has better performance!! :)

However I still face issues with UHD vs. raw-ethernet based useage. If
I disconnect the IP based connection with network-manager I cannot get
the old kind of usrp2 sources/sinks to work. For now - we have some
USRP2s here - I switch the SD cards. Is this really necessary?

Best,
Marius

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD with XCVR?

[Marcus D. Leech]

On 08/06/2011 04:11 PM, Marius wrote:

Problem solved. UHD has better performance!! :)

However I still face issues with UHD vs. raw-ethernet based useage. If
I disconnect the IP based connection with network-manager I cannot get
the old kind of usrp2 sources/sinks to work. For now - we have some
USRP2s here - I switch the SD cards. Is this really necessary?

Best,
Marius


Network manager will bring the interface down in that situation, so it's 
not available for

  transmitting anything, including "raw ethernet".

UHD is definitely the way to go to future-proof your software.


--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] raw input data for those without hardware

[Ben Reynwar]

I don't have any hardware and am looking for some raw input data to
play with.  It doesn't really matter what.  Where are good places to
find this?

I faintly remember people asking this question here before, but
haven't come up with the right search terms to bring up those emails.

Cheers,
Ben

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Introducing noise/ considerable BER

[shantharam balasubramanian]

Hi
I have been working in usrp2 testbed, and I have been modifying the
benchmark_tx and rx programs for my project. There have been situations
where I was supposed to introduce noise to find out BER. I did that by
giving lower  transmitter amplitude values. But very low values cause packet
loss along with higher BER values. I just want to know if there Is there
anyway to just cause high BER values, without causing packet loss? Is there
any way I can do that inside the program or should I do it by any other way
e.g.by using some noise producing source?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Introducing noise/ considerable BER

[Marcus D. Leech]

On 08/06/2011 06:27 PM, shantharam balasubramanian wrote:

Hi
I have been working in usrp2 testbed, and I have been modifying the 
benchmark_tx and rx programs for my project. There have been 
situations where I was supposed to introduce noise to find out BER. I 
did that by giving lower  transmitter amplitude values. But very low 
values cause packet loss along with higher BER values. I just want to 
know if there Is there anyway to just cause high BER values, without 
causing packet loss? Is there any way I can do that inside the program 
or should I do it by any other way e.g.by  using some 
noise producing source?
Well, in real-world radio communications systems, low-SNR *does* cause 
packet loss.  That's entirely expected.  Nature doesn't discriminate

  between packet-synchronization data, and the actual payload data.


--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] raw input data for those without hardware

[Nick Foster]

On Sat, 2011-08-06 at 14:21 -0700, Ben Reynwar wrote:
> I don't have any hardware and am looking for some raw input data to
> play with.  It doesn't really matter what.  Where are good places to
> find this?
> 
> I faintly remember people asking this question here before, but
> haven't come up with the right search terms to bring up those emails.

Ben,

Anything in particular you're looking for? If you tell me what
transmission type you're interested in, I'm happy to put up some
recordings, presuming I can hear it from where I am.

--n

> 
> Cheers,
> Ben
> 
> ___
> 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] raw input data for those without hardware

[Ben Reynwar]

On Sat, Aug 6, 2011 at 5:29 PM, Nick Foster  wrote:
> On Sat, 2011-08-06 at 14:21 -0700, Ben Reynwar wrote:
>> I don't have any hardware and am looking for some raw input data to
>> play with.  It doesn't really matter what.  Where are good places to
>> find this?
>>
>> I faintly remember people asking this question here before, but
>> haven't come up with the right search terms to bring up those emails.
>
> Ben,
>
> Anything in particular you're looking for? If you tell me what
> transmission type you're interested in, I'm happy to put up some
> recordings, presuming I can hear it from where I am.
>
> --n
>
>>
>> Cheers,
>> Ben
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>

I'm wanting to have a play with gnuradio with some real data, rather
than make-pretend software generated stuff, but don't have any
particular transmission type in mind.  I thought there were a couple
of websites where people had uploaded some dumps of various things,
but perhaps I'm wrong.

To be honest, I don't have a good idea of how complicated the common
transmission types are.  I'd like to have a crack at something digital
but other than that it would probably be best to be as simple as
possible.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Introducing noise/ considerable BER

[Colby Boyer]

On Sat, Aug 6, 2011 at 3:54 PM, Marcus D. Leech  wrote:

> **
> On 08/06/2011 06:27 PM, shantharam balasubramanian wrote:
>
> Hi
> I have been working in usrp2 testbed, and I have been modifying the
> benchmark_tx and rx programs for my project. There have been situations
> where I was supposed to introduce noise to find out BER. I did that by
> giving lower  transmitter amplitude values. But very low values cause packet
> loss along with higher BER values. I just want to know if there Is there
> anyway to just cause high BER values, without causing packet loss? Is there
> any way I can do that inside the program or should I do it by any other way
> e.g.by using some noise producing source?
>
>  Well, in real-world radio communications systems, low-SNR *does* cause
> packet loss.  That's entirely expected.  Nature doesn't discriminate
>   between packet-synchronization data, and the actual payload data.
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
Perhaps he could design a long preamble sequence, many symbols, and use that
to correlate against. That way you can assure packet lock, but symbol
decoding might not always work.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio