On 1/16/07, Bob McGwier [EMAIL PROTECTED] wrote:
I understand the need and/or desire to do this natively but we really
want to be doing cross platform for this target. 256 MB is not enough
for these large compiles.
I've spent a little time trying to build GNU Radio for my EFIKA board
using
2006/11/23, David P. Reed [EMAIL PROTECTED]:
This seems to me to be clean and correct. It has the result that if
you are running a 32-bit version of python, you just leave lib64 out of
PYTHONPATH and the 64-bit-specific code will not be found first.
(Fedora should have a
Perhaps my prior posts have included too much information to get a
response, so I'll try trimming it way down.
I have a file of waveform data that I want to send to the DAC on the
USRP. Can it be done? How do I do it? What format does the data in the
file need to be in?
Any response would be
If I want to apply the output (50 ohm) from a function generator
directly to the BasicRX inputs, what is the allowed voltage range that
can be applied:
1) Without damaging anything?
2) Without exceeding the range of the ADC?
Surely this kind of stuff is documented someplace. But where? I can't
Hi guys,
Q1: When using USRP source_c (complex) with decimation == 8, am I
getting 4 million complex samples per second? 64Mhz / 8 = 8MHz floats =
4MHz complex
Q2: If I saved that data to a file and shared it with people, would I
advertise it as Complex data, 4 million samples per second?
Harold D. Skank wrote:
People,
I mis-stated my problem in my earlier posting. It's not the receive
message closing that I need to modify, but the transmit message closing.
Otherwise the posting was correct.
What do you mean by message closing?
Matt
Bahn William L Civ USAFA/DFCS wrote:
If I want to apply the output (50 ohm) from a function generator
directly to the BasicRX inputs, what is the allowed voltage range that
can be applied:
1) Without damaging anything?
3V pk-pk should be safe, since it won't exceed the 3.3V supply
Chris Stankevitz wrote:
Q1: When using USRP source_c (complex) with decimation == 8, am I
getting 4 million complex samples per second? 64Mhz / 8 = 8MHz floats
= 4MHz complex
No.
64 MS/s complex samples / 8 = 8 MS/s complex
Q2: If I saved that data to a file and shared it with people,
Thanks. Does this mean that the signals need to be DC offset so as never
to go below ground?
No, the transformer handles the biasing. You put in a signal that is +/-1V
Is there an offset, or is it 0V to 2V?
no
Is there someplace where this is documented?
probably. I think the
Also, gr.file_sink stores data native-Endian, so you may want to include
the Endian-ness in the description.
-Dan
Matt Ettus wrote:
Chris Stankevitz wrote:
Q1: When using USRP source_c (complex) with decimation == 8, am I
getting 4 million complex samples per second? 64Mhz / 8 = 8MHz
On Tue, Jan 16, 2007 at 10:03:40PM -0500, Eric A. Cottrell wrote:
Bob McGwier wrote:
I understand the need and/or desire to do this natively but we really
want to be doing cross platform for this target. 256 MB is not enough
for these large compiles.
DO NOT get on Terra's Yellow
Matt Ettus wrote:
Q1: When using USRP source_c (complex) with decimation == 8, am I
64 MS/s complex samples / 8 = 8 MS/s complex
Okay. That's certainly easy to remember. Does float act the same way?
I was under the impression you sacrifice something (samples per
second) when you move
On Wed, Jan 17, 2007 at 07:47:02AM -0500, Philip Balister wrote:
On 1/16/07, Bob McGwier [EMAIL PROTECTED] wrote:
I understand the need and/or desire to do this natively but we really
want to be doing cross platform for this target. 256 MB is not enough
for these large compiles.
I've spent
On Wed, Jan 17, 2007 at 01:57:30PM +0100, Trond Danielsen wrote:
2006/11/23, David P. Reed [EMAIL PROTECTED]:
This seems to me to be clean and correct. It has the result that if
you are running a 32-bit version of python, you just leave lib64 out of
PYTHONPATH and the 64-bit-specific code
I'm getting the same problem (as far as I can tell) on an Ubuntu
6.10machine. The build fails with undefined references in
libmblock.so and libmblock-qa.so.
--Illix
On 1/16/07, Eric Blossom [EMAIL PROTECTED] wrote:
On Tue, Jan 16, 2007 at 11:24:55AM -0500, Robert W McGwier wrote:
Those
On Wed, Jan 17, 2007 at 04:37:58PM -0700, Bahn William L Civ USAFA/DFCS wrote:
I have a function generator outputting a sine wave into the RX-B
connector of the BasicRX board connected to the RX-B side of a USRP. I
am trying to capture the waveform and store it to a file.
Here are the
On Wed, Jan 17, 2007 at 05:45:33PM -0500, Illix wrote:
I'm getting the same problem (as far as I can tell) on an Ubuntu
6.10machine. The build fails with undefined references in
libmblock.so and libmblock-qa.so.
OK, I've looked at the log file that Bob sent me and compared it to
what I see
Agreed
Eric Blossom wrote:
On Wed, Jan 17, 2007 at 05:45:33PM -0500, Illix wrote:
I'm getting the same problem (as far as I can tell) on an Ubuntu
6.10machine. The build fails with undefined references in
libmblock.so and libmblock-qa.so.
OK, I've looked at the log file that Bob
Robert McGwier wrote:
Agreed
Eric Blossom wrote:
On Wed, Jan 17, 2007 at 05:45:33PM -0500, Illix wrote:
I'm getting the same problem (as far as I can tell) on an Ubuntu
6.10machine. The build fails with undefined references in
libmblock.so and libmblock-qa.so.
OK, I've looked at
Hi, everone,
I am modifying some rfx2400 boards for clock sync and phase coherent with
motherboard. I found this was achieved already when I changed the location
of some resistors. I send some signals and received with the same board, the
received signal constellation is not rotating. So, I think
20 matches
Mail list logo
