Re: [Discuss-gnuradio] Gigabit Ethernet cards

[Daniel O'Connor]

On 09/07/2010, at 1:31, Marcus D. Leech wrote:

> On 07/08/2010 11:50 AM, Lamar Owen wrote:
>> Since you said PCI, I'm assuming this isn't a PCI Express box we're talking 
>> about here, since that changes everything.  A single lane PCI-e slot is 
>> capable of 250MB/s throughput, if the chipset can keep up.  Typical server 
>> GigE cards for PCI-e can have two or four ports and need a four lane slot; 
>> if you have dual PCI-e x16 slots, use the secondary x16 slot in x4 mode.
>> 
>> 
>> 
> I have a PCIe x16 slot on the mobo, it's a GigaByte GA-880GM-UD2H, so I
> guess what I really need is a
>  PCIe GiGE card.

I use this http://www.newegg.com/Product/Product.aspx?Item=N82E16833106033 in 
my home (FreeBSD) server.
(When I ordered it it came with full height and LP plates but I didn't get it 
from Newegg so YMMV)

Never used it with a USRP2 though, however Intel em cards are widely regarded 
as being very good.

If you really did mean PCI instead of PCI express then I think I had one of 
these in an older server..
http://www.newegg.com/Product/Product.aspx?Item=N82E16833106122&Tpk=PWLA8391GTLBLK

It was also an excellent performer.

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C







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

[Discuss-gnuradio] Patch to increasy dynamic range of usrp2 by adding shift_iq setting

[Martin DvH]

Hi All,

I created a patch which adds a shift_iq setting to the usrp2.
This can shift the output of dsp_core_rx by 0 to 3 bits.
(= Multiply by 1, 2, 4 or 8)

It does proper rounding and clipping.

With the shift_iq setting in combination with the already existing
scale_iq you can optimize the dynamic range so that the samples going to
the PC always use the full 16 bit [-32768 to + 32767]

In practice this means a dynamic range increase of 6 dB or more.

Of course, if you set the shift to high you will get clipping.

The patch changes the fpga verilog, fpga firmware, usrp2, and gr-usrp
sources.


I did several icarus verilog simulations which came out OK.

I also created a python testscript which uses the actual usrp2. It
generates a 200 kHz signal on TX and receives it with RX.
(you need to loopback TX to RX using basicRX/TX or LFTX/RX boards.)
With the GUI you can set scale_iq and shift_iq.

I generated a new u2_rev3.bin and txrx.bin which seem to work fine.
Note that this firmware is based on my current git checkout.
So if you want to have this feature with the lastest code, you have to
apply my patch to the latest tree and generate new firmware yourself.

I created this patch on request, so it would be great if it were added
to the official tree. (So the default firmware can be used in the future
to have this function)

Patch and a testscript at:
http://www.olifantasia.com/projects/gnuradio/mdvh/usrp2_add_shift_iq/


Martin Dudok van Heel

diff --git a/gr-usrp2/src/usrp2.i b/gr-usrp2/src/usrp2.i
index 3197402..e960372 100644
--- a/gr-usrp2/src/usrp2.i
+++ b/gr-usrp2/src/usrp2.i
@@ -72,6 +72,7 @@ public:
   bool set_center_freq(double frequency, usrp2::tune_result *r);
   bool set_decim(int decimation_factor);
   bool set_scale_iq(int scale_i, int scale_q);
+  bool set_shift_iq(int shift_q, int shift_i);
   int decim();
   %rename(_real_adc_rate) adc_rate;
   bool adc_rate(long *rate);
diff --git a/gr-usrp2/src/usrp2_source_base.cc b/gr-usrp2/src/usrp2_source_base.cc
index 0ad7008..12fcd88 100644
--- a/gr-usrp2/src/usrp2_source_base.cc
+++ b/gr-usrp2/src/usrp2_source_base.cc
@@ -76,6 +76,12 @@ usrp2_source_base::set_scale_iq(int scale_i, int scale_q)
   return d_u2->set_rx_scale_iq(scale_i, scale_q);
 }
 
