Tuesday, August 31, 2010

Re: [Discuss-gnuradio] UHD Announcement - August 31st 2010 - USRP1 support

On 08/31/2010 07:08 PM, Marcus D. Leech wrote:
> On 08/31/2010 10:01 PM, Josh Blum wrote:
>> Hello list,
>>
>> USRP1 support is now part of the UHD. Fetch the latest host code and
>> images: http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki
>>
> I take it then, that USRP1 under UHD doesn't require new firmware on the
> USRP1?
>

Images are automatically loaded at runtime after each power-cycle; so
its not an issue to worry about what images your device has as it is
with USRP2.

That said, the FPGA images are identical to the ones checked into the
gnuradio tree. However, the firmware was slightly modified to make the
spi interface more sane. So, no, the firmware image is different than
the gnuradio build. Should it affect you? no.

-Josh

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

Re: [Discuss-gnuradio] USRP2-FLEX2400 Transmit and Receive problems

Hi Marcus,

I get exactly the same behaviour. I have finally traced the problem to an old Flex2400 using an internal clock rather than the usrp2 clock. I'll need to do some re-soldering and burn-db-eeprom with USRP1 and hopefully this should fix the problem:
http://gnuradio.org/redmine/wiki/1/USRPClockingNotes

On 01/09/2010 03:20, Marcus D. Leech wrote:
On 08/31/2010 01:48 PM, Joseph Wamicha wrote:
Hi Leech,

Thank you for your response. I'm using 2.4 GHz characterized antennas. No I'm not feeding the signal directly into the USRP2. I have a 2.4GHz resonant monopole antenna on the signal generator and another 2, 2.4GHz resonant antennas on both the RX and TX/RX SMA connectors of the FLEX2400.


How close are the antennae?

What parameters did you pass to usrp2_fft.py?   If you look closely at the spectrum, it looks
  *perfectly* symmetrical about DC, which should never be the case if all the "pieces" agree
  that this is a complex signal.

What happens if you tune usrp2_fft.py a few Khz away from 2.4GHz exactly?





Re: [Discuss-gnuradio] Re: making a small USRP board

On 08/31/2010 10:41 PM, Lin HUANG wrote:
> I like "powered from the USB port" too !!
>
> But I know what William want to make now. That will be a half-size
> USRP mother board + single daughter board, placed in a small
> underwater vehical, and powerd by vehical battery, right? It sounds
> interesting!
>
> Lin
>
>
I want something similar, but with an L-band daughter-card, and a 1GiGE
interface!

Although, there are now USB-2.0 extenders that allow you to extend
USB-2.0 over
Cat5e, and I think internally, they use 1GiGE and some kind of
proprietary protocol.


--
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] Re: making a small USRP board

I like "powered from the USB port" too !!

But I know what William want to make now. That will be a half-size
USRP mother board + single daughter board, placed in a small
underwater vehical, and powerd by vehical battery, right? It sounds
interesting!

Lin

2010/8/30 Mark J. Blair <nf6x@nf6x.net>:
>
> On Aug 30, 2010, at 8:24 AM, William Cox wrote:
>> Right now I'm thinking the easiest thing would be to keep everything the same, except remove the 2nd mixed-signal chip, and move the power circuit off the board.
>> So, yes, same form factor for daughterboard connections.
>
> That seems like a lot of effort and expense to make something just a little bit smaller. Now, if you could make the equivalent of a USRP + WBX board about the size of a pack of playing cards, and powered from the USB port, that would be quite interesting!
>
>
>
> --
> Mark J. Blair, NF6X <nf6x@nf6x.net>
> Web page: http://www.nf6x.net/
> GnuPG public key available from my web page.
>
>
>
>
>
> _______________________________________________
> 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 - August 31st 2010 - USRP1 support

On 08/31/2010 10:01 PM, Josh Blum wrote:
> Hello list,
>
> USRP1 support is now part of the UHD. Fetch the latest host code and
> images: http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki
>
I take it then, that USRP1 under UHD doesn't require new firmware on the
USRP1?

--

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

[Discuss-gnuradio] UHD Announcement - August 31st 2010 - USRP1 support

Hello list,

USRP1 support is now part of the UHD. Fetch the latest host code and
images: http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki

-----------------------------------------------------------------------
Firmware and FPGA images:

You can get the most recent pre-compiled images here:
http://www.ettus.com/downloads/uhd_images/

And the application notes for installing and or building them:
http://www.ettus.com/uhd_docs/manual/html/images.html

-----------------------------------------------------------------------
Completeness of the USRP1 support:

Using either daughterboard slot is supported, however only single
channel operation is possible for now. We are 90% of the way to
multi-channel operation, we probably need a new top level wrapper for it.

8bit sample support is not in there yet. This will eventually manifest
into an API call to set the over-the-wire data type.

I believe that everything else is in there...

Dont forget to take a look at the USRP1 application notes:
http://www.ettus.com/uhd_docs/manual/html/usrp1.html

-----------------------------------------------------------------------
USB Support:

The USB support in UHD relies on libusb 1.0 which has only been tested
and confirmed working on linux for now. If libusb is not found at
configure time, USRP1 support will not be built. Linux users will need
to install the libusb-1.0-dev package.

See the build guide:
http://www.ettus.com/uhd_docs/manual/html/build.html#libusb

Special thanks to Tom Tsou for the USB framework for UHD and the USRP1
support!

-----------------------------------------------------------------------
USRP1 timestamp support:

The current USRP1 FPGA + host code has no concept of timestamps. In
other words, the UHD rx and tx metadata is completely ignored.

For those that want to hack on USRP1 to add timestamps capability, I
recommend cloning the uhd on a github to collaborate. All of the FPGA
and firmware code is also in the uhd repository.

-----------------------------------------------------------------------
Feedback and testing is always welcome.

-Josh

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

Re: [Discuss-gnuradio] USRP2-FLEX2400 Transmit and Receive problems

On 08/31/2010 01:48 PM, Joseph Wamicha wrote:
> Hi Leech,
>
> Thank you for your response. I'm using 2.4 GHz characterized antennas.
> No I'm not feeding the signal directly into the USRP2. I have a 2.4GHz
> resonant monopole antenna on the signal generator and another 2,
> 2.4GHz resonant antennas on both the RX and TX/RX SMA connectors of
> the FLEX2400.
>
>
How close are the antennae?

What parameters did you pass to usrp2_fft.py? If you look closely at
the spectrum, it looks
*perfectly* symmetrical about DC, which should never be the case if
all the "pieces" agree
that this is a complex signal.

What happens if you tune usrp2_fft.py a few Khz away from 2.4GHz exactly?


--
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] USRP2-FLEX2400 Transmit and Receive problems

The RFX2400 is dated 2/6/2006.

On 01/09/2010 02:37, Joseph Wamicha wrote:
> Hi,
>
> - I'm now using the uhd firmware and fpga code (txrx_uhd_20100706.bin
> and u2_rev3_uhd_20100706.bin images).
>
> - I get some interesting results; when running the examples, it
> appears that the daughterboard can not be recognized and is unknown.
>
> - I'm not sure if this in any way will affect the results but due to
> firmware/fpga incompatibilities between the host machine code and the
> firmware & fpga code (Error: Expected fpga compatibility number 1, but
> got 0:), I changed USRP2_FPGA_COMPAT_NUM and USRP2_FW_COMPAT_NUM to 0
> and 5 from 1 and 6 in host/lib/usrp/usrp2/fw_common.h.
>
> I was then able to run the host/examples code. The code is straight
> out of the repository. Please find the results below:
>
> root@astrodonius:git-uhd/host/examples# ./benchmark_rx_rate
>
> Creating the usrp device with: ...
> Target recv sock buff size: 50000000 bytes
> Actual recv sock buff size: 131071 bytes
>
> Warning:
> The recv buffer is smaller than the requested size.
> The minimum recommended buffer size is 50000000 bytes.
> See the USRP2 application notes on buffer resizing.
>
> Warning: unknown dboard-id or dboard-id combination: unknown (0x0007)
> -> defaulting to the unknown board type
> Warning: unknown dboard-id or dboard-id combination: unknown (0x000b)
> -> defaulting to the unknown board type
> RX samples per packet: 362
> TX samples per packet: 363
> Recv pirate num frames: 89
> Using Device: Simple USRP:
> Device: usrp2 device
> Mboard: usrp2 mboard0 - rev 4:0
> RX DSP: usrp2 ddc0
> RX Dboard: usrp2 dboard (rx unit)
> RX Subdev: Unknown - unknown (0x0007)
> TX DSP: usrp2 duc0
> TX Dboard: usrp2 dboard (tx unit)
> TX Subdev: Unknown - unknown (0x000b)
>
> OTesting receive rate 0.500000 Msps (10.000000 second run)
>
> Received packets: 13813
> Received samples: 5000306
> Lost samples: 0
> Lost packets: 0 (approximate)
> Sustained receive rate: 0.500000 Msps
>
>
> Testing receive rate 1.000000 Msps (10.000000 second run)
>
> Received packets: 27625
> Received samples: 10000250
> Lost samples: 0
> Lost packets: 0 (approximate)
> Sustained receive rate: 1.000000 Msps
>
>
> Testing receive rate 2.000000 Msps (10.000000 second run)
>
> Received packets: 55249
> Received samples: 20000138
> Lost samples: 0
> Lost packets: 0 (approximate)
> Sustained receive rate: 2.000000 Msps
>
>
> Testing receive rate 4.000000 Msps (10.000000 second run)
>
> Received packets: 110498
> Received samples: 40000276
> Lost samples: 0
> Lost packets: 0 (approximate)
> Sustained receive rate: 4.000000 Msps
>
>
> Testing receive rate 8.333333 Msps (10.000000 second run)
>
> Received packets: 230203
> Received samples: 83333486
> Lost samples: 0
> Lost packets: 0 (approximate)
> Sustained receive rate: 8.333333 Msps
>
>
> Testing receive rate 16.666667 Msps (10.000000 second run)
>
> Received packets: 460190
> Received samples: 166588780
> Lost samples: 78192
> Lost packets: 216 (approximate)
> Sustained receive rate: 16.658847 Msps
>
>
> Testing receive rate 25.000000 Msps (10.000000 second run)
> ./lib/usrp/usrp2/fw_common.h
> Received packets: 683928
> Received samples: 247581936
> Lost samples: 2418160
> Lost packets: 6680 (approximate)
> Sustained receive rate: 24.758184 Msps
> Done!
>
> root@git-uhd/host/examples# ./rx_timed_samples
>
> Creating the usrp device with: ...
> Target recv sock buff size: 50000000 bytes
> Actual recv sock buff size: 131071 bytes
>
> Warning:
> The recv buffer is smaller than the requested size.
> The minimum recommended buffer size is 50000000 bytes.
> See the USRP2 application notes on buffer resizing.
>
> Warning: unknown dboard-id or dboard-id combination: unknown (0x0007)
> -> defaulting to the unknown board type
> Warning: unknown dboard-id or dboard-id combination: unknown (0x000b)
> -> defaulting to the unknown board type
> RX samples per packet: 362
> TX samples per packet: 363
> Recv pirate num frames: 89
> Using Device: Simple USRP:
> Device: usrp2 device
> Mboard: usrp2 mboard0 - rev 4:0
> RX DSP: usrp2 ddc0
> RX Dboard: usrp2 dboard (rx unit)
> RX Subdev: Unknown - unknown (0x0007)
> TX DSP: usrp2 duc0
> TX Dboard: usrp2 dboard (tx unit)
> TX Subdev: Unknown - unknown (0x000b)
>
> Setting RX Rate: 6.250000 Msps...
> Actual RX Rate: 6.250000 Msps...
> Setting device timestamp to 0...
>
> Begin streaming 1000 samples, 3 seconds in the future...
> OGot packet: 362 samples, 3 full secs, 0.000000 frac secs
> Got packet: 362 samples, 3 full secs, 0.000058 frac secs
> Got packet: 276 samples, 3 full secs, 0.000116 frac secs
>
> Done!
>
> root@astrodonius:git-uhd/host/examples# ./tx_timed_samples
>
> Creating the usrp device with: ...
> Target recv sock buff size: 50000000 bytes
> Actual recv sock buff size: 131071 bytes
>
> Warning:
> The recv buffer is smaller than the requested size.
> The minimum recommended buffer size is 50000000 bytes.
> See the USRP2 application notes on buffer resizing.
>
> Warning: unknown dboard-id or dboard-id combination: unknown (0x0007)
> -> defaulting to the unknown board type
> Warning: unknown dboard-id or dboard-id combination: unknown (0x000b)
> -> defaulting to the unknown board type
> RX samples per packet: 362
> TX samples per packet: 363
> Recv pirate num frames: 89
> Using Device: Simple USRP:
> Device: usrp2 device
> Mboard: usrp2 mboard0 - rev 4:0
> RX DSP: usrp2 ddc0
> RX Dboard: usrp2 dboard (rx unit)
> RX Subdev: Unknown - unknown (0x0007)
> TX DSP: usrp2 duc0
> TX Dboard: usrp2 dboard (tx unit)
> TX Subdev: Unknown - unknown (0x000b)
>
> Setting TX Rate: 6.250000 Msps...
> Actual TX Rate: 6.250000 Msps...
> Setting device timestamp to 0...
>
> Sent 1000 samples
>
> Done!
>
> root@astrodonius:git-uhd/host/examples# ./tx_waveforms
>
> Creating the usrp device with: ...
> Target recv sock buff size: 50000000 bytes
> Actual recv sock buff size: 131071 bytes
>
> Warning:
> The recv buffer is smaller than the requested size.
> The minimum recommended buffer size is 50000000 bytes.
> See the USRP2 application notes on buffer resizing.
>
> Warning: unknown dboard-id or dboard-id combination: unknown (0x0007)
> -> defaulting to the unknown board type
> Warning: unknown dboard-id or dboard-id combination: unknown (0x000b)
> -> defaulting to the unknown board type
> RX samples per packet: 362
> TX samples per packet: 363
> Recv pirate num frames: 89
> Using Device: Simple USRP:
> Device: usrp2 device
> Mboard: usrp2 mboard0 - rev 4:0
> RX DSP: usrp2 ddc0
> RX Dboard: usrp2 dboard (rx unit)
> RX Subdev: Unknown - unknown (0x0007)
> TX DSP: usrp2 duc0
> TX Dboard: usrp2 dboard (tx unit)
> TX Subdev: Unknown - unknown (0x000b)
>
> Setting TX Rate: 6.250000 Msps...
> Actual TX Rate: 6.250000 Msps...
>
> Setting TX Freq: 0.000000 Mhz...
> Actual TX Freq: 0.000000 Mhz...
>
> Setting TX Gain: 0.000000 dB...
> Actual TX Gain: 0.000000 dB...
>
>
> Done!
>
>
> There's a machine in the lab with an ISE license so I'm not sure if
> this is
> On 31/08/2010 19:48, Joseph Wamicha wrote:
>> On 31/08/2010 19:33, Marcus D. Leech wrote:
>>> On 08/31/2010 11:58 AM, Joseph Wamicha wrote:
>>>> Hi,
>>>>
>>>> We are currently experiencing Transmit and possibly Receive problems
>>>> with the USRP2-Flex2400 boards.
>>>>
>>>> - The USRP2 is detected:
>>>> # find_usrps -e eth0
>>>> 00:50:c2:85:32:73 hw_rev = 0x0400
>>>>
>>>> - The latest firmware and Raw Ethernet FPGA images have been written
>>>> onto the SDRAM: u2_rev3-20100603.bin, u2_rev3-20100603.bin
>>>>
>>>> - To test receive, we transmit a 2.4GHz, 10 dBm RF signal using the HP
>>>> 8350B Sweep Oscillator/Signal Generator. This is detected by both the
>>>> USRP2-FLEX2400 (using usrp2_fft.py script) and Agilent Spectrum
>>>> Analyzer. However, the usrp2_fft.py shows some odd sidebands around
>>>> the the 2.4GHz central frequency when the signal generator is turned
>>>> on. Also, there's barely any difference in dB receive strength with
>>>> the signal generator turned on:
>>>>> usrp2_fft.py output when signal generator is off:
>>>> http://rrsg.ee.uct.ac.za/members/jwamicha/usrp2_fft-SignalGenerator-Off.png
>>>>
>>>>
>>>>> usrp2_fft.py output when signal generator is off:
>>>> http://rrsg.ee.uct.ac.za/members/jwamicha/usrp2_fft-SignalGenerator-On.png
>>>>
>>>>
>>>>
>>>> - Both LEDs D and F are lit up.
>>>>
>>>> - Gnuradio version 3.2.2 is being used on Ubuntu Lucid Lynx (10.04).
>>>>
>>>> We then turn off the Signal Generator, and transmit a 2.4GHz signal
>>>> solely using the USRP2-FLEX2400 by running 'usrp2_siggen.py -f 2.4e9
>>>> -e eth0'. Nothing gets picked up by the Agilent Spectrum Analyzer
>>>> USRP2-FLEX2400.
>>>>
>>>> Is there a USRP2-FLEX2400 transmit/receive problem while using the
>>>> latest firmware and raw ethernet FPGA code? Could this be the symptoms
>>>> of an SDRAM problem even if both LEDs D and F are lit up?
>>>>
>>>> Thanks,
>>>> Jaw.
>>>>
>>>>
>>> Are you injecting +10dBm *directly* into the front end of the FLEX2400?
>>> If so, you risk destroying the LNA in the front-end of
>>> that device. Signal levels should be no more than -15dBm or so into
>>> the front-end.
>>>
>>> What is your antenna configuration on the FLEX2400? By default,
>>> without
>>> explicit configuration in the software, the device will
>>> use its TX/RX port. Are you perhaps plugged into the RX2 port when
>>> doing these tests?
>>>
>>>
>>>
>>>
>> Hi Leech,
>>
>> Thank you for your response. I'm using 2.4 GHz characterized
>> antennas. No I'm not feeding the signal directly into the USRP2. I
>> have a 2.4GHz resonant monopole antenna on the signal generator and
>> another 2, 2.4GHz resonant antennas on both the RX and TX/RX SMA
>> connectors of the FLEX2400.
>


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

Re: [Discuss-gnuradio] USRP2-FLEX2400 Transmit and Receive problems

Hi,

- I'm now using the uhd firmware and fpga code (txrx_uhd_20100706.bin
and u2_rev3_uhd_20100706.bin images).

- I get some interesting results; when running the examples, it appears
that the daughterboard can not be recognized and is unknown.

- I'm not sure if this in any way will affect the results but due to
firmware/fpga incompatibilities between the host machine code and the
firmware & fpga code (Error: Expected fpga compatibility number 1, but
got 0:), I changed USRP2_FPGA_COMPAT_NUM and USRP2_FW_COMPAT_NUM to 0
and 5 from 1 and 6 in host/lib/usrp/usrp2/fw_common.h.

I was then able to run the host/examples code. The code is straight out
of the repository. Please find the results below:

root@astrodonius:git-uhd/host/examples# ./benchmark_rx_rate

Creating the usrp device with: ...
Target recv sock buff size: 50000000 bytes
Actual recv sock buff size: 131071 bytes

Warning:
The recv buffer is smaller than the requested size.
The minimum recommended buffer size is 50000000 bytes.
See the USRP2 application notes on buffer resizing.

Warning: unknown dboard-id or dboard-id combination: unknown (0x0007)
-> defaulting to the unknown board type
Warning: unknown dboard-id or dboard-id combination: unknown (0x000b)
-> defaulting to the unknown board type
RX samples per packet: 362
TX samples per packet: 363
Recv pirate num frames: 89
Using Device: Simple USRP:
Device: usrp2 device
Mboard: usrp2 mboard0 - rev 4:0
RX DSP: usrp2 ddc0
RX Dboard: usrp2 dboard (rx unit)
RX Subdev: Unknown - unknown (0x0007)
TX DSP: usrp2 duc0
TX Dboard: usrp2 dboard (tx unit)
TX Subdev: Unknown - unknown (0x000b)

OTesting receive rate 0.500000 Msps (10.000000 second run)

Received packets: 13813
Received samples: 5000306
Lost samples: 0
Lost packets: 0 (approximate)
Sustained receive rate: 0.500000 Msps


Testing receive rate 1.000000 Msps (10.000000 second run)

Received packets: 27625
Received samples: 10000250
Lost samples: 0
Lost packets: 0 (approximate)
Sustained receive rate: 1.000000 Msps


Testing receive rate 2.000000 Msps (10.000000 second run)

Received packets: 55249
Received samples: 20000138
Lost samples: 0
Lost packets: 0 (approximate)
Sustained receive rate: 2.000000 Msps


Testing receive rate 4.000000 Msps (10.000000 second run)

Received packets: 110498
Received samples: 40000276
Lost samples: 0
Lost packets: 0 (approximate)
Sustained receive rate: 4.000000 Msps


Testing receive rate 8.333333 Msps (10.000000 second run)

Received packets: 230203
Received samples: 83333486
Lost samples: 0
Lost packets: 0 (approximate)
Sustained receive rate: 8.333333 Msps


Testing receive rate 16.666667 Msps (10.000000 second run)

Received packets: 460190
Received samples: 166588780
Lost samples: 78192
Lost packets: 216 (approximate)
Sustained receive rate: 16.658847 Msps


Testing receive rate 25.000000 Msps (10.000000 second run)
./lib/usrp/usrp2/fw_common.h
Received packets: 683928
Received samples: 247581936
Lost samples: 2418160
Lost packets: 6680 (approximate)
Sustained receive rate: 24.758184 Msps
Done!

root@git-uhd/host/examples# ./rx_timed_samples

Creating the usrp device with: ...
Target recv sock buff size: 50000000 bytes
Actual recv sock buff size: 131071 bytes

Warning:
The recv buffer is smaller than the requested size.
The minimum recommended buffer size is 50000000 bytes.
See the USRP2 application notes on buffer resizing.

Warning: unknown dboard-id or dboard-id combination: unknown (0x0007)
-> defaulting to the unknown board type
Warning: unknown dboard-id or dboard-id combination: unknown (0x000b)
-> defaulting to the unknown board type
RX samples per packet: 362
TX samples per packet: 363
Recv pirate num frames: 89
Using Device: Simple USRP:
Device: usrp2 device
Mboard: usrp2 mboard0 - rev 4:0
RX DSP: usrp2 ddc0
RX Dboard: usrp2 dboard (rx unit)
RX Subdev: Unknown - unknown (0x0007)
TX DSP: usrp2 duc0
TX Dboard: usrp2 dboard (tx unit)
TX Subdev: Unknown - unknown (0x000b)

Setting RX Rate: 6.250000 Msps...
Actual RX Rate: 6.250000 Msps...
Setting device timestamp to 0...

Begin streaming 1000 samples, 3 seconds in the future...
OGot packet: 362 samples, 3 full secs, 0.000000 frac secs
Got packet: 362 samples, 3 full secs, 0.000058 frac secs
Got packet: 276 samples, 3 full secs, 0.000116 frac secs

Done!

root@astrodonius:git-uhd/host/examples# ./tx_timed_samples

Creating the usrp device with: ...
Target recv sock buff size: 50000000 bytes
Actual recv sock buff size: 131071 bytes

Warning:
The recv buffer is smaller than the requested size.
The minimum recommended buffer size is 50000000 bytes.
See the USRP2 application notes on buffer resizing.

Warning: unknown dboard-id or dboard-id combination: unknown (0x0007)
-> defaulting to the unknown board type
Warning: unknown dboard-id or dboard-id combination: unknown (0x000b)
-> defaulting to the unknown board type
RX samples per packet: 362
TX samples per packet: 363
Recv pirate num frames: 89
Using Device: Simple USRP:
Device: usrp2 device
Mboard: usrp2 mboard0 - rev 4:0
RX DSP: usrp2 ddc0
RX Dboard: usrp2 dboard (rx unit)
RX Subdev: Unknown - unknown (0x0007)
TX DSP: usrp2 duc0
TX Dboard: usrp2 dboard (tx unit)
TX Subdev: Unknown - unknown (0x000b)

Setting TX Rate: 6.250000 Msps...
Actual TX Rate: 6.250000 Msps...
Setting device timestamp to 0...

Sent 1000 samples

Done!

root@astrodonius:git-uhd/host/examples# ./tx_waveforms

Creating the usrp device with: ...
Target recv sock buff size: 50000000 bytes
Actual recv sock buff size: 131071 bytes

Warning:
The recv buffer is smaller than the requested size.
The minimum recommended buffer size is 50000000 bytes.
See the USRP2 application notes on buffer resizing.

Warning: unknown dboard-id or dboard-id combination: unknown (0x0007)
-> defaulting to the unknown board type
Warning: unknown dboard-id or dboard-id combination: unknown (0x000b)
-> defaulting to the unknown board type
RX samples per packet: 362
TX samples per packet: 363
Recv pirate num frames: 89
Using Device: Simple USRP:
Device: usrp2 device
Mboard: usrp2 mboard0 - rev 4:0
RX DSP: usrp2 ddc0
RX Dboard: usrp2 dboard (rx unit)
RX Subdev: Unknown - unknown (0x0007)
TX DSP: usrp2 duc0
TX Dboard: usrp2 dboard (tx unit)
TX Subdev: Unknown - unknown (0x000b)

Setting TX Rate: 6.250000 Msps...
Actual TX Rate: 6.250000 Msps...

Setting TX Freq: 0.000000 Mhz...
Actual TX Freq: 0.000000 Mhz...

Setting TX Gain: 0.000000 dB...
Actual TX Gain: 0.000000 dB...


Done!


There's a machine in the lab with an ISE license so I'm not sure if this is
On 31/08/2010 19:48, Joseph Wamicha wrote:
> On 31/08/2010 19:33, Marcus D. Leech wrote:
>> On 08/31/2010 11:58 AM, Joseph Wamicha wrote:
>>> Hi,
>>>
>>> We are currently experiencing Transmit and possibly Receive problems
>>> with the USRP2-Flex2400 boards.
>>>
>>> - The USRP2 is detected:
>>> # find_usrps -e eth0
>>> 00:50:c2:85:32:73 hw_rev = 0x0400
>>>
>>> - The latest firmware and Raw Ethernet FPGA images have been written
>>> onto the SDRAM: u2_rev3-20100603.bin, u2_rev3-20100603.bin
>>>
>>> - To test receive, we transmit a 2.4GHz, 10 dBm RF signal using the HP
>>> 8350B Sweep Oscillator/Signal Generator. This is detected by both the
>>> USRP2-FLEX2400 (using usrp2_fft.py script) and Agilent Spectrum
>>> Analyzer. However, the usrp2_fft.py shows some odd sidebands around
>>> the the 2.4GHz central frequency when the signal generator is turned
>>> on. Also, there's barely any difference in dB receive strength with
>>> the signal generator turned on:
>>>> usrp2_fft.py output when signal generator is off:
>>> http://rrsg.ee.uct.ac.za/members/jwamicha/usrp2_fft-SignalGenerator-Off.png
>>>
>>>
>>>> usrp2_fft.py output when signal generator is off:
>>> http://rrsg.ee.uct.ac.za/members/jwamicha/usrp2_fft-SignalGenerator-On.png
>>>
>>>
>>>
>>> - Both LEDs D and F are lit up.
>>>
>>> - Gnuradio version 3.2.2 is being used on Ubuntu Lucid Lynx (10.04).
>>>
>>> We then turn off the Signal Generator, and transmit a 2.4GHz signal
>>> solely using the USRP2-FLEX2400 by running 'usrp2_siggen.py -f 2.4e9
>>> -e eth0'. Nothing gets picked up by the Agilent Spectrum Analyzer
>>> USRP2-FLEX2400.
>>>
>>> Is there a USRP2-FLEX2400 transmit/receive problem while using the
>>> latest firmware and raw ethernet FPGA code? Could this be the symptoms
>>> of an SDRAM problem even if both LEDs D and F are lit up?
>>>
>>> Thanks,
>>> Jaw.
>>>
>>>
>> Are you injecting +10dBm *directly* into the front end of the FLEX2400?
>> If so, you risk destroying the LNA in the front-end of
>> that device. Signal levels should be no more than -15dBm or so into
>> the front-end.
>>
>> What is your antenna configuration on the FLEX2400? By default, without
>> explicit configuration in the software, the device will
>> use its TX/RX port. Are you perhaps plugged into the RX2 port when
>> doing these tests?
>>
>>
>>
>>
> Hi Leech,
>
> Thank you for your response. I'm using 2.4 GHz characterized antennas.
> No I'm not feeding the signal directly into the USRP2. I have a 2.4GHz
> resonant monopole antenna on the signal generator and another 2,
> 2.4GHz resonant antennas on both the RX and TX/RX SMA connectors of
> the FLEX2400.


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

Re: [Discuss-gnuradio] adding a DC offset to the output of a LFTX

On 08/31/2010 07:50 AM, William Cox wrote:
> I'm trying to add a DC offset to the output of my LFTX driven from a
> USRP 1. Is this possible progromatically? I edited my GRC block diagram
> to include adding a constant value to my complex stream, before
> inputting into the USRP sink block. I have a scope output at the same
> point, which shows adding a constant value to the signal, but the output
> of the USRP doesn't match. What am I missing? I've tried adding both a
> constant real value, and a complex constant with equal parts I and Q -
> neither work.
> Thanks.
> -William


If you have a non-zero frequency set on the USRP then your DC offset
will be mixed to that frequency. If you really want DC offset then you
can not use the DUC, or you can use the registers in the AD9862 to add
DC offset after the upconversion. The registers will only give you a
limited range, however.

Matt


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

[Discuss-gnuradio] libusrp.so.0 error

trying install of git 3.3.1 on ubuntu lucid
lucid updated ok
got the git
put gnuradio in /usr/local assuggested
followed procedure
sudo make check works
formed the usrp group and i'm in it
lib.so.conf looks like this:

include /etc/ld.so.conf.d/*.conf
/usr/local/lib
/usr/lib

and ldconf done.

then run python test usrp_benchmark and:

ImportError: libusrp.so.0: cannot open shared object file: No such file
or directory

is the last line in the error chain.

there is indeed no file or directory libusrp.so.0 anywhere in the
filesystem.

there are two links called libusrp.so, presumably where they oughta be
in /usr/lib/usrp and in the gnuradio setup.
they point to the lib files for the git 3.3.1 as presumably they oughta.

also, the c++ examples in the build instructions give me:

/usr/bin/ld: cannot open output
file /usr/local/gnuradio/usrp/host/apps/.libs/14759-lt-test_usrp_standard_rx: Permission denied
collect2: ld returned 1 exit status

I tried copying the link files libusrp.so making link files libusrp.so.0
to the same file, that is the git library files; that did not work. I
uninstalled, made sure the .so.0 links were there and reinstalled; the
new link files had vanished. that seems to be a loop that can't be
simply overcome.
as a complete noob, i'm lost (and typing one-handed) about the python
problem, and why don't i have permission for the c++ examples, as they
don't involve the python libs?

thanks for the help!
don


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

[Discuss-gnuradio] 802.11 USRP2

Hi all,
I have a question on my python file.
The original source code is here: https://www.cgran.org/browser/projects/ftw_80211_ofdm_tx/trunk/src/examples
I modified the ftw_ofdm_tx.py a little.
I want to do like this:
I have a series: 1,-1,1,-1,-1,-1.....
I read the series one by one by a certain time, e.g., I read "1" at the time point 0, "-1" at the time point 5, the next "1" at the point 10.....
if I read "1", I send the msg to a certain frequency (e.g., 802.11g, 2.427G) for a specific time (1 second). Otherwise I do nothing. I use a while loop to control the time interval. 
I run: python /home/w500/Desktop/ftw_80211_ofdm_tx/trunk/src/examples/ftw_ofdm_tx_back.py -f 2.427G -n 3 -g 30
But it doesn't work like what I want.
So, could you please help me to figure it out? I will be appreciated very much.
Thank you!
John

Below is the modified file:(ftw_ofdm_tx.py), I use bold font to label the modified part.

#!/usr/bin/env python
#
# Copyright 2005, 2006 Free Software Foundation, Inc.
#
# This file is part of GNU Radio
#
# GNU Radio is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3, or (at your option)
# any later version.
#
# GNU Radio is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with GNU Radio; see the file COPYING.  If not, write to
# the Free Software Foundation, Inc., 51 Franklin Street,
# Boston, MA 02110-1301, USA.


# Projectname: ftw_80211_ofdm_tx
#
# Filename: ftw_ofdm_tx.py
#
# This is the main script that triggers the encoding procedures and
# sends the complex baseband signal to the USRP2 sink.
#
# List of Contributors: Andrea Costantini,
#                       Paul Fuxjaeger, (fuxjaeger@ftw.at)
#                       Danilo Valerio, (valerio@ftw.at)
#                       Paolo Castiglione, (castiglione@ftw.at)
#                       Giammarco Zacheo, (zacheo@ftw.at)


# Forschungszentrum Telekommunikation Wien
# Telecommunications Research Center Vienna
# (http://www.ftw.at)
# December 2009

import time, struct, sys, sched
from gnuradio import gr, blks2, usrp2, eng_notation
from gnuradio.eng_option import eng_option
from optparse import OptionParser
from ftw_ofdm import ftw_transmit_path

class my_top_block(gr.top_block):
    def __init__(self, options, payload=''):
        gr.top_block.__init__(self)

        self._interface          = options.interface       # logical network interface
        self._mac_addr           = options.mac_addr        # MAC address
        self._tx_freq            = options.freq            # center frequency
        self._interp             = options.interp          # interpolation factor
        self._gain               = options.gain            # Tx gain

        # setup sink and connect output of transmitpath to it
        self._setup_usrp_sink()
        self.txpath = ftw_transmit_path(options, payload)
        self.connect(self.txpath, self.u)
   
        # write final baseband signal to disk
    if options.log:   
        self.connect(self.txpath, gr.file_sink(gr.sizeof_gr_complex, "final.dat"))
       
    def _setup_usrp_sink(self):
        """
        Creates a USRP sink, determines the settings for best bitrate,
        and attaches to the transmitter's subdevice.
        """
        self.u = usrp2.sink_32fc(self._interface, self._mac_addr)
        self.u.set_interp(self._interp)
    self.u.set_gain(self._gain)
    self.set_freq(self._tx_freq)

    def set_freq(self, target_freq):
        """
        Set the center frequency we're interested in.

        @param target_freq: frequency in Hz
        @rtype: bool

        Tuning is a two step process.  First we ask the front-end to
        tune as close to the desired frequency as it can.  Then we use
        the result of that operation and our target_frequency to
        determine the value for the digital up converter.
        """
        tr = self.u.set_center_freq(target_freq)
        if tr == None:
            sys.stderr.write('Failed to set center frequency\n')
            raise SystemExit, 1
   
  
# /////////////////////////////////////////////////////////////////////////////
#                                   main
# /////////////////////////////////////////////////////////////////////////////


def main():

    def send_pkt(payload='', eof=False, delay=5):
    print "enter"
   
           curtime=time.time()
    print time.time()
    print delay
    print payload
    while time.time()-curtime < delay-0.05:
        #tb.start()
        print time.time()
        print "coming"
        print eof
        tb.txpath.send_pkt(payload, eof)
        tb.txpath.send_pkt(eof=True)
        #tb.wait()
        print "ccccc"

    #tb.txpath.send_pkt(eof=True)
    print "exit"

   
        #return tb.txpath.send_pkt(payload, True)

    s = sched.scheduler(time.time, time.sleep)
 
    parser = OptionParser(option_class=eng_option, conflict_handler="resolve")

    parser.add_option("-e", "--interface", type="string", default="eth0",
                          help="set ethernet interface, [default=%default]")

    parser.add_option("-m", "--mac-addr", type="string", default="",
                          help="set USRP2 MAC address, [default=auto-select]")

    parser.add_option("-f", "--freq", type="eng_float",
                          default = 2.412e9, help="set USRP2 carrier frequency, [default=%default]",
                          metavar="FREQ")
   
    parser.add_option("-i", "--interp", type="intx", default=5,
                          help="set USRP2 interpolation factor, [default=%default]\
                5  -> 802.11a/g, OFDM-symbolduration=4us, \
                10 -> 802.11p, OFDM-symbolduration=8us")

    parser.add_option("-g", "--gain", type="int", default=10 , help = "set USRP2 Tx GAIN in [dB] [default=%default]")

    parser.add_option("", "--regime", type="string", default="1",
                          help="set OFDM coderegime:    [default=%default]\
                        1 -> 6 (3) Mbit/s (BPSK r=0.5), \
                        2 -> 9 (4.5) Mbit/s (BPSK r=0.75), \
                        3 -> 12 (6) Mbit/s (QPSK r=0.5), \
                        4 -> 18 (9) Mbit/s (QPSK r=0.75), \
                          5 -> 24 (12) Mbit/s (QAM16 r=0.5), \
                        6 -> 36 (18) Mbit/s (QAM16 r=0.75), \
                        7 -> 48 (24) Mbit/s (QAM64 r=0.66), \
                        8 -> 54 (27) Mbit/s (QAM64 r=0.75)")

    parser.add_option("-n", "--norm", type="eng_float", default=0.3 , help="set gain factor for complex baseband floats [default=%default]")
       
    parser.add_option("-s","--swapIQ", action="store_true", default=False, help="swap IQ components before sending to USRP2 sink [default=%default]")

    parser.add_option("-r", "--repetition", type="int", default=1 , help="set number of frame-copies to send, 0=infinite [default=%default] ")

    parser.add_option("-l", "--log", action="store_true", default=False, help="write debug-output of individual blocks to disk")

    parser.add_option("-p", "--payload", type="string", default="HelloWorld",
                          help="payload ASCII-string to send, [default=%default]")
   
    (options, args) = parser.parse_args ()

    # This is the ASCII encoded message that will be put into the MSDU (you have to build IP headers on your own if you need them!)
    # Use monitor (promiscuous) mode on the receiver side to see this kind of non-IP frame.
    #my_msg = options.payload
    my_msg = 'A';


    # build the graph   
    tb = my_top_block(options, my_msg)

    r = gr.enable_realtime_scheduling()
    if r != gr.RT_OK:
       print "Warning: failed to enable realtime scheduling"

#    tb.start()

 ##   # start flow graph
 ##   tb.start()

 ##   # send frame       
 ##   send_pkt(my_msg , eof = False)
 ##   send_pkt(eof = True)

 ##   # wait for it to finish
 ##   tb.wait()

    s.enter(0,1,tb.wait,())

    i=0

    for item in [1,-1,1,1,-1,1,-1]:
    i=i+1
    if item == 1:
        s.enter((i-1)*5, i, send_pkt, [my_msg, False, 5])
    else:
         s.enter((i-1)*5, i, time.sleep, [5])

    s.enter(35,8,tb.wait,())

    s.run()

 #   tb.wait()


       
                  

if __name__ == '__main__':
    try:
        main()
    except KeyboardInterrupt:
        pass











网易邮箱,没有垃圾邮件的邮箱。



您想拥有和网易免费邮箱一样强大的软件吗?

[Discuss-gnuradio] USRP2-FLEX2400 Transmit and Receive problems

Hi,

We are currently experiencing Transmit and possibly Receive problems
with the USRP2-Flex2400 boards.

- The USRP2 is detected:
# find_usrps -e eth0
00:50:c2:85:32:73 hw_rev = 0x0400

- The latest firmware and Raw Ethernet FPGA images have been written
onto the SDRAM: u2_rev3-20100603.bin, u2_rev3-20100603.bin

- To test receive, we transmit a 2.4GHz, 10 dBm RF signal using the HP
8350B Sweep Oscillator/Signal Generator. This is detected by both the
USRP2-FLEX2400 (using usrp2_fft.py script) and Agilent Spectrum
Analyzer. However, the usrp2_fft.py shows some odd sidebands around the
the 2.4GHz central frequency when the signal generator is turned on.
Also, there's barely any difference in dB receive strength with the
signal generator turned on:
> usrp2_fft.py output when signal generator is off:
http://rrsg.ee.uct.ac.za/members/jwamicha/usrp2_fft-SignalGenerator-Off.png
> usrp2_fft.py output when signal generator is off:
http://rrsg.ee.uct.ac.za/members/jwamicha/usrp2_fft-SignalGenerator-On.png

- Both LEDs D and F are lit up.

- Gnuradio version 3.2.2 is being used on Ubuntu Lucid Lynx (10.04).

We then turn off the Signal Generator, and transmit a 2.4GHz signal
solely using the USRP2-FLEX2400 by running 'usrp2_siggen.py -f 2.4e9 -e
eth0'. Nothing gets picked up by the Agilent Spectrum Analyzer
USRP2-FLEX2400.

Is there a USRP2-FLEX2400 transmit/receive problem while using the
latest firmware and raw ethernet FPGA code? Could this be the symptoms
of an SDRAM problem even if both LEDs D and F are lit up?

Thanks,
Jaw.

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

[Discuss-gnuradio] USRP2-FLEX2400 Transmit and Receive problems

Hi,

We are currently experiencing Transmit and possibly Receive problems
with the USRP2-Flex2400 boards.

- The USRP2 is detected:
# find_usrps -e eth0
00:50:c2:85:32:73 hw_rev = 0x0400

- The latest firmware and Raw Ethernet FPGA images have been written
onto the SDRAM: u2_rev3-20100603.bin, u2_rev3-20100603.bin

- To test receive, we transmit a 2.4GHz, 10 dBm RF signal using the HP
8350B Sweep Oscillator/Signal Generator. This is detected by both the
USRP2-FLEX2400 (using usrp2_fft.py script) and Agilent Spectrum Analyzer
(Please see screen shots attached). However, the usrp2_fft.py shows some
odd sidebands around the the 2.4GHz central frequency when the signal
generator is turned on.

- Both LEDs D and F are lit up.

- Gnuradio version 3.2.2 is being used on Ubuntu Lucid Lynx (10.04).

We then turn off the Signal Generator, and transmit a 2.4GHz signal
solely using the USRP2-FLEX2400 by running 'usrp2_siggen.py -f 2.4e9 -e
eth0'. Nothing gets picked up by the Agilent Spectrum Analyzer
USRP2-FLEX2400.

Is there a USRP2-FLEX2400 transmit/receive problem while using the
latest firmware and raw ethernet FPGA code?

Thanks,
Jaw.

[Discuss-gnuradio] adding a DC offset to the output of a LFTX

I'm trying to add a DC offset to the output of my LFTX driven from a USRP 1. Is this possible progromatically? I edited my GRC block diagram to include adding a constant value to my complex stream, before inputting into the USRP sink block. I have a scope output at the same point, which shows adding a constant value to the signal, but the output of the USRP doesn't match. What am I missing? I've tried adding both a constant real value, and a complex constant with equal parts I and Q - neither work.
Thanks.
-William

Re: [Discuss-gnuradio] Re: making a small USRP board

Craig,

That sounds very interesting. Will the 2450 be integrated or removable? Most of our work is at low frequencies (under 100MHz), so that board is too high
-William


On Mon, Aug 30, 2010 at 3:56 PM, Craig Kief <craig.kief@cosmiac.org> wrote:

William,

I am not sure if it helps you or not but we are just now finishing up with a 3.5" x 3.5" fpga board design where we will mount a 2450 board on top.   Would love to collaborate.

Craig

 

 

signatureBlock.jpg

Craig J. Kief

Deputy Director

craig.kief@cosmiac.org

505.934.1861 cell (preferred)

505.242.0339 office

2350 Alamo Avenue SE, Ste. 100

Albuquerque, NM 87106

 

From: discuss-gnuradio-bounces+craig.kief=cosmiac.org@gnu.org [mailto:discuss-gnuradio-bounces+craig.kief=cosmiac.org@gnu.org] On Behalf Of William Cox
Sent: Monday, August 30, 2010 11:45 AM
To: Mark J. Blair
Cc: discuss-gnuradio
Subject: Re: [Discuss-gnuradio] Re: making a small USRP board

 

Mark,

Going from 36 sq-in to 18 sq-in is a big improvement for us. We'll be using it on an underwater vehicle, and space is a premium. Your idea for a smaller WBX board is cool, but would be a lot of work.

-William

On Mon, Aug 30, 2010 at 11:44 AM, Mark J. Blair <nf6x@nf6x.net> wrote:


On Aug 30, 2010, at 8:24 AM, William Cox wrote:
> Right now I'm thinking the easiest thing would be to keep everything the same, except remove the 2nd mixed-signal chip, and move the power circuit off the board.
> So, yes, same form factor for daughterboard connections.

That seems like a lot of effort and expense to make something just a little bit smaller. Now, if you could make the equivalent of a USRP + WBX board about the size of a pack of playing cards, and powered from the USB port, that would be quite interesting!



--

Mark J. Blair, NF6X <nf6x@nf6x.net>
Web page: http://www.nf6x.net/
GnuPG public key available from my web page.





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

 


Monday, August 30, 2010

Re: [Discuss-gnuradio] Python docstring plans

On 08/30/2010 09:43 PM, Ben Reynwar wrote:
> Hi all,
>
> What are the current plans for creating python docstrings? I found an
> email from 2005
> (http://lists.gnu.org/archive/html/discuss-gnuradio/2005-01/msg00249.html)
> that had plans for getting the c++ documentation into the docstrings
> but it doesn't appear to have happened yet. If it's just a case of
> needing someone to have a crack at it then I'm happy to have a go.
>

Go go go!

> Cheers,
> Ben
>
> _______________________________________________
> 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] Python docstring plans

Hi all,

What are the current plans for creating python docstrings? I found an
email from 2005
(http://lists.gnu.org/archive/html/discuss-gnuradio/2005-01/msg00249.html)
that had plans for getting the c++ documentation into the docstrings
but it doesn't appear to have happened yet. If it's just a case of
needing someone to have a crack at it then I'm happy to have a go.

Cheers,
Ben

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

Re: [Discuss-gnuradio] Running GNU Radio before you install it

On Mon, Aug 30, 2010 at 08:42:51PM -0400, Philip Balister wrote:
> I've got gnuradio cross compiled for the armv7 and have it NFS
> mounted on the target hw. Is there an easy way to test gnuradio by
> running applications out of the build tree?

Easy way? No.

> I know about running make check on the target, but I am interested
> in testing more complex flowgraphs.

Python or C++?

For python, take a look at gnuradio-core/src/python/gnuradio/gr/Makefile.am and
run_tests for clues about how you might be able to move forward.
(Note that we don't have any commitment to keep doing it the same way...)

Eric

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

[Discuss-gnuradio] Running GNU Radio before you install it

I've got gnuradio cross compiled for the armv7 and have it NFS mounted
on the target hw. Is there an easy way to test gnuradio by running
applications out of the build tree?

I know about running make check on the target, but I am interested in
testing more complex flowgraphs.

Philip

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

[Discuss-gnuradio] Using FPGA registers with custom Verilog code

I am running a custom feedback controller on the USRP1. So far I have been content with hard coding parameters of the controller and re-synthesizing the Verilog as needed. However I would like to explore using the FPGA registers to set some parameter values using the python function _write_fpga_reg(....).

What is the best way to go about setting up the Verilog to do this? After looking at the usrp_std.v top level module, I included and setup the serial_io and io_pins modules in my code and then used setting_reg to read the register values. When I do this, the code synthesizes fine but does not produce any output. Are there other modules that serial_io and io_pins depend on? Or am I going about this the wrong way?

Thanks!


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

Re: [Discuss-gnuradio] Clarification of lock() and unlock() in Dynamic Flow-Graph Reconfiguration

Hey,

We have tried just about every different combination of start,stop,wait,lock, and unlock possible ....

Whenever we remove the stop() call, we get an error that we do not receive whenever the stop() call is in place. With the stop() call removed, the program gives us the following error at the unlock() statement:

                 terminate called after throwing an instance of 'boost::thread_interrupted'
                 Aborted

This error does not come up if we remove the stop() statement, but the program freezes at the unlock instead. Any clues to solving the boost error or what this actually means??

From viewing the version 3.2.2 API documentation for the gr_top_block class, there is a note saying that "the lock() and unlock() methods should not be called from a flowgraph thread or the program will be become deadlocked". In my program the lock() and unlock() are being called from the same top_block() which is instantiated when the program is started. Could this be the cause of freezing once we get to the unlock statement?

Once again thanks for your help. I was extremely surprised at how quickly you guys responded :)




>
> A couple of things to try:
>Try removing the tb.stop() call, lock will stop the flowgraph anyway.
>You may need to 'disconnect' (essentially undo all the connect calls) the path before recreating it. In the first instance try >the disconnect_all() method, but from memory that had some issues so you could try calling disconnect for each block which was connected.


 
>             else:
>               print "Receiver Mode : USRP to Switch to Receiving Packets "
>               self.tb.stop()

Don't call stop.  Just call lock.



--
Venkat Vinod Patcha and Ben Carroll

Re: [Discuss-gnuradio] Gnuradio website

On 08/29/2010 11:00 PM, Eric Blossom wrote:
> On Sun, Aug 29, 2010 at 10:47:22AM -0400, Philip Balister wrote:
>> gnuradio.org is showing a redmine internal error.
>>
>> Philip
>
> Fixed with big hammer :-)
>
> Looks like the version of redmine we're using leaks memory and
> eventually (a couple of weeks?) consumes all memory and swap...

Can you use a bigger hammer? Attempts to access the website and git just
sit there for me ...

Philip

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

RE: [Discuss-gnuradio] Re: making a small USRP board

William,

I am not sure if it helps you or not but we are just now finishing up with a 3.5” x 3.5” fpga board design where we will mount a 2450 board on top.   Would love to collaborate.

Craig

 

 

signatureBlock.jpg

Craig J. Kief

Deputy Director

craig.kief@cosmiac.org

505.934.1861 cell (preferred)

505.242.0339 office

2350 Alamo Avenue SE, Ste. 100

Albuquerque, NM 87106

 

From: discuss-gnuradio-bounces+craig.kief=cosmiac.org@gnu.org [mailto:discuss-gnuradio-bounces+craig.kief=cosmiac.org@gnu.org] On Behalf Of William Cox
Sent: Monday, August 30, 2010 11:45 AM
To: Mark J. Blair
Cc: discuss-gnuradio
Subject: Re: [Discuss-gnuradio] Re: making a small USRP board

 

Mark,

Going from 36 sq-in to 18 sq-in is a big improvement for us. We'll be using it on an underwater vehicle, and space is a premium. Your idea for a smaller WBX board is cool, but would be a lot of work.

-William

On Mon, Aug 30, 2010 at 11:44 AM, Mark J. Blair <nf6x@nf6x.net> wrote:


On Aug 30, 2010, at 8:24 AM, William Cox wrote:
> Right now I'm thinking the easiest thing would be to keep everything the same, except remove the 2nd mixed-signal chip, and move the power circuit off the board.
> So, yes, same form factor for daughterboard connections.

That seems like a lot of effort and expense to make something just a little bit smaller. Now, if you could make the equivalent of a USRP + WBX board about the size of a pack of playing cards, and powered from the USB port, that would be quite interesting!



--

Mark J. Blair, NF6X <nf6x@nf6x.net>
Web page: http://www.nf6x.net/
GnuPG public key available from my web page.





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

 

[Discuss-gnuradio] Re: Make install - "cannot find -lcblas"

Figured it out. I had uninstalled the binary version of gnuradio prior to making the latest stable release. In the process, the required Atlas library might have been uninstalled. Anyway, installing the first below through the package manager below (and perhaps the second two as well) fixed it:

libatlas (all with this prefix - might get warning about 3D ones on older machines)
libblas (all with this prefix)
liblapack (all with this prefix)

Ben


On Thu, Aug 26, 2010 at 3:57 PM, Benjamin Lonske <blonske@i-a-i.com> wrote:
Hi, does anyone know why I would be getting link error? I am installing the latest stable release of gnuradio (3.3) on Ubuntu 9.04. I installed the necessary packages for Jaunty for gnuradio.  './configure' passes.

Ben


test -z "/usr/local/lib/python2.6/dist-packages/gnuradio" || /bin/mkdir -p "/usr/local/lib/python2.6/dist-packages/gnuradio"
 /bin/bash ../../libtool   --mode=install /usr/bin/install -c   _usrp2.la '/usr/local/lib/python2.6/dist-packages/gnuradio'
libtool: install: warning: relinking `_usrp2.la'
libtool: install: (cd /gnuradio/gnuradio-3.3.0/gr-usrp2/src; /bin/bash /gnuradio/gnuradio-3.3.0/libtool  --tag CXX --mode=relink g++ -g -O1 -Wno-strict-aliasing -Wno-parentheses -pthread -module -avoid-version -o _usrp2.la -rpath /usr/local/lib/python2.6/dist-packages/gnuradio _usrp2_la-usrp2.lo -lstdc++ libgnuradio-usrp2.la )
libtool: relink: g++ -shared -nostdlib /usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib/crti.o /usr/lib/gcc/i486-linux-gnu/4.3.3/crtbeginS.o  .libs/_usrp2_la-usrp2.o   -L/usr/local/lib -lgnuradio-usrp2 -lusrp2 -L/usr/lib -lgnuradio-core -lrt -lgruel -lboost_thread-gcc43-mt-1_35 -lfftw3f -lgsl -lgslcblas -lcblas -latlas -L/usr/lib/gcc/i486-linux-gnu/4.3.3 -L/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.3.3/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/i486-linux-gnu/4.3.3/crtendS.o /usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib/crtn.o  -pthread   -pthread -Wl,-soname -Wl,_usrp2.so -o .libs/_usrp2.so
/usr/bin/ld: cannot find -lcblas
collect2: ld returned 1 exit status
libtool: install: error: relink `_usrp2.la' with the above command before installing it
make[4]: *** [install-usrp2_pylibLTLIBRARIES] Error 1
make[4]: Leaving directory `/gnuradio/gnuradio-3.3.0/gr-usrp2/src'
make[3]: *** [install-am] Error 2
make[3]: Leaving directory `/gnuradio/gnuradio-3.3.0/gr-usrp2/src'
make[2]: *** [install] Error 2
make[2]: Leaving directory `/gnuradio/gnuradio-3.3.0/gr-usrp2/src'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/gnuradio/gnuradio-3.3.0/gr-usrp2'
make: *** [install-recursive] Error 1
root@IAI42:/gnuradio/gnuradio-3.3.0#


Re: [Discuss-gnuradio] Re: making a small USRP board


Ah, I see. That sounds like a neat project. 


On Aug 30, 2010, at 10:44, William Cox <wccox@ncsu.edu> wrote:

Mark,
Going from 36 sq-in to 18 sq-in is a big improvement for us. We'll be using it on an underwater vehicle, and space is a premium. Your idea for a smaller WBX board is cool, but would be a lot of work.
-William

On Mon, Aug 30, 2010 at 11:44 AM, Mark J. Blair <nf6x@nf6x.net> wrote:

On Aug 30, 2010, at 8:24 AM, William Cox wrote:
> Right now I'm thinking the easiest thing would be to keep everything the same, except remove the 2nd mixed-signal chip, and move the power circuit off the board.
> So, yes, same form factor for daughterboard connections.

That seems like a lot of effort and expense to make something just a little bit smaller. Now, if you could make the equivalent of a USRP + WBX board about the size of a pack of playing cards, and powered from the USB port, that would be quite interesting!



--
Mark J. Blair, NF6X <nf6x@nf6x.net>
Web page: http://www.nf6x.net/
GnuPG public key available from my web page.





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

Re: [Discuss-gnuradio] Re: making a small USRP board

Mark,
Going from 36 sq-in to 18 sq-in is a big improvement for us. We'll be using it on an underwater vehicle, and space is a premium. Your idea for a smaller WBX board is cool, but would be a lot of work.
-William

On Mon, Aug 30, 2010 at 11:44 AM, Mark J. Blair <nf6x@nf6x.net> wrote:

On Aug 30, 2010, at 8:24 AM, William Cox wrote:
> Right now I'm thinking the easiest thing would be to keep everything the same, except remove the 2nd mixed-signal chip, and move the power circuit off the board.
> So, yes, same form factor for daughterboard connections.

That seems like a lot of effort and expense to make something just a little bit smaller. Now, if you could make the equivalent of a USRP + WBX board about the size of a pack of playing cards, and powered from the USB port, that would be quite interesting!



--
Mark J. Blair, NF6X <nf6x@nf6x.net>
Web page: http://www.nf6x.net/
GnuPG public key available from my web page.





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

Re: [Discuss-gnuradio] Warning in usrp_benchmark_usb.py

On Mon, Aug 30, 2010 at 8:15 AM, Federico Battaglia
<federico.battaglia@hotmail.it> wrote:
> Hi everyone,
> in testing the USRP I came across several warnings. Can someone tell me what
> they mean and if they are irrelevant?
> Thanks in advance who will answer ...

That message usually means you either have an unrecognized
daughterboard installed or no daughterboard installed. It can happen
when you have a daughterboard just on side A but not B.

Jason

> -
> Federico Battaglia
>
> @ubuntu:/usr/share/gnuradio/examples/usrp$ ./usrp_benchmark_usb.py
> Testing 2MB/sec...
> Warning: Treating daughterboard with invalid EEPROM contents as if it were a
> "Basic Tx."
> Warning: This is almost certainly wrong...  Use appropriate burn-*-eeprom
> utility.
>
> Warning: Treating daughterboard with invalid EEPROM contents as if it were a
> "Basic Rx."
> Warning: This is almost certainly wrong...  Use appropriate burn-*-eeprom
> utility.
> gr_vmcircbuf_createfilemapping: createfilemapping is not available
> usb_throughput = 2M
> ntotal    = 1000000
> nright    = 997766
> runlength = 997766
> delta     = 2234
> OK
> Testing 4MB/sec...
> Warning: Treating daughterboard with invalid EEPROM contents as if it were a
> "Basic Tx."
> Warning: This is almost certainly wrong...  Use appropriate burn-*-eeprom
> utility.
>
> Warning: Treating daughterboard with invalid EEPROM contents as if it were a
> "Basic Rx."
> Warning: This is almost certainly wrong...  Use appropriate burn-*-eeprom
> utility.
> usb_throughput = 4M
> ntotal    = 2000000
> nright    = 1997113
> runlength = 1997113
> delta     = 2887
> OK
> Testing 8MB/sec...
> Warning: Treating daughterboard with invalid EEPROM contents as if it were a
> "Basic Tx."
> Warning: This is almost certainly wrong...  Use appropriate burn-*-eeprom
> utility.
>
> Warning: Treating daughterboard with invalid EEPROM contents as if it were a
> "Basic Rx."
> Warning: This is almost certainly wrong...  Use appropriate burn-*-eeprom
> utility.
> usb_throughput = 8M
> ntotal    = 4000000
> nright    = 3998755
> runlength = 3998074
> delta     = 1926
> OK
> Testing 16MB/sec...
> Warning: Treating daughterboard with invalid EEPROM contents as if it were a
> "Basic Tx."
> Warning: This is almost certainly wrong...  Use appropriate burn-*-eeprom
> utility.
>
> Warning: Treating daughterboard with invalid EEPROM contents as if it were a
> "Basic Rx."
> Warning: This is almost certainly wrong...  Use appropriate burn-*-eeprom
> utility.
> usb_throughput = 16M
> ntotal    = 8000000
> nright    = 7996694
> runlength = 7996694
> delta     = 3306
> OK
> Testing 32MB/sec...
> Warning: Treating daughterboard with invalid EEPROM contents as if it were a
> "Basic Tx."
> Warning: This is almost certainly wrong...  Use appropriate burn-*-eeprom
> utility.
>
> Warning: Treating daughterboard with invalid EEPROM contents as if it were a
> "Basic Rx."
> Warning: This is almost certainly wrong...  Use appropriate burn-*-eeprom
> utility.
> usb_throughput = 32M
> ntotal    = 16000000
> nright    = 15993798
> runlength = 15992882
> delta     = 7118
> OK
> Max USB/USRP throughput = 32MB/sec
> _______________________________________________
> 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] Re: making a small USRP board

I would strongly recommend keeping the LDO on the board, or at least
some form of power filtering or decoupling.

~Jeff

On 8/30/2010 11:24 AM, William Cox wrote:
> Right now I'm thinking the easiest thing would be to keep everything the
> same, except remove the 2nd mixed-signal chip, and move the power
> circuit off the board.
> So, yes, same form factor for daughterboard connections.
> -William
>
--
~Jeffrey Lambert, K1VZX

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

Re: [Discuss-gnuradio] Re: making a small USRP board

On Aug 30, 2010, at 8:24 AM, William Cox wrote:
> Right now I'm thinking the easiest thing would be to keep everything the same, except remove the 2nd mixed-signal chip, and move the power circuit off the board.
> So, yes, same form factor for daughterboard connections.

That seems like a lot of effort and expense to make something just a little bit smaller. Now, if you could make the equivalent of a USRP + WBX board about the size of a pack of playing cards, and powered from the USB port, that would be quite interesting!

--
Mark J. Blair, NF6X <nf6x@nf6x.net>
Web page: http://www.nf6x.net/
GnuPG public key available from my web page.

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

Re: [Discuss-gnuradio] Warning in usrp_benchmark_usb.py

On Aug 30, 2010, at 8:15 AM, Federico Battaglia wrote:
> in testing the USRP I came across several warnings. Can someone tell me what they mean and if they are irrelevant?
[...]
> @ubuntu:/usr/share/gnuradio/examples/usrp$ ./usrp_benchmark_usb.py
> Testing 2MB/sec...
> Warning: Treating daughterboard with invalid EEPROM contents as if it were a "Basic Tx."
> Warning: This is almost certainly wrong... Use appropriate burn-*-eeprom utility.
>
>
> Warning: Treating daughterboard with invalid EEPROM contents as if it were a "Basic Rx."
> Warning: This is almost certainly wrong... Use appropriate burn-*-eeprom utility.

Those look relevant to me. Each RF daughterboard is supposed to have an EEPROM (memory chip) whose contents tell the gnuradio software what kind of board is installed. Your software is complaining that it couldn't identify the installed daughterboard(s), so their EEPROM(s) may need to be reprogrammed.

There's some discussion of the EEPROMs here that might be helpful:

http://gnuradio.org/redmine/wiki/gnuradio/UsrpFAQDBoards


--
Mark J. Blair, NF6X <nf6x@nf6x.net>
Web page: http://www.nf6x.net/
GnuPG public key available from my web page.

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

Re: [Discuss-gnuradio] Re: making a small USRP board

Right now I'm thinking the easiest thing would be to keep everything the same, except remove the 2nd mixed-signal chip, and move the power circuit off the board.
So, yes, same form factor for daughterboard connections.
-William


On Mon, Aug 30, 2010 at 11:14 AM, Mark J. Blair <nf6x@nf6x.net> wrote:

On Aug 30, 2010, at 6:52 AM, William Cox wrote:
> As of yet, I'm trying to figure out if reducing the size of the USRP1 baord, by removing one of the transceivers, is feasible. I'm a GNURadio/USRP newbie and I'm just going off looking at the pysical board and thinking I didn't need half of it.

Are you considering keeping the same form factor and connectors for the RF daughterboards (i.e., mounting regular RF daughterboards on a reduced-size USRP motherboard), or further shrinking the package size by integrating the RF and digital stuff onto a single, smaller board dedicated to a specific RF band?

--
Mark J. Blair, NF6X <nf6x@nf6x.net>
Web page: http://www.nf6x.net/
GnuPG public key available from my web page.





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

[Discuss-gnuradio] Warning in usrp_benchmark_usb.py

Hi everyone,
in testing the USRP I came across several warnings. Can someone tell me what they mean and if they are irrelevant?
Thanks in advance who will answer ...
-
Federico Battaglia


@ubuntu:/usr/share/gnuradio/examples/usrp$ ./usrp_benchmark_usb.py
Testing 2MB/sec... 
Warning: Treating daughterboard with invalid EEPROM contents as if it were a "Basic Tx."
Warning: This is almost certainly wrong...  Use appropriate burn-*-eeprom utility.


Warning: Treating daughterboard with invalid EEPROM contents as if it were a "Basic Rx."
Warning: This is almost certainly wrong...  Use appropriate burn-*-eeprom utility.

gr_vmcircbuf_createfilemapping: createfilemapping is not available
usb_throughput = 2M
ntotal    = 1000000
nright    = 997766
runlength = 997766
delta     = 2234
OK
Testing 4MB/sec... 
Warning: Treating daughterboard with invalid EEPROM contents as if it were a "Basic Tx."
Warning: This is almost certainly wrong...  Use appropriate burn-*-eeprom utility.


Warning: Treating daughterboard with invalid EEPROM contents as if it were a "Basic Rx."
Warning: This is almost certainly wrong...  Use appropriate burn-*-eeprom utility.

usb_throughput = 4M
ntotal    = 2000000
nright    = 1997113
runlength = 1997113
delta     = 2887
OK
Testing 8MB/sec... 
Warning: Treating daughterboard with invalid EEPROM contents as if it were a "Basic Tx."
Warning: This is almost certainly wrong...  Use appropriate burn-*-eeprom utility.


Warning: Treating daughterboard with invalid EEPROM contents as if it were a "Basic Rx."
Warning: This is almost certainly wrong...  Use appropriate burn-*-eeprom utility.

usb_throughput = 8M
ntotal    = 4000000
nright    = 3998755
runlength = 3998074
delta     = 1926
OK
Testing 16MB/sec... 
Warning: Treating daughterboard with invalid EEPROM contents as if it were a "Basic Tx."
Warning: This is almost certainly wrong...  Use appropriate burn-*-eeprom utility.


Warning: Treating daughterboard with invalid EEPROM contents as if it were a "Basic Rx."
Warning: This is almost certainly wrong...  Use appropriate burn-*-eeprom utility.

usb_throughput = 16M
ntotal    = 8000000
nright    = 7996694
runlength = 7996694
delta     = 3306
OK
Testing 32MB/sec... 
Warning: Treating daughterboard with invalid EEPROM contents as if it were a "Basic Tx."
Warning: This is almost certainly wrong...  Use appropriate burn-*-eeprom utility.


Warning: Treating daughterboard with invalid EEPROM contents as if it were a "Basic Rx."
Warning: This is almost certainly wrong...  Use appropriate burn-*-eeprom utility.

usb_throughput = 32M
ntotal    = 16000000
nright    = 15993798
runlength = 15992882
delta     = 7118
OK
Max USB/USRP throughput = 32MB/sec

Re: [Discuss-gnuradio] Re: making a small USRP board

On Aug 30, 2010, at 6:52 AM, William Cox wrote:
> As of yet, I'm trying to figure out if reducing the size of the USRP1 baord, by removing one of the transceivers, is feasible. I'm a GNURadio/USRP newbie and I'm just going off looking at the pysical board and thinking I didn't need half of it.

Are you considering keeping the same form factor and connectors for the RF daughterboards (i.e., mounting regular RF daughterboards on a reduced-size USRP motherboard), or further shrinking the package size by integrating the RF and digital stuff onto a single, smaller board dedicated to a specific RF band?

--
Mark J. Blair, NF6X <nf6x@nf6x.net>
Web page: http://www.nf6x.net/
GnuPG public key available from my web page.

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