+bool 
+usrp2_source_base::set_shift_iq(int shift_q, int shift_i)
+{
+  return d_u2->set_rx_shift_iq(shift_q, shift_i);
+}
+
 int
 usrp2_source_base::decim()
 {
diff --git a/gr-usrp2/src/usrp2_source_base.h b/gr-usrp2/src/usrp2_source_base.h
index 2e2d51f..d318ad9 100644
--- a/gr-usrp2/src/usrp2_source_base.h
+++ b/gr-usrp2/src/usrp2_source_base.h
@@ -61,11 +61,24 @@ public:
   bool set_decim(int decimation_factor);
 
   /*!
-   * \brief Set receive IQ scale factors
+   * \brief Set receive IQ input scale factors
*/
   bool set_scale_iq(int scale_i, int scale_q);
 
   /*!
+   * \brief Set receive IQ output shift
+   * shift 0 (default) scales by 1
+   * shift 1 scales by 2
+   * shift 2 scales by 4
+   * shift 3 scales by 8
+   * Note that with a shift >0 overflow and clipping can occur.
+   * This can be resolved by reducing scale_iq to below the default 1024.
+   * By using a shift of 1 or 2 and reducing scale_iq,
+   * the full 16 bit output range (-32768 to +32767) can be used
+   */
+  bool set_shift_iq(int shift_q, int shift_i);
+
+  /*!
* \brief Get receive decimation rate
*/
   int decim();
diff --git a/usrp2/firmware/apps/app_common_v2.c b/usrp2/firmware/apps/app_common_v2.c
index 036d0ba..54bef3f 100644
--- a/usrp2/firmware/apps/app_common_v2.c
+++ b/usrp2/firmware/apps/app_common_v2.c
@@ -272,6 +272,9 @@ config_rx_v2_cmd(const op_config_rx_v2_t *p,
   if (p->valid & CFGV_SCALE_IQ){
 dsp_rx_regs->scale_iq = p->scale_iq;
   }
+  if (p->valid & CFGV_SHIFT_IQ){
+dsp_rx_regs->shift_iq = p->shift_iq;
+  }
 
   // Build reply subpacket
 
diff --git a/usrp2/firmware/include/usrp2_eth_packet.h b/usrp2/firmware/include/usrp2_eth_packet.h
index 63d4b3a..b1db5ac 100644
--- a/usrp2/firmware/include/usrp2_eth_packet.h
+++ b/usrp2/firmware/include/usrp2_eth_packet.h
@@ -283,6 +283,7 @@ typedef struct {
   uint32_t	freq_lo;	// low  32-bits of 64-bit fxpt_freq (Q44.20)
   uint32_t	decim;		// desired decimation factor (NOT -1)
   uint32_t	scale_iq;	// (scale_i << 16) | scale_q [16.0 format]
+  uint32_t	shift_iq;	// (shift_i <<  4) | shift_q  [0, 1, 2 or 3]
 } _AL4 op_config_rx_v2_t;
 
 // bitmask for "valid" field.  If the bit is set, there's
@@ -292,7 +293,7 @@ typedef struct {
 #define	CFGV_FREQ		0x0002	// target_freq field is valid
 #define	CFGV_INTERP_DECIM	0x0004	// interp or decim is valid
 #define	CFGV_SCALE_IQ		0x0008	// scale_iq is valid
-
+#define	CFGV_SHIFT_IQ		0x0010	// shift_iq is valid
 /*!
  * \brief Reply to receiver configuration
  */
diff --git a/usrp2/firmware/lib/memory_map.h b/usrp2/firmware/lib/memory_map.h
index 0d0cf04..14b5f7b 100644
--- a/usrp2/firmware/lib/memory_map.h
+++ b/usrp2/firmware/lib/memory_map.h
@@ -500,6 +500,32 @@ typedef struct {
*/
   volatile u

Re: [Discuss-gnuradio] gnuradio with alternate python

[Catalin Patulea]

On Sat, Jun 26, 2010 at 10:29 PM, Josh Blum  wrote:
> Somehow distutils solves this problem:
> http://docs.python.org/release/2.5.2/dist/node11.html
> If you figure out what its calling, perhaps we could port that the
> gnuradio build system
The code that does this can be seen here:
http://svn.python.org/view/python/trunk/Lib/distutils/command/build_scripts.py?revision=77704&view=markup

They use the following regexp:
^#!.*python[0-9.]*([ \t].*)?$

This handles both things like /usr/bin/env python and
/usr/local/bin/python, which is nice in the general case but not
particularly relevant for GR. They also restrict the match to the
first line of the file, which I think is prudent.

One thing about the @@PYTHON@@ option is it would make the scripts no
longer executable directly from the tree. Arguably you could still
execute them using "python 

Re: [Discuss-gnuradio] Re: Help required tunnel.py

[Tuan Ta]

Unfortunately tunnel.py in the ofdm folder doesn't work for me either. Since
you had benchmark_ofdm_* running, I would use the same settings for tunnel.
I don't even have benchmark_ofdm_* going at any setting. I'm trying to get a
hold of a spectrum analyzer. Hopefully it would help to clear things up.

A quick question: what bit rate did you use for your benchmark_tx/rx? The
default bit rate is 100kbps, which would get bumped up to 125kbps.

Tuan

On Thu, Jul 8, 2010 at 2:17 PM, chuck lorres wrote:

>
>  Thanks for your reply.
> Well I am trying to run the tunnel.py in ofdm folder. However there is no
> bit rate option in it.
> If you have been able to successfully run it, please send me the parameters
> that you changed?
> I have tried all day to run it but to no avail.
> Not even a single packet is being sensed.
> In digital folders tunnel.py is running perfectly.
> Thanks.
>
> --
> Date: Thu, 8 Jul 2010 13:07:04 -0400
>
> Subject: Re: [Discuss-gnuradio] Re: Help required tunnel.py
> From: ta.tu...@gmail.com
> To: chucklor...@hotmail.com; discuss-gnuradio@gnu.org
>
> I finally found a setting that actually works. So the real problem I think
> lies in the bit rate. I had no communication whatsoever in low bit rate
> (~250k). I started to have unreliable comm. at 500k and at 1Mbps I got no
> packet drops for tunnel.py. However, even at 1Mbps I still got about 5%
> drops using benchmark_* (always at the end).
>
> My theory is that lower bit rate corresponds to lower signal bandwidth. I
> think in some mixer/filter stage the frequency offset is too large thus push
> all of my useful bandwidth out of the passing band. With higher bandwidth, a
> large path of the useful bandwidth remains in spite of the frequency offset,
> thus the receiver was able to pick up some thing. Lower bandwidth works fine
> for Chuck so he might not have the frequency offset problem.
>
> Let me know if anyone has a better explanation.
>
> Tuan
>
> On Thu, Jul 8, 2010 at 11:12 AM, chuck lorres wrote:
>
>
> *-How far apart are your boards?*
> 1meter apart
>
> *- What options did you use to run tunnel, benchmark_ofdm_*, benchmark_*.*
> default with 2.41G frequency.
>
> *- When you run benchmark_*, did you get a lot of packet drops at the end
> of transmission (about 15%)?*
> perfect reception was observed. 0 packets were dropped.
>
>
>
>
> --
> Date: Thu, 8 Jul 2010 11:09:30 -0400
>
> Subject: Re: [Discuss-gnuradio] Re: Help required tunnel.py
> From: ta.tu...@gmail.com
> To: chucklor...@hotmail.com; discuss-gnuradio@gnu.org
>
>
> That's pretty much the same settings that I have. Can you clarify a bit
> more:
>
> - How far apart are your boards?
>
> - What options did you use to run tunnel, benchmark_ofdm_*, benchmark_*.
>
> - When you run benchmark_*, did you get a lot of packet drops at the end of
> transmission (about 15%)?
>
> Thanks a lot,
>
> Tuan
>
> On Thu, Jul 8, 2010 at 10:55 AM, chuck lorres wrote:
>
>  I am using RFX 2400,  gnuradio 3.2.2,  ubuntu 9.10 and 9.04 on another
>
>
> --
> Date: Thu, 8 Jul 2010 10:48:24 -0400
> Subject: Re: [Discuss-gnuradio] Re: Help required tunnel.py
> From: ta.tu...@gmail.com
> To: chucklor...@hotmail.com
> CC: discuss-gnuradio@gnu.org
>
>
> Chuck,
>
> What hardware are you using?
>
> On Thu, Jul 8, 2010 at 10:38 AM, chuck lorres wrote:
>
>  Hi,
> I have successfully run digital folders tunnel.py.
> However, I am not receiving anything when i run the ofdm folder tunnel.py.
> Whereas the benchmark_ofdm_tx+rx.py is running perfectly.
> I have varied almost all the available parameters but to no avail.
> Please help me out.
> Thanks in advance.
> Chuck.
>
>
> --
> Hotmail: Free, trusted and rich email service. Get it 
> now.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> --
> Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. Sign up
> now. 
>
>
>
> --
> Hotmail: Free, trusted and rich email service. Get it 
> now.
>
>
>
> --
> Hotmail: Trusted email with Microsoft’s powerful SPAM protection. Sign up
> now. 
> --
> Hotmail: Trusted email with powerful SPAM protection. Sign up 
> now.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Re: Help required tunnel.py

[chuck lorres]

 Thanks for your reply.Well I am trying to run the tunnel.py in ofdm folder. 
However there is no bit rate option in it.If you have been able to successfully 
run it, please send me the parameters that you changed?I have tried all day to 
run it but to no avail.Not even a single packet is being sensed.In digital 
folders tunnel.py is running perfectly.Thanks.

Date: Thu, 8 Jul 2010 13:07:04 -0400
Subject: Re: [Discuss-gnuradio] Re: Help required tunnel.py
From: ta.tu...@gmail.com
To: chucklor...@hotmail.com; discuss-gnuradio@gnu.org

I finally found a setting that actually works. So the real problem I think lies 
in the bit rate. I had no communication whatsoever in low bit rate (~250k). I 
started to have unreliable comm. at 500k and at 1Mbps I got no packet drops for 
tunnel.py. However, even at 1Mbps I still got about 5% drops using benchmark_* 
(always at the end).


My theory is that lower bit rate corresponds to lower signal bandwidth. I think 
in some mixer/filter stage the frequency offset is too large thus push all of 
my useful bandwidth out of the passing band. With higher bandwidth, a large 
path of the useful bandwidth remains in spite of the frequency offset, thus the 
receiver was able to pick up some thing. Lower bandwidth works fine for Chuck 
so he might not have the frequency offset problem.


Let me know if anyone has a better explanation. 

Tuan

On Thu, Jul 8, 2010 at 11:12 AM, chuck lorres  wrote:







-How far apart are your boards?
1meter apart
- What options did you use to run tunnel, benchmark_ofdm_*, benchmark_*.
default with 2.41G frequency.
- When you run benchmark_*, did you get a lot of packet drops at the end of 
transmission (about 15%)?

perfect reception was observed. 0 packets were dropped.




Date: Thu, 8 Jul 2010 11:09:30 -0400
Subject: Re: [Discuss-gnuradio] Re: Help required tunnel.py
From: ta.tu...@gmail.com

To: chucklor...@hotmail.com; discuss-gnuradio@gnu.org


That's pretty much the same settings that I have. Can you clarify a bit more:

- How far apart are your boards?

- What options did you use to run tunnel, benchmark_ofdm_*, benchmark_*.

- When you run benchmark_*, did you get a lot of packet drops at the end of 
transmission (about 15%)?



Thanks a lot,

Tuan

On Thu, Jul 8, 2010 at 10:55 AM, chuck lorres  wrote:







I am using RFX 2400,  gnuradio 3.2.2,  ubuntu 9.10 and 9.04 on another


Date: Thu, 8 Jul 2010 10:48:24 -0400
Subject: Re: [Discuss-gnuradio] Re: Help required tunnel.py
From: ta.tu...@gmail.com


To: chucklor...@hotmail.com
CC: discuss-gnuradio@gnu.org


Chuck,

What hardware are you using?

On Thu, Jul 8, 2010 at 10:38 AM, chuck lorres  wrote:








Hi,
I have successfully run digital folders tunnel.py.
However, I am not receiving anything when i run the ofdm folder tunnel.py.
Whereas the benchmark_ofdm_tx+rx.py is running perfectly.
I have varied almost all the available parameters but to no avail.



Please help me out.
Thanks in advance.
Chuck.

  
Hotmail: Free, trusted and rich email service. Get it now.




___

Discuss-gnuradio mailing list

Discuss-gnuradio@gnu.org

http://lists.gnu.org/mailman/listinfo/discuss-gnuradio



  
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. Sign up now.



  
Hotmail: Free, trusted and rich email service. Get it now.

  
Hotmail: Trusted email with Microsoft’s powerful SPAM protection. Sign up now.  
  
_
Hotmail: Trusted email with powerful SPAM protection.
https://signup.live.com/signup.aspx?id=60969___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP2 and Data Rate

[Garrett Wenger]

I went ahead and locked the USRP2 to my signal analyzer's reference clock
and that seemed to knock the error down to about 11-14%, which is obviously
much improved.

However, I then looked at the signal on an oscilloscope and it looks like
the USRP2 is sending out short bursts of data instead of a continuous signal
like I see when using the USRP1.  Both boards are using the Flex1800
daughterboard and are transmitting at 1.8GHz.  Is there some reason the
USRP2 would not be able to send data continuously even if the programs I've
been running are exactly the same?



On Wed, Jul 7, 2010 at 2:53 PM, Matt Ettus  wrote:

> On 07/07/2010 11:43 AM, Garrett Wenger wrote:
>
>> I am not quite sure what data rate I am getting.  I've been using a
>> signal analyzer to receive and demod what I'm transmitting and it can
>> generally pick up the bit sequence that I am now sending out, but I get
>> an error rate the fluctuates from about 5% all the way up to 70% or
>> higher.
>> My cpfsk mod index is set to 1 and the distance between the peaks is
>> about 10kHz, so it really seems like my data rate is somewhere around
>> what I want it to be, but the error rate is just way to high.
>>
>
> The problem is likely to be frequency offset.  I don't know your carrier
> frequency, but at 1 GHz, 10 ppm is 10 kHz.  So your 10 kHz wide signal at 1
> GHz could be completely out of the passband if the oscillators are off by 10
> ppm or more.  The USRP1 oscillator is typically 5-10 ppm but the spec is 20
> ppm, and the USRP2 is typically 10-20 ppm when not locked.
>
>
>
>> Also, I went ahead and added in the interpolating filter like you
>> suggested, but just for future reference, what is bad about having a
>> high samples per symbol value?
>>
>
> In theory, nothing.  In practice, a couple of things.  The higher the
> samples per symbol the longer your filters need to be.  Also, the filters in
> there are chosen for good timing recovery properties, not for out of band
> rejection.  By having so many samples per symbol, you get a lot more out of
> band energy which needs to be rejected.
>
> Matt
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD Announcement - July 6th 2010

[Josh Blum]

The make takes a device_addr_t which means you may pass in the formatted 
string or a device_addr_t dictionary object:


mimo_usrp::make("addr=192.168.10.11 192.168.20.11")

or

device_addr_t dev_addr;
dev_addr["addr"] = "192.168.10.11 192.168.20.11"
mimo_usrp::make(dev_addr);

-Josh

On 07/08/2010 05:30 AM, Per Zetterberg wrote:


If I use the UHD driver directly (i.e. not using gnuradio framework) should I call 
"mimo_usrp::make" with argument "addr=192.168.10.11 192.168.20.11 192.168.30.11 
192.168.40.11, addr=192.168.10.11 192.168.20.11 192.168.30.11 192.168.40.11" to achieve the 
same or how should the string be formatted ?


BR/
Per



From: discuss-gnuradio-bounces+perz=kth...@gnu.org 
[discuss-gnuradio-bounces+perz=kth...@gnu.org] on behalf of Zohair 
[zohair...@hotmail.com]
Sent: Thursday, July 08, 2010 12:16 PM
To: Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] UHD Announcement - July 6th 2010

Dear Josh,
I have successfully installed the UHD branch from jblum.git repo and have
tried out using the MIMO sources available. I have a few points to raise
here regarding this release and block:

1- I am using a PC with four Ethernet ports. I burned the firmware and the
fpga images created on 6-7-2010. Also, I tried assigning IP addresses from
the same subnetwork: 192.168.10.X/24. However, Only a single USRP2 is
discovered at a time while others are unreachable. (USRP2s IPs are also from
the same subnetwork above)

2- Then I tried assigning IPs from 4 different subnetworks to the USRP2's,
and all them  can be discovered normally. Is it possible that they work
using IPs from the same subnetwork or not? (case 1)

3- I used a MIMO source with 4 outputs and the following settings:
freq: 241400, 241400, 241400, 241400
Arg: addr=192.168.10.11 192.168.20.11 192.168.30.11 192.168.40.11,
recv_buff_size=50e6 50e6 50e6 50e6
sample rate: 195.312K ( Firstly, I used 32K but at runtime I was prompted
to use this value)
Gain= 35,35,35,35
Antennas= [‘RX2’, ‘RX2’, ‘RX2’, ‘RX2’]

I connected the 4 outputs to graphic scopes but once I run the flowgraph, I
see this error messages:

terminate called after throwing an instance of
'boost::exception_detail::clone_impl

'

   what():  bad lexical cast: source type value could not be interpreted as
target.

I have Boost 1.38.0 installed and I did use this command for configuration:
./configure --with-boost=$BOOST_PREFIX

Any advice or help regarding this issue, please?

Best regards,

Zohair
--
View this message in context: 
http://old.nabble.com/UHD-Announcement---July-6th-2010-tp29091756p29105404.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___


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


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

Re: [Discuss-gnuradio] UHD Announcement - July 6th 2010

[Josh Blum]

Zohair,



1- I am using a PC with four Ethernet ports. I burned the firmware and the
fpga images created on 6-7-2010. Also, I tried assigning IP addresses from
the same subnetwork: 192.168.10.X/24. However, Only a single USRP2 is
discovered at a time while others are unreachable. (USRP2s IPs are also from
the same subnetwork above)

2- Then I tried assigning IPs from 4 different subnetworks to the USRP2's,
and all them  can be discovered normally. Is it possible that they work
using IPs from the same subnetwork or not? (case 1)



The goal is to setup your networking on your such that all devices are 
accessible (ie your computer knows how to route udp/ip packets to the 
correct device based on ip address). The easiest way to use use a 
different subnet per ethernet card. 192.168.X.Y and burn each usrp with 
the corresponding address 192.168.X.Z. If you play around with subnet 
masks you can get other configurations.



3- I used a MIMO source with 4 outputs and the following settings:
freq: 241400, 241400, 241400, 241400
Arg: addr=192.168.10.11 192.168.20.11 192.168.30.11 192.168.40.11,
recv_buff_size=50e6 50e6 50e6 50e6
sample rate: 195.312K ( Firstly, I used 32K but at runtime I was prompted
to use this value)


What you probably saw was a warning that the system could not 
automatically request a large enough buffer.


http://www.ettus.com/uhd_docs/manual/html/usrp2.html#os-specific-notes

Also, you can only specify one buffer size across all boards. If you 
think about it the setup should be uniform per board.



Gain= 35,35,35,35
Antennas= [‘RX2’, ‘RX2’, ‘RX2’, ‘RX2’]

I connected the 4 outputs to graphic scopes but once I run the flowgraph, I
see this error messages:

terminate called after throwing an instance of
'boost::exception_detail::clone_impl

'

   what():  bad lexical cast: source type value could not be interpreted as
target.



it cant cast a "50e6 50e6 50e6 50e6" to a double. I need to catch these 
error and throw meaning full exceptions. :-)


Thanks for asking, it seems that I need to add more to the docs and 
polish. -Josh


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

Re: [Discuss-gnuradio] Re: Help required tunnel.py

[Tuan Ta]

I finally found a setting that actually works. So the real problem I think
lies in the bit rate. I had no communication whatsoever in low bit rate
(~250k). I started to have unreliable comm. at 500k and at 1Mbps I got no
packet drops for tunnel.py. However, even at 1Mbps I still got about 5%
drops using benchmark_* (always at the end).

My theory is that lower bit rate corresponds to lower signal bandwidth. I
think in some mixer/filter stage the frequency offset is too large thus push
all of my useful bandwidth out of the passing band. With higher bandwidth, a
large path of the useful bandwidth remains in spite of the frequency offset,
thus the receiver was able to pick up some thing. Lower bandwidth works fine
for Chuck so he might not have the frequency offset problem.

Let me know if anyone has a better explanation.

Tuan

On Thu, Jul 8, 2010 at 11:12 AM, chuck lorres wrote:

>
> *-How far apart are your boards?*
> 1meter apart
>
> *- What options did you use to run tunnel, benchmark_ofdm_*, benchmark_*.*
> default with 2.41G frequency.
>
> *- When you run benchmark_*, did you get a lot of packet drops at the end
> of transmission (about 15%)?*
> perfect reception was observed. 0 packets were dropped.
>
>
>
>
> --
> Date: Thu, 8 Jul 2010 11:09:30 -0400
>
> Subject: Re: [Discuss-gnuradio] Re: Help required tunnel.py
> From: ta.tu...@gmail.com
> To: chucklor...@hotmail.com; discuss-gnuradio@gnu.org
>
>
> That's pretty much the same settings that I have. Can you clarify a bit
> more:
>
> - How far apart are your boards?
>
> - What options did you use to run tunnel, benchmark_ofdm_*, benchmark_*.
>
> - When you run benchmark_*, did you get a lot of packet drops at the end of
> transmission (about 15%)?
>
> Thanks a lot,
>
> Tuan
>
> On Thu, Jul 8, 2010 at 10:55 AM, chuck lorres wrote:
>
>  I am using RFX 2400,  gnuradio 3.2.2,  ubuntu 9.10 and 9.04 on another
>
>
> --
> Date: Thu, 8 Jul 2010 10:48:24 -0400
> Subject: Re: [Discuss-gnuradio] Re: Help required tunnel.py
> From: ta.tu...@gmail.com
> To: chucklor...@hotmail.com
> CC: discuss-gnuradio@gnu.org
>
>
> Chuck,
>
> What hardware are you using?
>
> On Thu, Jul 8, 2010 at 10:38 AM, chuck lorres wrote:
>
>  Hi,
> I have successfully run digital folders tunnel.py.
> However, I am not receiving anything when i run the ofdm folder tunnel.py.
> Whereas the benchmark_ofdm_tx+rx.py is running perfectly.
> I have varied almost all the available parameters but to no avail.
> Please help me out.
> Thanks in advance.
> Chuck.
>
>
> --
> Hotmail: Free, trusted and rich email service. Get it 
> now.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> --
> Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. Sign up
> now. 
>
>
>
> --
> Hotmail: Free, trusted and rich email service. Get it 
> now.
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Gigabit Ethernet cards

[Lamar Owen]

On Thursday, July 08, 2010 12:01:53 pm Marcus D. Leech wrote:
> I have a PCIe x16 slot on the mobo, it's a GigaByte GA-880GM-UD2H, so I
> guess what I really need is a
>   PCIe GiGE card.

Broadcom is the biggest player in this market; eBay item # 150455393659 is one 
such example and only needs a x1 PCI-e slot.  The BCM57xx drivers are in-kernel 
and fairly robust.  This is the chip used by my laptop:

09:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5752 Gigabit 
Ethernet PCI Express (rev 02)
Subsystem: Dell Device 01c8
Flags: bus master, fast devsel, latency 0, IRQ 30
Memory at dcef (64-bit, non-prefetchable) [size=64K]
Expansion ROM at  [disabled]
Capabilities: [48] Power Management version 2
Capabilities: [50] Vital Product Data
Capabilities: [58] MSI: Enable+ Count=1/8 Maskable- 64bit+
Capabilities: [d0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [13c] Virtual Channel
Kernel driver in use: tg3
Kernel modules: tg3

There's also an HP NC110T on eBay ( item # 140423322343 ).  This card uses the  
Intel 82572G1 chipset, and it is a server-type adapter.  The eBay one is 
actually more expensive than one I found online a few minutes ago NIB, so 
google for it.

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

Re: [Discuss-gnuradio] Gigabit Ethernet cards

[Marcus D. Leech]

On 07/08/2010 11:50 AM, Lamar Owen wrote:
> Since you said PCI, I'm assuming this isn't a PCI Express box we're talking 
> about here, since that changes everything.  A single lane PCI-e slot is 
> capable of 250MB/s throughput, if the chipset can keep up.  Typical server 
> GigE cards for PCI-e can have two or four ports and need a four lane slot; if 
> you have dual PCI-e x16 slots, use the secondary x16 slot in x4 mode.
>
>
>   
I have a PCIe x16 slot on the mobo, it's a GigaByte GA-880GM-UD2H, so I
guess what I really need is a
  PCIe GiGE card.



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



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

Re: [Discuss-gnuradio] Gigabit Ethernet cards

[Lamar Owen]

On Friday, July 02, 2010 04:40:42 pm Marcus D. Leech wrote:
> I suspect that my GiGE NIC may be dropping packets.  It's an
> RTL8168d-type chip, according to "dmesg".
> 
> Are there known-to-be-good-with-GnuRadio NICs for PCI with low-profile
> brackets out there?  This is for
>   a 2U server platform.

As I don't have a USRP2, and probably won't be getting one any time soon, I 
can't help with that element of the question.

What I can help with is the low-profile GigE business. 

If these are 32-bit slots, and if there are other bandwidth hogs on the same 
bus (like a VGA card or hard disk controller/HBA), you simply run out of PCI 
bandwidth trying to do full-rate GigE (32-bit slots, 33MHz signalling, 133MB/s 
absolute max across the shared bus).  

My 2U personal server platform is a Supermicro dual Xeon (not the Dell 2850 
I've mentioned in relation to another project, but this is my own personal 
box), which has four complete PCI-X busses, two of which can run 64-bit cards 
in 133MHz signaled sockets, giving a max of 1066MB/s (the actual clock is 
133.33MHz, thus the data isn't 1064MB/s),  I have a dual Intel PRO/1000 
MT card with deep buffers, low-profile, and a 64-bit interface, sitting alone 
on one of the board's PCI-X busses.  It actually can't run at 133MHz, but can 
at 66MHz, but that's still 533MB/s data rates).  Got it on eBay for $39.95, 
NIB.  There's one on eBay now for that price; there's also a single port for 
$29.  Search for 'low profile PCI-X Intel' and those two are the only hits, as 
of 11:45A EDT, today.

The e1000 driver does have its issues, but it's been solid for me with Fedora 
13 for a few weeks now, and it was solid with CentOS 5 for months before that.

Since you said PCI, I'm assuming this isn't a PCI Express box we're talking 
about here, since that changes everything.  A single lane PCI-e slot is capable 
of 250MB/s throughput, if the chipset can keep up.  Typical server GigE cards 
for PCI-e can have two or four ports and need a four lane slot; if you have 
dual PCI-e x16 slots, use the secondary x16 slot in x4 mode.

Here's the lspci -a output for the above card:
05:01.0 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet 
Controller (Copper) (rev 01)
Subsystem: Intel Corporation PRO/1000 MT Dual Port Server Adapter
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 96
Memory at e852 (64-bit, non-prefetchable) [size=128K]
I/O ports at 5400 [size=64]
Capabilities: [dc] Power Management version 2
Capabilities: [e4] PCI-X non-bridge device
Capabilities: [f0] MSI: Enable- Count=1/1 Maskable- 64bit+
Kernel driver in use: e1000
Kernel modules: e1000

05:01.1 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet 
Controller (Copper) (rev 01)
Subsystem: Intel Corporation PRO/1000 MT Dual Port Server Adapter
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 97
Memory at e854 (64-bit, non-prefetchable) [size=128K]
I/O ports at 5440 [size=64]
Capabilities: [dc] Power Management version 2
Capabilities: [e4] PCI-X non-bridge device
Capabilities: [f0] MSI: Enable- Count=1/1 Maskable- 64bit+
Kernel driver in use: e1000
Kernel modules: e1000

HTH.

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

Re: [Discuss-gnuradio] Unable to build gr-wxgui on Mac OS X 10.6.1

[Michael Dickens]

Hi Bruh - Glad to hear you're getting Wx to work for you.  We're  
working on getting the Qt GUI working as well.  I know that the state  
of Wx on MacPorts is "confusing" right now -- to me as well.  If I  
were you, now that you've got it working, I'd leave my MacPorts  
install alone until the Wx stuff gets worked out; could be a long  
time, and it really depends on how quickly the Wx folks get their  
32/64 OSX 10.5/10.6 acts together.


To address your question:

On Jul 8, 2010, at 3:50 AM, Bruhtesfa Ebrahim wrote:

That did the trick and I now installed gnuradio including gr-wxgui and
grc, but got this warning:
{{{
*** Post-Install Message ***
Warning: python could not find the gnuradio module.
Make sure that /usr/local/lib/python2.6/site-packages is in your
PYTHONPATH
}}}
I used the "~/.bashrc" file suggested at

https://radioware.nd.edu/documentation/install-guides/mac-os-x/preliminaries 
,

where the PYTHONPATH was set to

/usr/local/lib/python${PYTHON_VERSION}/site-packages.

So, I could not figure out why this happened. Any suggestions?
Assuming you setup your .bashrc file exactly as found in the  
"Additional Login Scripts" section of that page, and MacPorts is fully  
installed to use its own 'python', then the PYTHONPATH should read  
something like:


PYTHONPATH=/opt/local/lib/python2.6/site-packages:/usr/local/lib/ 
python2.6/site-packages


where the former path is for MacPorts and the latter for GNU Radio.   
If all you're getting is the PYTHONPATH you list, then I would bet you  
haven't selected (in MacPorts) the correct version of python.  What  
does "which python" return for you?  ditto for "ls -l `which  
python`" ... if either of those shows that the version is "/usr/bin/ 
python" or the like, then you need to select the MacPorts' version,  
via (assuming you're using MacPorts' port "python26" as I do):


$ sudo port install python_select
$ sudo python_select python26

and that should do the trick.  No matter how much automation we build  
in, someone eventually messes with some part of it to require even  
more :)  Hope this help! - MLD


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

Re: [Discuss-gnuradio] Re: Help required tunnel.py

[Tuan Ta]

That's pretty much the same settings that I have. Can you clarify a bit
more:

- How far apart are your boards?

- What options did you use to run tunnel, benchmark_ofdm_*, benchmark_*.

- When you run benchmark_*, did you get a lot of packet drops at the end of
transmission (about 15%)?

Thanks a lot,

Tuan

On Thu, Jul 8, 2010 at 10:55 AM, chuck lorres wrote:

>  I am using RFX 2400,  gnuradio 3.2.2,  ubuntu 9.10 and 9.04 on another
>
>
> --
> Date: Thu, 8 Jul 2010 10:48:24 -0400
> Subject: Re: [Discuss-gnuradio] Re: Help required tunnel.py
> From: ta.tu...@gmail.com
> To: chucklor...@hotmail.com
> CC: discuss-gnuradio@gnu.org
>
>
> Chuck,
>
> What hardware are you using?
>
> On Thu, Jul 8, 2010 at 10:38 AM, chuck lorres wrote:
>
>  Hi,
> I have successfully run digital folders tunnel.py.
> However, I am not receiving anything when i run the ofdm folder tunnel.py.
> Whereas the benchmark_ofdm_tx+rx.py is running perfectly.
> I have varied almost all the available parameters but to no avail.
> Please help me out.
> Thanks in advance.
> Chuck.
>
>
> --
> Hotmail: Free, trusted and rich email service. Get it 
> now.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> --
> Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. Sign up
> now. 
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Re: Help required tunnel.py

[Tuan Ta]

Chuck,

What hardware are you using?

On Thu, Jul 8, 2010 at 10:38 AM, chuck lorres wrote:

>  Hi,
> I have successfully run digital folders tunnel.py.
> However, I am not receiving anything when i run the ofdm folder tunnel.py.
> Whereas the benchmark_ofdm_tx+rx.py is running perfectly.
> I have varied almost all the available parameters but to no avail.
> Please help me out.
> Thanks in advance.
> Chuck.
>
>
> --
> Hotmail: Free, trusted and rich email service. Get it 
> now.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Re: Help required tunnel.py

[chuck lorres]

Hi,
I have successfully run digital folders tunnel.py.
However, I am not receiving anything when i run the ofdm folder tunnel.py.
Whereas the benchmark_ofdm_tx+rx.py is running perfectly.
I have varied almost all the available parameters but to no avail.
Please help me out.
Thanks in advance.
Chuck.

  
_
Hotmail: Free, trusted and rich email service.
https://signup.live.com/signup.aspx?id=60969___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Re: Help required tunnel.py

[Tuan Ta]

Juan,

Thanks a lot for your response. I tried stopping at the ifconfig stage and
wait for both PCs to be ready before hitting enter. But all I saw was TX and
no RX. Do you have any idea where the problem might be?

Tuan

On Wed, Jul 7, 2010 at 7:10 PM, Juan Quiroz  wrote:

> I have installed deb package of GNU radio 3.2.2 for Ubuntu 9.04 and works
> fine, with openSUSE 11.1 I try tarball and everything is OK, for openSUSE
> there's a rpm package of GNU radio 3.1.3 avalaible in
> http://software.opensuse.org/search it's ok too.
>
> Try doing this step by step
> Run tunnel.py, in Ubuntu sudo tunnel.py -f 24xxe6 -c x x can be whatever
> you want.
>
> You will see an output asking to allocate gr0
>
> Set an IP address with sudo ifconfig gr0 192.168.200.1 netmask
> 255.255.255.0, don't press enter
>
> Wait here and go to next PC and repeat the same, but press enter when both
> PCs are ready
>
> If everything is fine immediately in console you will see RX and TX because
> of communication is beginning, is there's only TX messages we have a
> problem, if  is in your screen, it means back off no carrier sensed, try
> to change it with -c option.
>
> Again good luck
>
> Juan Quiroz
>
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] question to gmsk.py (modulation)

[Thilo Mönicke]

Hi all,

I'am doing some stuff with gmsk and so I had a look to gmsk.py
(gnuradio-core/src/lib/python/gnuradio/blks2impl/gmsk.py). In the
modulation part of the file, the incomming stream is nrz coded,
gaussian filtered and frequency modulated... so far so good.

But the gaussian taps for the FIR-filter are convoluted with a
rectangular window. I have no idear, why this is done. Could anybody
explain it to me?

thank you

Thilo

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

[Discuss-gnuradio] idea under GRC

[fangming he]

Hi, Josh,Could you distribute some documents about how to implementing the 
function of generating code in GRC? How to add new graphic signal processing 
block in GRC?I hope to get to know some ideas on designing GRC, such as why do 
you extract five basic primitives in XML: block, parameter, key, value, 
connection? Why do not choose some other primitives?How to translate the XML 
present to python Language?Or anyone have some ideas on it?Please let me know 
if anyone have some idea on it!Thanks!Fangming  

_
Hotmail: Free, trusted and rich email service.
https://signup.live.com/signup.aspx?id=60969___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD Announcement - July 6th 2010

[Zohair]

Regarding my post below, I have traced back the error and came to a result
that the error is occurring in device.cpp file. This line in the catch block
throws an error:
device::sptr dev = maker(dev_addr);
I beleive there is something wrong in : Arg: addr=192.168.10.11
192.168.20.11 192.168.30.11 192.168.40.11, recv_buff_size=50e6 50e6 50e6
50e6

Does the block support multiple buffer resizing?  or maybe I'm not
addressing the devices properly.

Looking foward to your reply.

Zohair



Zohair wrote:
> 
> Dear Josh,
> I have successfully installed the UHD branch from jblum.git repo and have
> tried out using the MIMO sources available. I have a few points to raise
> here regarding this release and block:
> 
> 1- I am using a PC with four Ethernet ports. I burned the firmware and the
> fpga images created on 6-7-2010. Also, I tried assigning IP addresses from
> the same subnetwork: 192.168.10.X/24. However, Only a single USRP2 is
> discovered at a time while others are unreachable. (USRP2s IPs are also
> from the same subnetwork above)
> 
> 2- Then I tried assigning IPs from 4 different subnetworks to the USRP2's,
> and all them  can be discovered normally. Is it possible that they work
> using IPs from the same subnetwork or not? (case 1)
> 
> 3- I used a MIMO source with 4 outputs and the following settings:
> freq: 241400, 241400, 241400, 241400
> Arg: addr=192.168.10.11 192.168.20.11 192.168.30.11 192.168.40.11,
> recv_buff_size=50e6 50e6 50e6 50e6
> sample rate: 195.312K ( Firstly, I used 32K but at runtime I was prompted 
> to use this value)
> Gain= 35,35,35,35
> Antennas= [‘RX2’, ‘RX2’, ‘RX2’, ‘RX2’]
> 
> I connected the 4 outputs to graphic scopes but once I run the flowgraph,
> I see this error messages:
> 
> terminate called after throwing an instance of
> 'boost::exception_detail::clone_impl
> >' 
>   what():  bad lexical cast: source type value could not be interpreted as
> target.
> 
> I have Boost 1.38.0 installed and I did use this command for
> configuration: ./configure --with-boost=$BOOST_PREFIX
> 
> Any advice or help regarding this issue, please?
> 
> Best regards,
> 
> Zohair
> 

-- 
View this message in context: 
http://old.nabble.com/UHD-Announcement---July-6th-2010-tp29091756p29106668.html
Sent from the GnuRadio mailing list archive at Nabble.com.


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

RE: [Discuss-gnuradio] UHD Announcement - July 6th 2010

[Per Zetterberg]

If I use the UHD driver directly (i.e. not using gnuradio framework) should I 
call "mimo_usrp::make" with argument "addr=192.168.10.11 192.168.20.11 
192.168.30.11 192.168.40.11, addr=192.168.10.11 192.168.20.11 192.168.30.11 
192.168.40.11" to achieve the same or how should the string be formatted ?


BR/
Per



From: discuss-gnuradio-bounces+perz=kth...@gnu.org 
[discuss-gnuradio-bounces+perz=kth...@gnu.org] on behalf of Zohair 
[zohair...@hotmail.com]
Sent: Thursday, July 08, 2010 12:16 PM
To: Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] UHD Announcement - July 6th 2010

Dear Josh,
I have successfully installed the UHD branch from jblum.git repo and have
tried out using the MIMO sources available. I have a few points to raise
here regarding this release and block:

1- I am using a PC with four Ethernet ports. I burned the firmware and the
fpga images created on 6-7-2010. Also, I tried assigning IP addresses from
the same subnetwork: 192.168.10.X/24. However, Only a single USRP2 is
discovered at a time while others are unreachable. (USRP2s IPs are also from
the same subnetwork above)

2- Then I tried assigning IPs from 4 different subnetworks to the USRP2's,
and all them  can be discovered normally. Is it possible that they work
using IPs from the same subnetwork or not? (case 1)

3- I used a MIMO source with 4 outputs and the following settings:
freq: 241400, 241400, 241400, 241400
Arg: addr=192.168.10.11 192.168.20.11 192.168.30.11 192.168.40.11,
recv_buff_size=50e6 50e6 50e6 50e6
sample rate: 195.312K ( Firstly, I used 32K but at runtime I was prompted
to use this value)
Gain= 35,35,35,35
Antennas= [‘RX2’, ‘RX2’, ‘RX2’, ‘RX2’]

I connected the 4 outputs to graphic scopes but once I run the flowgraph, I
see this error messages:

terminate called after throwing an instance of
'boost::exception_detail::clone_impl
>'
  what():  bad lexical cast: source type value could not be interpreted as
target.

I have Boost 1.38.0 installed and I did use this command for configuration:
./configure --with-boost=$BOOST_PREFIX

Any advice or help regarding this issue, please?

Best regards,

Zohair
--
View this message in context: 
http://old.nabble.com/UHD-Announcement---July-6th-2010-tp29091756p29105404.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___


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

[Discuss-gnuradio] what is latest stable release?

[Don Ward]

It has been a while since gnuradio-3.3.0 was sent out as a release 
candidate, but the Download page on the wiki still points to gnuradio-3.2.2. 
Is there a reason not to use 3.3.0 or is the wiki just out of date?


-- Don W.


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

Re: [Discuss-gnuradio] UHD Announcement - July 6th 2010

[Zohair]

Dear Josh,
I have successfully installed the UHD branch from jblum.git repo and have
tried out using the MIMO sources available. I have a few points to raise
here regarding this release and block:

1- I am using a PC with four Ethernet ports. I burned the firmware and the
fpga images created on 6-7-2010. Also, I tried assigning IP addresses from
the same subnetwork: 192.168.10.X/24. However, Only a single USRP2 is
discovered at a time while others are unreachable. (USRP2s IPs are also from
the same subnetwork above)

2- Then I tried assigning IPs from 4 different subnetworks to the USRP2's,
and all them  can be discovered normally. Is it possible that they work
using IPs from the same subnetwork or not? (case 1)

3- I used a MIMO source with 4 outputs and the following settings:
freq: 241400, 241400, 241400, 241400
Arg: addr=192.168.10.11 192.168.20.11 192.168.30.11 192.168.40.11,
recv_buff_size=50e6 50e6 50e6 50e6
sample rate: 195.312K ( Firstly, I used 32K but at runtime I was prompted 
to use this value)
Gain= 35,35,35,35
Antennas= [‘RX2’, ‘RX2’, ‘RX2’, ‘RX2’]

I connected the 4 outputs to graphic scopes but once I run the flowgraph, I
see this error messages:

terminate called after throwing an instance of
'boost::exception_detail::clone_impl
>' 
  what():  bad lexical cast: source type value could not be interpreted as
target.

I have Boost 1.38.0 installed and I did use this command for configuration:
./configure --with-boost=$BOOST_PREFIX

Any advice or help regarding this issue, please?

Best regards,

Zohair
-- 
View this message in context: 
http://old.nabble.com/UHD-Announcement---July-6th-2010-tp29091756p29105404.html
Sent from the GnuRadio mailing list archive at Nabble.com.


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

Re: [Discuss-gnuradio] Unable to build gr-wxgui on Mac OS X 10.6.1

[Bruhtesfa Ebrahim]

Hi Michael,

Yes, I came up with this post:
(http://www.mail-archive.com/macports-us...@lists.macosforge.org/msg19898.html),
where installing mesa is suggested before installing wxWidgets. It is
not listed in the dependencies though.

That did the trick and I now installed gnuradio including gr-wxgui and
grc, but got this warning:


*** Post-Install Message ***
Warning: python could not find the gnuradio module.
Make sure that /usr/local/lib/python2.6/site-packages is in your
PYTHONPATH


I used the "~/.bashrc" file suggested at
https://radioware.nd.edu/documentation/install-guides/mac-os-x/preliminaries,
where the PYTHONPATH was set to
/usr/local/lib/python${PYTHON_VERSION}/site-packages.

So, I could not figure out why this happened. Any suggestions?

Bruh


On Sun, Jun 20, 2010 at 4:06 PM, Michael Dickens  wrote:

> Hi Bruh - If you installed py26-wxpython and wxWidgets from MacPorts, then
> as of this morning neither allow for 'universal' compilation, and wxWidgets
> goes so far as to enforce 32-bit only compilation.  Chances are your Mac's
> compiler is trying to generate 64-bit code.  Hence, the wxpython wrappers
> are not being found because what's installed is for the incorrect
> architecture.  OSX will not allow you to mix 32-bit and 64-bit code within
> the same program.
>
> That said, the Wx folks have known that their products are not 64-bit
> compatible on OSX for along time.  The latest release of wxWidget is 64-bit
> compatible on OSX, but that still leaves the wxPython 64-bit OSX interface
> -- which is still in beta.
>
> Putting the pieces together, I think if you reinstall all of the background
> dependencies for GNU Radio as 'universal' and then the wx stuff as 32-bit,
> then compile GNU Radio as 32-bit, then everything should work.  I think
> others on this list have done that in the past, maybe even commented as such
> on this list.
>
> That said, I've taken over the Qt 4.6 ports on MacPorts -- which can be
> 64-bit -- and in the next couple of days I'll be releasing new ports that
> should allow for gr-qtgui to be usable on OSX.  I'll email again once that's
> further along.  After seeing the difference between wx and qt, I'd much
> prefer to use the latter.
>
> Hope the above helps and makes sense! - MLD
>
>
> On Jun 20, 2010, at 5:38 AM, Bruhtesfa Ebrahim wrote:
>
>> I am stuck on this problem for long. So,any help will be appreciated.
>>
>> I am trying to install GnuRadio on Mac OSX 10.6.1 . I have installed the
>> prerequisites including wxWidgets and py26-wxpython using MacPorts. However,
>> gr-wxgui and grc failed to build.  The output lines in ./configure that
>> correspond to this problem are:
>>
>> checking for Python wxWidgets wrappers >= 2.8... no
>> checking for Numeric Python extensions... yes
>> Not building component gr-wxgui.
>>
>> The problem is a bit similar to the one posted on:
>> http://www.ruby-forum.com/topic/185848#new. The solution suggested for
>> Ubuntu Jaunty was to remove python-wxgtk2.6 and it worked. So, what can I do
>> for MAC OS X 10.6.1 ?
>>
>> Any suggestions ?
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio